Nachdem im Silicon Valley über zwanzig Jahre lang mit agiler Softwareentwicklung experimentiert wurde, ist "Agile" 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.
Mit DevOps 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).
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.
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.
Die cloudbasierte IT-Architektur bei Netflix
Netflix hat beispielsweise eine cloudbasierte IT-Architektur entwickelt, die es den Entwicklern ermöglicht, täglich Hunderte von Deployments vorzunehmen. Die Website besteht aus Mikroservices, die in einer Cloud gehostet werden. Jeder Service wird von einem DevOps-Team gepflegt. Entwickler müssen keine Ressourcen beim IT-Betrieb anfragen, sondern können Code gemeinsam mit einem virtuellen Image direkt in die Produktionsumgebung einstellen. Beim Update eines virtuellen Image können neue Funktionen oder Services über eine auf Amazon Webservices basierenden Plattform in die bestehende Infrastruktur von Netflix integriert werden.
Anschließend werden die Images mit einem Subset von Nutzern in der Produktionsumgebung getestet. Sobald sie freigeschaltet sind, wird ein Teil der Zugriffe von der alten Versionen auf die neue Version umgeleitet. Erfüllt die neue Version nicht alle Anforderungen, wird der Datenverkehr mit Hilfe eines automatisierten Überwachungstools zurück zu den älteren Versionen geleitet. Dank dieser starken Automatisierung kann Netflix einen neuen Code binnen weniger Stunden in seiner Produktionsumgebung verteilen. Bei den meisten Unternehmen würde dies Wochen oder Monate dauern.
Natürlich haben Internetunternehmen wie Netflix den Vorteil, dass sie ihre IT-Architekturen von Grund auf neu gestalten konnten, ohne komplexe Altsysteme neu konfigurieren oder pflegen zu müssen. Und weil ihre wichtigsten Produkte - Webanwendungen - zu 100 Prozent auf ihre Kunden ausgerichtet sind, haben diese Unternehmen gelernt, rasch auf Kundenfeedback zu reagieren und "on the fly" neue Features und Verbesserungen herauszubringen.
Die Probleme für traditionelle Unternehmen
Im Gegensatz dazu stehen die meisten traditionellen Unternehmen, die in ähnlicher Weise ein DevOps-Modell einführen wollen, vor der Herausforderung, ihre älteren, transaktionsbasierten Systeme mit agilen Entwicklungsmethoden unter einen Hut zu bekommen. Noch komplizierter wird es dadurch, dass nicht jede Funktion in einem stationären Unternehmen einen DevOps-Ansatz benötigt - bei nicht zeitkritischen Erfassungssystemen wie dem Hauptbuch wäre das zum Beispiel der Fall. Diese Unternehmen müssen also nicht nur eine IT-Architektur der zwei Geschwindigkeiten entwickeln, sondern auch eine Organisation mit zwei Geschwindigkeiten managen.
Management einer Architektur der zwei Geschwindigkeiten
Mit einer IT-Architektur der zwei Geschwindigkeiten können große Unternehmen schneller innovative, kundenrelevante Produkte und Anwendungen auf den Markt bringen und gleichzeitig ihre alten IT-Systeme beibehalten, die weniger innovativ, aber notwendig für die Stabilität des Geschäfts sind. Bei einer solchen Architektur sind die entwickelten Softwareanwendungen stark mit der unterstützenden Hardwareinfrastruktur verzahnt.
In der Vergangenheit war der IT-Betrieb, also die Pflege von Software und Hardware, komplett von der Softwareentwicklung getrennt. Da sich vertikale ERP-Systeme jedoch immer mehr durchsetzen, Netzwerke immer häufiger virtualisiert werden und Software-as-a-Service-Modelle auf den Markt drängen, haben sich die beiden Seiten einander angenähert. Infolge dieser Entwicklungen sind Hardware-Stacks weniger komplex und für Softwareentwickler zugänglicher geworden.
Automatisierungstools für Softwarebereitstellung
In einer Umgebung mit zwei Geschwindigkeiten brauchen Unternehmen Automatisierungstools für eine kontinuierliche Softwarebereitstellung, insbesondere in der Test- und Produktionsphase. Mit solchen Tools lassen sich die Releases von Software-Updates, die Portierung von neuem Code und die allgemeine Verarbeitungsumgebung besser steuern. Vor allem jedoch können Automatisierungstools und cloudbasierte Technologien als Brücke zwischen IT-Altsystemen im Backend und kundenorientierten Anwendungen im Frontend fungieren und einen reibungslosen Ablauf von Test, Bereitstellung, Verteilung und Steuerung sowie Serversicherheit und neue Software-Releases gewährleisten (Schaubild 3).
Foto: Netflix
Cloud- und Automatisierungstechnologien bei Netflix
Eine IT-Architektur der zwei Geschwindigkeiten bietet einige entscheidende Vorteile; allerdings erfordert ihr Aufbau ein gewisses Maß an Zeit, sorgfältige Überlegungen und entschlossenes Handeln. Netflix hat beispielsweise den Großteil seiner Cloud- und Automatisierungstechnologien selbst entwickelt. Inzwischen gibt es für Unternehmen jedoch eine große Auswahl an Produkten und Paketen (zum Teil Open Source), mit denen sie eine ähnliche 2-Speed-Performance erreichen können.
Auf eines kommt es bei einer Architektur der zwei Geschwindigkeiten ganz besonders an: IT-Verantwortliche dürfen die Architektur nicht nur aus System- oder Prozesssicht betrachten, sondern müssen vor allem die benötigten Fähigkeiten im Blick haben. Dafür müssen sie herausfinden und klar definieren, welche Softwareanwendungen für mehrere Geschäftsbereiche relevant sind.
Aus dieser Fähigkeitenperspektive könnten sie dann zum Beispiel erkennen, dass einige für das Customer Relationship Management (CRM) des Unternehmens entwickelte Anwendungen einen DevOps-Ansatz erfordern, andere - z.B. Core-Banking-Systeme oder transaktionale Anwendungen - hingegen nicht. Die IT-Verantwortlichen können so ihre Ressourcen nach Bedarf auf "schnelle" und "langsame" Anwendungen verteilen - und soweit möglich von den entscheidenden Vorteilen des DevOps-Ansatzes profitieren.
IT-Organisation der zwei Geschwindigkeiten
Im Zusammenhang mit der für DevOps erforderlichen Technologiearchitektur und -infrastruktur sollten Unternehmen sich auch überlegen, ob sie verschiedene Prozesse und Governancestrukturen in der IT-Organisation und im gesamten Unternehmen ändern wollen.
Der DevOps-Ansatz stellt die etablierten Normen der Produktentwicklung in den meisten IT-Organisationen in Frage. Klassischerweise sind Infrastruktur (Hardware) und Anwendungsentwicklung (Software) in Unternehmen voneinander getrennt - so wie die Mitarbeiter für Entwicklung und Betrieb. Mit dieser Silostruktur wäre es bei einem DevOps-Ansatz vorbei - ein grundlegender Wandel in der IT-Management-Strategie. Zudem sollten sich IT-Verantwortliche bei der Einführung eines DevOps-Modells überlegen, wie die Technologiepartner in ihre Softwarebereitstellungsprozesse integriert sind. Dieser Trend zwingt einige Systemanbieter dazu, darüber nachzudenken, wie sie ihre Plattformen als Service zur Verfügung stellen können.
Die größte Aufgabe für IT-Verantwortliche ist es herauszufinden, in welchen Teilen des Unternehmens ein DevOps-Einsatz am sinnvollsten wäre. Dies wird vermutlich dort sein, wo Geschwindigkeit eine wichtige Rolle spielt und das Unternehmen Möglichkeiten sieht, seinen Kunden ein besseres Erlebnis zu bieten als seine Wettbewerber (z.B. ein Einzelhändler, der den Bezahlvorgang auf seiner Website mit Hilfe von DevOps verbessert, oder eine Bank, die auf ihrer Website neue Möglichkeiten anbietet, um die Entwicklung von Fonds zu verfolgen).
Dort, wo ein DevOps-Einsatz nicht besonders sinnvoll ist - weil Zuverlässigkeit und Stabilität der Software wichtiger sind als die Markteinführungszeit -, werden sich die IT-Verantwortlichen überlegen müssen, wie sie Softwareentwicklung und IT-Betrieb weiterhin voneinander getrennt halten können und welche Rollen und Prozesse sie für eine kontinuierliche Bereitstellung anpassen müssen.
Neudefinition von Rollen
Eine integrierte Produktentwicklung erfordert per se eine enge Zusammenarbeit zwischen Fachseite und IT - und in einigen Fällen auch neue oder neu definierte Rollen. Businessanalysten müssen die Anforderungen an neue Softwarefeatures und -funktionen so formulieren, dass Mitarbeiter aller Abteilungen sie verstehen können. Außerdem müssen sie diese Anforderungen flexibel und bereitwillig geringfügig ändern, wenn dies die Implementierung beschleunigen könnte. Ingenieure und Produktentwickler müssen funktions- und produktteamübergreifend zusammenarbeiten - bei einem DevOps-Modell ist die informelle Zusammenarbeit und Koordination zwischen Fachseite und IT tatsächlich noch wichtiger als formale Berichts- und Genehmigungsprozesse.
Softwaretester müssen mit Entwicklern und Businessanalysten zusammenarbeiten. Mit Ersteren klären sie zunächst Anfragen zu bestimmten Funktionen, Letzteren geben sie nach der Codeentwicklung direktes Feedback zur Funktionstüchtigkeit der Software. Bei DevOps warten die Endnutzer nicht mehr passiv auf fertige Software- oder Service-Releases, sondern werden bereits frühzeitig in Entwicklung und Test neuer Softwarefunktionen einbezogen und von den Unternehmen regelmäßig um Feedback gebeten.
Funktionsübergreifende Teams mit Vertretern aus Anwendungsentwicklung, Infrastrukturmanagement und IT-Betrieb sollten gemeinsam die Verantwortlichkeiten für die Stacks in der Abwendungspipeline klären. Bei einer kontinuierlichen Bereitstellung würde zum Beispiel ein gemeinsames Team sämtliche Prozesse (und die damit verbundenen Tools) dieser Entwicklungstätigkeit beaufsichtigen - also Anwendungsentwicklung, -test und -verteilung, Performance-Management und -Monitoring sowie Virtualisierung und Konfigurationsmanagement. Bisher war die Verantwortung hier zum Teil auf unterschiedliche Organisationen verteilt. Überdies sollten die Infrastrukturteams ein Mitspracherecht und die gleichen Entscheidungsbefugnisse wie die Entwicklerteams erhalten.
Neudefinition von Unternehmenskultur und Talentmanagement
Eine integrierte Entwicklung und kontinuierliche Bereitstellung ist nur in einer Unternehmenskultur möglich, die ihre Softwareentwickler mit gewissen Vollmachten ausstattet und ihre IT- und F&E-Berichtsstrukturen darauf ausrichtet. In den meisten Organisationen sind Produktentwicklung und IT-Betrieb räumlich voneinander getrennt und beschäftigen Mitarbeiter mit ganz unterschiedlichen Einstellungen, Fähigkeiten und Erfahrungen. Diese Barrieren müssen Führungskräfte von IT und Fachseite niederreißen. Statt zum Beispiel alle Entwickler dem Leiter Entwicklung und alle operativen Mitarbeiter dem Leiter Betrieb zu unterstellen, müssen in manchen Fällen bewusst andere Berichtswege festgelegt werden.
Darüber hinaus brauchen die Mitarbeiter entsprechende Schulungen; gegebenenfalls müssen auch die Gehaltssysteme angepasst werden. Während der Entwickler in einem klassischen Umfeld nur für die Anwendung verantwortlich ist, ist er in einer DevOps-Umgebung für die Qualität ihres Codes im operativen Betrieb verantwortlich. Sie müssen die Grundlagen des Betriebs beherrschen und ausgesprochen teamfähig sein, um sich bei Problemen in der Anwendungsentwicklung oder -verteilung gemeinsam mit dem Betrieb auf das richtige Prozedere zu einigen.
Angesichts dessen haben viele Unternehmen ihre Personalbeschaffungsprozesse bereits angepasst und halten nun verstärkt nach "Full Stack"-Teammitgliedern Ausschau - Experten, die sich mit sämtlichen Aspekten der IT auskennen und in der Entwicklung von Benutzeroberflächen ebenso versiert sind wie im Umgang mit Netzwerken und cloud-basierten Infrastrukturen.
Neudefinition von Prozessen und Governance
Um zu entscheiden, welche Aspekte der Softwarebereitstellung neu definiert oder vollständig automatisiert werden sollen, müssen sich Unternehmen die ganze Bankbreite der Prozesse anschauen. Ziel ist es, auf Entwicklungsseite bei Bedarf von den Vorteilen von Infrastruktur-as-a-Service zu profitieren und Code in einem standardisierten Verfahren in Test- und Produktionsumgebungen zu portieren. Herkömmliche Unternehmen können sich in puncto Prozess- und Governance-Änderungen für eine DevOps-Umgebung einiges von Internetpionieren abschauen.
Zum Beispiel wenden Internetunternehmen in der Entwicklung das Self-Service-Prinzip an: Entwicklungsteams können Code in Produktionsumgebungen testen, weiterentwickeln und verteilen, ohne ständig die Hilfe des Infrastrukturbetriebs anzufordern. Am Ende sind beide Teams gemeinsam für die Code-Performance verantwortlich.
Ein weiteres Merkmal von Internetfirmen sind konsequente, automatisierte Tests von neuem Code in sämtlichen Phasen des Anwendungsentwicklungsprozesses. In manchen Firmen werden alle 10 bis 15 Minuten automatisch aufwändige Tests durchgeführt. Darüber hinaus nutzen sie Advanced Analytics und andere Tools, um Code vorab auf Ausnahmen zu prüfen, und senden Entwicklern automatisierte Berichte zu jenen Codesegmenten, die mit hoher Wahrscheinlichkeit zu Fehlern führen.
Der Wechsel zu einer DevOps-Umgebung kann sowohl die Produktivität als auch die Markteinführungszeit von Softwareprodukten deutlich verbessern. Mit der Einführung einer neuen IT-Methode ist es dabei allerdings nicht getan. Gefragt ist eine unternehmensweite Transformation, bei der Prozess- und Governance-Fragen genauso Rechnung getragen wird wie Technologiethemen.