Plattform als Produkt
Einführung · 4 Abschnitte · ~9 Min Lesezeit · Stand
Die Plattform hat Kunden
Eine interne Plattform ist keine Infrastruktur, die andere zufällig mitbenutzen. Sie hat Nutzer — die Produktteams — und deren tägliche Arbeit ist ihre Anforderungsquelle. Wer das ernst nimmt, führt ein Backlog, kennt die konkreten Arbeitsabläufe seiner Nutzer und misst, ob die Plattform diese Abläufe schneller und sicherer macht.
| Frage | Antwort im Produktmodus |
|---|---|
| Woher kommen Anforderungen? | Aus beobachteten Arbeitsabläufen der Nutzerteams, nicht aus Annahmen des Infrastrukturteams. |
| Was ist der Erfolgsbeleg? | Freiwillige Nutzung und messbar geringere Reibung — nicht die Zahl gebauter Funktionen. |
| Wer entscheidet Prioritäten? | Ein benannter Owner der Plattform, gegen einen sichtbaren Bedarf. |
| Was passiert bei Nichtnutzung? | Ursachensuche bei denen, die nicht nutzen — meist eine Anforderungs-, Onboarding- oder Kommunikationslücke, selten eine Disziplinlücke. |
- Bauen ins Blaue: monatelang gegen vermutete Bedarfe entwickeln und erst beim Rollout merken, dass niemand danach gefragt hat.
- Ticket-Betrieb: die Plattform wird zum Bestellschalter, jede Anfrage braucht einen Menschen. Das ist das Gegenteil von Self-Service und skaliert nicht.
Golden Path: Angebot statt Zaun
Ein Golden Path ist der vorgeprüfte, dokumentierte Standardweg für einen häufigen Fall: eine Umgebung mit passendem Identitäts-, Netz- und Logging-Setup, fertig verdrahtet und ohne Rückfrage nutzbar. Sein Wert entsteht daraus, dass er der einfachste Weg ist — nicht daraus, dass er der einzige erlaubte ist. Teams müssen daneben eigene Fähigkeiten betreiben dürfen, wenn das Angebot ihren Fall nicht abdeckt.
Im Alltag werden zwei Dinge ständig vermischt, die sich sauber trennen lassen:
| Default (Golden Path) | Ein Angebot. Deckt die häufigen Fälle ab, nie alle. Setzt sich über Attraktivität durch, nicht über Vorschrift. |
|---|---|
| Guardrail | Eine organisationsweit gesetzte Kontrolle: Identität, Egress-Kontrolle, Verschlüsselung, Audit-Logging. Gilt auch dort, wo jemand den Pfad verlässt. |
Ein Team mit belegtem Sonderbedarf ist kein Regelverstoß, sondern eine Information über die Grenzen des Pfades. Der übliche Umgang damit ist ein Ausnahmeverfahren: befristet, dokumentiert, mit benanntem Owner für den abweichenden Teil — und als Eintrag im Plattform-Backlog.
Kurzcheck
Ein Team weicht mit gutem Grund vom Golden Path ab. Was gilt weiterhin?
- Die organisationsweiten Kontrollen — Identität, Egress-Kontrolle, Audit-Logging
- Die vom Golden Path vorgegebenen Bausteine und Instanztypen
- Nichts — wer abweicht, verantwortet ab dann alles selbst
Richtig. Sie hängen an der Organisationshierarchie und nicht am gewählten Weg.
Wo die Plattform endet
Eine Plattform ohne erklärte Grenze wird entweder zum Betriebsengpass für alle Anwendungen oder zum Ticket-Verschiebebahnhof. Beides ist vermeidbar, wenn die Grenze vorher benannt ist. In geteilten Betriebsmodellen ist die übliche Linie: Die Plattform verantwortet ihre eigene Ebene, das Produktteam trägt die Bereitschaft für Fehler im eigenen Anwendungscode.
| Plattform schuldet | Verhalten und Verfügbarkeit der bereitgestellten Bausteine, sichtbare Limits, Änderungshistorie, Telemetrie über die Plattformebene, Unterstützung im Störungsfall. |
|---|---|
| Produktteam schuldet | Verhalten und Fehler der eigenen Anwendung innerhalb der Plattformzusagen — inklusive Bereitschaft für fachliche Störungen. |
| Gemeinsam | Die Klärung an der Grenze: Wer welchen Nachweis liefert, bevor eine Ursache behauptet wird. |
Der entscheidende Punkt ist die Beweislast. „Kein Plattformproblem“ ist erst dann eine Aussage, wenn die Plattformseite mit ihren Signalen belegt ist. Bis dahin ist es eine Vermutung — und eine Vermutung beendet keinen laufenden Ausfall.
- Eskalation annehmen, Zeitraum und Symptom abgrenzen
- Plattformebene mit eigenen Signalen belegen oder widerlegen
- Befund mit Zeitstempeln festhalten und übergeben
- Owner der nächsten Handlung benennen und die Übernahme bestätigen lassen
An dieser Grenze gibt es eine zweite Unterscheidung, die im Ernstfall die Entscheidung trägt: stützen ist nicht dasselbe wie ändern.
| Befristete Stützmaßnahme | Ein Limit oder eine Kapazität im eigenen Baustein vorübergehend anheben, für diese eine Störung, mit Rückbautermin, Owner und Eintrag im Störungsprotokoll. In der Nacht vertretbar. |
|---|---|
| Dauerhafte Plattformänderung | Dieselbe Stellschraube unbefristet verstellen. Wirkt auf alle Nutzer des Bausteins, verdeckt die eigentliche Ursache und gehört in ein Review — nicht in eine laufende Eskalation. |
Gleich im Check
Drei Achsen, die du gleich selbst entscheidest:
- Eine kaum genutzte Plattform wieder auf Kurs bringen — als Produkt mit Nutzern, nicht als Infrastrukturprojekt.
- Ein Team mit legitimem Sonderbedarf am Golden Path vorbeiführen, ohne die organisationsweiten Kontrollen aufzugeben.
- Eine nächtliche Eskalation an der Grenze zwischen Plattform und Anwendung auflösen — inklusive der Frage, wie weit die Plattform stützen darf.