DevOps in einer Two-Speed-Architektur

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.