DevOps steht bei IT-Entscheidern, die Apps und Services schneller ausliefern wollen, hoch im Kurs. Development und Operations zu verschmelzen, ist jedoch alles andere als ein Kinderspiel. [...]
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 , 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 , 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.“
*Bob Violino arbeitet als freier IT-Journalist für InfoWorld und Network World in den USA.
Be the first to comment