The Need for Speed – eine Geschichte über DevOps, Microservices, Continuous Delivery und Cloud-Computing

Derzeit sind drei Megatrends auszumachen, die die IT zu einem dramatischen Wechsel zwingen:

• Wirtschaftsdarwinismus
• Digitalisierung
• Disruptive Technologien

Alle drei sind außerordentlich wichtig und Firmen, die diese Trends ignorieren, werden früher oder später hinter ihren Konkurrenten zurückbleiben (zumindest solange diese Firmen in einem effizienten Markt leben – nichteffiziente Märkte sind eine andere Geschichte).

Märkte im Wandel

Kommen wir zum ersten Trend und beginnen mit einer kurzen Erläuterung: „Darwinismus“ bedeutet kurz gesagt „Nur die Besten überleben“ (Survival of the fittest) – der „Beste“ ist nicht der Stärkste, sondern derjenige, der sich schnell genug an die Anforderungen der Umgebung anpassen kann.

Mega-Trends setzen die IT unter Druck und erzwingen damit einen fundamentalen Wandel

Das gilt auch für Firmen: Nur die Firmen, die sich schnell genug an die sich ändernden Ansprüche und Forderungen ihrer Kunden anpassen können, werden auf lange (oder auch nur kurze) Sicht überleben.

Nun könnten Sie fragen: „Hey, was ist daran neu? Das ist doch schon immer so in der Wirtschaft.“ Und Sie hätten recht.

Entscheidend ist, dass die Märkte, in denen die meisten Firmen agieren, vor einigen Jahren einen drastischen Wandel erfahren haben. Fast ein Jahrhundert lang waren die meisten Märkte weit, nahezu unbeschränkt und träge: Die Nachfrage war immer größer als das Angebot und die größte Herausforderung für die Firmen in diesen Märkten war es, die Produktion ihrer Waren möglichst kosteneffizient zu skalieren.

Das änderte sich in den 1980ern: Langsam aber sicher wurde ein Markt nach dem anderen immer enger. Globalisierung, Marktsättigung und das Internet haben zu stark konkurrierenden und dynamischen Märkten geführt. (Tatsächlich gab es noch mehr Triebkräfte für den Wandel im Markt, doch das würde den Rahmen dieses Blogposts sprengen.) Die Märkte wurden stark bedarfsgesteuert und die neue größte Herausforderung der Firmen war, sich an die veränderten Bedürfnisse der Kunden schnell genug anzupassen. Die entscheidende Triebkraft wechselte von „kosteneffiziente Skalierung“ zu „Reaktionsfähigkeit“.

Veränderte Rolle der IT

Nun könnten Sie sagen: „Gut, das weiß ich alles. Doch was hat das mit IT zu tun?“

Die Sache ist die, dass Business und IT heutzutage eng miteinander verflochten sind. Man kann sie nicht mehr unabhängig voneinander betrachten, selbst wenn alles ganz anders begann:

Wenn Sie an die Beziehung zwischen Business und IT in den 1950ern und 1960ern denken, unterstützte die IT winzige Bruchteile der Geschäftsfunktionen – einen kleinen Bericht hier, eine kleine Analyse da. Das geschah ziemlich selektiv, da die damalige Rechenleistung der Mainframes recht beschränkt war (jedes moderne Mobiltelefon hat um Größenordnungen mehr Rechenleistung als die Computer in den 1960ern).

Dennoch war es für die Geschäftsabteilungen ziemlich angenehm, die Berichte und Analysen nicht mehr per Hand erstellen zu müssen. Und sie wollten mehr davon haben – was schließlich zur Softwarekrise führte: Der Bedarf an Software überstieg deutlich das Angebot.

Die Reaktion auf die Softwarekrise war die Erfindung des Software-Engineering: eine Ingenieurs-Disziplin mit dem Ziel, die Produktion von Software kosteneffizient zu skalieren. Klingt vertraut, nicht wahr? Die Industrialisierung stand Anfang des 20ten Jahrhunderts vor einem sehr ähnlichen Problem und der damalige Lösungsansatz war Taylorismus in seinen verschiedenen Varianten. Es dürfte also nicht überraschen, dass das Software-Engineering viele tayloristische Konzepte und Praktiken aufgegriffen und auf die Softwareentwicklung übertragen hat.

