Mit herkömmlichen Release-Zyklen lassen sich aktuelle Anforderungen nicht mehr abdecken. Die Softwareentwicklung muss schneller und kundennäher agieren. Das DevOps-Konzept ist zwar ein vielversprechender Ansatz, muss aber auch die Heterogenität unterschiedlicher Plattformen berücksichtigen. Im Mainframe-Umfeld lässt sich DevOps nicht ohne Modernisierung realisieren. [...]
Mit DevOps wird nun eine Integration von Software-Entwicklung und Software-Betrieb angestrebt. Dies ist zunächst keine technische Aufgabe, sondern eine organisatorische, ja sogar eine zum Teil psychologische Aufgabe: die vordem getrennten Teams von Software-Entwicklung und -Betrieb sollen eng zusammenarbeiten und eine gemeinsame – agile – Sichtweise entwickeln. Kurze Wege in der Abstimmung, gegenseitiges Vertrauen der Beteiligten und intensiver Austausch von Know-how sind die wichtigsten Faktoren. Die Teams werden dann auch gemessen an einem gemeinsamen Endergebnis, der funktionierenden Anwendung, die erst fertig ist, wenn sie eingesetzt wird. Im Grunde wendet DevOps die agilen Methoden auf den IT-Betrieb an und verzahnt damit diesen mit der Softwareentwicklung. Auf diese Weise werden Release-Zyklen verkürzt, die Anwendungsentwicklung wird aber auch flexibler und unterm Strich kostengünstiger.
Erst in einem weiteren Schritt ist DevOps auch eine technisch zu lösende Aufgabe, indem den Teams geeignete Werkzeuge zur Verfügung gestellt werden müssen, um agil zusammenzuarbeiten. Diese Werkzeuge, beispielsweise Puppet, Chef oder Rational Teamconcert, müssen dann auch eine weitgehende Automatisierung der Prozesse ermöglichen, um die Herstellung von Software insgesamt so effizient wie möglich zu gestalten, sie müssen also zur Release Automation weitergehen.
HERAUSFORDERUNG MODERNISIERUNG
Allerdings muss die Unternehmens-IT heute ja nicht nur Software-Ent wicklung und Software-Betrieb unter einen Hut bringen, sie hat – wie eingangs erwähnt – zugleich die Aufgabe, unterschiedliche Arten von Anwendungen beziehungsweise sogar unterschiedliche Arten von IT-Welten zu verbinden. Dies betrifft vor allem Unternehmen, die noch mit klassischer Mainframe-IT oder auch AS/400 beziehungsweise System i ausgestattet sind, und die diese aus vielerlei Gründen nicht einfach aufgeben können oder sollten – bewährte Applikationen, sehr große Workloads, sehr große Nutzerzahlen, höchste Anforderungen an Stabilität und Verfügbarkeit. In vielen Fällen wäre es einfach zu riskant und zu aufwändig, Kern-Anwen dungen auf offene Systeme zu portieren. Trotzdem muss die Software-Ent wicklung auch in solchen Landschaften schneller, flexibler und eben auch agiler werden, will sie nicht den Anschluss verlieren.
Die Modernisierung der Mainframe-Entwicklungslandschaft durch den Einsatz agiler Methoden und entsprechender Werkzeuge sichert vorhandenes Know-how, kann junge Entwickler aktivieren und motivieren, steigert aber auch die Qualität und ermöglicht Kostenersparnis durch Automatisierung. Re-Hosting, also die Portierung auch anderer Plattformen, ist in diesem Zusammenhang möglich, aber keineswegs zwingend, noch in jedem Fall sinnvoll – wie so eine Modernisierung in der Praxis aussehen kann, zeigt das Beispiel im Kasten.
Die Ausgangssituation ist bei der Modernisierung der herkömmlichen Entwicklungslandschaft vergleichbar mit der des DevOps-Konzepts: Die einzelnen Bereiche – in diesem Fall etablierte und agile Entwickler – kommunizieren nur unzureichend miteinander. Meistens stehen sich hier unterschiedliche Kulturen gegenüber: die Open-System-Fraktion hält den Mainframe und seine Verfahren für altes Zeug, während die Mainframe-Fraktion Open System für Micky-Mouse-IT ansieht. Ein zusätzliches Problem entsteht daraus, dass Mainframe-Experten meist ältere Mitarbeiter sind, die nach und nach aus den Unternehmen ausscheiden und nicht mehr ersetzt werden können, da jüngere Entwickler über kein Mainframe-Know-how mehr verfügen.
Be the first to comment