Heute gibts den Start meines Berichts von der DevOpsCon 25. So viel allgemeines vorweg: War schön. Druckbetankung wie es sich gehört.
Los ging es mit einer Keynote über interne Entwickler-Plattformen und was dabei gerne schief geht.
1 | Reality-Check: 90 % der Devs nutzen schon eine IDP – wir auch
- Laut Jessica arbeiten rund 90 % aller Entwickler:innen mittlerweile mit einer internen Plattform – oft, ohne es zu merken.
- Wir auch? Was ist unsere Plattform?
2 | Das theoretische Fundament
Jessica empfahl vier Bücher, die jede:r Platform‑Builder kennen sollte. (Lustigerweise gab Sie zu, das Sie selbst noch nicht alle davon gelesen komplett gelesen hat.)
| Buch | Kernaussage für IDP | Mein Take‑away |
|---|---|---|
| Transformed | Von Silos zu empowereden Produkt‑Teams | Auch Plattform‑Teams brauchen Produktdenken und Produkt-Manager. |
| Team Topologies | Team‑Typen & Schnittstellen (u. a. Platform & Enabling Teams) | Klingt sehr ähnlich zu dem wie wir organisiert sind. Unterschiede: Komplizierte Subsysteme brauchen eigene Teams. Enabling‑Teams sind hier fast immer temporär. |
| Accelerate | Deploy‑Freq., Lead‑Time, Failure‑Rate, MTTR | DORA‑Scores = Proxy für Platform-Team‑Erfolg. Nugget: Im Raum war niemand der alle 4 Metriken einsetzt, oder jemanden kennt der das tut… |
| Platform Engineering | Plattform ersetzt Glue‑Code & schafft Self‑Service | Eine IDP ist Software, kein Ops‑Team. |
3 | Typische Fallstricke
- Menschen im Plattform-Team bringen ihre Erfahrungen mit
- „It’s faster if I just do it.“ Sorgt gerne dafür das das Ergebnis auch nur Sie benutzen können.
- Damit erzeugt man ein neues Ops-Silo. Dringend zu vermeiden. Das Ziel ist, das andere Teams sich selbst helfen können.
- Rudis Resterampe (Scope Creep)
- Plattform‑Team sammelt alles, was sonst niemand machen will.
- Konsequenz: Keine Zeit mehr für strategische Funktionen.
- Braucht eine klare Vision, und insbesondere By-In von Leadership. Dann Iterationen und viel Kommunikation.
- Alles sofort lösen wollen (Rudis Resterampe 2.0)
- Minimalismus ist King 👑. Nicht jedes Problem muss gleich gelöst werden.
- Priorisiere Onboarding, Self‑Service & Empowerment.
- Das falsche Problem Lösen
- Es ist sehr einfach das falsche Problem zu lösen. Schließlich sind wir alle Entwickler und wissen was wir brauchen.
- Aber jedes Team ist anders und hat andere Aufgaben. Daher ist es unglaublich wichtig mit den Menschen intensiv zu sprechen die man beglücken will.
- Plattform-Engineering braucht genauso Produkt-Management und einen Produkt-Manager wie andere Themen. Wenn das Budget dafür nicht vorhanden ist, muss man diese Aufgaben trotzdem erfüllen.
- Plattform‑Migrationen unterschätzen
- Jede Migration ist Schmerzhaft und kostet Vertrauen (Vertrauen ist wie eine Währung. Wenn man es ausgegeben hat, ists wech).
- Daher so wenig Migrationen wie möglich, und diese gut vorbereiten, auch wenn es viel Aufwand erzeugt.
- Ziel: Automatisierte, Low‑Impact‑Migrationspfade.
4 | Fragen an den Leser
- Was ist deine aktuelle Plattform?
- Wo klemmt es eigentlich derzeit?
- Macht es Sinn die DORA‑Baselines zu messen?
5 | Fazit
Ein internes Developer‑Platform‑Team ist kein Sonder‑Ops‑Team, sondern ein Produkt‑Team mit klarer Vision, fokussiertem Scope und messbarem Impact. Je einfacher, desto besser – und Vertrauen ist kostbar.
„Minimalismus ist King – löse die wichtigsten 20 % zuerst, die den Teams 80 % des Schmerzes nehmen.“ – Jessica Anderson