„Bottlenecks“ in der Software-Entwicklung

Wenn man sich die Deployment-Häufigkeit großer Firmen ansieht, stößt man auf gewaltige Unterschiede. Woher kommt die Diskrepanz? Wie soll man nach dem „Bottleneck“, dem Flaschenhals, der den Software-Entwicklungsprozess behindert, suchen? Und was sind die Lösungsansätze, wenn das „Bottleneck“ gefunden wurde?

Wie häufig deployen führende IT-Unternehmen neue Software?

Warum ist es für Unternehmen wichtig, häufig neue Software in Produktion zu bringen?
Gilt nicht der Grundsatz: „never change a running system“ – „verändere nie ein (gut) laufendes System“?

Um in der aktuellen VUCA-Welt die Wettbewerbsfähigkeit aufrecht zu halten, ist „time to market“ ein extrem wichtiger Faktor. Wer möchte schon gerne der Konkurrenz hinterherhinken?
Und das bedeutet dann, dass man neue Funktionalität schnell deployen, d.h. erfolgreich in Produktion bringen muss. Wobei, was heißt eigentlich „schnell deployen“?

Wenn man den Daten im Web trauen kann, dann liegen auf der einen Seite des Spektrums folgende Firmen:

• Amazon: 23.000 Deployments pro Tag
• Google: 5.500 Deployments pro Tag
• Facebook: 1 Deployment pro Tag

Typische Großunternehmen in Deutschland kommen dagegen – auf der anderen Seite des Spektrums – auf etwa 4 große Releases pro Jahr, ca. ein kleineres Release pro Monat und dann vielleicht noch ein paar Hotfix-Releases, die zwischendurch eingestreut werden.
Das ergibt ca. 1 Deployment in zwei Wochen.

Woher kommt diese enorme Diskrepanz?
Gehen Amazon und Google hier größere Risiken ein oder sind leichtfertiger mit ihren Releases? Eher nein – beide Firmen sind genauso auf fehlerfreie, permanent funktionierende Software in Produktion angewiesen wie das hier aufgeführte „typische Großunternehmen“. Sie gehen daher sorgfältig vor.

Möchten andere Unternehmen nicht auch häufiger Releases in Produktion bringen?
Was hindert sie? Betrachten wir doch dazu eine typische Wertschöpfungskette in der Software-Entwicklung und fragen uns, ob und wo es dort ggf. einen Flaschenhals („Bottleneck“) gibt.

Analyse des Software-Entwicklungsprozesses

• Am Anfang der Kette steht hier der Fachbereich mit seinen Wünschen/Vorgaben und seiner maßgeblichen Beteiligung am fachlichen Design (Anforderungsdefinition – lassen wir hier einmal agile Entwicklungsmodelle außer Betracht).
• Das technische Design dazu und die technische Umsetzung liegt in der Hoheit der Anwendungsentwicklung.
• Das Ergebnis deren Arbeit muss im Test verifiziert werden – gerne unter Beteiligung von sowohl Fachbereich als auch Anwendungsentwicklung.
• Nach erfolgreichem Test geht die Software ins Deployment/Release, meist durch die Betriebskollegen unter Mitwirkung der Anwendungsentwicklung.

Wo stecken jetzt die Showstopper und „Bottlenecks“, die die Durchführung von mehr als 20 Releases im Jahr verhindern?

Nehmen wir im ersten Schritt den Fachbereich unter die Lupe: Er hat mehr Ideen als er Umsetzungsbudget dafür hat.
Ist das der Faktor, der die gesamte Kette bremst?
Stellen wir uns die Frage, was passieren würde, wenn der Fachbereich mehr Budget hätte. Ginge dann alles schneller?

Voraussichtlich nicht. Die gewünschten Umsetzungen bis zum Release dauern lange. Das Budget ist zwar ein „Bottleneck“, aber nicht der Kernpunkt, der die Gesamtkette in der Umsetzung ausbremst.
(Der Fachbereich kann auch noch zu einem Bottleneck werden, wenn Arbeitsergebnisse (z.B. Analysen) zu lange dauern, bis sie fertig sind – aber das wollen wir hier nicht weiter betrachten).

