Vom „nur“ Entwickler zum Umsatzsteigerer Empfehlungen für die erfolgreiche Einführung von DevOps

Anbieter zum Thema

Amazon Web Services EMEA SARL,

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Der Migration in die Cloud folgt häufig auch die schrittweise Übernahme von Verantwortlichkeiten im Sinne von DevOps. Hierbei übernehmen Anwendungsteams zusätzlich die prozessübergreifende Zuständigkeit für die Bereitstellung und den Betrieb ihrer Infrastruktur.

In traditionellen IT-Organisationen ist dies eine Gelegenheit, die starre IT-Disziplintrennung aufzulösen und Mitarbeitern einen neuen Entwicklungspfad aufzuzeigen. Besonders eignet sich ein DevOps Modell für die interne Entwicklung mit hoher Release Frequenz. Um diesen Wandel herbeizuführen wird DevOps häufig in kontrollierter Umgebung eingeführt. In diesem Artikel gehen wir darauf ein, was bei dem Übergang von DevOps als kontrolliertem Experiment zu DevOps als Regelbetrieb zu beachten ist.

Bislang war ich Vollzeit-Entwickler – künftig soll ich auch Betrieb machen?

DevOps ist eine organisatorische Fähigkeit, dessen Erwerb viel Erfahrung und Kompetenz erfordert. Wer DevOps als ein klassisches Verlagerungsprojekt angeht, scheitert schnell, zumal Anwendungsteams bereits ausgelastet sind. Die Verlagerung manueller Arbeit führt eher zu Chaos statt zu Autonomie und Flexibilität. Die erfolgreiche Einführung von DevOps beruht unter anderem auf dem Wandel der Arbeitsschritte.

Die Amazon Web Services (AWS) Cloud erleichtert dies in vielen Bereichen: Je nach AWS-Service sind Infrastrukturaufgaben teils oder vollständig abstrahiert; ihre Modellierung und Bereitstellung erfolgt als Code; dies wiederum ermöglicht die Programmierung von selbstheilenden Maßnahmen zur Entstörungsautomatisierung. Erst mit zunehmender Automatisierung lässt sich eine nachhaltige Grundlage für den Schritt in Richtung DevOps schaffen – damit entsteht eine Aufwandsverschiebung statt Arbeitsverlagerung.

In Zusammenarbeit mit einem globalen Versicherungsunternehmen konnten wir dank der gezielten Nutzung der AWS Cloud in Kombination mit DevOps den Gesamtaufwand in der IT-Organisation von 70 Prozent Betriebstätigkeit zu 70 Prozent Softwareentwicklung verschieben. Beim größten Neuentwicklungsprojekt eines Industrieunternehmens war dieses Verhältnis noch drastischer – auf 500 Entwickler in DevOps Teams kamen zehn Betriebstechniker dazu.

DevOps eröffnet die Chance für IT-Mitarbeiter an Wachstumsthemen zu arbeiten und für die IT-Organisation den Geschäftsbeitrag zu steigern. Der Wandel der IT-Arbeit ist über längere Zeiträume fundamentaler als die Summe aller neu eingeführten Werkzeuge und buchhalterischen Auswirkungen. DevOps beruht auf der Förderung einer agilen Kultur. Diese legt Wert auf Komplexitätsreduktion durch kontinuierliche Veränderungen, z.B. viele kleine Releases, statt das Aufrechterhalten eines statischen Betriebs; auf kontinuierliche Verbesserung durch Feedback-Kanäle und die systematische Neuausrichtung des Zielsystems, z.B. von Serverstabilität hin zu Anwendungsstabilität und Kundenzufriedenheit.

Klare Regeln für mehr Autonomie

DevOps verlangt grundlegende Änderungen am Arbeitsmodell und damit neue Regeln. Dazu gehören folgende.

1) Veranlassen Sie die Zugriffsberechtigung auf Systeme: Die prozessübergreifende Zuständigkeit erfordert Erweiterungen im Systemzugriff. Betriebsingenieure, die einem DevOps-Team beitreten, sollten berechtigt sein, Änderungen am Quellcode durchzuführen. Entwickler wiederum sollten befugt sein, Releases in die Produktion zu überführen. Dies ist selten einfach. Für manche Organisationen steht das im Widerspruch zu der bisherigen Personalpolitik, Information Security Richtlinie oder dem offiziellen Rollenleitfaden – Änderungen daran werden durch die Personalabteilung begleitet und benötigen der Zustimmung des Betriebsrats. Man beachte auch regionale und vertragliche Unterschiede, die einschränken, wer im DevOps Team Abrufbereitschaft bzw. Überstunden leisten darf. Wer DevOps erfolgreich einführen will, geht dieses Thema von der ersten Stunde an.

2) Zögern Sie nicht beim Bilden produktorientierter, funktionsübergreifender Teams: Ein DevOps Team ist für seine Anwendungen entlang des gesamten Lebenszykluses zuständig. Die Anwendungen sind typischerweise interne Entwicklungen mit einer hohen Release-Frequenz – vom Mischen von Anwendungen verschiedener Betriebsmodelle in einem Team oder der Ausgliederung bestimmter Funktionen wie User Testing oder Datenbankadministration raten wir ab. Die Teamzusammensetzung sollte so erfolgen, dass das DevOps-Team für jeden Arbeitsschritt autark agieren kann – ohne auf andere angewiesen zu sein. Hierfür sollten Personen mit unterschiedlichen Funktionen (von Softwareentwicklung bis Infrastruktur) als formelle Teammitglieder einbezogen werden. Neben der formellen Umschulung (z.B. Cloud-Betrieb für alle Entwickler) hilft in der Übergangsphase der funktionsübergreifende Wissensaustausch und das Coaching. Dies setzt Vollzeit-Engagement jedes Mitglieds voraus. Die BMW Group IT ging so weit, die komplette IT-Organisation nach Produktorientierung zu strukturieren. Die neu gegründeten interdisziplinären „BizDevOps Teams“ haben weitgehende Produkthoheit, Entscheidungsbefugnis und eigenständiges Budget. Dies sendet ein klares Zeichen an die Belegschaft, dass Autonomie nicht nur gefordert, sondern „von oben” auch ermöglicht wird.

