DevOps in Unternehmen etablieren
Seite 2: Theorie
Von Funktionen bis Betrieb alles aus einer Hand
Im Gegensatz zum DevOps-Leitbild des kooperativen Verhältnisses stehen die Bereiche einander in der Praxis allzu häufig konfrontativ gegenüber. Die einen entwickeln unter Zeitdruck kreative Anwendungen, deren Spezifikationen Kunden nicht selten noch kurzfristig ändern. Die anderen garantieren stabile IT-Prozesse und sorgen dafür, dass zu festen Release-Terminen neue Software nach strikten Vorgaben sicher in Betrieb genommen wird. Dazwischen herrscht mangelndes Verständnis für die Arbeitsweise und Zielsetzungen der jeweils anderen Abteilung (s. Abb. 1).
Die DevOps-Idee ist einfach erklärt: Es gibt keine andere Abteilung, der sich bei Problemen die Schuld zuweisen lässt. Anwendungsentwicklung und IT-Betrieb sind eins. Das komplette Team wird daran gemessen, dass der Service, den es verantwortet, verfügbar ist. Diese gemeinsame Zielvereinbarung ist ein wichtiges Element der DevOps-Philosophie.
Dass Unternehmen der reibungslosen Verzahnung von Anwendungsentwicklung und Betrieb in der letzten Zeit zunehmend Beachtung schenken, liegt an den veränderten Anforderungen von Kunden und Märkten. Um darauf reagieren zu können, muss sich das IT-Management im Spannungsfeld von Mobilität, Agilität und Elastizität – den drei grundlegenden IT-Trends – neu positionieren. Das erfordert eine neue Denkschule für das Management von IT.
Firmen, die sich mit Konzepten agiler Softwareentwicklung beschäftigen und die Zielsetzung haben, ihre IT-Management-Strukturen elastischer zu gestalten, werden sich früher oder später mit DevOps beschäftigen (s. Abb. 2). Denn was nutzen die wöchentlichen Sprints eines Scrum-Projekts, wenn die Organisation des IT-Betriebs darauf ausgerichtet ist, dreimal jährlich ein Software-Release zu veröffentlichen? Wie sich das in der Praxis auswirkt, zeigt ein Blick auf den Lotteriemarkt: Lotteriegesellschaften benötigen IT-Services, mit denen sie auf unterschiedlichen Vertriebskanälen kurzfristig neue Spielangebote bereitstellen können. Das IT-System muss dann in der Lage dazu sein, Kapazitäten an eine im Vorfeld nicht kalkulierbare Spielerzahl dynamisch anpassen und die Services liefern zu können.
Unabhängig von Branchenzugehörigkeit und Unternehmensgröße sind heutzutage Konzepte gefordert, die die schnelle Verfügbarkeit stabiler Softwareprodukte garantieren.
Geboren und weiterentwickelt wurde die DevOps-Idee in Start-up-Unternehmen, deren gesamtes Geschäftsmodell von IT abhängt. Das sind Unternehmen, bei denen Schnelligkeit und Innovationsfreude in den Genen verankert sind, aber auch Unternehmen, die jung sind und ohne große Rücksichtnahme auf ihre IT-Historie agieren können.
Diese Herkunft kann DevOps nicht verleugnen. Und sie erschwert es, das Konzept eins zu eins auf etablierte Unternehmen mit tradierten Strukturen zu übertragen. Bei Flickr mag es selbstverständlich sein, bis zu zehn Releases täglich auszuliefern; der ganze IT-Bereich ist von Beginn an entsprechend aufgestellt. Eine Bank auf der anderen Seite veröffentlicht jährlich zwei bis vier neue Softwareversionen für ihre IT-Anwendungen. Nicht selten arbeiten Entwicklung und Betrieb seit Jahrzehnten auf Basis derselben Aufgabenteilung mehr oder weniger zusammen.
Einführung mit Augenmaß
Die Herausforderung für viele IT-Verantwortliche liegt darin, innerhalb dieser etablierten Strukturen ein neues Konzept der Zusammenarbeit zu implementieren. Im Gegensatz zu Planspielen auf der grünen Wiese sind davon echte Menschen betroffen. Und echte Umsätze. Die Einführung von DevOps ist ein Investment. Entsprechend ist dem ganzen Prozess die Frage nach dem ökonomischen Sinn voranzustellen. Wo rechnet sich die Einführung? Welche Abläufe sollen "devopsiert" werden? Wo wird das bisherige Vorgehen beibehalten? Diesen Grundsatzfragen müssen sich alle Verantwortlichen stellen, die die Veränderung ihrer IT-Struktur anstreben (s. Abb. 3).
In der Praxis hat sich ein dreistufiges Vorgehen bewährt, mit dessen Hilfe DevOps schrittweise eingeführt wird, ohne die Anpassungsfähigkeit einer Organisation zu überfordern. Die Verantwortlichen definieren zunächst einen eng abgegrenzten Bereich, der nach DevOps-Vorgaben umstrukturiert wird; anfangs ohne große organisatorische Anpassungen. Zug um Zug erweitern sie, auf Basis der gewonnen Erfahrungen, dann diesen Bereich (s. Abb. 4).
