Plattform Engineering entlastet den Betrieb erst mit einem gepflegten Servicekatalog

Viele Unternehmen investieren gerade in Internal Developer Platforms, Golden Paths und Self-Service-Portale für Entwicklungsteams. Die Erwartung ist nachvollziehbar: weniger Ticket-Pingpong, schnellere Bereitstellung, bessere Standards und weniger Reibung zwischen Plattformteam, Entwicklung, Security und Betrieb. In der Praxis kippt diese Hoffnung aber erstaunlich oft. Das Portal sieht modern aus, die Templates funktionieren, doch bei Incidents, Ownership-Fragen oder Abhängigkeiten beginnt wieder das alte Rätselraten. Wer ist für den betroffenen Service zuständig? Welche API hängt an welchem System? Welche Ressource ist produktiv kritisch? Und in welchem Lebenszyklus befindet sich die Komponente überhaupt?

Genau an dieser Stelle wird Plattform Engineering zur Betriebsfrage. Ein Internal Developer Portal hilft nur dann dauerhaft, wenn dahinter ein gepflegter Servicekatalog steht, der nicht bloß Namen sammelt, sondern Ownership, Systemgrenzen, Ressourcen und Betriebsbezug sauber abbildet.

Das ist keine theoretische Forderung. Backstage beschreibt seinen Software Catalog ausdrücklich als zentrales System für Ownership und Metadaten über Services, Websites, Libraries und Datenpipelines. Im Descriptor-Format gehören Felder wie owner, system und lifecycle zum Kern. Und im Systemmodell werden Komponenten, APIs und Ressourcen bewusst getrennt, damit Abhängigkeiten und Verantwortlichkeiten sichtbar werden. Wer Plattform Engineering ernst meint, braucht genau diese Disziplin.

Self-Service scheitert selten am Template, sondern an fehlender Zuordnung

Die meisten Plattforminitiativen starten mit einem sinnvollen Ziel: Entwicklerinnen und Entwickler sollen Standards schneller nutzen können, ohne für jede Kleinigkeit ein Ticket beim Plattformteam oder bei der Infrastruktur zu eröffnen. Das Problem beginnt meist erst nach dem Provisioning. Ein neuer Service ist angelegt, aber der Betrieb kann ihn nicht sauber einordnen. Der Service Desk kennt keinen klaren Owner. Das Security-Team weiß nicht, welche Komponente zu welchem System gehört. Im Incident fehlt eine verlässliche Liste produktiver Abhängigkeiten. Und bei Änderungen an APIs oder Runtime-Ressourcen wird erst spät sichtbar, welche Teams mitbetroffen sind.

Dann passiert genau das Gegenteil von dem, was Plattform Engineering verspricht. Statt Reibung zu reduzieren, verlagert das Unternehmen Reibung in spätere Prozessschritte. Das Onboarding wird schneller, der Betrieb aber unschärfer. Ein schöner Katalog-Frontend-Screen ohne belastbare Metadaten ist deshalb kein Fortschritt, sondern nur besser verpackte Unklarheit.

Ein brauchbarer Servicekatalog braucht mehr als eine Repository-Liste

Viele Organisationen starten ihren Katalog faktisch als Inventarliste: Repository-Name, Teamname, vielleicht noch ein kurzer Beschreibungstext. Für den Alltag reicht das nicht. Ein nutzbarer Katalog muss mindestens fünf Dinge verlässlich liefern: einen fachlich und operativ zuständigen Owner, die Zuordnung zu einem System oder Produktkontext, den Lifecycle-Status, bekannte APIs oder Schnittstellen und den Bezug zu produktiv relevanten Ressourcen.

Gerade die Trennung zwischen Komponenten, APIs und Ressourcen ist operativ wertvoll. Sie verhindert, dass ein Service nur als Codepaket betrachtet wird. Ein Incident betrifft oft nicht nur die Anwendung, sondern auch Datenbanken, Topics, Buckets, Secrets, externe APIs oder gemeinsame Plattformdienste. Wer diese Zusammenhänge im Katalog nicht abbildet, muss sie im Störfall mühsam zusammensuchen.

Backstage empfiehlt zudem, die Metadaten zusammen mit dem Code in Versionsverwaltung zu halten. Das ist mehr als eine Komfortentscheidung. Es sorgt dafür, dass Änderungen an Ownership, Lifecycle oder Systemzuordnung denselben Review- und Änderungsweg durchlaufen wie technische Anpassungen. Ein Servicekatalog bleibt nur dann brauchbar, wenn seine Pflege in die normale Delivery-Routine eingebaut ist.

Ownership muss für Betrieb, Security und Change dieselbe Sprache sprechen

Ein häufiger Fehler besteht darin, Ownership nur als Namen im Portal zu verstehen. Für den Betrieb ist Ownership aber erst dann nützlich, wenn dieselbe Zuordnung auch in Incident Management, Change-Bewertung, Security-Follow-up und Kommunikationswegen wieder auftaucht. Sonst steht im Developer Portal ein Teamname, während der Service Desk mit anderen Verteilern arbeitet und die Security-Eskalation wiederum eine dritte Sicht nutzt.