3) Positionieren Sie Ihre Spezialisten als Ermöglicher statt Türsteher: Die prozessübergreifende Zuständigkeit verlangt zusätzliche Fähigkeiten und Kompetenzen und genug Freiraum, diese zu erwerben. Das klappt nicht allein mit der Einführung eines agilen Entwicklungsprozesses. In der Übergangsphase sollte die Arbeitszuweisung ohnehin nicht vollständig agil erfolgen. Vielmehr sollte man Arbeitsschritte gemäß der neuen Arbeitsaufteilung gezielt zuweisen, um ein kontrolliertes Lernen am Arbeitsplatz mit zunehmender Verantwortung zu ermöglichen. Das Rollenverständnis für IT-Spezialisten verändert sich grundlegend. Die Rolle des Betriebstechnikers im DevOps-Team besteht nun darin, Entwicklern die autonome Ausführung von Betriebsaufgaben zu ermöglichen; die Rolle des Testers wiederum, Entwicklern die Möglichkeit zu geben, Tests eigenverantwortlich auszuführen und zu automatisieren. In der Theorie ist das für jedes Teammitglied ein zweifacher Vorteil – man lernt vom Team und versucht gleichzeitig Routine-Aufgaben überflüssig zu machen. In der Realität ist das Trennen von der bisherigen Aufgabe kein Sachvorgang, sondern mit Emotionen verbunden wie der Angst vor einer geringeren Wertschätzung. Es fällt uns häufig schwer, die bisherige Rolle in der Organisation aufzugeben, für die wir jahrelang gearbeitet haben und dafür geschätzt wurden. Gute Führungskräfte sind daher angehalten, im Dialog mit jedem Mitarbeiter einen Entwicklungsplan zu erarbeiten und ein neues Rollenverständnis im DevOps Team aufzuzeigen.

4) Etablieren Sie ein zentrales Unterstützungsmodell für Ihre DevOps-Teams: Häufig unterstützt ein zentrales Team die Änderungen am Betriebsmodell, um die Lernkurve von Anwendungsteams zu beschleunigen. Man denke an den großen Werkzeugkasten, den jeder Techniker benötigt – beim jeweiligen Vorgang jedoch eigenständig entscheidet, welches Werkzeug zum Einsatz kommt. Im DevOps-Werkzeugkasten finden sich moderne Werkzeuge für die automatisierte und sichere Konfiguration, Bebauung, Bereitstellung und den Betrieb von Anwendungen samt deren Infrastruktur. Erfolgreiche Cloud Center of Excellence (CCoE) oder DevOps Engineering Teams schaffen den schmalen Grad, globale Standards und Werkzeuge mit umfassenden Trainingsmaßnahmen bereitzustellen, ohne Anwendungsteams durch zentralisierte Prozesse und harte Vorschriften in ihrer Arbeit einzuschränken. Binden Sie nicht ihre DevOps-Teams an globale Werkzeugketten, die von einer Handvoll Technikern betrieben werden. Ermöglichen Sie eine Vielfalt von Werkzeugen für verschiedene Anwendungsfälle und eine kompetente Beratungsunterstützung wie man sie vom Lieblingsbaumarkt kennt, anstatt auf die Wahl des vom Stammhaus erlaubten Hammer für jeden Zweck warten zu lassen.

Wo man als Erstes ansetzt

In Gesprächen mit Mitarbeitern in IT-Organisationen kommt häufig die Frage nach dem richtigen Zeitpunkt für die Einführung von DevOps. Man glaube nicht, dass derzeit der richtige Zeitpunkt sei und würde einen längeren Zeithorizont von mehreren Jahren sehen. Wie mit jeder Veränderung beginnt man im Idealfall heute, anstatt auf morgen zu schieben, und plant genug Zeit ein, um erste Erfahrungen zu sammeln und Mitarbeiter zu entwickeln.

Nicht jeder Bereich Ihres Anwendungsportfolios eignet sich gleichermaßen für DevOps. Die idealen Kandidaten finden Sie häufig in den Wachstumsbereichen, die ihre Geschäftsprozesse direkt unterstützen und von einem modernen Betriebsmodell profitieren.

Für ein Finanzinstitut war dies beispielsweise die Neuentwicklung von Kernsystemen, die bislang auf dem Mainframe liefen; für ein Pharmakonzern wiederum bei der container-gestützten Bereitstellung von Anwendungen, die elektronische Patientenleistungen ermöglichen und die Medikamentenprüfung beschleunigen. Wer den Wandel in Richtung DevOps ernsthaft angeht, achtet auf die obigen Regeln und zögert nicht beim Umsetzen organisatorischer Veränderungen.

* Der Autor Rostislav Markov ist Senior Consultant für Amazon Web Services. Dieser Artikel ist der vierte Teil einer Serie.

Lesen Sie auch die anderen Beiträge von Rostislav Markov:

Cloud-Migration als Chance für die Modernisierung der Unternehmens-IT

Lieber Innovation statt Server-Umzug

Wie eine Migrationsfabrik bei der IT-Modernisierung hilft

Cloud-Migration am laufenden Band

So beschleunigen Sie die Migration in die AWS-Cloud

Erfolgsfaktoren für die Modernisierung der Unternehmens-IT

(ID:47900300)