Werfen wir einen Blick auf das nächste Element der Wertschöpfungskette:

Die Anwendungsentwicklung muss sich um viele parallellaufende Software-Projekte kümmern. Die resultierenden Rüstzeiten verlangsamen die Entwicklung. Und ein:e Entwickler:in kann entweder Projektarbeit machen oder ein Produktionsproblem lösen – nicht beides.

Dieser Schritt in der Kette läuft erkennbar nicht optimal, aber dennoch könnte die Anwendungsentwicklung mehr bereitstellen, als am Ende tatsächlich in Produktion geht. Wir müssen weitersuchen.

Wie gut oder schlecht sieht es denn beim Test aus?

Trotz vielfältiger Bemühungen, auf der Basis von Test Driven Design (TDD) zu arbeiten und die Tests zu automatisieren ist der Test noch immer aufwändig und größtenteils manuell mit Experten-Knowhow durchgeführt. Ähnlich wie bei der „Umsetzung“ ist dies nicht der entscheidende Engpass.

Schauen wir nun auf das tatsächliche Deployment und die Release-Durchführung am Ende der Kette:

Wenn ein Unternehmen mit formalen Releases und Stabilisierungsphasen/“frozen zones“ arbeitet („Enterprise-Release“, „Monats-Release“, Infrastruktur-Release“, etc.), dann limitiert die Zahl der Releases das, was für den Fachbereich in Produktion gebracht werden kann.

Neben dieser eher organisatorischen oder prozessualen Performance-Grenze gibt es dann sehr häufig noch viele manuelle Schritte, die den eigentlichen Deployment-Prozess langsam und fehleranfällig machen. Noch immer ist es ein weiter Weg für die Betriebsteams die Deployments vollständig zu verscripten. Viele Tools unterstützen inzwischen das Deployment, aber ihre Orchestrierung, damit sie auf Knopfdruck automatisch funktionieren, ist oft eine nicht angegangene Aufgabenstellung.

So lange ein Mensch z.B. der verantwortliche im Release-Management noch sein schriftliches OK zum Deployment anhand von eingereichten Testberichten geben muss, können die Deploymentzahlen von Amazon oder Google nicht erreicht werden. An dieser Stelle wird die fehlende vollständige Testautomatisierung dann auch zum Mit-Showstopper.

Mit dem Deployment-Schritt haben wir den zentralen Flaschenhals der betrachteten Wertschöpfungskette gefunden. Wenn wir diesen Schritt verbessern können, optimieren wir sofort die gesamte Kette.

Aber wie können wir diese Optimierung erreichen?

Optimierung des Deployments

Woher kommen denn diese großen, seltenen Einzeldeployments (Releases)?
Sie sind oft großer Komplexität und einem großen Sicherheitsbedürfnis geschuldet. Die Komplexität resultiert aus dem Ineinandergreifen von zahlreichen Software-Komponenten, das mit manuellen Mitteln nur schwer auszutesten ist.
Das Sicherheitsbedürfnis ergibt sich aus der Kritikalität der Anwendungen für das Unternehmen, das sich Fehlerfunktionen in Produktion nicht leisten kann (beispielsweise müssen Banküberweisungen fehlerfrei ausgeführt werden – der Schaden an Image oder Wirtschaftlichkeit des Unternehmens wäre sonst immens).

Aber gilt das mit der angestrebten Fehlerfreiheit nicht auch für die anfangs genannten Firmen Amazon oder Google? Was machen diese Firmen anders bei ihren Deployments?

Die Antwort: sie haben ihre Tests und ihre Deployments vollständig automatisiert. Sie haben alle manuellen Schritte, die hier langsam und fehleranfällig sind, eliminiert (im Sinne von „Infrastructure as Code“).
Sie haben die Schranken zwischen Anwendungsentwicklung und Betriebsteam entfernt und auf Basis eines DevOps-Teams Synergien gehoben und Zusammenarbeit gefördert, wo vorher Arbeiten „über den Zaun geworfen“ wurden. Das Ergebnis heißt „Continuous Integration“ oder „Continuous Deployment“ (CD).

