Enterprise Platform Engineering — Organisationsdesign, Personalbedarf und Fehlermuster ab 1.000 Engineers

Platform Engineering bei 200–500 Engineers ist vor allem eine Frage von „gut machen“ — Golden Paths definieren, den Capability-Stack der IDP aufbauen, ein Plattformteam einstellen, ausliefern. Platform Engineering ab 1.000 Engineers ist ein anderes Problem: Governance über Geschäftsbereiche hinweg, Konsistenz ohne Starrheit, betriebliche Koordination über mehrere Regionen, Change-Management auf dem Niveau, das die Aufsicht erwartet, und die politische Dynamik geschäftsbereichsübergreifender Infrastrukturentscheidungen.

Was sich ab 1.000 Engineers ändert

Drei strukturelle Verschiebungen:

1. Mehrere Platform-Engineering-Teams

Ein einzelnes Plattformteam skaliert bis etwa 50–100 Produktteams oder 500–1.000 Produkt-Engineers. Darüber zerfällt die Plattformfunktion — nach Domäne (Datenplattform, ML-Plattform, Infrastrukturplattform), nach Geschäftsbereich (Consumer Cloud, Enterprise Cloud, interne IT) oder nach Geografie (regionale Plattformteams unter regulatorischen Vorgaben).

Die Koordination mehrerer Plattformteams wird zu einer eigenen Disziplin — Governance einer Plattform aus Plattformen, gemeinsame Standards, Eskalationswege für plattformübergreifende Entscheidungen.

2. Der Governance-Aufwand wird erheblich

Architekturentscheidungen betreffen Tausende Engineers und Millionen Euro an wiederkehrenden Kosten. Entscheidungen können nicht ad hoc fallen; sie brauchen Governance — Architecture Review Boards, Prozesse für das Technologie-Radar, Abkündigungsrichtlinien, die Übergangsfenster von 2–3 Jahren respektieren, und eine Abstimmung über die Geschäftsbereiche hinweg.

Bei 200 Engineers funktioniert „Das Plattformteam entscheidet“. Ab 1.000 Engineers erzeugt „Das Plattformteam entscheidet allein“ einen politischen Gegenwind, der die Adoption stärker bremst, als die Entscheidung Zeit spart.

3. Change-Management auf Aufsichtsniveau

Für regulierte Unternehmen (Banken, Versicherer, öffentlicher Sektor, Telekommunikation, Energie, Gesundheitswesen) laufen Plattformen im Enterprise-Maßstab unter einem prüfungsfesten Change-Management. Produktionsänderungen durchlaufen eine dokumentierte Freigabe, sind aus Artefakten reproduzierbar und erzeugen Nachweise, die die Aufsicht verwerten kann.

Die Plattform selbst wird zu einem aufsichtsrelevanten Objekt — die Kontrollen nach DORA Artikel 6 leben im Code der Plattform.

Muster für das Organisationsdesign

Drei Muster, die wir im Enterprise-Maßstab sehen:

Muster A: An Domänen ausgerichtete Aufteilung der Plattform

Eigene Plattformteams pro großer Engineering-Domäne:

• Infrastrukturplattform — Compute, Networking, Storage, Identity
• Datenplattform — Data Warehousing, ETL, Echtzeit-Streams
• ML-/KI-Plattform — GPU-Scheduling, Model Serving, Feature Stores
• Anwendungsplattform — Laufzeitdienste, Deployment-Automatisierung

Jedes Plattformteam hat eigene Kunden (die Produktteams, die die jeweilige Domäne nutzen). Gemeinsame Standards werden über die Governance-Funktion gesichert.

Passt zu: Organisationen mit klaren Grenzen zwischen Engineering-Domänen (die meisten Fintechs, die meisten Consumer-Tech-Unternehmen dieser Größe).

Muster B: An Geschäftsbereichen ausgerichtete Plattformföderation

Eigene Plattformteams pro Geschäftsbereich:

• Plattform für das Privatkundengeschäft
• Plattform für das Firmenkundengeschäft
• Plattform für das Wealth Management
• Plattform für konzernweite Shared Services

Jeder Geschäftsbereich betreibt seine eigene Plattform auf einem gemeinsamen Substrat. Die Föderation läuft über Governance — Architecture Review Board, Technologie-Radar, Abkündigungsrichtlinien.

Passt zu: Organisationen mit starker Autonomie der Geschäftsbereiche (die meisten etablierten Finanzdienstleister, die meisten großen Industriekonglomerate).

Muster C: Hybrid — gemeinsames Substrat plus Domänen-Erweiterungen

Eine einzige grundlegende Plattform (Compute, Networking, Storage, Identity), die alle Geschäftsbereiche teilen. Domänenspezifische Plattformerweiterungen (ML-Plattform, Datenplattform) setzen darauf auf und werden von spezialisierten Domänenteams betrieben.

Passt zu: Organisationen, die Konsistenz (grundlegendes Substrat) mit Spezialisierung nach Domänen (ML, Daten) ausbalancieren.