Praktisch lohnt sich deshalb ein kleines, aber hartes Pflichtset pro Service: verantwortliches Team, technische Kontaktgruppe, Eskalationsweg für produktive Incidents, Lifecycle, Kritikalität und verknüpfte Kernressourcen. Das ist keine Bürokratie, sondern die Mindestbasis dafür, dass ein Plattformmodell im Störfall trägt. Gerade bei wachsender Zahl interner Services ist nicht die Bereitstellung das Nadelöhr, sondern die saubere Führbarkeit im Alltag.

Hier passt auch der Blick auf DORA. Das DORA Core Model versteht bewährte Fähigkeiten und Metriken als Grundlage für kontinuierliche Verbesserung. Auf Plattform Engineering übertragen heißt das: Erfolg misst sich nicht daran, wie modern das Portal aussieht, sondern daran, ob Teams schneller liefern können, ohne dass Ownership, Änderungstransparenz und betriebliche Stabilität verloren gehen.

Golden Paths brauchen Pflicht-Metadaten, sonst werden sie zu Schnellstraßen ohne Verkehrsschilder

Golden Paths sind dann stark, wenn sie gute Entscheidungen voreinstellen. Dazu gehören nicht nur Build-Pipelines, Runtime-Defaults oder Security-Scanner, sondern auch verbindliche Katalogdaten. Wenn ein neuer Service per Template entsteht, sollten Owner, Systemkontext, Lifecycle, Runbook-Link, API-Typ und kritische Ressourcentypen nicht als freiwillige Felder behandelt werden.

Sonst entsteht ein vertrautes Muster: Die ersten 20 Services sind ordentlich gepflegt, danach nimmt die Datenqualität ab, und ein Jahr später vertraut niemand dem Katalog mehr. Dann verliert auch das Portal seinen operativen Wert. Wer Pflichtfelder schon im Erstellungsprozess sauber abfragt und später gegen Drift prüft, verhindert genau diese schleichende Entwertung.

Besonders wichtig ist das bei Plattformen, die Self-Service als Produktversprechen aufbauen. Platformengineering.org beschreibt Platform Engineering ausdrücklich mit Produktdenken, nutzerzentrierten Self-Service-Workflows und dem Ziel, kognitive Last zu senken. Diese kognitive Last verschwindet aber nicht, wenn Entwickler fehlende Betriebsinformationen später in Wikis, Chats und Tickets zusammensuchen müssen. Ein gepflegter Servicekatalog ist deshalb kein Nebensystem, sondern ein Kernbestandteil guter Developer Experience.

Der bessere Einstieg ist klein, aber verbindlich

Viele Unternehmen scheitern nicht an fehlender Einsicht, sondern am zu großen Wurf. Sie wollen sofort jedes Repository, jede API und jede Ressource perfekt modellieren. Das blockiert. Sinnvoller ist ein enger Start mit klarer Verbindlichkeit: zunächst die produktiv kritischen Services, alle extern sichtbaren APIs und die wichtigsten gemeinsamen Plattformressourcen. Für diese Menge werden Pflichtfelder definiert, Review-Regeln festgelegt und Drift sichtbar gemacht.

Hilfreich ist auch eine einfache Governance-Regel: Kein neuer produktiver Service ohne Katalogeintrag, kein Owner-Wechsel ohne Katalog-Update, keine Stilllegung ohne Lifecycle-Anpassung. Dazu kommen regelmäßige Qualitätschecks, zum Beispiel auf verwaiste Owner, veraltete Lifecycle-Werte oder fehlende Runbook-Links. So wächst der Katalog nicht nur, sondern bleibt verlässlich.

Wer später CMDB, Asset-Daten oder Observability-Informationen anbinden will, hat damit außerdem eine tragfähige Basis. Ohne sauberes Service-Modell entstehen sonst nur neue Integrationen auf unscharfer Grundlage.

Fazit

Plattform Engineering entfaltet seinen Wert nicht durch Templates allein. Der eigentliche Hebel liegt darin, Entwicklung, Betrieb und Ownership in einem gemeinsamen Modell zusammenzubringen. Ein gepflegter Servicekatalog macht sichtbar, wem ein Service gehört, in welchem System er arbeitet, welche APIs er anbietet und welche Ressourcen für seinen Betrieb kritisch sind.

Genau deshalb sollte der Servicekatalog nicht als nettes Portal-Feature behandelt werden. Er ist die operative Datenbasis dafür, dass Self-Service nicht in neues Chaos umschlägt. Wer Plattform Engineering als Betriebsmodell versteht und den Katalog als verbindlichen Teil von Delivery, Incident und Change aufbaut, entlastet Entwicklungsteams wirklich. Wer ihn vernachlässigt, beschleunigt nur die Erstellung neuer Services, nicht deren verlässlichen Betrieb.