Eine neue Sichtweise auf die Architektur von DevOps-Implementierungen

DevOps steht im Mittelpunkt. Da sich die Welt auf eine robuste, softwaregesteuerte Zukunft zubewegt, erleben wir einen Anstieg der Anzahl und des Umfangs von DevOps-Projekten. Diese umfassen ein breites Spektrum an Aktivitäten, von groß angelegten Implementierungen auf Unternehmensebene bis hin zu Technologien und Lösungen zur Bewältigung der Herausforderungen von Continuous Integration und Continuous Delivery (CI/CD).

Inmitten einer Vielzahl von Szenarien scheint der rote Faden für alle DevOps-Engagements in den kulturellen und führungsbezogenen Aspekten der Transformationsreise zu liegen.

Und DevOps ist in der Tat eine Reise.

Es gibt die irrtümliche Ansicht, dass DevOps nur eine Kombination oder Verschmelzung der Entwicklungs- und Betriebsteams ist, um identifizierte Herausforderungen zu lösen. Tatsächlich ist DevOps mehr als nur ein Werkzeug für CI/CD. Kulturelle Veränderungen, neue Arbeitsweisen und eine neu belebte Führung sind der Schlüssel zur Transformation des Teams - eine Reise, die von Tools und Technologien zur Automatisierung der Prozesse für schnelleres Feedback, pünktliche Lieferung und verbesserte Qualität angetrieben und unterstützt wird.

Im Folgenden möchte ich die Erkenntnisse und Lehren aus unseren Erfahrungen schildern, die wir bei der Unterstützung eines großen globalen Kunden bei der Ermittlung des aktuellen Stands der IT-Entwicklung und des IT-Betriebs sowie bei der Neudefinition seiner DevOps-Transformationsreise gewonnen haben.

Was beinhaltete dies?

In Gesprächen mit den Führungskräften des Kunden wurde deutlich, dass das Unternehmen an Produktivität, Rentabilität und Marktanteilen einbüßt, weil es nicht in der Lage ist, IT-Services für Unternehmen bereitzustellen. Die IT-Abteilung war nicht in der Lage, ihr Versprechen der rechtzeitigen Bereitstellung von Software einzuhalten. Wir identifizierten mehrere Probleme bei der Leistung von Software Delivery and Operations (SDO), darunter:

• Lange Vorlaufzeit bei der Bereitstellung von Funktionen für das Unternehmen,
• Mangelnde Einbeziehung des Unternehmens in der Entwicklungsphase,
• Überschreitung von Terminen aufgrund von Qualitätsproblemen in späteren Phasen,
• Mangelnde Automatisierung und zu viele manuelle Übergaben sowie ein
• Silo-Ansatz in den Entwicklungs- und Betriebsteams.

Vor dem Hintergrund dieses herausfordernden Szenarios wollen wir sehen, wie wir das DevOps-Paradigma des Unternehmens umgestaltet haben.

Erstens: Bereitstellung von DevOps-Führungskräften - Dies ist der Schlüssel zum Erfolg der DevOps-Implementierung.Wir haben festgestellt, dass viele Transformationsprojekte aufgrund von unzureichenden Transformationsinitiativen scheitern. Dazu gehören:

• Keine Definition des "Warum" Teil von DevOps-Implementierungen,
• Mangelnde Dringlichkeit hinsichtlich der Notwendigkeit von DevOps,
• Schlechte Strategie für die DevOps-Transformation,
• Keine klare und deutliche Kommunikation mit den Beteiligten,
• Fehlen einer Vision und eines Endziels im Kopf, und
• Kein Durchdenken des kulturellen Wandels.

Wir arbeiteten gemeinsam an der Lösung dieser Probleme, indem wir die volle Unterstützung der Führungskräfte sicherstellten und den Transformationsplan durch ein "Übermaß an Kommunikation" an die Organisation herantrugen (glauben Sie mir - das ist genau das, was der Arzt verordnet!).

Unsere Teams halfen dabei, die Mitarbeiter mit dem richtigen Wissen und den richtigen Tools auszustatten, um die richtige Kultur zu schaffen.

Die wiederbelebte DevOps-Reise begann daher mit einer anfänglichen Bewertung (Due Diligence) der aktuellen Geschäfts- und Entwicklungsabläufe sowie der Lieferpraktiken. Wir halfen bei der Erstellung einer guten DevOps-Transformations-Roadmap, um gemeinsam mit dem Führungsteam des Kunden das Beste aus der Reise zu machen.

