Case: IDP für 500 Entwickler

Lernziele

Nach dieser Lektion kannst du den größten und offensten Platform-Case strukturiert bearbeiten: eine Internal Developer Platform für ein Enterprise mit 500 Entwicklern und heterogenen Tech-Stacks. Du lernst, die IDP in Schichten zu zerlegen, Golden Paths gegen Escape Hatches abzuwägen, bestehende Tools zu integrieren statt zu ersetzen und einen Rollout zu skizzieren, der an Adoption gemessen wird statt an Feature-Vollständigkeit.

Das Szenario

„Designe eine Internal Developer Platform für 500 Entwickler in 80 Teams. Die Tech-Stacks sind heterogen — Java, Go, Python, Frontend. Es gibt ein Plattform-Team mit 12 Personen.” Dieser Case ist gefährlich, weil er grenzenlos ist: Eine IDP berührt Provisionierung, CI/CD, Observability, Secrets, Dokumentation und Organisationsfragen. Genau das ist der Test — der Interviewer will sehen, ob du scopen kannst. Wer versucht, alles zu designen, liefert nichts in Tiefe; wer früh priorisiert („ich fokussiere auf den Pfad von Code zu Produktion, weil dort der meiste Schmerz sitzt”), zeigt Produktdenken. Die zweite versteckte Prüfung: 12 Plattform-Leute für 500 Entwickler — ein Verhältnis von etwa 1:40. Alles, was du designst, muss mit diesem Team betreibbar sein.

Anforderungen klären: Schmerz vor Features

Bei einer IDP klärst du nicht zuerst Technik, sondern Schmerzpunkte — denn eine IDP ist ein Produkt, und Produkte beginnen beim Problem:

• „Was ist heute der größte Engpass für Entwickler?” — Angenommen: Ein neuer Service braucht 3 Wochen bis Produktion, weil Repos, CI, Infrastruktur und Monitoring manuell über Tickets beantragt werden. Das definiert dein primäres Erfolgskriterium: Time-to-First-Deployment.
• „Welche Tools sind gesetzt?” — Angenommen: GitHub, Jira, PagerDuty, Datadog sind vorhanden und bleiben. Wichtige Konsequenz, laut ausgesprochen: „Ich integriere, ich ersetze nicht — ein Datadog-Rip-and-Replace würde das Projekt politisch und technisch versenken.”
• „Wie heterogen sind die 80 Teams wirklich?” — Angenommen: ~60 Teams bauen Standard-Web-APIs und Frontends, ~20 haben Sonderfälle (Data, ML, Legacy). Das begründet die Golden-Path-Strategie: Standardisiere die 75 %, gib den 25 % definierte Ausnahmewege.
• „Gibt es schon Kubernetes-Erfahrung und bestehende Cluster?” — Angenommen: Ja, mehrere Teams betreiben eigene Cluster wildwüchsig. Die IDP konsolidiert das.
• „Woran wird das Plattform-Team gemessen?” — Angenommen: DORA-Metriken und Adoption. Das brauchst du später für den Rollout-Teil.

Architektur: die IDP in vier Schichten

Zerlege die IDP in Schichten und designe sie von unten nach oben — so bleibt das Bild auch bei einem so breiten Thema geordnet:

Schicht 1 — Compute & Runtime: Kubernetes mit dem Namespace-as-a-Service-Modell aus dem vorigen Case. Die IDP baut auf der Multi-Tenant-Plattform auf, sie ersetzt sie nicht.

Schicht 2 — Delivery: Pro unterstütztem Stack ein Golden Path: ein Template, das Repo, CI-Pipeline, Dockerfile, Kubernetes-Manifeste, Observability-Anbindung und Katalog-Eintrag in einem Schritt erzeugt. Deployments laufen über GitOps (Argo CD) — Teams committen, die Plattform rollt aus. Der Golden Path ist dabei keine Pflicht, sondern der bequemste Weg: Wer ihm folgt, bekommt alles geschenkt; wer abweicht, übernimmt mehr Eigenverantwortung, wird aber nicht blockiert. Diese Formel — unterstützt, nicht erzwungen — ist die wichtigste kulturelle Designentscheidung des Cases.