Und damals war das auch vollkommen in Ordnung. Doch mit der Zeit hat sich die Rolle der IT essentiell gewandelt. In den 1980ern begann der Siegeszug des PC und Netzwerke gewannen an Bedeutung. Das mooresche Gesetz wirkte weiter, Computer wurden immer leistungsfähiger. Letztlich unterstützte die IT nicht mehr nur ausgewählte Geschäftsfunktionen, sondern zunehmend die Geschäftsprozesse im Ganzen. Sie rutschte immer näher an das Business mit all seiner Komplexität.

Diese Entwicklung ging weiter, das Internet begann seinen Siegeszug in den 1990ern und mittlerweile ist die IT das Nervensystem jeder nichttrivialen Firma: Das gesamte Businesswissen ist in IT codiert, IT-Ausfälle von nur wenigen Stunden gelten für viele Firmen als existenzbedrohend. Das bedeutet aber auch, dass Sie Ihr Business nicht mehr ändern können – weder neue Produkte noch neue Features oder Prozessänderungen –, ohne die IT anzufassen.

The Need for Speed

Wenn man die oben beschriebenen Beobachtungen zusammenfasst, zeigt sich, dass die IT zu einem entscheidenden Erfolgsfaktor für jede Firma geworden ist, um im Wirtschaftsdarwinismus bestehen zu können. Egal wie gut Sie die die Bedürfnisse und Forderungen Ihrer Kunden kennen, wenn Ihre IT nicht schnell genug liefern kann, werden Sie das Nachsehen haben.

Dennoch klammern sich die meisten Firmen an die Ideen des herkömmlichen Software-Engineering, wo es das primäre Ziel ist, die Produktion von Software kosteneffizient zu skalieren. Das Problem ist, dass Skalierung der Softwareproduktion und IT-Kosteneffizienz nicht mehr die entscheidendsten Treiber sind (tatsächlich schreiben wir heutzutage viel zu viel Software, es dauert nur zu lange und sehr oft ergibt sich nur ein Bruchteil des erwarteten Mehrwerts).

Der entscheidendste Treiber für die heutige IT sind Durchlaufzeiten – wie lange es dauert, um eine Idee zum Kunden zu bringen. Es geht also um die erforderliche Zeit, um die gesamte IT-Wertschöpfungskette zu durchlaufen, beginnend beim Aufnehmen der Anforderungen bis die Lösung live in der Produktion läuft.

Je kürzer diese Durchlaufzeiten sind, desto besser kann man sich an den sich ständig verändernden Bedarf der hochdynamischen Märkte anpassen. Wir brauchen „Speed“!

Verschärfte Bedingungen

Wenn wir uns den zweiten Megatrend – die Digitalisierung – ansehen, wird es noch etwas schwieriger: Mit Digitalisierung wird die IT das Business nicht mehr nur unterstützen, sondern selbst zum Business. Wir erzeugen neue Businessprodukte, die teilweise oder gänzlich aus IT bestehen. Auf der einen Seite verlangt das nach Innovation, da wir gerade erst verschwommene Ideen entwickeln, welche zukünftigen Geschäftsmodelle Trends wie z.B. das Internet der Dinge (Internet of Things, IoT) ermöglichen werden. Andererseits bedeutet das, dass unsere IT noch robuster als zuvor sein muss, da auch unsere Kunden ständig damit in Berührung kommen.

Der dritte Megatrend sind disruptive Technologien wie Cloud-Computing, Mobile Services, Big Data und IoT. Diese Technologien eröffnen ganz andere Möglichkeiten, um Geschäftsanforderungen umzusetzen, bis hin zu einer Ebene, wo sie vollständig neuartige Geschäftsmodelle ermöglichen. Da wir aber gerade erst begreifen, was wir mit diesen Technologien anstellen können, verschärfen sie die oben beschriebenen Bedingungen:

