Mittlerweile gibt es viele Methoden, die Digitalisierung in den Unternehmen voranzutreiben. DevOps ist eine davon. Zusammengesetzt aus den Begriffen Development und Operations, soll die Verschmelzung von Entwicklung und Betrieb ein Schlüssel dazu sein, künftig kürzere Software-Release-Zyklen umsetzen zu können. Wie wichtig es ist, möglichst schnell und effizient eine gut funktionierende Software auf den Markt zu bringen und ebenso schnell auf Änderungswünsche von Kunden reagieren zu können, zeigen die zahlreichen neuen, meist serviceorientierten Geschäftsmodelle, die durch Digitalisierung überhaupt erst möglich sind. Legacy-getriebene Systeme sind hier einem besonders hohen Druck ausgesetzt, da durch die langen Release-Zyklen der Abstand zum Business zu groß wird, um mit den Wettbewerbern mithalten zu können. Geschwindigkeit und der Zugriff auf Daten sind aus dieser Perspektive heutzutage ein Muss, wenn man nicht vom Fortschritt überholt werden will.
Foto: whiteMocca - shutterstock.com
Informationen zu den Partner-Paketen der DevOps Studie
Doch es gibt auch einen anderen Blickwinkel, aus dem heraus Geschwindigkeit allein nicht alles ist: Es entstehen immer mehr Business-Modelle, die in klassischen Architekturen nicht mehr bedient werden können. Auch gesetzliche Rahmenbedingungen machen einen Eingriff in ein existierendes Kernsystem notwendig. Natürlich müssen diese Anpassungen innerhalb eines bestimmten Zeitraums erfolgen, doch dabei nur auf Geschwindigkeit zu setzen, wäre fatal. Die Umsetzung muss effizient, nachhaltig und vor allem funktionsfähig sein. Das trifft insbesondere dann zu, wenn mit DevOps Legacy-Systeme modernisiert werden sollen. Und dann gibt es natürlich noch Branchen wie etwa den Flugzeugbau, in denen die Sicherheit oberste Priorität hat.
Agilität und Geschwindigkeit auf der einen Seite, Sicherheit und Stabilität auf der anderen: Um beides in Balance zu bringen, braucht es die Zusammenarbeit von Entwicklung und Betrieb. DevOps hier als Mittel zum Zweck zu sehen, funktioniert aber nur, wenn dieser auch bekannt ist. Erst wenn die Zielsetzung klar ist und der Mehrwert definiert ist, kann die Entscheidung für oder gegen DevOps getroffen werden.
Die Herausforderung liegt nicht in der Technik
Dass sich ein Mehrwert für ein Unternehmen nicht zwangsläufig aus einem neuen, digitalen Geschäftsmodell ergibt, zeigt sich an einem Beispiel aus dem Mainframe-Umfeld. Das Wissen vieler Unternehmen steckt in den Mainframe-Systemen. Teilweise sind sie 30 Jahre und älter, aber sie stellen nach wie vor den Kern des Geschäfts dar - und das Know-how aus mehreren Jahrzehnten ist nirgendwo dokumentiert. Um Transparenz für die Anwendung zu schaffen und die Entwicklungsumgebung zu modernisieren, benötigt man gemischte Teams aus erfahrenen Leuten, Experten für spezielle Themen mittleren Alters und junge Leuten mit frischen Ideen. Letztere dahingehend zu motivieren, bestehende Mainframe-Systeme zu modernisieren, weiterzuentwickeln und nicht komplett abzulösen, dafür scheint DevOps ein geeigneter Weg zu sein - gäbe es da nicht einen gern übersehenen Haken: DevOps fängt nicht bei einem Softwareprodukt an, sondern es ist eine Kultur, die sich erst entwickeln muss.
DevOps ist zu 90 Prozent kein technologisches Thema. Deshalb liegt die Herausforderung auch nicht in den Tools, sondern im klassischen Konflikt zwischen Devs und Ops, der im Mindset über Jahrzehnte gewachsen ist. Noch immer sprechen Entwickler eine völlig andere Sprache als traditionelle "Betriebler". Und als wäre es nicht schon kompliziert genug, trotz Kommunikationsschwierigkeiten das Gute aus beiden Welten zusammenzubringen, kam durch die zwischenzeitliche Begriffserweiterung zu BizDevOps - hier werden das Business und die Fachabteilungen miteinbezogen - eine dritte Fremdsprache hinzu. Nicht selten führt die vermeintliche Kenntnis darüber, was Anwendungsentwicklung und Betrieb machen und das Business tatsächlich will, zu vielen Missverständnissen und somit zum Scheitern von DevOps-Projekten. Eine konsequent Workshop-getriebene Herangehensweise dauert hier sicherlich länger, doch nur mit einer schrittweisen Analyse lässt sich herausfinden, wie die Prozesse aussehen, wie sie von Werkzeugen unterstützt werden und wo das Optimierungspotenzial liegt.
Die Zusammenarbeit dieser drei Bereiche, die als Kultur auch gelebt werden muss, organisatorisch auf die Beine zu stellen ist also eine echte Herausforderung. Vor allem, weil sie den Wandel von einer projekt- hin zu einer produktorientierten Organisation nach sich zieht. Und die ist kein IT-Thema, sondern greift in Führungsstrukturen ein. Wer sich für DevOps entscheidet, muss bereit sein, Hierarchien aufzubrechen, denn der frühere Manager hat als künftiger Product Owner keine Führungs- und Personalverantwortung mehr. Bei der Einführung von DevOps ebenfalls zu beachten ist, dass es dafür kein Patentrezept gibt. So kann es durchaus sein, dass kleinere Pilotprojekte funktionieren, sich aber nicht in die bestehende Infrastruktur integrieren lassen, da die übrigen Prozesse nicht dazu passen. Von daher ist es wichtig, auch eine Fehlerkultur zu akzeptieren und Mechanismen aus der Erkenntnis abzuleiten, dass es in der Vergangenheit nicht funktioniert hat und warum.
DevOps-Erfolg - nur eine Frage der Definition?
Dass sich die DevOps-Kultur erst noch entwickeln muss, darüber waren sich die Diskussionsteilnehmer einig. Worin liegt also der Unterschied zwischen den bereits erfolgreich umgesetzten Projekten und den gescheiterten? Die Antwort ist einfach: in der Definition von DevOps. Und diesbezüglich gingen die Meinungen zum Teil sehr weit auseinander. Die einen fassen DevOps als Team auf. Darin ist jeder grundsätzlich befähigt, alle notwendigen Aufgaben zur Weiterentwicklung des Produkts, für das man zuständig ist, zu übernehmen. Getreu dem Prinzip "You built it, you run it" muss also der Entwickler seiner Verantwortung nachkommen und auch den Betrieb mit übernehmen.
Informationen zu den Partner-Paketen der DevOps Studie
Für andere ist diese Auffassung realitätsfremd, denn es gibt keinen, der alles kann. Aus diesem Grund kann DevOps auch als Organisationsform gesehen werden, in der Leute aus Entwicklung und Betrieb zusammengebracht werden, ohne dass dadurch ein Entwickler gleich zum "Betriebler" werden muss. Der Begriff DevOps muss auch nicht zwangsläufig mit Personen assoziiert werden, wie eine andere Definition zeigt: DevOps ist eine Kultur, ein Prozess oder ein Vorgehen, das die Zusammenarbeit in der Kommunikation von Entwicklern, Ingenieuren und anderen IT-Experten betont und gleichzeitig den Prozess der Softwarebereitstellung und Infrastrukturänderungen automatisiert. Es zielt darauf ab, eine Kultur und ein Umfeld zu schaffen, in dem die Entwicklung, das Testen und die Freigabe von neuen Funktionen schnell, kontinuierlich und zuverlässig erfolgen können.
Zeitdruck auf Anwenderseite wird immer größer
Auch wenn die Anhänger der Teamdefinition diese Auslegung als blanke Projektarbeit bezeichnen, so verfolgen beide Ansätze immerhin dasselbe Ziel. Und auch darüber lässt sich DevOps definieren: DevOps ist eine essentielle Unternehmensfähigkeit für die kontinuierliche Bereitstellung softwarebasierter Innovationen, die es Unternehmen ermöglichen, Marktchancen zu ergreifen und schneller auf Kunden-Feedback reagieren zu können. Wie man diese Fähigkeit erlangt, ist demnach sekundär, wichtig ist, dass man sie hat.
Und genau dieses heterogene Verständnis und die individuelle Herangehensweise liegen auch bei den Kunden vor, was es umso schwieriger macht, sie zurzeit von DevOps zu überzeugen. Hinzu kommt, dass der Zeitdruck, das Ziel zu erreichen, für die Kunden immer größer wird. Welcher von Definition und Verständnis unabhängige Weg führt nun zur gemeinsamen Schnittmenge? Es ist die Kultur-Spur, die erst noch gelegt werden muss.