In allen drei Mustern ist die Governance der Plattform aus Plattformen das tragende Element. Ohne sie führt die Aufteilung zu 50 verschiedenen Plattformen mit 50 verschiedenen Betriebsmodellen — deutlich schlechter als eine gut gesteuerte Plattform.

Personalrechnung

Für Platform Engineering im Enterprise-Maßstab hilft folgende Faustregel:

• Team für die grundlegende Substrat-Plattform — 1 Engineer pro 50–100 Produkt-Engineers. Bei 2.000 Produkt-Engineers sind das 20–40 Platform Engineers, verteilt auf Teilteams für Infrastruktur, Daten, Anwendungen und SRE.
• Domänen-Plattformteams — jeweils 5–15 Engineers, skaliert mit der domänenspezifischen Komplexität und der Zahl der Kunden.
• Governance- und Architekturfunktion — 3–8 Personen (Architekten, Verantwortliche für das Technologie-Radar, Verantwortliche für Abkündigungen).
• Betrieb und Rufbereitschaft — getrennt vom Build-Engineering; skaliert nach Vorfallvolumen und SLA-Stufe.

Gesamte Platform-Engineering-Funktion: etwa 5–10 % der gesamten Engineering-Belegschaft in reifen Plattformorganisationen. Darunter ist die Plattform strukturell unterfinanziert.

Governance-Modelle

Das Muster des Architecture Review Board (ARB) funktioniert im Enterprise-Maßstab, wenn es bewusst gestaltet wird:

Besetzung des ARB

Leitende Platform Engineers (eine Person pro Plattformteam) plus leitende Produkt-Engineers (rotierend, etwa 5 gleichzeitig) plus Security-Leitung plus Compliance-Leitung plus Chief Architect (Vorsitz).

Das Board prüft Architekturentscheidungen, die mehrere Teams betreffen, legt Zeitpläne für die Abkündigung ausgemusterter Fähigkeiten fest, genehmigt neue Abhängigkeiten von Herstellern oder Open-Source-Projekten und pflegt das Technologie-Radar (Adopt / Trial / Assess / Hold).

Entscheidungsrhythmus

Monatliche ARB-Sitzung für Routineentscheidungen. Quartalsweise für den strategischen Review. Asynchrone Entscheidungen zwischen den Sitzungen, wenn es zeitkritisch ist.

Was das ARB NICHT tut

Das ARB steuert nicht die Architekturentscheidungen einzelner Produktteams innerhalb ihres eigenen Verantwortungsbereichs im Detail. Diese bleiben Entscheidungen der Produktteams. Das ARB verantwortet ausschließlich teamübergreifende Entscheidungen.

Diese Grenze ist wichtig: ARBs, die übergreifen, erzeugen politische Reibung, die die Governance-Funktion selbst untergräbt.

Woran Enterprise Platform Engineering scheitert

Fünf Fehlermuster wiederholen sich:

1. Plattformfunktion als Kostenstelle statt als Werttreiber

Das Plattformteam wird als Overhead budgetiert. Die Stellen werden aus Kostengründen begrenzt. Investitionen in Golden Paths werden auf „nach der Auslieferung von Feature X“ verschoben. Sechs Monate später hat die Geschwindigkeit der Plattform nachgelassen, aber die Kosteneinsparungs-Erzählung bestimmt weiter das Budget.

Lösung: Messen Sie den Wert des Plattformteams in Kennzahlen der Geschwindigkeit des Produkt-Engineerings (Zeit bis zur Umgebung, Zeit bis zur Produktion, Fehlerquote der Deployments). Zeigen Sie die Wirkung in denselben Kennzahlen, mit denen der CFO die Produktivität der Produktteams bewertet.

2. Das Backstage-als-Plattform-Antipattern

Backstage kaufen und das Plattformproblem für gelöst erklären. Backstage funktioniert als Portal nur, wenn die zugrunde liegenden Fähigkeiten tatsächlich als Self-Service verfügbar sind. Enterprise-Organisationen, die Backstage vor dem Plattformsubstrat kaufen, bekommen schöne Kataloge über betrieblichem Chaos. Die Adoption stockt.

Lösung: Backstage als Oberfläche für die Nutzer, nachdem das Plattformsubstrat real existiert. Developer Self-Service von Ænix lässt sich mit Backstage kombinieren, wenn der Kunde das bevorzugt; das Cozystack Dashboard funktioniert ebenfalls.

3. Aufteilung ohne Governance

Mehrere Plattformteams entstehen organisch (jeder Geschäftsbereich baut seine eigene Plattform). Es gibt keine gemeinsamen Standards. Workloads zwischen Geschäftsbereichen zu verschieben, ist schwer oder unmöglich. Engineers können nicht ohne erhebliche Umschulung zwischen Geschäftsbereichen wechseln.

Lösung: Investieren Sie früh in Governance. Das ARB muss nicht schwerfällig sein; es muss nur existieren und Entscheidungsbefugnis haben.

4. Die herstellergeführte „Plattform aus der Box“

Ein großer Hersteller verkauft dem Kunden eine komplette Platform-Engineering-Lösung. Der Kunde akzeptiert. 18–24 Monate später funktioniert die Plattform für die Referenzkunden des Herstellers, aber nicht für diese konkrete Organisation. Der Vendor-Lock-in ist strukturell, die Kosten für einen Austausch sind enorm.

