DevOps in Unternehmen etablieren

Architektur/Methoden Jürgen Rühling  –  0 Kommentare

In der Informationstechnik entstehen am Übergang zwischen Anwendungsentwicklung und IT-Betrieb Reibungsverluste. Agile Softwareentwicklung trifft auf einen IT-Betrieb, der auf Stabilität und kontinuierliche Verfügbarkeit ausgerichtet ist. Das führt bei Problemen leicht zu wechselseitigen Schuldzuweisungen. DevOps setzt dagegen auf eine gemeinsame, ganzheitliche Ergebnisverantwortung.

Ziel von DevOps ist es, die Bruchstellen zwischen Anwendungsentwicklung und IT-Betrieb dauerhaft in der Unternehmenspraxis zu überwinden. Der Begriff – aus "Dev" für Anwendungsentwicklung (Development) und "Ops" für IT-Betrieb (Operations) zusammengesetzt – steht für das Zusammenrücken der beiden Bereiche mit dem ziel, dass diese neue Organisation Software schneller und fehlerfreier erstellen und verfügbar machen kann. DevOps ist dabei im ersten Schritt ein organisatorisches Thema: Um die Vorteile des Konzepts zu realisieren, müssen IT-Verantwortliche die Strukturen und Verantwortungen anpassen. Ein dreistufiger Ansatz hilft dabei, das Konzept in Unternehmen einzuführen.

Development and Operations in love?

Patrick Debois wird Ende Oktober 2009 kaum geahnt haben, wie sehr die von ihm mitorganisierten DevOps Days die IT-Welt innerhalb weniger Jahre verändern werden. Als Consultant saß Debois in Projekten häufig zwischen den Stühlen von Anwendungsentwicklung und IT-Betrieb. Er war davon überzeugt, dass es kooperativere und damit auch effektivere Wege der Zusammenarbeit zwischen diesen Abteilungen geben müsse. Und die Zeit war reif für einen neuen Ansatz: Nur wenige Monate zuvor hatten John Allspaw und Paul Hammond in ihrer bekannten Velocity-Präsentation "10 + Deploys Per Day: Dev & Ops Cooperation at Flickr" ein großes rotes Herz mit der Aufschrift "Dev and Ops" gezeigt. Der Beginn einer großen Liebe?

Um diese Idee weiterzuentwickeln, lud Debois Interessierte nach Gent in Belgien ein. Diese diskutierten die Vorträge und Workshops im Anschluss an die Veranstaltung online unter dem Hashtag #devops weiter. Unter diesem Namen sollte das Konzept dann auch bekannt werden. Endgültig zum Durchbruch verhalf die Gartner Group dem Thema. Gartner prognostizierte im März 2011, dass sich DevOps bis zur Mitte des Jahrzehnts zur Mainstream-Managementtechnik entwickeln werde. Die wegen ihrer Vorhersagen häufig gescholtenen Analysten scheinen recht zu behalten.

Wenn auch in einem technischen Umfeld angesiedelt, ist DevOps im ersten Schritt kein Technologiethema. Es ist eine Philosophie, ein Konzept einer von gegenseitigem Aufgabenverständnis und Akzeptanz geprägten, organisationsübergreifenden Zusammenarbeit von Anwendungsentwicklung und IT-Betrieb. Erst im zweiten Schritt sollten Unternehmen technische Umsetzungen betrachten. Diese helfen dabei, die Ideen von DevOps in die Unternehmenspraxis umzusetzen. Konfigurationswerkzeuge wie Chef oder Puppet entfalten ihre ganze Wirkung nur in einem geeigneten organisatorischen Umfeld. Verwirklichen lässt sich das DevOps-Leitbild nur durch engagierte IT-Experten, die eingefahrene Denkstrukturen überwinden und eine verfahrene Situation verbessern wollen.

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).

Das Spannungsverhältnis zwischen Entwicklung und Betrieb (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.

Einordnung des Themas DevOps (Abb. 2)

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).

Aspekte des DevOps-Konzepts (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).

Die drei Wellen der DevOps-Einführung (Abb. 4)

Wellen der DevOps-Einführung

Welle 1 – Säen