Schicht 3 — Self-Service-Portal: Backstage als Einstiegspunkt mit drei Kernfunktionen: Software-Katalog (wem gehört welcher Service, wo sind Docs, Dashboards, On-Call), Templates (die Golden Paths aus Schicht 2 als Klick-Erlebnis) und TechDocs (Doku als Code im Repo, gerendert im Portal). Wichtig ist die ehrliche Einordnung: Backstage ist ein Framework, kein Produkt — es kostet Engineering-Kapazität. Bei 12 Plattform-Leuten würde ich initial 2–3 davon für Portal und Templates einplanen, und es lohnt sich erst, weil 80 Teams die Investition amortisieren. Bei 10 Teams wäre meine Antwort ein Git-Template-Repo und ein gutes README.

Schicht 4 — Querschnitt: Secrets über External Secrets Operator gegen einen zentralen Store, Policies über eine Policy-Engine (Pflicht-Labels, Image-Herkunft, Ressourcen-Limits), Observability über die bestehende Datadog-Integration — automatisch verdrahtet im Golden Path, sodass jeder neue Service ab Minute eins Dashboards und Alerts hat.

Eine Zahl zur Plausibilisierung des Nutzens: 80 Teams × grob 2 neue Services pro Team und Jahr ≈ 160 Service-Erstellungen jährlich. Wenn der Golden Path die Einrichtung von 3 Wochen auf unter einen Tag drückt, sparst du im Jahr mehrere Entwickler-Jahre — das ist die Rechnung, mit der du das Investment begründest.

Rollout: Thin Platform statt Big Bang

Der Rollout-Teil trennt bei diesem Case Senior von Mid-Level. Die falsche Antwort: 18 Monate bauen, dann groß launchen. Die richtige: eine Thin Platform — der schmalste Durchstich, der einem echten Team echten Schmerz nimmt.

Phase 1 (erste Monate): Ein Golden Path für einen Stack (den häufigsten, etwa Java-API), pilotiert mit 2–3 freiwilligen Teams, die laut Feedback geben. Phase 2: Templates für die weiteren Stacks, Katalog-Pflicht für neue Services, Onboarding-Welle. Phase 3: Bestandsmigration — die schwierigste Phase, weil bestehende Services niemand freiwillig umzieht; hier helfen Anreize (bessere Dashboards, weniger Betriebspflichten) mehr als Deadlines.

Adoption misst du explizit: Anteil der Services im Katalog, Anteil der Deployments über den Golden Path, Time-to-First-Deployment neuer Services, plus DORA-Trends pro Team. Und ein organisatorischer Satz, der stark wirkt: „Die IDP braucht einen Product Owner und User Research — die Entwickler sind Kunden, keine Nutzer per Dekret.”

Einwände des Interviewers

„Warum Backstage und nicht etwas Leichteres?” Zugestehen, dass Backstage teuer ist, und die Bedingung nennen: Es amortisiert sich über die Teamanzahl und den Katalog-Effekt (Ownership-Transparenz bei 80 Teams ist allein schon das Geld wert). Unterhalb von ~20 Teams würde ich es nicht empfehlen.

„Was, wenn Teams die Plattform nicht nutzen?” Die Adoption-Frage ehrlich beantworten: Zwang erzeugt Schatten-IT. Stattdessen den Golden Path so gut machen, dass Abweichen unattraktiv ist, mit Pilot-Teams Glaubwürdigkeit aufbauen und Adoption messen statt verordnen. Ein Rest von Nicht-Nutzern ist akzeptabel, solange die Mehrheit profitiert.

„80 Teams, heterogene Stacks — wie viele Golden Paths willst du pflegen?” So wenige wie möglich: Starte mit zwei (Backend-API, Frontend), ergänze nur bei nachgewiesenem Bedarf mehrerer Teams. Jedes Template ist ein dauerhaftes Wartungsversprechen — bei 12 Plattform-Leuten sind fünf gepflegte Paths realistischer als fünfzehn verwaiste.

„Wie verhinderst du, dass die Plattform zum Engpass wird?” Self-Service als Architekturprinzip: Das Plattform-Team baut Automaten, keine Durchlaufstation. Alles, was ein Ticket braucht, ist ein Design-Fehler — die Eskalationsmetrik dafür ist die Ticket-Quote pro Monat.

Praxis