Wir müssen verstehen und lernen, wir müssen Innovation treiben, wir müssen uns an die sich ständig ändernden Märkte anpassen und das Ganze muss schnell geschehen, wobei wir die neuen Möglichkeiten disruptiver Technologien berücksichtigen müssen. Und wir werden nicht erfolgreich sein, wenn wir uns dabei an Ideen klammern, die vor vielen Jahren in einer gänzlich anderen Geschäfts- und IT-Ära entwickelt wurden.

Wir müssen IT neu denken!

IT neu denken

Dies war die Kurzversion der langen Geschichte, warum Durchlaufzeiten zum wichtigsten Treiber für die heutige IT geworden ist, warum wir IT neu denken müssen.

Doch wenn das alte Wissen, auf der wir immer noch die meisten unserer IT-Prozesse und Arbeitsabläufe aufbauen, nicht geeignet ist, um IT neu zu denken, was ist es dann?

Kernbausteine einer neuen IT, die auf die veränderten Treiber reagiert

Das ist eine durchaus berechtigte Frage. Ein guter Ausgangspunkt sind üblicherweise Organisation und Prozesse: Die Organisations- und die Systemtheorie haben gezeigt, dass sich dezentrale Organisationen mit vorwiegend autonomen Einheiten viel besser und deutlich schneller an die sich ständig ändernden Anforderungen anpassen können als hierarchische Organisationen, die auf tayloristischen Prinzipien beruhen. Außerdem sind dezentrale Organisationen typischerweise ein ganzes Stück robuster gegenüber unerwarteten Anforderungen.

Wenn wir uns einen Moment lang umsehen, werden wir schnell erkennen, dass es bei DevOps genau um diesen Punkt geht: Wir schaffen vorwiegend autonome Teams, die ganzheitlich Verantwortung für dedizierte Geschäftsfähigkeiten übernehmen und wir lassen sie auf alle Änderungsforderungen in ihrem Kompetenzbereich reagieren. Tatsächlich gehört noch viel mehr zu DevOps, wie zum Beispiel ganzheitliche Optimierung von Durchlaufzeiten, Verstärkung von Feedback-Schleifen, um gegebenenfalls erforderliches Wissen bereitzustellen, und eine Kultur des beständigen Lernens. Dies sind ebenfalls sehr wichtige Eigenschaften von DevOps, die genau in die Richtung der Treiber zeigen, die wir oben gesehen haben.

Doch DevOps allein genügt nicht. Wir müssen sicherstellen, dass Teamautonomie nicht durch Software und Systeme verletzt wird, an denen die Teams arbeiten. Wenn zum Beispiel viele Teams an einem großen Monolithen arbeiten (der leider die Tendenz hat, im Laufe der Zeit zu einem großen Brocken Spaghetticode zu verkommen), werden die Teams normalerweise jede einzelne Änderung koordinieren müssen und die Autonomie ist dahin. Wenn wir Software nur in großen Alles-oder-nichts-Releases freigeben können, wenn wir mit einem Laufzeit-Megamonolithen konfrontiert sind, müssen die Teams sämtliche Änderungen koordinieren und sich auf ein Release-Datum verständigen – und die Autonomie ist ebenfalls dahin.

Wir brauchen also ein Architekturmuster, das Autonomie in Bezug auf Entwicklung und Bereitstellung von Software unterstützt. Microservices sind ein solches Architekturmuster. Deren Eigenständigkeit („Self-containment“) und problemlose Erfassbarkeit für den Einzelnen („Fits in one brain“) unterstützen Teamautonomie sehr gut. Zudem erlauben sie schnelle Änderungen und kurze Durchlaufzeiten. Faktisch sind Microservices nicht der einzige Stil, der den gegebenen Anforderungen entspricht, und zugegebenermaßen ist es recht einfach, sie zu verpfuschen und am Ende vor einem großen verteilten Kuddelmuddel zu stehen (auch bekannt als „verteilte Hölle“). Doch richtig gemacht unterstützen sie Autonomie und schnelle Anpassung sehr schön.