Lösung: ein Open-Source-Substrat (Cozystack, Vanilla Kubernetes usw.) mit optionalem kommerziellem Support. Der Kunde behält die architektonische Hoheit.

5. Optimierung auf technische Eleganz statt auf die Adoption durch Produktteams

Eine architektonisch schöne Plattform, die Produktteams nicht nutzen wollen. Die Adoption stockt. Das Plattformteam gibt den Produktteams die Schuld, die Produktteams dem Plattformteam.

Lösung: Interviews mit Produktteams als wiederkehrende Disziplin des Plattformteams. Messen Sie die Adoption pro Golden Path. Stellen Sie Pfade ein, die nicht angenommen werden. Bauen Sie Pfade, die dem entsprechen, was Produktteams tatsächlich anfragen.

Was Enterprise Platform Engineering von Ænix liefert

Ein typisches Projekt umfasst:

Arbeitspaket 1 — Bestandsaufnahme des Ist-Zustands

Erfassung der bestehenden Plattforminvestitionen: Teams, Technologie-Stack, Governance-Funktion, Adoptionskennzahlen, Ausgangswerte für die Zeit bis zur Umgebung. Oft ist das erste nützliche Artefakt die Bestandsaufnahme selbst — die meisten Enterprise-Organisationen haben kein einziges Dokument, das den gesamten Plattform-Footprint abbildet.

Arbeitspaket 2 — Design des Soll-Zustands

Empfehlung zum Organisationsdesign nach den oben beschriebenen Mustern. Personalprognosen pro Plattformteam. Design der Governance-Funktion (ARB-Charta, Entscheidungsrhythmus, Eskalationswege). Ersteinrichtung des Technologie-Radars.

Arbeitspaket 3 — Plattformsubstrat auf Basis von Cozystack (wo zutreffend)

Grundlegendes Substrat auf der Ænix Private Cloud Platform (für regulierte Organisationen) oder auf Developer Self-Service (für produktorientierte Organisationen). Multi-Region, Multi-DC, für Audits isolierte Umgebungen, Ausrichtung an DORA / NIS2, wo zutreffend.

Dieses Arbeitspaket ist nicht immer Teil des Projekts — manche Kunden behalten ihr bestehendes Substrat und beauftragen Ænix nur mit Governance und Disziplin.

Arbeitspaket 4 — Roadmap der Golden Paths

Die 5–15 Golden Paths mit der größten Hebelwirkung für die konkreten Bedürfnisse der Produktteams des Kunden identifizieren. In eine Reihenfolge bringen. Gestaffelt ausrollen. Adoptionskennzahlen.

Arbeitspaket 5 — Kompetenztransfer und betriebliche Übergabe

Die Ænix-Engineers reduzieren ihre direkte Beteiligung schrittweise. Die Platform-Engineering-Funktion des Kunden übernimmt die Verantwortung. Der Ænix-Retainer läuft für Beratung und Eskalationen unter SLA (Plus- oder Enterprise-Support-Stufe) weiter.

Wann dieses Projekt passt

Gute Passung:

• 1.000+ Engineers über mehrere Geschäftsbereiche oder Domänen
• Eine bestehende Platform-Engineering-Funktion, aber Probleme mit Governance, Adoption oder teamübergreifender Konsistenz
• Rückhalt durch Vorstand oder Geschäftsleitung für eine mehrjährige Plattforminvestition
• Regulatorische Pflichten (Finanzdienstleistungen, öffentlicher Sektor, Telekommunikation, Energie, Gesundheitswesen)
• Betrieb über mehrere Regionen oder Rechtsräume hinweg

Bedingte Passung:

• 500–1.000 Engineers — hier passt eher Developer Self-Service (schlankerer Umfang) als ein vollständiges Enterprise-Platform-Engineering-Projekt

Schlechte Passung:

• Kleinere Organisationen — Developer Self-Service oder Leistungen für Platform Engineering haben den richtigen Umfang
• Organisationen mit nur einem Geschäftsbereich, unabhängig von der Zahl der Engineers — der Governance-Aufwand zahlt sich nicht aus

Weiterführende Inhalte

• Leistungen für Enterprise Platform Engineering — die kommerzielle Landingpage
• Leistungen für Platform Engineering — der kleinere Umfang
• Leistungen rund um die Internal Developer Platform — das Projekt auf der IDP-Ebene
• Lösungsseite Developer Self-Service — für Organisationen mit Fokus auf Produkt-Engineering
• Produktseite Private Cloud Platform — für regulierte Organisationen
• Internal Developer Platform — 6 Muster ohne Backstage-Lock-in — sechs Muster aus der Produktion
• Reifegradmodell für Platform Engineering — Reifegradmodell mit fünf Stufen und acht Dimensionen
• Developer Self-Service — die Ökonomie der Entwicklungsgeschwindigkeit — der wirtschaftliche Fall für die IDP
• Private Cloud aufbauen — 90-Tage-Playbook — für das Arbeitspaket zum Aufbau des Substrats