This article is also available in English
Dieser Artikel ist Teil einer Reihe.
- Teil 1: Gängige Methoden im Umfeld soziotechnischer Architekturen
- Teil 2: Plattformen, Teams und APIs: Wie passt das zusammen?
- Teil 3: Soziotechnische Architektur als Wettbewerbsvorteil
- Teil 4: Vergesst die Menschen nicht
- Teil 5: Wieviel Denken erträgt ein Team?
- Teil 6: Interne Entwicklungsplattformen – Shift Down statt Shift Left (dieser Artikel)
- Teil 7: Enabling von Stakeholdern als Erfolgsfaktor
- Teil 8: Soziotechnische Architekturen: Informalität vom Bergbau bis heute
Die Älteren erinnern sich: Vor der Zeit der agilen Softwareentwicklung gab es die Ära der großen Phasenmodelle, wie z. B. das Wasserfallmodell. Bis die Nutzer:innen laufende Software zum ersten Mal zu Gesicht bekamen, verging viel Zeit. Übergaben zwischen Teams, etwa zwischen Entwicklung und QA, waren aufwändig und zeitraubend. Alle beteiligten Teams waren weit von echter Autonomie entfernt. Jedes Team hing innerhalb des Entwicklungsprozesses immer mindestens von dem Team vor und nach ihm stark ab. Die mentale Last des Entwicklungsteams war dabei allerdings vergleichsweise niedrig. Entwickler:innen mussten hauptsächlich Entwurfsprinzipien, Programmiersprachen und Frameworks kennen.
Agilität erhöht Autonomie, aber auch mentale Last
Ende der 1990er-Jahre kam die Agilität auf, z. B. mit Modellen wie Extreme Programming, Scrum oder Crystal. Diese Modelle versprachen damals die schnelle Lieferung von Software im 6-Wochen-Takt im Vergleich zu den üblichen 6 bis 24 Monaten. Das lag unter anderem daran, dass es teilweise keine Übergaben mehr gab. Das Entwicklungsteam war nun „cross-funktional“. Verschiedene Rollen wie Requirements Engineering, Entwicklung und Testen waren nun Teil eines einzigen Teams. Security und Betrieb lagen allerdings weiterhin außerhalb des Entwicklungsteams. Die mentale Last stieg jedoch deutlich an. Neben der Softwareentwicklung mussten Entwickler:innen nun auch automatisierte Tests schreiben, oft direkt mit den Nutzer:innen sprechen, User Stories schätzen, Ergebnisse präsentieren und vieles mehr.
Shift Left, DevOps und „You Build It, You Run It“
Nach dem Erscheinen des Buches Continuous Delivery (2010) [1] und dem berühmten Interview mit Werner Vogels zur Softwareentwicklung bei Amazon (2006) [2] wanderte auch der Betrieb in das Entwicklungsteam („You Build It, You Run It“). Der Begriff „Shift Left“ wurde populär.
Der Ursprung des Begriffs liegt im Wasserfallmodell, das visuell von links nach rechts dargestellt wird. „Shift Left“ bedeutet, dass Aufgaben wie Testing oder Betrieb „nach links“ verschoben werden, also in frühere Phasen des Prozesses, wie Architektur oder Entwicklung.
Entwicklungsteams, die viele Tätigkeiten erfolgreich nach links verschieben konnten, waren in der Lage, sehr schnell qualitativ hochwertige Software zu liefern. Warum? Sie hatten eine sehr hohe Autonomie. Geschwindigkeit wird erreicht, indem Handoffs zwischen Teams verkürzt oder gar eliminiert werden. Die mentale Last für diese Teams ist jedoch erheblich gestiegen. Zu den bisherigen Aufgaben kamen Betrieb und Infrastruktur hinzu, etwa die Betreuung von CI/CD-Pipelines, Cloud-Technologie, On-Call-Rotation oder Observability.
Die mentale Überlastung: Von Shift Left nach Pile Left
Mit der Einführung von Konzepten wie DevSecOps, FinDev und FinOps wurden Entwicklungsteams immer mehr Fähigkeiten abverlangt. Viele Unternehmen stellten fest, dass dies für Entwicklungsteams nicht mehr zu bewältigen war. Es handelte sich nicht mehr um ein „Shift Left“, sondern um ein „Pile Left“.
Entwicklungsteams hatten plötzlich zu viele Verantwortlichkeiten. Sie sollten sich – im Namen von hoher Autonomie und Liefergeschwindigkeit – um alles kümmern. In manchen Fällen wurde von Entwicklungsteams sogar erwartet, sich um den Kauf von Lizenzen zu kümmern.
„Pile Left“ führte unweigerlich zu Problemen. Es gibt Grenzen, was ein Entwicklungsteam leisten kann und soll. UX, Security, QA, Infrastruktur, Betrieb und andere Bereiche sind komplexe Disziplinen, die spezialisierte Fähigkeiten erfordern. Sehr erfahrene Teams mit einem guten Mix aus Kompetenzen können diese Aufgaben möglicherweise übernehmen, aber Unternehmen mit mehreren Teams können sich nicht darauf verlassen, dass alle Teams entsprechend aufgestellt sind oder die notwendigen Fähigkeiten schnell genug erlernen können.
Effizient ist diese Herangehensweise ohnehin nicht.
Die Komplexität des Lebens von Entwickler:innen hat in den letzten 25 Jahren stetig zugenommen. Was Ende der 1990er-Jahre, zur Zeit des Aufkommens der Agilität, undenkbar war – dass Entwickler:innen für die Testautomatisierung verantwortlich sein könnten – ist heute völlig normal.
Zusätzlich arbeiten wir heute mit größeren und komplexeren Softwaresystemen, die mehr Entwickler:innen in mehr Teams erfordern. Beides führt dazu, dass es sich für viele Unternehmen lohnt, in Enabling Teams und Internal Developer Platforms zu investieren. Diese helfen, redundante Arbeit und Wissensaufbau besser zu organisieren und so die steigende Komplexität zu bewältigen.
Mit Plattformen und Enabling hin zu Shift Down
Wenn eine hohe Autonomie für viele Entwicklungsteams eine hohe mentale Last erzeugt, müssen Lösungen gefunden werden. Aktuell gibt es zwei sich ergänzende Ansätze: Internal Developer Platforms (IDPs) und Enabling Teams [3].
IDPs versuchen, so viel wie nötig von dem oben genannten Spezialwissen in der Plattform „zu verstecken“ („Shift Down“). Sie können sich beispielsweise um Infrastrukturprovisionierung, Monitoring, Dashboards, Log-Infrastruktur, CI/CD, Security (z. B. Secrets-Management, Vulnerability-Checks, Autorisierung und Authentifizierung), Lizenz-Scanning sowie um Application- und Service-Templates kümmern. Entwickler:innen müssen sich dadurch nicht mehr um „alles“ kümmern, da die IDP die im jeweiligen Kontext relevanten Arbeiten übernimmt.
Hier ist Vorsicht geboten: Zu viel Funktionalität in einer IDP ist problematisch, da dies die Kosten in die Höhe treiben kann. Zudem wird den Entwickler:innen möglicherweise die notwendige Freiheit zur Innovation auf der IDP genommen.
IDPs können und sollten sich auch um domänenspezifische Infrastrukturthemen kümmern. Eine IDP könnte beispielsweise eine „Kundendatenbank“ bereitstellen, die betriebliche Anforderungen an Lokalität, Verschlüsselung und Datensicherung für Kundendaten erfüllt. Dies geht über die Bereitstellung einer einfachen Cloud-Datenbank hinaus, die erst noch entsprechend konfiguriert werden müsste (Hohpe und Seitz [4]).
Eine Plattform kann vieles leisten, aber nicht alle mentale Last für Themen wie Infrastruktur, Security oder Testing von Entwicklungsteams fernhalten. Für diese Lücken benötigt man „Enabling“, also Coaching und Unterstützung durch spezielle Teams. Diese bündeln Expert:innen und haben die Aufgabe, andere Teams zu befähigen, spezifische Herausforderungen zu meistern.
Erfolgsfaktoren für Interne Developer Plattformen
Eine erfolgreiche IDP zu bauen und zu betreiben wird häufig unterschätzt. Eine IDP ist ein internes Produkt mit eigenen Kund:innen (Entwickler:innen, Operations, Business) und benötigt daher alles, was ein Produkt erfordert: Neben einem Entwicklungsteam auch Produktmanagement, gutes Requirements Engineering, Support, eine hervorragende Developer Experience, Self-Service-Fähigkeit und internes Marketing. Da dies erheblichen Aufwand verursacht, lohnt sich eine IDP in der Regel erst ab einer gewissen Größe der Entwicklungsorganisation. Je schlanker die IDP, desto eher kann sich ein Unternehmen eine leisten.
Ein Blick über den Tellerrand: Fachliche Plattformen
IDPs sind nicht die einzigen internen Plattformen, die es in Unternehmen gibt. Es existieren auch interne fachliche Plattformen, die mancherorts als „common services“ bezeichnet werden. Diese bieten Funktionen, die häufige und wiederkehrende Anforderungen vieler Entwicklungsteams der entsprechenden Fachdomäne abdecken, wie beispielsweise Payment-Abwicklung, Betrugserkennung oder Datenanalyse. Diese fachlichen Plattformen müssen als wichtige Business-Bausteine identifiziert, entwickelt, intern bekannt und auffindbar gemacht werden. Wie bei den IDPs gilt auch hier: Sie sind interne Produkte und benötigen dieselben organisatorischen Voraussetzungen und Aufgaben, um erfolgreich zu sein.