Autonome DevOps-Teams, die auf die sich ständig ändernden Forderungen reagieren, müssen ihre Software auch freigeben („deployen“) können, wann immer sie wollen. Und wenn sie ihre Software mehrmals pro Tag freigeben müssen, darf das keine Probleme machen. Software unabhängig nach Bedarf freizugeben verlangt normalerweise nach Automatisierung. Manuelles Erstellen, Testen und Freigeben ist viel zu teuer und fehleranfällig, wenn dies häufig geschehen muss. Dies ist die Domäne von Continuous Delivery, das ja gerade das konsequente Automatisieren von Erstellen, Testen und Freigeben von Software zum Ziel hat.

Der letzte Teil des Bilds ist die Infrastruktur, auf der die Software läuft, da sie ebenfalls sehr flexibel sein muss. Wenn es Tage, Wochen oder Monate dauert, um die erforderliche Infrastruktur für Entwicklung, Bauen, Testen oder Freigeben zu bekommen, ist jede Teamautonomie und Reaktionsfähigkeit dahin. Die Teams müssen in eigener Regie auf die erforderliche Infrastruktur zugreifen können („Self-service access“), wann immer sie sie brauchen, und sie müssen sie auch wieder abstoßen können, sobald sie sie nicht mehr brauchen. Genau diesen Anforderungen entspricht das Cloud-Bereitstellungsmodell. Darüber hinaus ermöglicht der API-basierte Ansatz elastisches Skalieren zur Laufzeit sowie bessere Automatisierung des Build-, Test- und Freigabeprozesses.

Weitere Überlegungen

Wir haben gesehen, dass DevOps, Microservices, Continuous Delivery und Cloud-Computing Kernbausteine einer neuen IT sind. Doch reicht das aus für unsere neue IT oder fehlen noch irgendwelche Teile?

Bausteine einer neuen IT, einschließlich unterstützender Elemente

Tatsächlich fehlen einige unterstützende Teile. Das erste ist das Unternehmensarchitektur-Management (Enterprise Architecture Management, EAM), doch nicht auf die Weise, wie man es kennt. Es hat keinen Mehrwert, Unmengen von Bildern im Voraus zu zeichnen und zentral zu versuchen, die gesamte IT-Landschaft im Detail unmittelbar vom Elfenbeinturm aus vorauszuplanen und zu beschreiben. Dies wird standardmäßig ein Flaschenhals sein und ist ziemlich genau das Gegenteil von dem, worum es bei DevOps geht.

Dennoch gibt es einige wichtige Aufgaben in einer DevOps-Organisation, wo EAM eine Menge Mehrwert erzeugen kann: Selbst wenn die Teams möglichst unabhängig und autonom sein sollten, müssen sie trotzdem noch an einem gemeinsamen Ziel arbeiten. Hier bietet sich EAM an, um die gemeinsame Vision zu verbreiten und den Teams zu helfen, das große Ganze im Blick zu behalten.

Zweitens ist totale Teamautonomie nicht möglich, da alle Teams auf ein gemeinsames Ziel hin arbeiten und die von ihnen produzierte Software zusammenspielen muss. Das heißt Koordination. Die Teams müssen sich wechselseitig abstimmen, wie ihre Software mit der jeweils anderen zusammenarbeitet. Das kann recht umständlich und ineffizient sein, wenn über jede einzelne Interaktion von Grund auf neu abgestimmt werden muss. Deshalb ist es sinnvoll, sich über bestimmte Interaktionsstandards über alle Teams hinweg zu verständigen. Diese Minimalmenge an Standards zu ermitteln und zu pflegen, ist ebenfalls eine gute Aufgabe für EAM.

Eine andere Definition ist, dass sich EAM um das große Ganze und den Raum zwischen den Verantwortlichkeiten der Teams kümmert. Eine letzte Anmerkung zu EAM: Normalerweise ist dies kein Vollzeitjob und es sollte kein Elfenbeinturmteam damit betraut werden. Stattdessen sollte das EAM-Team aus Abgesandten der DevOps-Teams bestehen, die sich gelegentlich oder einfach nur bei konkretem Bedarf treffen.

Der zweite große unterstützende Baustein ist das Führungsmodell („Governance“). Wir müssen immer noch sicherstellen, dass die Visionen des Top-Level-Managements und die Arbeit der Teams zueinander passen. Wichtig ist Transparenz – was geschieht in den Teams? Und ebenso wichtig ist, dass das Top-Level-Management den Teams Richtungsänderungen effizient vermitteln kann.

