Foto: Sevastsyanau Uladzimir - shutterstock.com
Viele Unternehmen haben ihren IT-Mix mit dem DevOps-Ansatz angereichert - sowohl für kleinere Projekte als auch in größerem Umfang. Dabei bietet DevOps potenziell eine ganze Reihe von Vorteilen, nämlich:
schnellere Bereitstellung von Anwendungen und Funktionen,
verbesserte Kommunikation und Zusammenarbeit zwischen Development- und Operations-Teams,
schnellere Lösung von Problemen und
iterative IT-Servicebereitstellung.
Eine Erfolgsgarantie gibt es dabei jedoch nicht. Wie das Analystenhaus Gartner feststellt, "wird DevOps schnell zum Mainstream, aber es bleiben Fragen offen, wie dieser relativ neue Ansatz für Kultur, Automatisierung und Plattformdesign halten kann, was er verspricht."
Viele Unternehmen sähen sich bei der Implementierung und Skalierung von DevOps mit Problemen konfrontiert, so Gartner. Die Analysten gehen davon aus, dass 75 Prozent aller DevOps-Initiativen bis 2022 die Erwartungen nicht erfüllen werden. Im Wesentlichen liegt das nach Ansicht der Auguren an Problemen mit organisatorischem Lernen und Veränderung. Um zu verhindern, dass das auch Ihrem Unternehmen blüht, sollten Sie die folgenden DevOps-Fallstricke vermeiden.
1. Skill-Mangel
Dass erforderliche technologische Kompetenzen fehlen, kann jeden Aspekt der IT betreffen, DevOps bildet dabei keine Ausnahme. Wenn einzelne Teammitglieder nicht über die nötigen Fähigkeiten verfügen, sind in der Regel aber alle Versuche, Vorteile aus DevOps zu ziehen, zum Scheitern verurteilt. "Alle Teammitglieder sollten über die nötigen Hard- und Soft Skills verfügen", empfiehlt Sam Babic, Chief Innovation Officer bei Hyland. Das Unternehmen setzt DevOps und Automatisierung in mehreren Bereichen ein. "DevOps wird innerhalb unserer IT-Organisation genutzt, um die betrieblichen Anforderungen des Unternehmens zu erfüllen, zum Beispiel, wenn es um Buchhaltung, Finanzen, Vertrieb oder Marketing geht", erklärt Babic.
Darüber hinaus bringt Hyland das DevOps-Konzept auch für die Erstellung seiner Softwareprodukte zum Einsatz, die über verschiedene Kanäle an die Kunden ausgeliefert werden: "Bei Cloud-basierten Produkten, die einem Continuous-Delivery-Modell folgen, nutzen wir DevOps und Automatisierung, um die Single-Source-Software sowie alle Datenmodelle und andere periphere Komponenten, die für den Betrieb notwendig sind, zu aktualisieren. In dieser Umgebung kommt Automatisierung auch für Monitoring-Zwecke zum Einsatz", erzählt Babic.
Diese Umgebung erfordert dabei Hard Skills in verschiedenen Bereichen, zum Beispiel in Sachen Kubernetes, Anwendungen für das Release Management, Tools für die Softwarebereitstellung, Konfigurationsmanagement und Anwendungsbereitstellung, Tools und Services für die Versionskontrolle wie GitHub, Programmiersprachen wie Python, JavaScript, Bash und Node.js sowie verschiedene Sicherheitstechnologien.
"Da die Workloads, die wir für unsere Kunden verwalten, in der Cloud liegen, muss das Team sowohl die Plattformen als auch die verfügbaren Services genau kennen", sagt Babic. Was die Soft Skills angehe, seien Kommunikation und Zusammenarbeit entscheidend: "Wer DevOps-Champion sein will, muss in der Lage sein, sich über Ideen und Methoden auszutauschen. In den Bereichen, in denen die Teams zusammenarbeiten, müssen sie die verschiedenen Produkte und die Art und Weise, wie diese ausgeliefert werden, verstehen und eng mit den Produktteams zusammenarbeiten." Nur so könne sichergestellt werden, dass ihre Produkte schon in den frühen Entwurfsphasen mit den Deployment-Strategien übereinstimmen, erklärt der Hyland-CIO. Damit die Automatisierungspraktiken stetig verbessert werden können, seien vor allem auch Feedback-Schleifen wichtig, so Babic.
2. Prozessversäumnisse
"DevOps ist ein Prozess, eine Kultur und eine Disziplin, die Entwicklungsaufgaben mit betrieblichen Abläufen verbindet", weiß Emal Ehsan, Director beim Beratungsunternehmen Cervello.
"Jede Organisation muss sich ihre aktuellen Ansätze ansehen und eine Reihe von grundlegenden Prozessen und Verfahren für den Aufbau von DevOps als Kernkompetenz festlegen. Zudem gilt es, die Auswirkungen dieser Veränderungen aufzeigen", so Ehsan. "Sobald das erledigt ist, sollte man sich die Zeit nehmen, die grundlegenden Fähigkeiten aufzubauen. Dabei sollten Sie sich darüber bewusst sein, dass diese Maßnahmen eine gewissenhafte Planung erfordern."
Für Unternehmen, die Wert auf agile Prozesse und frühe Erfolge legen, könne das einen einschüchternden Tempowechsel darstellen, der aber durch die höhere Qualität wettgemacht werde, die replizierbar sei: "Wenn der Prozess zum ersten Mal zusammengesetzt wird, kann es bis zum ersten Einsatz länger dauern als erwartet. Nachfolgende Implementierungen können dann allerdings in einem Bruchteil der Zeit durchgeführt werden. Der Return on Investment für die Vorlaufkosten ergebe sich zwangsläufig aus den nachfolgenden Iterationen," so Ehsan.
In der Grundlagenphase sei es ungemein wichtig, zu definieren, was 'Erfolg' bedeutet und wie er gemessen werden soll. Die Definition von Erfolg diene dabei dem Cervello-Manager zufolge zwei Zwecken: "Der erste ist, Ihnen die Grundlage dafür zu liefern, die Einführung weiter voranzutreiben. Der zweite, dem Team ein greifbares Ziel zu verschaffen. Wenn Ihr Team von Natur aus wettbewerbsorientiert ist, kann eine hohe Messlatte die besten Ergebnisse bringen. Teams, die von Versagensangst geprägt sind, brauchen hingegen niedrigere Zielvorgaben, um Vertrauen in den Prozess und die einzelnen Mitglieder aufzubauen. In beiden Fällen führt Erfolg oft über das definierte Ziel hinaus", meint der Chef-Berater.
3. Zuviel zu schnell
DevOps-Initiativen im großen Stil auszurollen, ist für Unternehmen nicht empfehlenswert, da das zu Überforderung führen kann: "Eine DevOps-Transformation ist eine grundlegende Veränderung, die nicht über Nacht ablaufen kann. Wählen Sie zu Beginn einen Fokuspunkt - zum Beispiel ein kleines Projekt, das Input von verschiedenen Abteilungen erfordert und implementieren Sie dort DevOps", empfiehlt Emal Ehsan.
Die Toolsets, die Unternehmen zur Zielerreichung einsetzen, hätten - ebenso wie die Menschen, die sie implementieren - einen unterschiedlichen Reifegrad, führt der Berater aus: "Der kulturelle und technologische Support steckt bei den ersten Anwendungsfällen vielleicht noch in den Kinderschuhen - und egal, wie gut Ihr Ansatz geplant ist, wird der Zeitpunkt kommen, an dem Sie feststellen, dass es nicht wie geplant laufen kann."
Wird ein Unternehmen von einer DevOps-Initiative überwältigt, auf die es nicht vorbereitet war, sei das beste Gegenmittel, mehrere Problemlöser im Team zu haben, die Aufgaben aus verschiedenen Blickwinkeln angehen: "Kleine Erfolge und gute Zusammenarbeit wirken ansteckend. Wenn Sie das richtige Team haben, das flexibel genug ist, können Sie anfänglichen Erfolg und die Akzeptanz des Gesamtprozesses insgesamt sicherstellen", so Ehsan.
4. Autonomie-Dysbalance
Ein Mantra der DevOps-Philosophie ist es, Teams mit Autonomie auszustatten und ihnen die Möglichkeit zu geben, ihre eigene Arbeitsweise zu entwickeln, um gute Ergebnisse zu erzielen. Ola Chowning, Partner beim Beratungsunternehmen ISG, weiß, wo dabei die Fallstricke lauern: "Zu viel Autonomie kann zu architektonischem Wildwuchs führen, sowohl logisch als auch bei den Tools. Zu wenig Autonomie, der Aufbau von Barrieren, die die Arbeit verlangsamen, und suboptimale Werkzeuge sind ebenfalls nicht förderlich."
Um die Herausforderung der Autonomie-Balance zu meistern, sei die Einrichtung eines Standardisierungsgremiums, wie zum Beispiel eines Center of Excellence (CoE) ein guter Weg. Dieses sollte sich aus Praktikern verschiedener Teams zusammensetzen, die Leitplanken für die Bereiche aufstellen, in denen Standards zu Effizienzsteigerungen beitragen und bei der Auswahl von Tools, Methoden und Governance-Parametern helfen können.
"Erlauben Sie den Teams, Bedürfnisse außerhalb der aktuellen Standards an das CoE heranzutragen, um Tools, Prozesse und Arbeitsweisen kontinuierlich verbessern zu können. Außerdem sollten die CoE-Mitglieder rotieren, um möglichst alle Teammitglieder einzubeziehen", rät Chowning.
5. One-Size-fits-all DevOps
Wenn Unternehmen DevOps auf breiter Basis ausrollen, neigen sie in den Augen von Chowning oft dazu, alles zu standardisieren, um die Implementierung zu vereinfachen. Das sei allerdings keine gute Idee: "Bestimmte Produkte oder Funktionen brauchen oder können nicht alle Elemente eines solchen Standardmodells unterstützen. Das kann etwa an der Architektur oder den geschäftlichen Anforderungen liegen."
Statt sich auf ein einheitliches DevOps-Modell festzulegen, empfiehlt ISG die Erstellung von "Full DevOps"- und "Minimal DevOps"-Modellen: "Erstellen Sie aus diesen beiden Modellen eine Liste von Mindestanforderungen, die für beide gelten und von denen jedes Team profitieren kann. Was Sie am Ende haben, sind im Wesentlichen mehrere Ebenen von DevOps, die sich effektiv von Team zu Team unterscheiden und jedes Team befähigen, 'auf-' oder 'abzusteigen'", so Chowning.
6. Messverweigerung
DevOps bedeutet Veränderung, und Veränderung läuft nicht immer reibungslos. Sie sollten also besser früher als später herausfinden, wenn etwas nicht so läuft, wie es sollte. "Wenn Sie automatisierte Tests in einer neuen Deployment Pipeline ausführen, können frühe Warnsignale vor Katastrophen schützen. Leider bemerkt niemand Brände, die nie stattgefunden haben, oder feiert den Elektriker, der das Haus nicht niedergebrannt hat", merkt Emal Ehsan an.
Unternehmen, die Metriken zur Wirksamkeit ihrer DevOps-Initiative sammeln, würden die Früchte ihrer Arbeit im Laufe der Zeit in Form von Qualitätssteigerungen und zufriedenen Kunden ernten. Darüber hinaus sei es schwierig, die für DevOps aufgewendete Zeit und das Geld zu rechtfertigen, ohne die Auswirkungen aufzuzeigen: "Wenn Sie möchten, dass die Vertriebsteams die Vorlaufzeit erhöhen, der CFO das Budget genehmigt und die Initiative auf das gesamte Unternehmen ausgeweitet wird, brauchen Sie entsprechende Daten", so Ehsan.
7. Keine DevOps-Kultur
Damit DevOps zum Erfolg wird, müssen die Teams mit Leidenschaft bei der Sache sein. Das lässt sich durch den Aufbau einer entsprechenden Kultur erreichen, wie Brian Balzer, Vice President of Digital Technology and Business Transformation bei G&J Pepsi, weiß: "Die Kultur ist der Schlüssel. Das Team muss mit DevOps-Methoden arbeiten wollen. Dazu braucht es auch den Willen, sich disziplinübergreifende Fähigkeiten anzueignen und gute Geschäftskenntnisse. Ansonsten werden Sie es schwer haben."
Das Franchise-Unternehmen von Pepsi arbeitet seit 2009 mit dem DevOps-Framework und hat die Methode 2018 auch offiziell übernommen. "Da wir ein schlankes, kleines Team waren, wurde diese Arbeitsweise nicht unbedingt gewählt, um eine formale Definition dafür zu finden, wie man arbeitet, sondern eher aus der Notwendigkeit heraus, dem Unternehmen einen Mehrwert zu liefern", so Balzer.
Es hat viel Zeit gekostet, eine DevOps-Umgebung und ein -Team aufzubauen, einschließlich rigoroser Ausbildung und Schulung. Im Herbst 2020 holte das Unternehmen einen agilen Coach ins Haus, um die Prozesse und die Arbeitsweise des Teams zu bewerten. "Das war sehr wertvoll und nach ein paar Monaten hatten wir umstrukturiert. Das Team hat sich weiterentwickelt und arbeitet nun reibungslos nach der DevOps-Methode", so der Manager.
"Wir messen unseren Durchsatz, unsere Fähigkeit, Storyboards zu erstellen, und den Wert, den wir für das Unternehmen liefern. Und was am wichtigsten ist: Wir bauen Glaubwürdigkeit beim Führungsteam auf, haben die Beziehungen zu unseren Geschäftspartnern drastisch verbessert und die Akzeptanz der Produkte, die wir implementieren, im gesamten Unternehmen erhöht." (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CIO.com.
- 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.“