DevOps? Ein Ansatz zur Beschleunigung und Flexibilisierung der IT! (1/5)

In dieser fünfteiligen Artikelserie möchte ich die Prinzipien hinter DevOps genauer beleuchten. Mein Ziel ist es, ein grundlegendes Verständnis von DevOps zu schaffen, danach die einzelnen Faktoren zu diskutieren und schließlich ein Fazit zu ziehen. Hierbei möchte ich deutlich machen, dass sowohl die organisatorischen Veränderungen (Zusammenführen von Development und Operations) als auch die technischen Anpassungen umfassend und anspruchsvoll sind. Mit diesem ersten Artikel soll ein Basisverständnis der Herausforderungen innerhalb des Software-Lifecycle hergestellt werden, um in den nächsten Artikeln auf die einzelnen Prinzipien von DevOps im Detail einzugehen.

DevOps zur Optimierung des Software-Lifecycle

Kaum ein Versicherer hat sich in den letzten Jahren nicht der Digitalisierung verpflichtet. Im Fokus stehen hierbei in der Regel die Flexibilisierung und Beschleunigung in Richtung der (internen und externen) Kunden. Ein wichtiger Ausgangspunkt mit weiterhin hohem Potenzial ist dabei die IT. Sie steht in Zusammenarbeit mit den Fachbereichen seit jeher im Zentrum, wenn es darum geht, (kundenfreundliche) Lösungen umzusetzen und diese in kurzen Zyklen weiterzuentwickeln. Unter kurzen Zyklen sind hier jedoch nicht einige Wochen und Monate gemeint, sondern die Fähigkeit, neue Funktionen innerhalb weniger Tage zu designen und umzusetzen sowie diese anschließend automatisiert innerhalb von Minuten in die produktiven Umgebungen zu überführen und somit den Kunden zugänglich zu machen.

Als ein in Digitalunternehmen sehr verbreitetes Arbeitsmodell hat sich DevOps schon in vielen anspruchsvollen Situationen bewährt und Unternehmen dabei geholfen, die Qualität und Geschwindigkeit des Software-Lifecycle und somit auch gegenüber dem Kunden signifikant zu verbessern. Bei DevOps handelt es sich jedoch nicht nur um eine organisatorische Maßnahme, bei der Entwicklung (Dev) und IT-Betrieb (Ops) in interdisziplinären Lösungsteams zusammengeführt werden, sondern um einen umfassenden Ansatz, der Auswirkungen auf das komplette Operating Model der IT hat: Angefangen bei der Organisation und den Skills der Mitarbeitenden über die relevanten IT-Prozesse bis hin zur Anwendungslandschaft und Infrastruktur.

Theory of Constraints als zentrale Grundlage

Zum besseren Verständnis von DevOps will ich kurz auf dessen Ursprünge zurückschauen. Diese finden sich zum größten Teil im Lean Manufacturing. So unterstellt DevOps, dass es nur marginale Unterschiede zwischen einer Produktionsstraße und dem Software-Lifecycle-Prozess gibt. Ein grundlegender Ansatz, der hierbei zum Tragen kommt, ist die Theory of Constraints. Diese besagt, dass der Durchsatz in einem System – oder in unserem Fall die Durchlaufzeit einer Änderung von der Anforderungsdefinition bis zur Produktivsetzung – ausschließlich von einem begrenzenden Faktor bzw. einem Engpass bestimmt wird. Sämtliche Optimierungen vor dem Engpass führen nur dazu, dass sich noch mehr Arbeit vor dem Engpass staut, während sämtliche Optimierungen nach dem Engpass dazu führen, dass die entsprechenden Folgestationen nicht ausgelastet werden. Engpässe sind dabei systemimmanent: Sobald ein Engpass aufgelöst wird, muss an anderer Stelle ein neuer entstehen. Es beginnt ein ewiger Verbesserungskreislauf.

Um die einzelnen Elemente von DevOps verständlicher zu machen, gehe ich im Folgenden auf typische Ursachen für Engpässe innerhalb des Software-Lifecycle-Prozesses ein. Dabei orientiere ich mich an dessen („Produktions“-)Schritten:

• Anforderungsdefinition: Anforderungen werden in der Anwendungsentwicklung so umgesetzt, wie die Entwicklung es „verstanden“ bzw. aus dem Fachkonzept „interpretiert“ hat. In einem sequenziellen Vorgehen hat der Fachbereich erst wieder im Test die Möglichkeit festzustellen, ob Anforderungen ggf. am Ziel vorbei umgesetzt wurden. Dies führt insbesondere bei größeren Anforderungen durch zusätzliche Schleifen zu deutlichen Verzögerungen und Engpasssituationen.
• Entwicklung: Die Entwicklung muss ihren Code kompilieren und diesen auf eine Testumgebung überführen. Häufig kommt es bei der (kurzfristigen) Anforderung bzw. Bereitstellung von Testumgebungen im IT-Betrieb zu Verzögerungen, oder die Entwicklung nimmt einfach ihr bekannte (alte) Testumgebung, die ggf. in ihrer Konfiguration nicht mehr die Produktionsumgebung angemessen widerspiegelt. In diesem Fall können konfigurationsbedingte Probleme beim Deployment in Produktion zu signifikanten Verzögerungen führen.
• Test: Sofern die umgesetzte Anforderung nicht ausreichend durch die Entwicklung vorgetestet wurde – beispielsweise durch automatische Unit-Tests während der Entwicklung oder Smoke-Tests nach dem Deployment –, treten im Test durch den Fachbereich häufig noch vermeidbare (technische) Fehler auf. Dies führt zu erneuten Korrekturschleifen und zeitlichen Verzögerungen. Bei größeren Änderungen sind zudem noch weitere Teststufen wie umfassende Integrationstests vorgesehen, die oftmals nur im Zusammenhang mit Releases alle paar Monate durchgeführt werden. Auch dies führt dazu, dass Änderungen nicht zeitnah in die Produktion überführt werden können, sondern sich in den übergeordneten Release-Takt einordnen müssen.
• Produktivsetzung: Mit dem finalen Deployment werden die Änderungen von den vorgelagerten Umgebungen durch den IT-Betrieb in die Produktionsumgebungen übertragen. Dies führt häufig aufgrund unterschiedlicher Konfigurationen zwischen Produktion und vorgelagerten Umgebungen zu Problemen im Rahmen der Produktivsetzung, welche dann zumeist ad hoc zu analysieren und zu beheben sind. Nicht selten kommt es vor, dass durch den IT-Betrieb keine abschließende Analyse möglich ist und die Entwicklung hinzugezogen werden muss. Im schlimmsten Fall ist die Produktivsetzung abzubrechen und die Produktion zurückzusetzen.

Zentrale Herausforderungen im Software-Lifecycle-Prozess

Die vorangegangene Aufzählung, die sicherlich nicht abschließend ist, möchte ich nutzen, um drei zentrale Probleme sichtbar zu machen:

1. Organisation: Die organisatorische Trennung zwischen Fachbereich, Anwendungsentwicklung und IT-Betrieb sowie fehlende frühzeitige Feedbackschleifen zwischen den Bereichen können zu Nacharbeiten und deutlichen Verzögerungen führen. Hier gilt die alte Weisheit: Ein Fehler wird umso teurer, je später er entdeckt wird. Bestehende Trennungen zwischen den einzelnen Bereichen sind daher aufzulösen und diese stattdessen in Form interdisziplinärer Teams zu organisieren.
2. Prozesse: Manuelle Prozesse insbesondere bei Build, Test und Deployment können zu (menschlichen) Fehlern führen. Weiterhin gibt es häufig für jede eingesetzte Technologie spezielle Expertinnen und Experten, die in der Organisation besonders gefragt sind und schnell zur Engpassressource werden. Daher lohnt die Kodifizierung dieses Expertenwissens in Form von automatisierten Prozessen wie z. B. Continuous Integration und Continuous Deployment.
3. Anwendungslandschaft: Starke Abhängigkeiten in der IT-Landschaft erhöhen die Komplexität und das Risiko von Änderungen. Aus diesem Grund werden bei größeren Änderungen verpflichtende Integrationstests vorgeschaltet, um Seiteneffekte ausschließen zu können. Diese Integrationstests sind jedoch mit einem hohen Aufwand verbunden und finden daher zumeist nur im Vorfeld großer Releases statt. An dieser Stelle ist somit die Architektur unser Engpass, die es verhindert, dass wir umgesetzte Anforderungen direkt unseren Kunden zugänglich machen können.

Mit der Auflistung der zentralen Herausforderungen und ersten Ausblicken zu möglichen Lösungsansätzen möchte ich diesen Artikel abschließen. Ich hoffe, die enormen Verbesserungspotenzial im Software-Lifecycle-Prozess, aber auch die Tragweite einer DevOps-Umsetzung sind schon ansatzweise deutlich geworden. Im nächsten Artikel wird es dann im Detail um die organisatorischen Stellhebel von DevOps gehen.