Von heute auf morgen lässt sich die Implementierung von DevOps, also die enge Verzahnung von Application Development und IT Operations, nicht umsetzen. Der Prozess ist komplex und geht weit über die Einführung agiler Vorgehensweisen in der Softwareentwicklung hinaus. [...]
Voraussetzung für das Gelingen von DevOps sind das Aufbrechen von Silos zwischen einzelnen Teams sowie das Etablieren einer Kultur der Zusammenarbeit. Aber wie sollten Unternehmen dieses Unterfangen angehen, welche Herausforderungen organisatorischer und technischer Art gilt es zu meistern? Im Interview dazu Martin Luckow, der bei Trivadis neben Application Development alle Themen zu agilen Projekten sowie Digitalisierung verantwortet.
Wie ist der aktuelle Stand von Unternehmen in puncto DevOps nach den Erfahrungen von Trivadis?
DevOps, ist in den meisten Organisationen ein Thema, aber noch nicht richtig angekommen. Das zeigen nicht nur unsere Erfahrungen, sondern wird auch von anderen bestätigt, beispielsweise auf Branchenkonferenzen wie der DevOpsCon. In vielen Unternehmen hat sich an der grundsätzlichen Ausrichtung der Organisation trotz Umstrukturierungen und Digitalisierungsprojekten nichts geändert: Business, Application Development und Operations sind Bereiche mit unterschiedlichen Zielen. Fachabteilungen und Entwicklung möchten manchmal am laufenden Band neue Features ausliefern, wohingegen die für den reibungslosen Betrieb im Tagesgeschäft verantwortlichen Mitarbeiter eher konservativ handeln müssen, denn ihr Job ist es, für einen reibungslosen, stabilen Betrieb zu sorgen. Daher hat sich in den meisten Unternehmen die Trennung zwischen Entwicklung und Betrieb etabliert. Dazwischen gibt es – hoffentlich – ein Quality Gateway, das Features intensiv testet und erst danach in Ops übernimmt. Mir sind Quality Assurance Abteilungen bekannt, die haben so lange Warteschlangen bei ihren Multiprojekten, dass Releasezyklen von einem Jahr keine Seltenheit sind. Das sind Verfahren, die nicht mehr zeitgemäß sind: Besonders im B2C-Umfeld warten Enduser nicht, bis ein neues Feature verfügbar ist, sondern klicken einfach zur Konkurrenz, die das schon kann.
Was hindert Unternehmen daran, schnell auf DevOps umzuschwenken, um konkurrenzfähig zu bleiben?
Um aus dem vermeintlichen Gegeneinander von Application Development und Operations ein Miteinander zu schaffen, müssen etablierte Organisationsstrukturen aufgebrochen werden. Darin liegt die eigentliche Herausforderung. Diese Strukturen sind teilweise 20 Jahre und älter; manchmal haben Mitarbeiter sich in Komfortzonen eingerichtet, die sie nur widerwillig aufgeben. Nicht zuletzt sind die betroffenen Mitarbeiter ebenfalls mit den Strukturen älter geworden, was es oft noch schwerer macht, neues Denken und neue Prozesse einzuführen. Ich sage das ungern, aber die tägliche Praxis zeigt es leider. Dabei müssen die Beteiligten bei Dev und Ops verstehen, dass die Welt sich verändert hat. Wer lange Release-Zyklen in der heutigen Welt zulässt, läuft Gefahr, dass Features schon bei der Veröffentlichung veraltet sind. Wieder wird dies vor allem im B2C-Umfeld zum Problem: seit Jahren sind dies beispielsweise Webseiten, die nicht für den mobilen Zugriff optimiert sind — einfach nur abschreckend für Endverbraucher und oft ein Grund schnell zur Konkurrenz zu wechseln. Diese Langsamkeit bei der Modernisierung hat messbare monetäre Nachteile. Organisationen müssen daher schneller werden, ohne die Qualität aus den Augen zu verlieren. Qualität schließt dabei Schutz und Sicherheit mit ein, weshalb wir bei Trivadis auch gerne von DevSecOps sprechen, um die Integration der Sicherheitsaspekte in DevOps zu betonen.
Was sind die technischen Herausforderungen?
Vor allem auf Entwicklerseite sehen wir kaum technische Herausforderungen. Application Developer wurden in 1990er Jahren von der agilen Szene quasi indoktriniert. Das heißt, sie beherrschen Methoden, mit denen sie auf sehr kurze Iterationszeiten eingestellt sind. Das kann man als eine Vorstufe von DevOps bezeichnen; allerdings hat gefehlt, dass die Ergebnisse zeitnah in Produktion gehen. Mit Scrum etwa hat man gelernt, neue Features im Monats- oder manchmal sogar 14-Tage-Takt bereitzustellen. Im Zeitalter der Digitalisierung ist sogar ein Monat manchmal zu lang. Wer allerdings kürzere Iterationszeiten fordert, läuft Gefahr, einen administrativen Wasserkopf zu schaffen, denn es gibt keinen linearen Zusammenhang zwischen kurzen Iterationszeiten und dem administrativen Aufwand dafür – insbesondere die Kommunikation. Sprints sollten deshalb gewisse Zeiten nicht unterschreiten… oder anders: je nach Szenario ist Scrum für DevOps zu langsam.
Was ist notwendig, um DevOps umzusetzen?
Wer es mit DevOps ernst meint, muss mit fertigen Features schnellstmöglich nach draußen gehen und seine Organisation genau darauf abstimmen. Grundlage für DevOps ist, dass Organisationen, also Entwicklung und Betrieb, in Features statt in Iterationen denken. Wer im B2C-Geschäft Kunden halten will, muss sehr schnell sein. Im B2B-Umfeld ist die Geschwindigkeit oft nicht ganz so hoch, weil die Organisationen langsamer in der Adaption neuer Features sind, aber auch hier nimmt sie zu. Im E2E-Umfeld wird die Notwendigkeit einer hohen Geschwindigkeit oft unterschätzt. Doch kann sogar dabei helfen, neue, junge Mitarbeiter zu gewinnen. Viele Unternehmen können mit alten Lösungen und Prozessen keine jungen Mitarbeiter begeistern. Wenn Berufseinsteiger heute erkennen, dass in Unternehmen noch viel Papier umgeschlagen wird, der Einsatz moderner Arbeitsmittel, wie Handys, die Seltenheit ist, und das Ganze eher starr und unflexibel ist, suchen sie sich oft lieber einen moderner denkenden Arbeitgeber.
Wer sollte das organisieren?
Oft sieht man, dass der Impuls aus der Entwicklung und dem IT-Betrieb kommt. Häufig auch nur aus der Entwicklung. Doch man muss ganz klar sagen: DevOps, Entwicklung, Betrieb usw. sind nur Mittel zum Zweck. Und der ist die Wertschöpfung durch die gesamte Organisation. Aus diesem Grund sollten Bottom-Up-Initiativen positiv aufgenommen, gemanaged und die positiven Effekte mitgenommen werden. Doch die Transformation muss von oben gesponsert, angeführt, geleitet und begleitet werden. Hier gilt es, diplomatisch und sensibel vorzugehen, denn es müssen dabei Kompetenzen verschoben werden und Grabenkämpfe zwischen den betroffenen Bereichen dürfen gar nicht erst beginnen. Das Anpassen der Dev- und Ops-Strukturen ist organisatorisches Handwerk, das sollte das Management beherrschen.
Wichtig ist, dass sich Dev und Ops bewusst sind, dass es mit seiner gemeinsamen Lösung Business Value generiert und sich alles diesem Ziel unterordnet – dieses Denken ist nicht überall anzutreffen. Es sind keine Fünfjahrespläne mehr gefragt. Was im Business als vorteilhaft erkannt wird, dann in Dev umgesetzt wird, muss so schnell wie möglich in Ops wieder herauskommen. Auch das zeigt, dass der Umbau von Organisationen viel weiter gehen muss, als lediglich Dev und Ops zusammenzulegen. Das genügt einfach nicht.
Stichwort Umbau von Organisationen, was kann Trivadis als IT-Dienstleister hier überhaupt beisteuern?
Trivadis hat sich in seiner 25-jährigen Geschichte einen Namen in der Anwendungsentwicklung, als Infrastrukturdienstleister, etwa für Datenbanken, Cloud und natürlich Betrieb gemacht. Die DevOps-Themen und die technische Seite der Digitalisierung beherrschen wir also von Beginn an. Es ist aber wichtig zu verstehen, auch für uns, dass Technologie kein Selbstzweck und kein Allheilmittel gegen organisatorische Schwächen in Unternehmen ist. Seit Jahren liegt unser Fokus daher auch auf prozessualen und organisatorischen Themen, die damit einhergehen.
Wie helfen Sie jemanden, der nun auf sie zukommt und fragt, was er tun kann, um DevOps in sein Unternehmen zu bringen?
Erfahrungsgemäß leiden die Fachbereiche am meisten, denn auf ihnen lastet die Verantwortung, Umsätze zu machen und die Ergebnisse zu steigern. Auf den „nachgelagerten“ Bereichen liegt weniger Druck, sie werden meist nicht direkt an Umsätzen gemessen. Die Gefahr ist es nun in verkrusteten Organisationen, dass Fachbereiche eine Schatten-IT aufbauen, um ihre Schmerzen punktuell zu verringern. Ich sage den Leuten aus den Fachbereichen, die zu mir kommen: ‚Klar können wir deine Probleme durch DevOps lösen, damit bekommst du sehr schnell die Features, die du brauchst und zwar laufend.‘ Wichtig ist aber auch, dass die ‚Lösungskette‘ stimmt. Daher muss eine solche Anfrage auch in das Senior-Management getragen werden. Dort muss die Überzeugung erzeugt werden, dass es sich unbedingt lohnt, aber auch dass sich um nicht nur um eine technische, sondern auch um eine organisatorische Herausforderung handelt.
Be the first to comment