"Gemeinsame Serviceverantwortung entwickeln" – das ist das Motto der frühen DevOps-Einführung in Unternehmen. Die Grundlage der DevOps-Implementierung bilden ein einzelner oder einige wenige geeignete Services. Hierfür bieten sich innovative IT-Anwendungen aus den Bereichen Internet und Mobile Computing an, die mit marktgängigen Plattformen (.NET, Java EE) realisiert sind und etablierte Softwarearchitektur-Muster verwenden. Komplexe Mainframe- und Legacy-Anwendungen, die meistens auf mehrere Jahrzehnte IT-Betrieb "zurückblicken", sind ungeeignet. Ebenso sollte das regulatorische und gesetzliche Umfeld, in dem die betreffenden Services entwickelt und betrieben werden, keine zu komplexen und restriktiven Vorgaben an die Gestaltung der IT-Governance stellen.

Dabei wird ein pragmatischer Ansatz der Einführung verfolgt: Um ein gemeinsames Serviceverständnis zu entwickeln, ist es im ersten Schritt nicht notwendig, direkt organisatorische Fakten zu schaffen. "Virtuelle Teams", in denen Teile von Entwicklung und Betrieb zeitlich befristet zusammenarbeiten, haben sich in der Praxis bewährt.

Organisatorischer Wandel ist das grundlegende Thema, auf dem DevOps aufbaut. Am Ende der ersten Einführungswelle haben alle Beteiligten ihre Erfahrungen damit gemacht, wie die Organisation auf diesen Wandel reagiert. Gelingt es, die eingefahrenen Abläufe und Denkweisen zu ändern? Ist der Sprung über den Schatten möglich? Das Wissen, das in der ersten Phase gewonnen wird, beeinflusst den weiteren DevOps-Weg – bis hin zur Erkenntnis, dass die gewünschten neuen Strukturen die bestehende Organisation überfordern.

Welle 2 – Pflegen

Auf Basis des in Welle 1 konzipierten und erprobten DevOps-Blueprint rollen die Teams DevOps im zweiten Schritt weiter aus und verankern das Konzept tiefer in der Organisation. Dazu wählen die Verantwortlichen einen repräsentativen Querschnitt aus dem Portfolio der IT-Services aus. Für diese Auswahl werden DevOps-Teams aufgebaut. "Hotspots" für die Auswahl geeigneter IT-Services sind Prozesse, die von der neuen Art der Zusammenarbeit besonders profitieren. Das Geschäftsmodell und die Untersuchung der IT-Organisation liefern Anhaltspunkte für die Suche: An welchen Stellen sind häufiger Änderungen an der Unternehmenssoftware umzusetzen? Wo muss das Unternehmen schnell mit Lösungen auf dem Markt sein? Wo in der Ablauforganisation treten Hemmnisse auf, die zu mangelnder Servicequalität führen? Die Antworten auf diese Fragen liefern Hinweise darauf, wo sich DevOps-Potenzial verbirgt, das sich schnell realisieren lässt.

Gleichzeitig zementiert das Management die organisatorischen Änderungen: Aus zeitlich befristet angelegten virtuellen Teams werden feste "Entwicklungs- und Betriebseinheiten". Die IT-Teams nehmen jetzt nicht nur organisatorisch, sondern auch technologisch umfangreiche Umbauarbeiten vor. Eine wichtige Rolle spielt die Vereinheitlichung von IT-Infrastrukturen und Anwendungsentwicklungsprozessen. Um Entwicklungs-, Test- und Staging-Umgebungen schnell bereitstellen zu können, ist die Standardisierung und Virtualisierung von IT-Ressourcen eine notwendige Voraussetzung. Welle 2 ist der Einstieg in die Automatisierung der gesamten Wertschöpfungskette entlang der Kette aus Entwicklung, Inbetriebnahme und Betrieb. Am Ende stehen vollautomatisierte Deployment-Prozesse für einzelne Anwendungen und Services, die die "Handarbeit" auf das notwendige Minimum reduzieren. Das senkt einerseits die Fehlerquote im Release-Prozess und hilft andererseits dabei, entstandene Fehler schneller tilgen zu können.

