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. [...]
In den letzten Jahren hat sich die Softwareentwicklung erheblich verändert und jahrzehntelang bewährte Verfahren und Gepflogenheiten wurden dabei in Frage gestellt oder neu bewertet. Ausgangspunkt dafür waren neue Anforderungen, die vor allem mit dem Entstehen neuer Anwendungsszenarien im Umfeld des Webs und der mittlerweile allgegenwärtigen mobilen Systeme entstanden sind. Diese Entwicklungen haben die Unternehmens-IT mit einer stetig wachsenden Zahl unterschiedlicher technischer Systeme konfrontiert, die alle in ein und demselben Unternehmen nicht nur nebeneinander, sondern auch miteinander arbeiten sollen: Mainframe, klassische Client-Server, Cloud Computing und natürlich eine Menge von Apps für Smartphones und Tablets. Diese Systeme unterscheiden sich ja nicht nur im Aussehen erheblich, sie orientieren sich auch hinsichtlich der Software-Entwicklung an Paradigmen, die erst mal nicht zueinander passen.
Die andere große Herausforderung ist, dass Unternehmen heute ihre Applikationen beziehungsweise deren Änderungen sehr schnell benötigen. Herkömmliche Release-Zyklen von sechs oder zwölf Monaten, wie sie nicht nur in der Mainframe-Entwicklung üblich waren, sind im Web und bei mobilen Anwendungen nicht darstellbar. Die so genannten digitalen Unternehmen aus dem E-Commerce oder den Sozialen Medien, die hier die Maßstäbe setzen, bringen schon mal bis zu zehn neue Releases am Tag heraus. Zum Teil beruhen sogar deren Geschäftsmodelle auf dem Konzept der Continuous Delivery, also auf der laufenden Bereitstellung neuer Software-Versionen, um aktuellen Veränderungen der Anforderungen quasi in Echtzeit folgen zu können. Mit den herkömmlichen Verfahren der Software-Entwicklung ist dergleichen natürlich nicht zu realisieren.
AGILE METHODEN: MODELL MIT STRAHLKRAFT
Zur Beschleunigung der Entwicklungsprozesse werden schon seit längerem immer wieder neue Verfahren und Ansätze ausprobiert. In den letzten Jahren haben sich besonders die agilen Methoden etabliert, wobei in kleinen Teams – in so genannten Sprints – ohne aufwändige Spezifikation oder Regelwerke kurzfristig lauffähige Versionen erstellt werden. Auf diese Weise kann Software schneller und flexibler produziert werden, und die Praxis hat gezeigt, dass diese Anwendungen nicht schlechter oder fehlerhafter sind, als solche, die nach herkömmlichen Vorgehensmodellen entstanden sind.
Als Problem bei der Umsetzung dieses Konzepts erwies sich jedoch, dass für die Bereitstellung der Software für den Produktivbetrieb – Delivery – keine entsprechenden, also ebenfalls agilen Prozesse vorgesehen waren. Der Softwarebetrieb erwies sich als Engpass für Continuous Delivery. Seine wichtigen Parameter sind Stabilität und Performance, die sich zunächst einmal nicht mit agilen Konzepten, beispielsweise mit täglichen Release-Wechseln, vertragen. Andererseits sind diese Parameter nicht einfach obsolet geworden, weil alles schneller verfügbar sein muss. Tägliche Release-Wechsel mit instabilen, nicht performanten Versionen braucht niemand.
Dev und Ops sind die zwei gegenüberliegenden Waagschalen einer Balkenwaage. Obwohl sie in der Balance sein sollten, gewinnt häufig die Entwicklung die Oberhand. Das ist gut um tolle Applikationen zu generieren, aber wenn es um Performance und Stabilität geht, ist es nicht gut, den Betrieb zu vernachlässigen.
Be the first to comment