Der größte Bremsklotz für die Geschwindigkeit im Enterprise-Engineering ist weder technische Schuld noch Legacy-Code. Es ist die Provisioning-Steuer: die Zeit, die Entwickler mit Warten, Konfigurieren und Umgehen der Umgebungseinrichtung verbringen.
In Enterprise-Cloud-Teams ist diese Steuer enorm — und wird fast nie gemessen. Bei einem globalen Versicherer, mit dem ich gearbeitet habe, dauerte die Bereitstellung von Cloud-Infrastruktur über ein Jahr. Nicht, weil die Entwickler langsam waren. Sondern weil jede Umgebung manuelle Freigaben, individuelles Networking, Security-Reviews und eine Ticket-Warteschlange durchlief, für die sich niemand verantwortlich fühlte.
Die direkte Kosten sind Wartezeit. Schlimmer sind die indirekten.
Entwickler, die auf Umgebungen warten, hören nicht auf zu arbeiten. Sie wechseln auf andere Aufgaben und bauen kognitiven Overhead auf. Sie basteln Workarounds: lokale Umgebungen, die nicht zur Produktion passen, geteilte Dev-Server, die Konflikte erzeugen, Schatten-IT-Deployments, die die Freigabe-Warteschlange ganz umgehen.
Jeder Workaround wird zu Wartungsschuld, jeder Kontextwechsel knabbert an der Qualität. Die Steuer summiert sich.
Gemessen wird sie nicht — sie verteilt sich über Ticket-Queues, Slack-Threads und Kalenderblocker. Die Führung sieht "langsame Lieferung" und schließt daraus, das Engineering-Team brauche mehr Leute. Es braucht nicht mehr Leute. Es braucht weniger Stunden Wartezeit auf Infrastruktur.
Provisioning bleibt eine Steuer, weil es als Ticket-Warteschlange verantwortet wird und nicht als Produkt.
Eine Warteschlange hat ein SLA und bekommt mehr Personal, wenn der Rückstand wächst. Ein Produkt hat Adoption-Kennzahlen und eine Roadmap und bekommt Investitionen, wenn die Erfahrung schlecht ist. Die meisten Unternehmen betreiben Provisioning als Ersteres und wundern sich, dass es nie besser wird.
Sobald du Provisioning als Produkt behandelst — mit Self-Service-Oberflächen, Infrastructure-as-Code-Templates und automatisierten Compliance-Checks in der Pipeline — fällt die Steuer deutlich. Bei der Allianz haben wir die Bereitstellung mit genau diesem Ansatz von Monaten auf Tage gebracht.
Miss die Steuer. Zähl die Kalendertage zwischen "Entwickler fordert Umgebung an" und "Entwickler deployt den ersten Code in diese Umgebung". Multipliziere mit der Zahl der betroffenen Entwickler. Die Zahl wird groß genug sein, um Provisioning als vollwertiges Produkt zu behandeln statt als Supportfunktion.
Die günstigste Infrastrukturinvestition ist die, die deinen Entwicklern die Zeit zurückgibt, in der sie nicht entwickeln.