„Das geht bei uns nicht“

Da höre ich schon die Stimmen, die sagen: „Das geht vielleicht bei Google, aber nicht bei uns.“ Warum nicht?

Die Technologie steht allen zur Verfügung. Es gibt keine technischen Gründe, die eine Firma hindern würden, ähnlich wie die großen IT-Firmen vorzugehen. Vielmehr wird eine Verbesserung von Tests & Deployments oft nicht als vorrangiges Ziel verfolgt – und damit auch der mögliche Nutzen nie realisiert.

Es gibt Ansätze zur Automatisierung des Deployments, aber sie bleiben oft unzureichend. Viele Tools werden eingesetzt, aber nicht konsequent durch Scripting u.ä. miteinander verbunden, so dass doch wieder Expert:innen mit manuellen Eingriffen das Deployment abschließen müssen (Beispiel: Vergabe der Passwörter für technische User in Produktion).

Ähnlich sieht es bei der Testautomatisierung aus. Als Argument wird dann gerne vorgebracht, dass die Pflege der automatisierten Tests so aufwändig ist, wie die manuelle Durchführung der Tests. Das mag sogar sein.

Aber in dem einen Fall erhalte ich die Möglichkeit, komplexe Software auf Knopfdruck auf die korrekte Funktionsweise zu prüfen – und das beliebig oft, zu jeder Tages- und Nachtzeit.
Im anderen Fall muss ich darauf warten, dass die Tester:innen die Zeit für einen Testlauf finden. Und das dann nachher manuell in den entsprechenden Tools dokumentieren, damit jemand anders dann darauf schauen kann und den Test als „abgeschlossen“ und die Software als „freigegeben“ erklären kann. Aber, sind das wirklich wertschöpfende Tätigkeiten? Nein.

Dann sollte besser der Weg eingeschlagen werden zu einer Erhöhung der täglichen Builds und Deployments.

Wie erhöhe ich die Zahl der Deployments?

Die Kernstichpunkte auf dem Weg zu einem schnellerem Deployment – als Vorstufe zu „Continuous Deployment“ – habe ich im Vorangegangenen schon erwähnt. Es sind:

• Aufbau von DevOps-Teams
• Umstellung auf 100% automatisiertes Testing
• Anpassung auf „Infrastructure as Code“ zur Automatisierung der Deployment-Arbeiten

Die DevOps-Teams bilden das Thema auf organisatorischer Ebene ab. Es ist ein Team, das an einem gemeinsamen Ziel arbeitet – das „Über den Zaun werfen“ entfällt.

Das 100% automatisierte Testing ermöglicht schnelles Testen zu beliebigen Zeitpunkten und mit beliebiger Häufigkeit.

Wenn die Konfiguration der Infrastruktur wie ein Code betrachtet wird, dann ist der erste Schritt zu Versionsverwaltung, Verskriptung, etc. gemacht.

Da kommt die Frage auf, mit welchem Toolstack das Ganze abgebildet werden soll. Dies kann nicht pauschal beantwortet werden, sondern nur im Kontext Ihrer technischen Architektur und Ihrer Software-Architektur. Wir von it-economics beraten Sie dabei gerne.

Wenn dann viel mehr Deployments als vorher möglich geworden sind, kann man die Deployment-Frequenz, die sich aus den genannten Maßnahmen ergibt, dann z.B. als Maßstab für den Erfolg verwenden (s. DORA-Metrics).

Noch mehr Unternehmen als die zu Beginn genannten, sind auf diesem Weg schon sehr erfolgreich unterwegs (z.B. auch Netflix, Adobe oder Sony Pictures Entertainment)

Suchen Sie auf diesem Weg externe Unterstützung durch einen in diesem Themenfeld sehr erfahrenen Partner? Sprechen Sie mich und meine Kollegen von it-economics gerne dazu an.

Autor

Martin Joswig
Senior Manager