Zum Inhalt springen

Wissensbasis

Amazon Cost to Serve Software (CTS-SW)

Amazons Zahlen zur Developer Experience: was Amazon gemessen hat, wie die Einsparungen einen Business Case ergeben, was die Kosten senkt und welche Kennzahlen Amazon ablehnt.

Verfasst von

Aktualisiert:

Belege 7

Unsere Position. Das Developer-Experience-Fundament unter dem Modell ist der Teil der Factory, der nicht schrumpft. Das Modell verbessert sich nach eigenem Zeitplan, das Fundament darunter baut ihr selbst. Die meisten agentischen Tools, die ein Team kauft, überleben die nächste Modellgeneration nicht. Grundlagen, die zuerst Menschen und dann Agents helfen, überleben sie (sechs Investitionen, die die Tools überdauern (öffnet in einem neuen Tab)).

Amazons Zahlen stützen diese Position mit einem Ergebnis, das in Geld gemessen ist statt in eingesparten Minuten (Quantifying the Impact of Developer Experience: Amazon’s 15.9% Breakthrough (öffnet in einem neuen Tab)). Die meisten Hebel hinter der Senkung sind Grundlagen wie Build, Test, Review und Onboarding. Nur zwei der acht Hebel setzen KI ein.

Was ist Cost to Serve Software?

Amazon hat seine Kennzahl “cost to serve” aus dem eigenen Einzelhandelsgeschäft auf die Softwareauslieferung übertragen. CTS-SW = Gesamtkosten, um eine Einheit Software auszuliefern. Die Einheit hängt vom Team ab: Deployments bei Microservices, abgeschlossene Pull Requests bei Monolithen und Mobile Apps. So erfasst eine einzige ökonomische Kennzahl den gesamten SDLC, nicht bloß die Geschwindigkeit.

Die zentrale Erkenntnis: Klassische Produktivitätsmaße greifen zu kurz, etwa reine Geschwindigkeit, eingesparte Minuten oder Kennzahlen auf Aktivitätsebene. Sie ignorieren Qualität, Risiko und Verfügbarkeit und lassen sich manipulieren. CTS-SW knüpft an vermiedene Kosten und ROIC an, also an die Sprache, die Finance und Führung verstehen.

Was hat Amazon gemessen?

Amazon berichtet für 2024 diese Veränderungen gegenüber dem Vorjahr:

  • 15,9 % weniger CTS-SW (vermiedene Kosten, nicht bloß Tempo)
  • 18,3 % mehr wöchentliche Produktions-Deployments pro Builder
  • 30,4 % weniger menschliche Eingriffe pro Deployment (Automatisierung)
  • 32,5 % weniger incidentbezogene Tickets pro Deployment (seit 2022)

Wie werden die Einsparungen zum Business Case?

Unternehmen (Software unterstützt das Geschäft): 1.000 Developer zu je 130.000 $ = 130 Mio. $ Kostenbasis. 15 % CTS-SW-Verbesserung = 20 Mio. $ vermiedene Kosten. Bei 2 Mio. $ Lösungskosten = 10-facher ROI.

Tech-Unternehmen (Software ist das Produkt): 400 Developer, Software = 60 % des Umsatzes. 15 % CTS-SW-Verbesserung = 9 Prozentpunkte mehr Bruttomarge. Bei 15 % Gewinnmarge = 60 % mehr Gewinn.

Was senkt die Cost to Serve?

  • Build- und Testprozesse verschlanken
  • Code Reviews effizienter machen
  • Neue Builder schneller einarbeiten
  • Updates und Upgrades zentralisieren (weniger Toil)
  • Sicheres, einfaches CI/CD-Tooling (weniger manuelle Schritte, weniger Rollbacks)
  • Technische Schulden und häufige Fehlerquellen abbauen
  • KI-gestützte Migrationen (Java-Versionsupgrades mit Amazon Q Developer)
  • KI-gestützter Wissenszugang (Q Business für Onboarding und Loganalyse)

Welche Produktivitätsmaße lehnt Amazon ab?

  • Nur die Geschwindigkeit messen (ignoriert Qualität, Risiko, Verfügbarkeit)
  • “minutes saved” für einzelne Tätigkeiten berechnen (ergibt keinen Geschäftswert)
  • Kennzahlen auf Aktivitätsebene, die zu eng an bestimmte Aufgaben gebunden sind (manipulierbar)
  • Isolierte Teams, die nur optimieren, was sie direkt kontrollieren

Verwandte Seiten

Quellen

Artikel