Der größte Bremsklotz für die Geschwindigkeit im Enterprise-Engineering, dem ich immer wieder begegne, ist die Provisioning-Steuer: die Kalenderzeit zwischen dem Moment, in dem ein Entwickler eine Umgebung anfordert, und dem ersten Deploy in diese Umgebung, plus alles, was Entwickler tun, um mit dieser Wartezeit zurechtzukommen.
In Enterprise-Cloud-Teams ist diese Steuer groß und steht fast nie auf einem Dashboard. Bei der Allianz dauerte die Bereitstellung neuer Infrastruktur im schlimmsten Fall über ein Jahr, quer durch manuelle Freigaben, individuelles Networking, Security-Reviews und eine Ticket-Warteschlange.
Die direkten Kosten sind Wartezeit. Die indirekten sind größer, und sie verstecken sich besser.
Entwickler, die auf Umgebungen warten, hören nicht auf zu arbeiten. Sie wechseln auf andere Aufgaben und tragen den kognitiven Overhead jedes Wechsels mit sich herum. Sie bauen Parallel-Setups, um weiterzukommen, und jedes davon wird später zu etwas, das gewartet, migriert oder einem Auditor erklärt werden muss.
Nichts davon taucht in einem einzelnen Bericht auf. Es verteilt sich über Ticket-Queues, Slack-Threads und Kalenderblocker, also sieht die Führung „langsame Lieferung“ und schließt daraus, das Engineering-Team brauche mehr Leute. Was das Team braucht, sind weniger Stunden Wartezeit auf Infrastruktur.
Provisioning bleibt eine Steuer, weil es als Ticket-Warteschlange betrieben wird. Eine Warteschlange hat ein SLA und bekommt mehr Personal, wenn der Backlog wächst. Ein Produkt hat Adoption-Kennzahlen und eine Roadmap und bekommt Investitionen, wenn die Erfahrung schlecht ist. Die meisten Unternehmen betreiben Provisioning auf die erste Art und wundern sich, dass es nie besser wird.
Provisioning als Produkt zu behandeln, mit Self-Service-Oberflächen, Infrastructure-as-Code-Templates und Compliance-Checks in der Pipeline, hat die Wartezeit bei der Allianz für Standard-Umgebungen 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. Leg diese Zahl neben den Budgetantrag des Plattformteams.
Sie ist meistens groß genug, um die Diskussion zu beenden, ob Provisioning einen Product Owner verdient.