Wie die Elefanten tanzen lernen
Die Vorstellung, einen Elefanten dabei zu beobachten, wie er voller Anmut, flink, schnell und agil das Tanzbein in der Savanne schwingt, ist zugegebenermaßen ebenso so skurril wie absurd. Dieses Bild assoziiert man dann doch wohl eher mit dem der graziösen Antilope. Bei den gutmütigen und trägen Dickhäutern sind wir wohl eher geneigt, diese als starke, respekteinflößende und sogar manchmal – wie im Buddhismus –heilige Tiere zu betrachten. Aber wer sagt, dass Elefanten nicht auch tanzen können und was hat das Ganze mit der IT zu tun?
Um mit der rasanten Veränderung des Kundenverhaltens durch die wachsenden Online Angebote mithalten zu können, müssen Unternehmen neue Funktionalitäten in immer kürzerer Zeit auf einer ebenso wachsenden Anzahl von Endgeräten einer breiten Masse verschiedener Benutzerprofilen zur Verfügung stellen. Im Zuge dieser Entwicklung mit seiner wachsenden Anforderung an Flexibilität und „Time to Market“ sind in den Unternehmen neben den traditionellen Entwicklergruppen für Mainframe und verteilte Anwendungen, neue Teams für die Erstellung von Webanwendungen und modernen Applikationen für mobile Endgeräte entstanden. Diese Teams nutzen meist unterschiedliche Prozesse, Vorgehensweisen und Tools für das Softwareerstellungs- und
-freigabeverfahren in ihrem jeweiligen Bereich. Und das obwohl oft eine starke Abhängigkeit zwischen eigentlichen Geschäftsanwendungen auf dem Mainframe, auch „Systems of Record“ genannt, und den Client Anwendungen, auch „Systems of Engagement“ genannt, die auf diese Geschäftsfunktionen zugreifen, besteht. Klassisches Silodenken sowohl innerhalb der Teams als auch über Bereiche hinweg besteht häufig fort, und unterschiedliche Sichtweisen und Kulturen der einzelnen Bereiche bremsen daher die Implementierung der Geschäftsanforderungen von der Anwendungsentwicklung bis hin zur Auslieferung in Produktion. So hält die Open-System-Fraktion vielleicht den Mainframe und seine etablierten Verfahren für überholt, während die Mainframe-Fraktion die Vorgehensweise auf den offenen Systemen oft als unstrukturiert und riskant wahrnimmt. Die hippen Java App-Entwickler arbeiten einfach, agil drauf los, nutzen Methoden wie Scrum oder Kanban und setzen dafür moderne Tools mit intuitiven Dashboards für eine integrierte Planung und Kontrolle der Aktivitäten von der Idee über die Umsetzung bis zur Produktion ein, während die Cobol und Mainframe Entwickler noch immer gemäß des Wasserfall-Modells arbeiten, bei dem die Softwareentwicklung in Phasen organisiert ist und die Planungs- und Kontrollaufgaben vielfach mit herkömmlichen Mittel wie Excel oder Word verwaltet werden. Das Wasserfall-Modell hat durchaus seine Berechtigung, denn häufig unterliegen Mainframe Applikationen, insbesondere im Finanzsektor, strengen Regulierungen, und sind außerdem über die Jahre in einer Architektur entwickelt worden, die schnelle Änderungen und produktiven Einsatz nicht zulassen. Zudem sind die Werkzeuge, die auf dem Mainframe für die Verwaltung und Konfiguration der Anwendungen verwendet werden, größtenteils für den kompletten agilen bzw. DevOps Ansatz nicht geeignet. Die geschäftskritischen Anwendungen wurden über Jahre hinweg programmiert, beinhalten die für den Wettbewerb entscheidende Geschäftslogik und eine Fehlfunktion oder gar ein Ausfall des Systems kann schwerwiegende betriebswirtschaftliche Folgen nach sich ziehen. Auch eine vollständige Migration der gesamten Geschäftslogik ist in vielen Fällen zu riskant, extrem kostspielig und vor allem viel zu aufwändig, so dass Unternehmen zu recht weiter auf ihre „Legacy-Systeme“ setzen.
Der Wasserfall verschwimmt mit den agilen Prozessen – warum der Mainframe von DevOps profitieren kann
Die große Herausforderung ist die Prozesse auf dem Mainframe für den Einsatz neuer Funktionen zu beschleunigen und die Qualität zu verbessern. Ziel ist es auch die Bereitstellung geschäftskritischer Funktionen über verschiedenen Plattformen hinweg zu synchronisieren, zum Beispiel Java-Applikationen die auf Cobol Anwendungen auf dem Mainframe zugreifen. Eine DevOps Initiative bietet gerade Unternehmen, die IT-Systeme und Plattformen verschiedener Generationen nutzen, hier durchaus Chancen. So kann eine plattformübergreifende Integration von Standardwerkzeugen, beispielsweise für flexibles- und skalierbares automatisiertes Testen dabei helfen, defekten Code frühestmöglich während der Softwareentwicklung zu erkennen, dadurch Kosten zu senken und die Komplexität zu verbessern. Man spricht in diesem Zusammenhang auch vom „shift left testing“. Doch ein Wechsel von bislang linearen, iterativen hin zu dynamischen und flexiblen Prozessen lässt sich nicht mit dem Umlegen eines Schalters vergleichen. Nur moderne Werkzeuge wie etwa Eclipse als Ersatz für TSO/ISPF zu verwenden, reicht nicht aus. Vielmehr geht es darum, die Werkzeuge so zu integrieren, dass Prozesse plattformübergreifend verwendet werden können. DevOps beschreibt keine Komplettlösung und es gibt auch kein allgemeingültiges Maturity-Model, auf das man zurückgreifen könnte. DevOps steht für ein breitgefächertes Set an Disziplinen und Vorgehensweisen, die das Zusammenspiel zwischen Menschen, Technologie und Prozessen von der Idee über die Entwicklung und Test bis zum produktiven Einsatz optimiert. Jedes Unternehmen muss zunächst für sich selbst erkennen, welche Abläufe dafür verändert werden müssen, und welche Werkzeuge dabei unterstützen können, um eine solche Verbesserung zu erreichen. DevOps Prinzipien helfen die Barrieren zwischen den einzelnen Schritten der klassischen Softwareentwicklung ( Plan – Build – Test – Release ) aufzubrechen und einen „continuous workflow“ zu erzielen.