Zweitens: Kulturelle Transformation und Agile vorantreiben - bei DevOps geht es wirklich um die Menschen. Unternehmen leiden oft unter einer eingefrorenen Kommunikation zwischen Teams, siloartigen hierarchischen Strukturen und Kommunikationsbarrieren, die zu einem Verlust der End-to-End-Vision der Produktentwicklung führen. Eine der größten Herausforderungen besteht daher darin, den kulturellen Bedarf zu ermitteln und einen robusten und effektiven Transformationsplan zu entwerfen.

Die agile Transformation ist der Schlüssel zur Änderung der Gewohnheiten der Teams, um neue Arbeitsweisen und Denkweisen zu übernehmen. Unsere Transformationsmethodik führte zu etwa 25 agilen Teams, so genannten Squads, die in einem bestimmten produktbasierten Portfolio-Wertstrom organisiert sind. Kleine Chargen, die Visualisierung des Arbeitsflusses, häufige Lieferung und Feedback brachten Veränderungen in der Denkweise der Squads.

Kulturelle Veränderungen, Trainingscamps und Agile Konferenzen wurden organisiert, um eine vollständige Veränderung der Denkweise und der Lieferprozesse zu gewährleisten.

Als Nächstes steht die Einführung von CI/CD-Verfahren im gesamten Unternehmen auf dem Programm.

CI/CD-Implementierung - Unsere Teams halfen dem Kunden bei der geordneten Einführung von Continuous Delivery in der gesamten Organisation. Wir führten ein Pilotprojekt durch, dessen Erfolg in jedem Geschäftsbereich und jeder Technologie durch die Automatisierung und Standardisierung der Softwarebereitstellung gemessen wurde.

Während dieser Umstellung wurden schrittweise Verbesserungen vorgenommen, um die Freigabeprozesse zu rationalisieren. Infolgedessen wurden die wichtigsten Risiken und Probleme bei der Bereitstellung ermittelt, und der Freigabeprozess wurde iteriert, um durch kontinuierliche Verbesserungen zusätzliche Sicherheit zu gewährleisten. Abbildung 2 (9unten) zeigt die typische Continuous-Delivery-Pipeline - Source, Build, Test und Production.

Abbildung 2: Eine typische Continuous-Delivery-Pipeline - Source, Build, Test und Production

DevOps ist ein kontinuierlicher Prozess, so die allgemeine Weisheit. Die Ergebnisse sind jedoch von Anfang an sichtbar.

Während die Implementierung auf Unternehmensebene für das Beispiel, über das wir vorhin gesprochen haben, noch läuft, haben wir bereits erste ermutigende Ergebnisse beobachtet:

• Verbesserte Qualität des gelieferten Produkts mit einer 50-prozentigen Verringerung der Fehlerquote,
• Erhöhtes Mitarbeiterengagement und zufriedene Entwickler,
• Verbesserte, verstärkte und erweiterte Pipelines,
• Integration von Neuem in die Staging-Umgebung für UAT,
• Erhöhung der Lieferfrequenz um 20 % und
• Inkrementelle Verringerung der Vorlaufzeit (von 90 auf unter 60 Tage) bei zunehmender Automatisierung der manuellen Übergabe von Altprojekten.

So ermutigend die Ergebnisse auch sind, sie spornen uns an, Praktiken zur Standortzuverlässigkeit und Beobachtungen durchzuführen, um eine tiefgreifende Transformation des Architekturprozesses für die DevOps-Implementierung voranzutreiben. Durch die Verbesserung der Pipeline-Effizienz, die Modernisierung der Anwendungsarchitektur, Arbeitsweisen, Denkweisen und Verhaltensweisen wird die Reise zum Nutzen aller Beteiligten nur noch stärker.

Eine maßgeschneiderte interne DevOps-Plattform (IDP), die in der Lage ist, einen großen Teil der Komplexität, die DevOps-Ingenieure und IT-Betreiber belastet, zu beseitigen, kann sich hier als entscheidender Faktor erweisen. Die Idee ist, dass der Kunde/Entwickler in der Lage sein sollte, sein bevorzugtes Tool mit der erforderlichen Lizenz zu konfigurieren, um eine DevOps-Toolchain zu erstellen. Dies würde den Entwicklern Erfahrungen im kontinuierlichen Lernen und Experimentieren bringen, um das Gesamtergebnis der DevOps-Reise zu maximieren und den gemeinsamen Erfolg des Prozesses zu unterstreichen.

Der Wandel, wenn er denn eintritt, wäre ein stiller, aber mächtiger Wandel. Denn schließlich sind die tiefgreifendsten Revolutionen oft die leisesten.