DevOps ist im Kern transformativ. Der agile Ansatz kann die Kultur innerhalb der IT verändern. Neue Werkzeuge und Prozesse, Kennzahlen-basierende Performance, Kollaboration und Teamwork – die breite Palette an möglichen Mehrwerten ist erstaunlich. Allerdings weisen die meisten Business Cases den möglichen Nutzen und Wertbeitrag nicht vollständig aus. Sie beschränken sich häufig auf den Return on Investment (RoI), Kostensenkungen oder einfache technologische Kenngrößen. Dieser Ansatz greift zu kurz; er engt die echten Wertschöpfungspotenziale und Veränderungsmöglichkeiten von DevOps ein.
Insbesondere zwei Kernbereiche werden durch DevOps bei der Auswahl des passenden Anbieters und der Produkte wichtig:
Übereinstimmung der Unternehmensstrategie mit der Strategie der Business Unit: Für die Definition der Prozesse und das Festlegen messbarer Kenngrößen, die die Geschäftsergebnisse abbilden, ist die Übereinstimmung der Strategien des Unternehmens und der Business Unit ein kritischer Faktor. Richten Sie sich an den strategischen Zielen des Business-Managements aus, ist es einfacher, an höhere Budgets zu kommen. Ihre politische Präsenz wird gestärkt. Auch die ganzheitliche Verbindung der einzelnen Projekte vereinfacht sich auf diesem Weg.
Leitung und Team bei DevOps: Die Basis erfolgreicher, auf DevOps basierender Projekte bildet eine starke Leitung sowie Teams, die eng über Silogrenzen hinweg zusammenarbeiten. Management und Team müssen darauf achten, wie ein Hersteller und dessen Lösung DevOps in vier Kernbereichen unterstützen: Tool-Auswahl, Unterstützung der Kultur, Vertriebsunterstützung sowie Feedback-Mechanismen.
Besonders leistungsstarke DevOps-Teams konzentrieren sich erfahrungsgemäß beim Auswahlverfahren für einen passenden Anbieter und eine geeignete Lösung auf die folgenden vier Schlüsselbereiche:
1. Tool-Auswahl
Cross-funktionales Lösungs-Review: Unterstützt bei der Planung kurz- und langfristiger Ziele und Ergebnisse von DevOps. Zudem zeigt das Review mögliche Herausforderungen bei der Integration und den User-Interfaces auf.
Zugang des Product Managements: DevOps-Teams sollten ihre Beziehung zum Product Management definieren, um über Prioritäten, Budgetzuweisungen und die Berichtsstruktur der Organisation Bescheid zu wissen.
Investitionsbewertung: Wie wichtig ist DevOps in der Strategie eines Anbieters? DevOps-Teams sollten sich hierüber einen genauen Überblick verschaffen, denn dieser Punkt betrifft Budgets, Ressourcenzuordnung, Vertriebsunterstützung sowie die grundsätzliche „Ability to Execute“.
Auftragsumsetzung: DevOps-Prozesse sind mit unterschiedlichen Feedback-Mechanismen ausgestattet. Die IT-Verantwortlichen müssen ein genaues Bild davon haben, wie und in welcher Geschwindigkeit angefragte Merkmale und Kunden-Feedback in neue Produkterweiterungen einfließen.
2. Kultur
Herstellerkultur: Bestimmen Sie die wesentlichen kulturellen Merkmale eines Anbieters und prüfen Sie, ob diese zu Ihrer Unternehmenskultur passen.
Kennzahlen: Fragen Sie potenzielle Anbieter nach klar definierten geschäftlichen und technologischen Kennzahlen, die andere Kunden mit den jeweiligen Produkten erreicht haben.
Unterstützung bei der Transformation: Nehmen Sie Kontakt zu Referenzkunden des Anbieters auf, die bereits eine DevOps-Transformation innerhalb ihres Unternehmens in die Wege geleitet haben.
Organisatorische Möglichkeiten: DevOps-Teams sollten sich auf die organisatorischen Strukturen konzentrieren, auf damit verbundene politischen Hemmnisse sowie auf die mögliche Notwendigkeit organisatorischer Veränderungen. Diese Faktoren sind kritisch für den Erfolg bei DevOps.
3. Vertriebsunterstützung
Personalwechsel: DevOps-Teams sollten das Personalkarussell im Vertrieb des Anbieters im Auge behalten. Dreht es sich schnell, könnte das auf mangelndes Interesse an DevOps und geringe Aufmerksamkeit seitens des Managements hinweisen.
Deployment-Unterstützung: DevOps-Teams sollten sich nach den Deployment-Kosten und nach dem Zeitrahmen erkundigen. Wichtig ist zudem, wie sich das Produkt in andere Lösungen integriert.
Rückhalt durch das Management: Die Teams müssen sich im Klaren darüber sein, in welchem Maß die Unternehmensführung hinter DevOps steht. Indikatoren dafür sind die Strategie des Anbieters und Budgetentscheidungen.
Strategische Prioritäten: Ein neues Management bei einem Anbieter bedeutet oft auch eine neue Strategie. DevOps-Teams müssen also wissen, an welcher Stelle DevOps in der Prioritätenliste eines Herstellers steht.
4. Feedbackmechanismen
Entwicklung: DevOps-Teams sollten wissen, wie die Feedback-Schleifen eines Anbieters innerhalb des Entwicklungszyklus‘ funktionieren.
Prozessintegration: Identifizieren und definieren Sie, wo eine Prozessintegration zum Anbieter notwendig ist.
Professional Services: Verschaffen Sie sich einen Überblick, wo zusätzliche Kenntnisse benötigt werden und welche DevOps-relevanten Fähigkeiten eventuell fehlen.
Tipp 1: Bringen Sie die kontinuierlichen Verbesserungszyklen mit Produktfunktionen in Einklang
Herausforderung: Viele IT-Organisationen sind mit den Gedanken der fortlaufenden Verbesserung vertraut. Jedoch wurden diese nicht immer in der Praxis konsequent umgesetzt. Dazu sind klare Regeln und ein lernbasierendes Betriebsmodell notwendig.
Entwicklung, Deployment und Management einer modernen Applikation nach den DevOps-Prinzipien bieten eine gute Basis dafür, die fortlaufende Verbesserung für Anwendungen, Geschäftsergebnisse und Kundenerfahrung zu verankern. Der sogenannte Demingkreis (PDCA-Cycle: Plan – Do - Check – Act) des W. Edwards Deming Instituts beschreibt die Phasen des fortlaufenden Verbesserungsprozesses.
Die IT sollte sich die Prozesse genau anschauen, um diejenigen herauszufiltern, die Verbesserungspotenzial haben. Diese Punkte sollten Sie wiederum mit den Möglichkeiten neuer Tools verbinden, die einen Mehrwert bieten oder Teile des Prozesses automatisieren.
Beispiel: Das DevOps-Team eines großen Retail-Unternehmens entwickelte einen Business Case um herauszufinden, welche Prozesse in der Software-Entwicklung verbessert werden müssten, um die Kunden-Deployments zu beschleunigen. Dabei nutzte das Team als Basis die kontinuierliche Verbesserung nach Demings Ansatz für verschiedene DevOps-Projekte. Mit diesen sollten kurzfristige Verbesserungsmöglichkeiten sowie langfristige Integrationsmöglichkeiten innerhalb von Entwicklung und Testing identifiziert und beziffert werden.
Das Ergebnis übertraf die Erwartungen: Legacy-Prozesse wurden mit neuen Tools zur Konfigurationsautomatisierung umgestaltet. Auch entwickelte das Team Kunden-Self-Service-Mechanismen, die einerseits die Code-Qualität verbesserten und andererseits die Reaktionszeiten auf Feature Requests senkten.
Tipp 2: Identifizieren Sie Renditepotenzial, das fünf Disziplinen umfasst
Herausforderung: Oft schränken DevOps-Teams ihre Analysen zur Wertschöpfung und zum Return on Investment ungewollt auf direkte Einsparungen ein oder auf einige Kenngrößen, die ein bestimmtes funktionales Silo betreffen.
Die meisten IT-Verantwortlichen fokussieren häufig auf Kostensenkungen, technologische Prozessverbesserungen und/oder Business-Nutzen in der einen oder anderen Form. Allerdings können DevOps-Teams eine breite Palette von Mehrwerten bieten. Die IT-Verantwortlichen und DevOps sollten also auf eine ebenso breite Palette an Metriken zurückgreifen, um den Wertbeitrag von DevOps genauer und ausführlicherer zu durchleuchten.
Beispiel: Eine große Bank gliederte jüngst einen Geschäftsbereich aus. Dieser führte ein DevOps-Modell für die IT-Organisation ein. Dadurch wurden zahlreiche Veränderungen innerhalb der IT-Organisation in die Wege geleitet. Mit der Aufstellung von DevOps-Teams und der Auswahl von Projekten benötigten sowohl die IT- als auch die Business-Verantwortlichen für alle Projekte Business Cases mit ergänzenden RoI-Analysen und direkten Bezügen zu den Produkten des Unternehmens.
Das Steuerungskomitee der IT entschied, dass eine einfache RoI-Analyse nicht ausreiche. RoI spiegelte schlicht den Wert von DevOps nicht wieder. In den meisten Fällen wurden Kosteneinsparungen vorausgesetzt. Die zentralen Business-Ziele hingegen betrafen Time to Market, höhere Margen und Kundenbindung. Zudem gelang es dem IT-Management, die IT-Kultur hin zu mehr Verantwortungsbewusstsein und Transparenz zu verändern. Gleichzeitig wurden die DevOps-Teams dabei unterstützt, zügig Ergebnisse zu erzielen, die einfach zu verstehen und zu messen waren.
Tipp 3: Definieren Sie eine Kunden-Persona
Herausforderung: Viele IT-Organisationen haben ihre Kunden nicht ausreichend klar definiert: Wer sind diese, was wollen sie und wie nehmen sie Nutzen wahr? Eine Kunden-Persona als Teil des DevOps-Business-Case hilft dabei, weitreichende Entscheidungen zu treffen.
Die Definition einer Kunden-Persona im Rahmen eines Business Case ist relativ einfach und sehr hilfreich. Um eine Persona zu schaffen, muss das Team einige grundlegenden Recherchen anstellen: Kunden-Background, Demographie, Herausforderungen, allgemeine Ziele müssen ermittelt werden. Durch die Definition des Kunden erhält das DevOps-Team eine klarere Vorstellung davon, für wen es arbeitet und welcher Nutzen erwartet wird. Das Erarbeiten der Persona bietet eine solide Basis für einen bestehenden DevOps-Business-Case.
Beispiel: Das IT-Management eines großen Biotech-Unternehmens startete eine Transformation: Das Team stellte einen auf drei Jahre angelegten strategischen Plan auf. Es arbeitete gemeinsam mit internen Geschäftspartnern und Entscheidungsträgern an der Definition neuer Produkte, einem neuen Prozess zur Kapitalallokation, einem Product Innovation Center und überarbeitete die Organisationstrukturen und Performance-Metriken der IT.
Bevor der Strategieplan jedoch final festgeschrieben wurde, stellte das Exekutivkomitee ein Kundenkomitee auf, das mit jeder Gruppe von Geschäftspartnern gemeinsam eine Kunden-Persona für die einzelnen Business-Units definierte. Diese Querschnittskunden wurden dazu genutzt, bei der Festlegung einiger zentraler Bereiche der Strategie zu helfen sowie bei Führungsstil, besonderen fachlichen/rechtlichen/regulatorischen Anforderungen, Projektprioritäten, Performance-Metriken und Grundsätzen für das IT-Marketing.
Tipp 4: Reduzieren Sie die Risiken über den DevOps-Projekt-Lifecycle hinweg
Herausforderung: Oft gelingt es den DevOps-Teams nicht, Risiken der Geschäftsstrategie, bei Design- und Delivery-Kapazitäten oder bei der Kundenerfahrung zu begrenzen. Werden diese Risiken vor der Auswahl eines Anbieters oder Produkts isoliert, kann das Team mögliche Stolperfallen und kritische Risikofaktoren bei Strategie, Technologie oder Prozessen besser erkennen.
DevOps-Teams müssen sich mit zahlreichen Risiken auseinandersetzen. Durch eine gute Planung jedoch können viele dieser Risiken im gesamten Projekt-Lifecycle begrenzt werden. Die Teams sollten mit PLM-Teams zusammenarbeiten, um Mehrwerte für die Kunden zu schaffen. Die Zusammenarbeit mit PLM-Teams reduziert per se die Risiken. Die möglichen Risiken haben zudem Einfluss darauf, welcher Anbieter und welches Produkt am besten über den Lebenszyklus hinweg passen.
Auch sollten DevOps-Teams sich der Risiken bei Design und Delivery bewusst sein. Jedes DevOps-Projekt wirkt sich auf Design- und Architekturparameter aus, auf Interface-Anforderungen, Erwartungen und auf die Kundenerfahrung. Sind diese Risiken bekannt, kann das DevOps-Team die Produkte und priorisierten Merkmale besser am gewünschten Ergebnis ausrichten. Eine Bewertung der Delivery-Risiken sollte Security, Operations und Entwicklung umfassen, um mögliche Lücken zu erkennen.
Beispiel: Ein Unternehmen der Gesundheitsbranche entschied sich dazu, ein DevOps-Team aufzubauen, um das manuelle Testing und Application Performance Management zu automatisieren. Da es sich dabei um ein komplexes Projekt handelte, musste die DevOps-Leitung einen Business Case aufstellen, der die zu erwartenden Auswirkungen auf die Strategie der Business Unit und zahlreiche weitere Parameter analysierte.
Das DevOps-Team schuf einen neuen Prozess und einen Regelsatz für die Erstellung von Business Cases im Unternehmen. Zudem wurde eine signifikante Zeitspanne für Planung und Team-Building im Vorfeld genutzt. Die Führungsrolle des IT-Managements war für den Aufbau des Teams und zur Einführung des neuen Business-Case-Formats sehr wichtig. Das Team kommunizierte den Case an verschiedene Entscheidungsträger auf Business- und auch Technologie-Seite. Dies half dabei, Beziehungen aufzubauen, Vertrauen zu gewinnen und den Zugang zu kritischen Informationen zu gewährleisten.
Fazit
IT-Verantwortliche und deren DevOps-Teams sollten bei der Auswahl von Anbietern und Produkten aggressiver vorgehen und zur Unterstützung das IDC-Framework heranziehen. Viele Entscheider unterschätzen das Potenzial von DevOps aktuell noch. IT-Verantwortliche, die um die Vorteile wissen, die DevOps in verschiedenen Bereichen bietet, können die Transformation innerhalb ihres Unternehmens beschleunigen, sich damit selbst für den nächsten Karriereschritt empfehlen und den Wandel stärker beeinflussen.
Wie geht es weiter?
Die DevOps-Teams haben gute Gelegenheit, den Nutzen ihrer Projekte auszuweiten und das Vorgehen bei der Auswahl von Anbietern und Produkten für DevOps besser aufzustellen. Ein ganzheitlicher Ansatz, bei dem strategische und taktische Analysen in Einklang sind, bringt für DevOps-Management und -Teams in eine gute Startposition für erfolgreiche Projekte. Konkret sollten Sie folgende Schritte einleiten:
Bringen Sie die kontinuierlichen Verbesserungszyklen mit Produktfunktionen in Einklang
Identifizieren Sie Renditepotenzial, das fünf Disziplinen umfasst
Definieren Sie eine Kunden-Persona
Reduzieren Sie die Risiken über den DevOps-Projekt-Lifecycle hinweg