# Plattform als Produkt

> Golden Paths anbieten statt erzwingen und die Support-Grenze der Plattform sauber ziehen.

Track: [Cloud Infrastructure & Platform Engineering](https://opsmith.app/learn/cloud-infra)  
Kanonische Fassung: https://opsmith.app/learn/cloud-infra/platform-operating-model  
Stand: 2026-07-30  
Interaktiver Teil: 3 Checks (nur im Browser)

## Plattform als Produkt

### 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. |

> **Merksatz:** Freiwillige Adoption ist das ehrlichste Qualitätssignal, das eine interne Plattform bekommen kann. Wer sie durch Zwang ersetzt, schaltet das Signal ab — nicht das Problem.

- **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. |

> **Einordnung:** Das Begriffspaar **Default / Guardrail** ist die Arbeitsunterscheidung dieses Moduls, keine zitierbare Norm — in den Plattform-Quellen steht sie so nicht. Technisch tragfähig ist sie trotzdem: Richtlinien, die an der Ressourcenhierarchie einer Cloud-Organisation hängen, werden an alle darunterliegenden Ressourcen vererbt und wirken unabhängig davon, über welchen Weg jemand etwas anlegt. Eine Abweichung vom Angebot hebelt sie deshalb nicht aus — eine Änderung an der Hierarchie schon.

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.

> **Praxis-Heuristik, keine Norm:** Zwei Faustregeln, die sich in der Praxis bewähren, aber in keiner einzelnen Quelle kodifiziert sind: **erstens**, Ausnahmen brauchen Befristung, Dokumentation und Owner, sonst werden sie unsichtbar dauerhaft; **zweitens**, ein zweiter Golden Path lohnt erst bei **wiederkehrender** Nachfrage — Golden Paths zielen auf die häufigsten Arbeitsabläufe, ein Einzelfall trägt den Pflegeaufwand eines eigenen Pfades selten.

> **Trade-off:** Ein erzwungener Pfad erzeugt Schatten-Infrastruktur: Teams weichen aus, und Ausweichen erzeugt genau die unbeaufsichtigten Ecken, die du vermeiden wolltest. Ein Pfad, der jeden Einzelfall aufnimmt, verliert dagegen das, was ihn wertvoll macht — wenige, gut getestete Wege.

**Kurzcheck:** Ein Team weicht mit gutem Grund vom Golden Path ab. Was gilt weiterhin?

- [x] 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

> **Einordnung:** Die Zuspitzung **Beweislast** ist die Formulierung dieses Moduls, keine zitierbare Norm. Belegt ist, worauf sie aufsetzt: dass in geteilten Betriebsmodellen die Bereitschaft für Fehler im Anwendungscode beim Entwicklungsteam liegt, und dass bei einer Übergabe im Störungsfall jederzeit klar sein muss, wer führt — mit ausdrücklicher Bestätigung der Übernahme, festgehalten in einem mitlaufenden Störungsprotokoll. Auch die gleich folgende Trennung zwischen befristetem Stützen und dauerhaftem Ändern ist eine Arbeitsunterscheidung dieses Moduls, abgeleitet aus dem Umgang mit Notfall- und Standardänderungen — kein zitierbarer Standard.

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. |

> **Merksatz:** Stützen ist eine Nachtaktion, dauerhaft ändern ist eine Tagesentscheidung. Wer die Support-Grenze zu weit zieht, wird zum Engpass; wer sie zu eng zieht, verliert seine Nutzer — und damit die freiwillige Adoption, von der die Plattform lebt.

### 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.

> **Gleich im Check:** Bei jeder Option siehst du danach, **warum** sie trägt oder kippt — inklusive des Preises der richtigen Wahl.

## Quellen

- CNCF TAG App Delivery — Platforms White Paper — https://tag-app-delivery.cncf.io/whitepapers/platforms/
- DORA — Capability: Platform engineering — https://dora.dev/capabilities/platform-engineering/
- Evan Bottcher — What I Talk About When I Talk About Platforms — https://martinfowler.com/articles/talk-about-platforms.html
- Google Cloud — Organization Policy Service, Übersicht — https://cloud.google.com/resource-manager/docs/organization-policy/overview
- Google SRE Book, Kap. 32 — The Evolving SRE Engagement Model — https://sre.google/sre-book/evolving-sre-engagement-model/
- Google SRE Book, Kap. 14 — Managing Incidents — https://sre.google/sre-book/managing-incidents/