Aufgaben, Rollen, Organisation
DevOps in einer Two-Speed-Architektur
- Was IT-Verantwortliche beachten müssen, wenn sie ein DevOps-Modell in einer IT der zwei Geschwindigkeiten einführen möchten
- Netflix hat eine cloudbasierte IT-Architektur entwickelt, in der Entwickler täglich Hunderte von Deployments vornehmen können
- Mit der klassischen IT-Silostruktur ist beim DevOps-Ansatz vorbei; ein grundlegender Wandel der IT-Management-Strategie wäre zwingend nötig
- Unternehmen können sich bei Prozess- und Governance-Änderungen einiges von Internetpionieren abschauen
Nachdem im Silicon Valley über zwanzig Jahre lang mit agiler Softwareentwicklung experimentiert wurde, ist "AgileAgile" nun Mainstream geworden. Unternehmen im Silicon Valley und anderswo bedienen sich in irgendeiner Form dieser Entwicklungsmethode, deren Schwerpunkt unter anderem auf der schnellen Erstellung und häufigen Bereitstellung von Software und Systemupdates liegt. Der Nutzer wird dabei über den gesamten Prozess hinweg eingebunden. Alles zu Agile auf CIO.de
Mit DevOpsDevOps steht nun die nächste Innovationswelle in der Softwareentwicklung und -bereitstellung an. Mit diesem Ansatz können Softwareentwicklungsteams produktiver arbeiten, digitale Produkte und Dienstleistungen gelangen schneller auf den Markt, und die Kundenzufriedenheit steigt. In einem Fall ließ sich die durchschnittliche Dauer der Entwicklung und Implementierung von Code dadurch von 89 auf 15 Tage - also auf 17 Prozent der ursprünglichen Dauer - verkürzen (Schaubild 1). Alles zu DevOps auf CIO.de
Foto: McKinsey Analyse
Softwareentwicklung in IT-Betrieb integrieren
Zahlreiche Unternehmen haben dieses Produktentwicklungskonzept bereits übernommen. Grundidee des Konzepts ist die Integration der Softwareentwicklung in den IT-Betrieb, damit Teams neue digitale Anwendungen häufiger und effizienter entwickeln, testen, herausbringen und warten können. Die Software wird nicht im luftleeren Raum, sondern ganz konkret für spezielle Geschäftsanforderungen und die Systemintegration entwickelt, und Entwickler und operative IT-Mitarbeiter sind für die Codebereitstellung und -stabilität gleichermaßen verantwortlich.
Bis jetzt ist es jedoch nur wenigen Unternehmen gelungen, die Vorteile von DevOps wirklich voll auszuschöpfen, ganz unabhängig von der Branche. Die Einführung agiler Systeme wirkte sich bislang meist nur auf die Zusammenarbeit kleiner Gruppen von Projektbeteiligten der Fachseite und einzelnen Anwendungsentwicklungsteams aus. Der Wechsel zu einem DevOps-Modell erfordert hingegen größere und systematischere Veränderungen, die erhebliche Auswirkungen auf die Zusammenarbeit zwischen allen Softwarebereitstellungsteams, operativen IT-Mitarbeitern und Projektbeteiligten der Fachseite haben könnten. Dies ist ein komplizierteres Unterfangen.
- Prüfen von Anforderungen in agilen Projekten
Ohne die Priorisierung der Anforderungen des IT-Projekts drohen hohe Folgekosten in einzelnen Sprintphasen. - Verzögerungen durch exportierte Probleme
Neben dem Totalausfall eines Sprints gehören Verzögerungen zur Tagesordnung. Diese entstehen etwa bei unklar definierten Anforderungen, die eventuell im falschen Detaillierungsgrad vorliegen oder durch Überlastung des Product Owners verspätet priorisiert werden. - Zeitverluste durch fehlende Aufgabenzuordnung
Zunächst lassen sich nicht ausreichend gut definierte Anforderungen durch ohnehin erforderliche Routinearbeiten wie der Spezifikation technischer Anforderungen kompensieren. Später droht dagegen der Totalverlust ganzer Sprints. - Anforderungen treffen ungesteuert auf das Projektteam
Bei agilem Projektmanagement stehen viele Unternehmen noch immer auf der Bremse. Der Grund: Viele Projektverantwortliche müssen zusätzlich zu den Projektanforderungen weiterhin Aufgaben im Tagesgeschäft übernehmen. - Anforderungen laufen beim Product-Owner-Team zusammen
In einem Projektteam aus typischerweise sechs bis acht Mitarbeitern laufen alle Fäden beim Product Owner zusammen. Das Product-Owner-Team besteht aus maximal drei Personen. Der Product Owner managed alle an das Team herangetragenen Anforderungen. Das gilt sowohl vonseiten der Auftraggeber als auch der beteiligten Fach- und IT-Abteilungen sowie der Revision. Viele Unternehmen machen dabei den Fehler, Product Owner nicht ausreichend vom Tagesgeschäft freizuhalten.
Nicht jede Anwendung braucht DevOps
Für die meisten Großunternehmen ist die Neuausrichtung des IT-Betriebs an einer IT-Architektur der zwei Geschwindigkeiten, die stabile, transaktionsorientierte Systeme auf der einen Seite und schnell wechselnde Kundenanwendungen auf der anderen Seite umfasst, eine Voraussetzung für die Implementierung von Agilität und DevOps-Konzepten. Aber nicht jede Anwendung, die ein Unternehmen entwickelt, und nicht jedes Update in einer Umgebung mit zwei Geschwindigkeiten erfordert diese gemeinsame Zusammenarbeit, die das Herzstück eines DevOps-Modells ist.
Einige Mechanismen, die zur schnellen Entwicklung von E-Commerce-Anwendungen verwendet werden, sind zum Beispiel nicht für die Entwicklung oder Pflege von in COBOL entwickelten eher transaktionalen Anwendungen geeignet. In solchen Fällen ist die traditionelle Verteilung von Rollen und Verantwortlichkeiten auf IT-Betrieb, Softwareentwicklung und Projektbeteiligten der Fachseite möglicherweise besser geeignet.
Die Aufgaben für IT-Führungskräfte
Dieser Artikel zeigt auf, welche Überlegungen IT-Verantwortliche anstellen müssen, wenn sie ein DevOps-Modell in einer IT-Umgebung mit zwei Geschwindigkeiten einführen möchten (Schaubild 2). Sie müssen entscheiden, wie und wo neue Technologien wie Automatisierung und Cloud-Plattformen eingeführt werden sollen, und dabei berücksichtigen, welche Unternehmensteile am meisten von einem DevOps-Ansatz profitieren. Zudem müssen sie neue Produktionsprozesse und Steuerungsmöglichkeiten testen, damit IT-Betrieb und Softwareentwicklung trotz unterschiedlicher Geschwindigkeiten effektiv zusammenarbeiten können.
Foto: McKinsey Analyse
DevOps mit zwei Geschwindigkeiten
In den vergangenen zehn Jahren haben digitale Unternehmen die herkömmliche Entwicklung und Pflege von Technologieinfrastruktur sowie die Softwareentwicklung und -verteilung auf den Kopf gestellt. Sie waren mit die Ersten, die ihre Softwareentwicklungsfunktionen in ihren IT-Betrieb integrierten und sich die kontinuierliche Bereitstellung kleiner Upgrades zum Ziel setzten. Zentrales Merkmal dieses neuen Konzepts ist die enorme Schnelligkeit, mit der Softwareänderungen designt, integriert, getestet, bereitgestellt und überwacht werden.