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.
- Bernd Wachter, Capgemini
„DevOps ist einer der zentralen Bausteine, um Software schneller releasen zu können, Agilität, DevOps und Cloud werden in Summe die IT-Landschaft so verändern, wie sie in den vergangenen Jahren nicht verändert worden ist. Die Kunst dabei ist, die Transformation vom projekt- zu einer produktorientierten Organisation aktiv zu gestalten. Und das ist kein rein technologisches Thema, sondern ein primär kulturelles, das bis in die Führungsebenen hineinreicht und oft unterschätzt wird. Deshalb scheitert die erfolgreiche Umsetzung von DevOps derzeit noch bei vielen Unternehmen in Deutschland.“ - Mark Aichholz, IBM
„Es ist wichtig, die Brücke zwischen Business und IT zu schlagen. Ein probates Mittel dafür ist, die Menschen beim Kunden zusammenzubringen und in Workshops herauszuarbeiten, wo das Business die IT sieht. Wie weit bin ich vom Bild eines perfekten agilen Unternehmens entfernt? Wo verliert man die meiste Zeit, wo ist die Qualität nicht ausreichend, und wo schmerzt es das Business am meisten? Ohne begleitenden Schulungs- und Überzeugungsprozess wird es schwierig, DevOps über die Fläche auszurollen.“ - Mark Hlawatschek, ATIX
„Ein aufgezwungener Ansatz funktioniert nicht, weil DevOps eine Kultur ist. Das Team muss verstehen, dass es Verantwortung haben will und am Ende auch tragen muss. Es geht bei der Entscheidung für DevOps nicht um Ja oder Nein, sondern um die Frage, warum man DevOps machen möchte. Es ist auch nicht die Frage, mit welcher Hardware ein Kulturwandel vollzogen wird. Es braucht die Zusammenarbeit von Entwicklung und Betrieb sowie Automatisierungslösungen. Eine funktionierende DevOps-Kultur ist ausschlaggebend für den Erfolg digitaler Geschäftsmodelle. Die Geschwindigkeit, mit der neue Softwareversionen veröffentlicht werden können, ist einer der wichtigsten Erfolgsfaktoren.“ - Ulrich Eschbaumer, CGI
„Das Thema DevOps ist aktuell ein Hype, bei dem man nicht auf der grünen Wiese anfängt. Es muss mit Kompetenz und jahrelangem Know-how implementiert werden, weshalb der Altersdurchschnitt der Beteiligten relativ hoch ist. Die Umstellung in den Köpfen ist dabei eine der wesentlichen Herausforderungen. Eine andere liegt in der Hybridsituation aus agilen und klassischen Vorgehensweisen. Diese zu verheiraten und zusätzlich noch Geschwindigkeit aufzunehmen ist eine echte Challenge.“ - Donald S. Fitzgerald, EasiRun
„Um die Implementierung von DevOps als Strategie zu rechtfertigen, benötigt man deutliche Mehrwerte, und die kommen hauptsächlich vom damit erreichten verbesserten Erfolg im Markt. Im Markt entscheidet nur einer über Qualität und Vorteile: der Kunde! Erfolgreiche Implementierungen von DevOps-Strategien und -Prozessen realisieren die Qualitätsansprüche von Kunden nicht durch die Geschwindigkeit, wobei Patches und Releases täglich beziehungsweise stündlich rausgehen – ganz im Gegenteil: Wenn alle Beteiligten in die Wertschöpfungskette eingebunden sind, ihre Beiträge leisten und das Bewusstsein entwickeln, dass der Kunde über die Qualität entscheidet, wird die Wahrnehmung für Qualität als Ziel geschärft – auch die des Kunden.“ - Markus Eisele, Red Hat
„DevOps hat seine Wurzeln in der Open-Source-Kultur. Die hohe Geschwindigkeit, die heute durch kürzere Produktionszyklen und die Automatisierung bei der Infrastrukturbereitstellung angestrebt wird, spielt in der Open-Source-Gesellschaft seit vielen Jahren eine herausragende Rolle. Allerdings wird hier aufgrund der großen Community viel offener kommuniziert, nach ganz anderen Regeln und mit weniger Bürokratie, also in einer offenen Kultur. Das Kultur-Thema ist letztlich auch der Dreh- und Angelpunkt, an dem Unternehmen immer wieder sehen, warum Pilotprojekte scheitern.“ - Peter Schmidt, PKS Software
„Es gibt kein Patentrezept für die Einführung von DevOps, denn die beteiligten Personen – junge und langjährig erfahrene Softwareentwickler, IT-Abteilung und Fachbereich, Entscheider und Umsetzer – sind über ganz unterschiedliche Aspekte für solch ein Vorhaben zu motivieren. Hier braucht es also neben IT- und Tool-Experten vor allen Dingen auch das Wissen um die Belohnungssysteme der Menschen und darüber, wie man Teams so zusammenstellt, dass der Projekterfolg programmiert ist. Für ein Pilotprojekt werden häufig die engagiertesten Mitarbeiter aus den einzelnen Abteilungen eingebunden – damit ist ein initialer Erfolg quasi garantiert. Doch die Einführung beziehungsweise der Roll-out gestaltet sich umso schwieriger. Gerade bei den Legacy-Systemen gibt es in den Unternehmen viele Kopf-Monopole mit Klumpenrisiko; gerade diese Mitarbeiter muss man mit auf die Reise nehmen, um von DevOps dauerhaft als Unternehmen zu profitieren.“ - Wilfried Cleres, Fujitsu
„Bei der Einführung von DevOps gibt es drei wichtige Punkte. Der erste ist die Ist-Aufnahme: Wo stehe ich heute mit meiner Tool-Landschaft? Zweiter Punkt: Vergiss die Menschen nicht. Nimm alle mit, sonst kann man die Kultur nicht umsetzen. Und drittens: Entwickelt gemeinsam den künftigen Bebauungsplan mit den wichtigsten Zielen. Wichtig ist, dass diese auch erreichbar sind. Lieber weniger Ziele setzen, die dann aber auch erreicht werden können.“
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.