Die Teams führen all diese Änderungen und Anpassungen "bei laufendem Motor" aus. Denn bei allem Willen zur Veränderung: Die Leistungserbringung des aktuellen Serviceportfolios muss jederzeit sichergestellt sein. Nur dann wird das Management das Thema DevOps-Einführung so unterstützen, wie es notwendig ist.

Welle 3 – Ernten

Die Umstrukturierung des verbleibenden Teils des Serviceportfolios, der für das DevOps-Konzept geeignet ist, ist ein wichtiges Element der letzten Phase. Ziel ist nicht die hundertprozentige Durchdringung aller IT-Management-Strukturen, sondern die am Geschäftsnutzen orientierte Umstellung mit Augenmaß. Auf der technischen Seite wird die Automatisierung der Abläufe flächendeckend ausgebaut. Die IT-Experten führen auf Basis einer standardisierten IT-Infrastruktur Self-Services für das Deployment von Entwicklungs- und Testumgebungen, einschließlich der erforderlichen Testdaten, ein.

Zwei Punkte sind bei der Auswahl geeigneter Services zu beachten: Erstens gilt es, diese Entscheidung nicht nur vor dem Hintergrund der aktuellen IT-Struktur zu treffen. Werden mittel- und langfristige IT-strategische Überlegungen einbezogen, kann dies das DevOps-Serviceportfolio verändern. Ein Thema wie die Analyse und Auswertung großer Datenmengen (Big Data) mag heute noch nicht die Bedeutung haben, um für DevOps in Frage zu kommen. In den kommenden Jahren entwickelt Big Data aber eventuell das Potenzial, zu einer Säule des Geschäftsmodells zu werden. Dann sollten jetzt schon die richtigen Grundlagen dafür gelegt werden.

Der zweite Punkt ist technischer Natur: Innerhalb einer Unternehmens-IT gibt es zahlreiche Verflechtungen zwischen den verschiedenen Services. Diese Interdependenzen, die sich durch gemeinsame Infrastrukturen oder eng gekoppelte Softwarearchitekturen ergeben, sind bei der Serviceauswahl zu beachten. Eventuell muss, wer Service A sagt, auch Service B sagen. Service Level Agreements zurren die gemeinsame Serviceverantwortung von Entwicklung und Betrieb fest: Was als virtuelles Team beginnt, wird nun zur Organisationseinheit.

Gewohnte Arbeitsweisen in Frage zu stellen, über Jahre erlernte Konzepte aufzugeben, das reflexartige Denken in den Kategorien "Wir" und "Die" über den Haufen zu werfen: Die Einführung und das Leben von DevOps verlangen Mitarbeitern einiges ab. Die Gefahr besteht, dass sich gerade in der ersten Zeit nach Welle 3 wieder herkömmliche Verhaltensweisen einschleichen. Während des gesamten Einführungsprozesses und auch darüber hinaus ist das sehr wohl zu berücksichtigen.

Fazit

Die (Neu-)Ausrichtung der Zusammenarbeit von Anwendungsentwicklung und IT-Betrieb unter dem gemeinsamen Leitbild DevOps verbessert Erstellung, Inbetriebnahme und Betrieb der IT-Services. Die Voraussetzung hierfür bilden Veränderungen auf drei wesentlichen Gestaltungsfeldern der IT-Organisation: Governance, Arbeitsprozesse und Automatisierung.

Prozessmodelle, Technologien und Werkzeuge, mit denen sich DevOps erfolgreich umsetzen lässt, sind in ausreichender Anzahl und guter Qualität vorhanden. Die Herausforderung, denen sich in der nahen Zukunft Unternehmen und ihre IT-Organisationen stellen müssen, ist der organisatorische Veränderungsprozess. Er bringt sozusagen die (technisch) bereitstehende PS-Leistung auf die Straße. Dafür müssen sich aber Menschen auf allen Ebenen des Unternehmens bewegen. (ane)

Jürgen Rühling
ist bei der adesso AG für die Leitung von Beratungsprojekten in den Themenfeldern Prozess- und IT-Servicemanagement sowie Transition & Transformation verantwortlich. In mehr als 20 Jahren beruflicher Tätigkeit in verschiedenen Fach- und Führungsfunktionen in unterschiedlichen Branchen sammelte er umfassende Projekterfahrungen sowohl bei Beratungs- als auch bei Anwenderunternehmen von Informationstechnik.