Spiele den Case 60 Minuten am Whiteboard durch (dieser Case braucht mehr Zeit als die 45-Minuten-Standardrunde). Diese fünf Punkte müssen vorkommen:

1. Die Schmerzpunkt-Frage zuerst, und ein daraus abgeleitetes, benanntes Erfolgskriterium (z. B. Time-to-First-Deployment).
2. Eine explizite Scope-Entscheidung in den ersten zehn Minuten („Ich fokussiere auf X, klammere Y aus, weil…”).
3. Das Vier-Schichten-Bild mit dem komplett erzählten Developer Journey: Template-Klick → Repo + CI + Manifeste → GitOps-Deploy → automatische Observability.
4. Die Golden-Path-Abwägung inklusive Escape-Hatch-Regel und der Wartungskosten-Rechnung pro Template.
5. Ein dreiphasiger Rollout mit Pilot-Teams und mindestens drei Adoption-Metriken.

Bonus-Übung: Wiederhole nur den Rollout-Teil für ein Unternehmen mit 15 statt 80 Teams — und prüfe, ob du den Mut hast, Backstage wegzulassen.

Typische Stolperfallen

Alles designen wollen. Die IDP ist zu groß für 60 Minuten — ohne explizites Scoping wird jede Antwort flach. Die Scope-Ansage ist kein Ausweichen, sondern die erwartete Senior-Leistung.

Das Portal mit der Plattform verwechseln. Backstage ist die Oberfläche, nicht die Plattform. Wer 30 Minuten über Portal-Plugins redet und den Delivery-Pfad darunter nie erklärt, hat eine Fassade ohne Haus gebaut.

Bestehende Tools ersetzen. „Ich führe statt Datadog den Prometheus-Stack ein” verbrennt im Enterprise Monate an Politik und Migrationsaufwand für ein Problem, das nicht in der Aufgabenstellung stand. Integration ist fast immer die richtige Antwort, wenn Tools als „vorhanden” genannt werden.

Die Teamgröße ignorieren. Jede Komponente, die du einzeichnest, muss von 12 Personen betrieben werden — neben Support, Weiterentwicklung und On-Call. Wer das Verhältnis 1:40 nie erwähnt, designt im luftleeren Raum.

Interview-Vorbereitung

Deine Kernbotschaft: Eine IDP ist ein Produkt mit Entwicklern als Kunden — vier Schichten (Runtime, Delivery mit Golden Paths, Portal, Querschnitt), Integration statt Ersatz bestehender Tools, Thin-Platform-Rollout mit Pilot-Teams und Adoption als oberste Messgröße.

Rechne mit diesen Follow-ups:

• „Was ist ein Golden Path?” — Der gepflasterte Standardweg von der Service-Erstellung bis Produktion: Template erzeugt Repo, CI, Manifeste und Observability in einem Schritt; empfohlen und unterstützt, aber nicht erzwungen.
• „Wie misst du den Erfolg der IDP?” — Adoption (Katalog-Abdeckung, Golden-Path-Quote), Time-to-First-Deployment, DORA-Trends pro Team, Ticket-Quote ans Plattform-Team.
• „Build vs. Buy fürs Portal?” — Backstage lohnt ab einer Teamanzahl, die die Engineering-Kosten amortisiert; darunter Git-Templates plus Doku; kommerzielle Portal-Produkte als Mittelweg, wenn Engineering-Kapazität der Engpass ist.
• „Wie gehst du mit den 20 Sonderfall-Teams um?” — Definierte Escape Hatches: Sie nutzen Plattform-Bausteine à la carte (Secrets, Observability), ohne den vollen Golden Path; ihre Muster beobachten und bei Häufung zum neuen Template machen.

Zusammenfassung

Der IDP-Case prüft Scoping, Produktdenken und Betreibbarkeit: vier Schichten von Runtime bis Portal, Golden Paths für die häufigen Stacks mit Escape Hatches für den Rest, Integration der Bestandstools und ein Rollout, der klein anfängt und an Adoption gemessen wird — alles dimensioniert auf ein 12-Personen-Team. Damit hast du die Plattform aus Nutzersicht designt; die nächste Lektion dreht die Perspektive auf den Maschinenraum: GitOps für eine Flotte von 20 Clustern über drei Regionen — wie hältst du so viele Cluster konsistent, ohne 20-mal Hand anzulegen?