Die herkömmlichen Führungsmodelle von hierarchischen Organisationen sind nicht geeignet für eine DevOps-Organisation, die Durchlaufzeiten und Marktreaktivität optimiert. Wir brauchen ein anderes Führungsmodell. Das gute daran ist, dass diese Führungsmodelle schon eine ganze Zeit bekannt sind und von diversen großen Firmen, die sie übernommen haben, erfolgreich in der Praxis erprobt wurden. Diese Modelle sind unter dem Namen „Beyond Budgeting“ oder „Beta-Kodex“ (eine Weiterentwicklung von „Beyond Budgeting“) bekannt.

Als dritter großer unterstützender Baustein ist Craftsmanship zu nennen. Ja, es geht um Menschen (leider vergessen wir das allzu oft)! Wir müssen allen beteiligten Personen helfen, ein verändertes Verständnis bzgl. der Art und Weise zu entwickeln, wie sie arbeiten.

Auf der einen Seite ist es wichtig, den Leuten dabei zu helfen, ständig die Art und Weise zu verbessern, wie sie ihre Arbeit erledigen und mit ihren Kollegen zusammenarbeiten. Man bezeichnet dies auch als „Meisterschaft“ („Mastery“). Eine Haltung der Art „alles wird sich finden“ ist nicht mehr ausreichend. Dies ist die Kernidee von Craftsmanship.

Auf der anderen Seite brauchen die Menschen kein stabiles Arbeitsmodell mehr, sondern vielmehr ein robustes Veränderungsmodell. Menschen brauchen Orientierung – einige Regeln und Ankerpunkte, an denen sie sich orientieren können. In der Vergangenheit wurde den Leuten ein Modell vorgesetzt, wie sie ihre Arbeit zu erledigen haben, entweder mithilfe detaillierter Prozessbeschreibungen oder über weniger förmliche Richtlinien.

Das Problem bei diesem Ansatz ist, dass sich die Arbeitsweise ständig ändert, da sich Firmen fortwährend an die sich ständig ändernden Bedürfnisse und Forderungen ihrer Kunden anpassen müssen. Demzufolge ist es nicht möglich, ein Arbeitsmodell bereitzustellen, das über einen längeren Zeitraum stabil ist. Deshalb ist es notwendig, den Leuten ein Modell an die Hand zu geben, mit dem sie leichter verstehen können, wann eine Veränderung notwendig ist und warum. Wir gehen also eine Stufe nach oben vom Bereitstellen eines stabilen Arbeitsmodells zum Bereitstellen eines robusten Veränderungsmodells. Selbst wenn dies kein zentraler Aspekt von Craftsmanship ist, gehört er zweifellos in diesen Bereich.

Fazit

Wir müssen IT neu denken – die Märkte, in denen die Firmen agieren, haben sich geändert, die IT selbst hat sich geändert. Die Rahmenbedingungen, unter denen unsere traditionellen IT-Modelle entwickelt wurden, existieren nicht mehr. Unser primärer IT-Treiber ist nicht mehr die kosteneffiziente Skalierung der Softwareproduktion, vielmehr geht es darum, die Durchlaufzeiten zu minimieren, um die Reaktionsgeschwindigkeit des Unternehmens zu maximieren.

Die Kernbausteine für diese neue IT sind DevOps, Microservices, Continuous Delivery und Cloud-Computing, die durch einige zusätzliche Elemente wie EAM (ebenfalls neu gedacht!), Beyond Budgeting und Craftsmanship ergänzt werden müssen.

Immerhin ist dies lediglich das „große Bild“, eine Draufsicht aus 10.000 Metern Höhe. Es gibt viele Schattierungen, die ich zugunsten der Kürze weggelassen habe – und dennoch ist es ziemlich lang geworden. Außerdem besteht jeder hier erwähnte Baustein aus vielen weiteren Details auf verschiedenen Ebenen. Und es sind jede Menge Details zu berücksichtigen, um nicht alles am Ende zu verpfuschen. Doch das sind andere Geschichten …