Atulpriya Sharma, CNCF Ambassador und Organisator der Platform Engineering TCG, zufolge lautet die wichtigste Frage in der Plattformtechnik nicht, ob ein Unternehmen eine Plattform aufgebaut hat, sondern wie Entwickler tatsächlich mit ihren Fähigkeiten interagieren. Unternehmen, die noch keine offizielle Plattform besitzen, greifen häufig auf verstreute Skripte und individuelles Wissen zurück. Andere verfügen möglicherweise über ein Entwicklerportal, eine CLI-Schnittstelle und vorgefertigte Pfade, bearbeiten Anfragen jedoch weiterhin manuell. In beiden Fällen liegt das Problem in der Reife der Schnittstelle, über die Teams die Fähigkeiten der Plattform nutzen.
Der Beitrag stützt sich auf das CNCF-Reifemodell für Plattformtechnik, das fünf Aspekte unabhängig voneinander misst: Investitionen, Akzeptanz, Schnittstellen, Betrieb und Messung. Für jeden Aspekt gibt es vier Stufen: provisorisch, operativ, skalierbar und optimierend. Nach dem Modell entwickelt sich ein Unternehmen nicht als Einheit weiter; es kann in einem Aspekt Fortschritte machen, während es in einem anderen zurückbleibt. Die Analyse konzentriert sich auf den Aspekt der Schnittstellen, also auf Modelle, CLI-Schnittstellen, Portale und APIs, die von Entwicklern genutzt werden.
Vier Phasen für die Plattformschnittstelle
Auf der ersten Stufe setzt das Unternehmen auf maßgeschneiderte Abläufe: manuelle Anfragen, Prozesse, die sich zwischen Teams unterscheiden, und Wissen, das von einer Person zur nächsten weitergegeben wird. Das Fehlen eines offiziellen Plattformnamens bedeutet nicht, dass faktisch keine Plattform existiert: Wiederholte Nachrichten an einen bestimmten Ingenieur mit der Bitte, eine Datenbank einzurichten, stellen die aktuelle Plattformschnittstelle dar, auch wenn sie nicht verwaltet wird.
Die zweite Stufe trägt die Bezeichnung standardisierte Tools. Hier entstehen Golden Paths oder befestigte Wege sowie konsistente Dokumentationen, Vorlagen und Schnittstellen, um Fähigkeiten bereitzustellen und zu überwachen. Die Ergebnisse wirken gewöhnlich positiv: höhere Akzeptanz, eine schnellere Einarbeitung neuer Mitarbeiter und bessere Kennzahlen. Anfragen außerhalb des erwarteten Pfades erfordern jedoch weiterhin den Eingriff des Plattformteams. Die Schnittstelle ist daher einheitlich, ohne selbstständig nutzbar zu sein.
Auf der dritten Stufe entstehen Self-Service-Lösungen, mit denen Entwickler die meisten routinemäßigen Anfragen erledigen können, ohne das Plattformteam einzuschalten. Diese Stufe misst eher das Verhalten der Teams, als sich ausschließlich auf Kennzahlen zu stützen: Die Zahl der Tickets für routinemäßige Bereitstellungen geht zurück, neue Ingenieure beginnen, die Plattform direkt zu nutzen, und die Arbeit des Plattformteams verlagert sich von der Bearbeitung einzelner Anfragen auf die Verbesserung des Rahmens, der diese verwaltet. Nach den vom Autor angeführten Beispielen berichteten Unternehmen von einem Rückgang der Anfragen nach Ausnahmen um 40 bis 60 Prozent, nachdem Optionen für die Self-Service-Konfiguration hinzugefügt worden waren.
Auf der vierten Stufe, den integrierten Diensten, werden Plattformfähigkeiten zu einem transparenten Bestandteil der täglichen Arbeitswerkzeuge. Beim Erstellen eines neuen Dienstes können Überwachung, Protokollierung und Sicherheit automatisch integriert werden, während Sicherheitsrichtlinien ihre Regeln über die Plattform durchsetzen, statt Entwickler zu einer manuellen Abstimmung zu zwingen. Die Plattform wird nahezu unsichtbar; ihr Erfolg wird daran gemessen, wie selten Entwickler über die Infrastruktur nachdenken müssen.
Warum bleiben Unternehmen auf der zweiten Stufe stehen?
Die Analyse identifiziert vier wiederkehrende Probleme. Das erste ist das Warteschlangenproblem: Golden Paths decken häufige Fälle ab, doch Ausnahmefälle können in großen Unternehmen 30 Prozent der Arbeit ausmachen. Der Autor führt das Beispiel einer Einzelhandelsorganisation an, die einen Golden Path für die Bereitstellung von Kubernetes mit Helm Charts und ArgoCD verwendete. Innerhalb von sechs Monaten erreichte die Akzeptanz 85 Prozent, doch es sammelten sich 40 Ausnahmefälle an, und das Team wandte 60 Prozent seiner Zeit für Konfigurationen außerhalb des vorgesehenen Pfades auf.
Das zweite Problem ist die Erfahrungslücke. Plattformteams können allgemeine Fähigkeiten entwickeln, die den Anforderungen spezialisierter Teams nicht vollständig entsprechen, woraufhin diese Teams eigene Alternativen entwickeln. Das dritte ist die Wartungsfalle: Jede neue Fähigkeit vergrößert die Fläche, die bei Auftreten einer Sicherheitslücke oder einem Kubernetes-Upgrade aktualisiert, getestet und korrigiert werden muss. Der Autor erwähnt einen Fall, in dem sich alte Helm-Chart-Schnittstellen, Abhängigkeiten von einem Cloud-Anbieter und Annahmen über Netzwerke angesammelt hatten, bis eine Aktualisierung riskant wurde.
Das vierte Problem ist die Starrheit. Ein Golden Path spiegelt bei seiner Entwicklung gültige Annahmen wider, doch diese können sich mit veränderten Technologien, Prozessen und Anforderungen der Teams in Einschränkungen verwandeln. Dann vermehren sich Ausnahmen und Schatteninfrastruktur, und das Plattformteam wird zu einer Fabrik für individuelle Lösungen, statt die grundlegende Schnittstelle zu verbessern.
Was ändert sich in der Praxis?
Für den Übergang von der ersten zur zweiten Stufe empfiehlt der Autor, das Vorhandene zunächst zu benennen, bevor ein neues Portal gebaut wird: die häufigsten, zeitaufwendigsten und am stärksten standardisierbaren Anfragen erfassen und anschließend einen einzigen Golden Path auswählen und tatsächlich verbessern, bevor der Katalog erweitert wird.
Für den Übergang von der zweiten zur dritten Stufe muss das Plattformteam aufhören, ein verpflichtendes menschliches Bindeglied zu sein. Dazu müssen Golden Paths konfigurierbar werden, mit validierten Optionen und Einschränkungen, die durch Richtlinien statt durch feste Werte erzwungen werden, sowie mit Auswegen für berechtigte Fälle. Die Analyse empfiehlt außerdem, die Anfragen vor ihrer Automatisierung zu messen. In einem Beispiel aus dem Mediensektor führte die dreimonatige Erfassung von Anfragen zur Erkenntnis, dass 20 Prozent der Anfragearten 80 Prozent des Volumens ausmachten. Daher wurde zunächst für diese Muster ein Self-Service-Angebot entwickelt, wodurch der Rückstand innerhalb von sechs Monaten um 60 Prozent sank.
Ebenso sollte die Schnittstelle als Produkt betrachtet werden, nicht nur die Backend-Fähigkeiten. Auffindbarkeit, Validierungsregeln, Verträge und der Umgang mit unerwarteten Anfragen sind allesamt Bestandteile des Produkts. Auf dem Weg zur vierten Stufe verlagert sich die Automatisierung von einer vom Entwickler ausgewählten Ausführung hin zu intelligenten, durch Richtlinien vorgegebenen Standardannahmen in Git, der Entwicklungsumgebung und CI/CD-Systemen. Gleichzeitig wird die Verantwortung für Fähigkeiten zwischen Sicherheits-, Datenbank- und Überwachungsteams auf Grundlage klarer Verträge verteilt.
Die Einordnung von certi.news
Die tatsächliche Veränderung, auf die der Artikel hinweist, ist die Verlagerung des Erfolgsmaßstabs einer Entwicklerplattform: weg von der Anzahl der eingeführten Tools und Pfade, hin zum Umfang der Autonomie, die Nutzer erhalten, und anschließend zum Grad, in dem diese Fähigkeiten in den Arbeitsablauf integriert sind. Das ist für Plattformteams relevant, weil sie die Akzeptanz scheinbar steigern können, während sie die Umsetzungslast in eine Warteschlange aus Ausnahmen und Wartungsaufgaben verlagern.
Die hier genannten Beispiele und Zahlen präsentiert der Autor jedoch als Beobachtungen aus Interaktionen mit Unternehmen und nicht als unabhängige quantitative Studie, die belegt, dass dieselben Prozentsätze für jedes Unternehmen gelten. Außerdem setzt das Erreichen der vierten Stufe Reife bei Verträgen und Richtlinien sowie eine Verteilung der Verantwortung voraus – Dinge, die der Kauf eines Portals oder das Hinzufügen eines KI-Agenten allein nicht bereitstellt. Das Fazit wirft eine wichtige offene Frage auf: Eine für Entwickler konzipierte Self-Service-Schnittstelle ist nicht zwangsläufig eine von KI-Agenten nutzbare Schnittstelle, da diese APIs mit einer Häufigkeit und in Mustern verwenden, die sich von menschlichen Arbeitsabläufen unterscheiden. Daher könnte die Reife maschinenlesbarer Schnittstellen die nächste Entwicklungsstufe sein, die Plattformteams messen müssen.