Plattform oder Fassade? Platform Engineering ehrlich

7 Min. Lesezeit

Self-Service ist das Wort, das 2026 auf jeder Plattform-Engineering-Folie steht. Hinter dem Wort sehen wir zwei sehr verschiedene Realitäten. Auf der einen Seite Plattformen, die Teams produktiver machen. Auf der anderen Portale, die nur Formulare hübscher rendern. Der Unterschied entscheidet, ob das Plattform-Team in zwei Jahren Budget bekommt oder rückabgewickelt wird.

Das Wichtigste in Kürze

• Plattform-Substanz schlägt UI-Politur: Eine echte interne Plattform liefert Abstraktion über die darunterliegenden Services, Standardisierung der Lifecycle-Operationen und einen messbaren Beitrag zur Lead-Time. Ein Portal ohne diese drei Schichten ist eine Fassade mit Login.
• Self-Service braucht Reversibilität: Teams nutzen Plattformen erst dann freiwillig, wenn sie eine Ressource ohne Ticket anlegen können und sie zwei Stunden später ohne Konsequenzen wieder zurücknehmen. Wer diesen Loop nicht baut, baut ein Antragsformular.
• Plattform-Teams scheitern an Trade-off-Disziplin, selten an Technik: Das hartnäckigste Anti-Pattern 2026 ist die Plattform, die jedes Team-Special-Wunsch übernimmt und damit ihre eigene Standardisierungslogik aushöhlt.

Verwandt:BYOD im deutschen Enterprise 2026  /  SAP Sovereign Cloud France

Was ist Platform Engineering?

Was ist Platform Engineering? Platform Engineering bezeichnet die Disziplin, eine interne Entwickler-Plattform aufzubauen, die wiederkehrende Lifecycle-Operationen wie Service-Bereitstellung, Skalierung, Updates und Rückbau über standardisierte Self-Service-Workflows abbildet. Die Plattform ersetzt nicht die Cloud-Infrastruktur, sondern legt eine Abstraktion darüber, die Anwendungs-Teams ohne Operations-Eingriff nutzen können. Eine reife Plattform liefert fünf Schichten konsistent: Abstraktion mit klaren Verträgen, standardisierte Lifecycle-Operationen, Reversibilität in der gleichen Stunde, messbaren Beitrag zur Lead-Time und ein bewusstes Trade-off-Regime über akzeptierte und abgelehnte Use-Cases.

Vom Hype zum operativen Stresstest

Platform Engineering ist 2026 in der Breite angekommen. Gartner zählt das Disziplin-Label in deutlich mehr Konferenz-Tracks und Stellenanzeigen. Das ist die gute Nachricht. Die andere: die Fehlinterpretationen wachsen schneller mit. Wer heute ein Plattform-Team aufbaut, trifft auf drei Erwartungen, die selten kompatibel sind.

Die Entwickler erwarten eine Erfahrung wie bei einem Public-Cloud-Provider. Die Security-Verantwortlichen wollen weniger Schatten-IT und einheitliche Audit-Trails. Die Plattform-Owner sollen beides liefern, mit einer Mannschaft im einstelligen Bereich, ohne nennenswertes Test-Environment.

In dieser Spannung entstehen die Fassaden-Plattformen. Sie sehen nach Self-Service aus. Sie funktionieren auch, solange ein Team genau das tun will, was die Knopf-Maske vorsieht. Sobald jemand eine Konfiguration anpassen muss, fällt das Konstrukt auf den alten Ticket-Workflow zurück.

Der Fassaden-Test: drei Symptome

Wir haben in den letzten zwölf Monaten ein knappes Dutzend Plattformen reviewt, davon ungefähr die Hälfte in Industrieunternehmen mit eigener IT-Tochter. Drei Symptome tauchen verlässlich auf, wenn die Plattform-Substanz fehlt.

Symptom eins: Die Plattform kennt nur den glücklichen Pfad. Eine neue Datenbank-Instanz lässt sich in zwei Klicks anlegen. Ein Rollback nach drei Wochen erfordert eine Mail an das Plattform-Team. Wer Self-Service ernst meint, baut beides in den gleichen Workflow.

Symptom zwei: Die Abstraktion endet am UI. Hinter der Maske passieren Bash-Skripte, manuelle Approvals und Ad-hoc-Ansible-Runs. Das funktioniert. Es bleibt allerdings ein hübscher Wrapper um Operations. Die Abstraktion fehlt genau dort, wo die Plattform Mehrwert bringen sollte: in der Lifecycle-Logik.

Symptom drei: Die Kennzahlen messen die UI, nicht das Outcome. Wir lesen Dashboards mit Knopfdruckzahlen, Klickraten und Time-to-First-Login. Selten finden wir Lead-Time-to-Production, Mean-Time-to-Restore oder die Quote der Self-Service-Operationen, die ohne Ticket-Eskalation enden.

Was eine echte Plattform liefert

Eine interne Plattform, die ihren Namen verdient, liefert fünf Schichten konsistent. Wer eine davon nicht beherrscht, hat eine Toolchain. Das ist auch in Ordnung. Aber dann sollte das Team nicht Plattform heißen.

Erste Schicht: Abstraktion mit klaren Verträgen. Ein Service-Owner deklariert seine Anforderungen über ein API-Schema. Die Plattform übersetzt das in konkrete Cloud-Ressourcen. Crossplane, Terraform-Modules und Kubernetes-Operators sind dafür reife Werkzeuge. Die Entscheidung ist weniger Tool, mehr Schema-Disziplin: was die Plattform versteht und was sie ablehnt, gehört in einen versionierten Vertrag.

Zweite Schicht: standardisierte Lifecycle-Operationen. Create, Update, Scale, Decommission. Alle vier Operationen müssen den gleichen Pfad nehmen. Die Plattform, die nur Create anbietet, ist eine Halbplattform. Wer Decommission per Ticket macht, wird Self-Service nicht skalieren.

Dritte Schicht: Reversibilität in der gleichen Stunde. Das ist der härteste Test. Eine produktiv genutzte Plattform erlaubt es, eine Fehlbestellung in der gleichen Stunde rückgängig zu machen. Ohne Eskalation, ohne Sondergenehmigung. Wer den Rückbau in den Plattform-Workflow integriert, hat eine Plattform. Wer ihn auslagert, hat einen Eingangsschalter.

Vierte Schicht: messbarer Lead-Time-Beitrag. Die Plattform reduziert die Zeit zwischen Code-Commit und produktiv laufendem Service. Wer diese Kennzahl nicht erhebt, kann nicht beweisen, dass die Plattform existiert. Branchenstandard 2026 sind Reduktionen um Faktor drei bis fünf gegenüber Ticket-getriebenen Prozessen.

Fünfte Schicht: ein bewusstes Trade-off-Regime. Die Plattform kann nicht jeden Sonderwunsch übernehmen. Sie braucht eine klare Liste der unterstützten Operationen. Daneben einen Eskalationspfad für den Rest. Plattformen scheitern selten an Last, häufig an Special-Cases, die ungeprüft hereinkommen und die Standardisierungslogik aushöhlen.

Wer die Plattform baut, entscheidet das Trade-off-Regime

Ein häufiger Fehler ist die Besetzung des Plattform-Teams ausschließlich mit Senior-Engineers. Das Team braucht technische Tiefe. Es braucht aber genauso einen Product-Owner mit der Bereitschaft, Anfragen abzulehnen. Daneben einen Stakeholder, der die Trade-off-Disziplin in der Linie verteidigt. Wer den Product-Owner spart, bekommt eine Plattform, die jedes Special-Wish akzeptiert. Wer den Linien-Stakeholder spart, bekommt eine Plattform, die nach achtzehn Monaten Wartungsmodus ausgerollt wird.

Die produktivsten Teams, die wir reviewt haben, hatten zwischen vier und acht Personen, davon eine in der Product-Owner-Rolle und eine mit explizitem Mandat für Developer-Experience. Die Plattform-Größe folgte der Frequenz der Lifecycle-Operationen, nicht der Anzahl der konsumierenden Teams. Eine Plattform, die fünfzig Teams bedient, aber nur dreißig Operationen pro Tag handhabt, kommt mit weniger Personal aus als eine Plattform mit zehn Teams und tausend Operationen täglich.

Vier Wochen bis zur ehrlichen Selbsteinschätzung

Wer eine bestehende Plattform überprüfen will, kommt mit einem klaren Vier-Wochen-Plan weit. Der Plan ist kein Audit, sondern ein Spiegel. Er beantwortet die Frage, ob die Plattform Substanz hat oder ob ein Refactor ansteht.

Woche eins: Inventur der Self-Service-Workflows. Liste alle Plattform-Operationen auf, die ohne Plattform-Team-Eingriff durchlaufen. Liste daneben alle Operationen, die formal Self-Service heißen, aber faktisch Tickets generieren. Die Differenz ist der Fassaden-Anteil.

Woche zwei: Lead-Time-Messung. Erfasse für drei beispielhafte Service-Lifecycle (eine neue Datenbank, ein neuer Microservice, ein Decommission eines alten Service) die Zeit von Anforderung bis produktive Wirkung. Erfasse parallel die Anzahl der Personen, die involviert waren. Eine echte Plattform reduziert beides.

Woche drei: Rückbau-Test. Wähle drei Self-Service-Operationen aus Woche eins und vollziehe sie rückwärts. Wenn der Rückbau nicht im gleichen Workflow läuft, ist die Plattform asymmetrisch. Das ist verkraftbar, erklärt aber, warum Self-Service-Quoten in vielen Setups nicht steigen.

Woche vier: Trade-off-Bilanz. Trage zusammen, wie oft die Plattform in den letzten neunzig Tagen Special-Cases akzeptiert hat, die ihre eigene Standardisierungslogik unterlaufen. Setze das in Relation zur Anzahl der Operationen, die der Standardlogik gefolgt sind. Das Verhältnis sagt mehr über die Zukunft der Plattform als jede Roadmap.

Was Plattform-Teams 2026 messen müssen

Die Plattform-Kennzahlen, die uns überzeugen, sind weniger ambitioniert als die in den meisten Decks. Sie sind dafür belastbar. Vier Werte reichen, wenn sie konsequent erhoben werden.

Self-Service-Quote: Anteil der Plattform-Operationen, die ohne Plattform-Team-Eingriff durchlaufen. Branchenwerte über fünfundsiebzig Prozent sind erreichbar, aber nur mit echter Reversibilität.

Lead-Time-to-Production: Median-Zeit zwischen Service-Request und produktiv laufender Ressource. Werte unter zwei Stunden für Standard-Operationen, unter einem Tag für komplexere Pfade.

Eskalationsquote: Anteil der Operationen, die im laufenden Workflow ans Plattform-Team eskaliert werden. Wer hier unter zehn Prozent kommt, hat eine reife Plattform. Wer dauerhaft über dreißig Prozent liegt, betreibt einen Wrapper.

Trade-off-Compliance: Anteil der gebauten Funktionalität, die dem dokumentierten Plattform-Standard entspricht. Diese Kennzahl wird oft unterschlagen, weil sie unbequem ist. Sie ist trotzdem die ehrlichste Prognose über die Plattform-Lebensdauer.

Plattform-Engineering 2026 ist kein Architektur-Pattern. Es ist eine Disziplin, in der die unangenehmen Entscheidungen vor der hübschen UI kommen. Wer das umdreht, baut eine Fassade. Die hält ein bis zwei Budgetzyklen.

Plattform vs. Portal: Pros und Cons im Vergleich

Mehr aus dem MBF Media Netzwerk

• BYOD im deutschen Enterprise 2026 (cloudmagazin)
• SAP Sovereign Cloud Frankreich: SecNumCloud und Bleu im Vergleich (cloudmagazin)
• Compliance-Kosten: Architektur entscheidet (cloudmagazin)

Häufige Fragen

Wann lohnt sich der Aufbau eines eigenen Plattform-Teams?

Ab einer Größenordnung von ungefähr fünfzig Entwicklern oder mehr als zehn parallelen Services lohnt sich ein dediziertes Plattform-Team. Darunter ist eine kuratierte Toolchain mit klarer Ownership oft die effizientere Lösung. Entscheidend ist die Frequenz wiederkehrender Lifecycle-Operationen, weniger die Personenzahl.

Wie unterscheidet sich Platform Engineering von klassischem DevOps?

DevOps ist eine Kulturpraktik, die Entwicklung und Betrieb in den gleichen Verantwortungsbereich legt. Platform Engineering ist eine Bereitstellungsdisziplin, die diese Verantwortung über eine interne Plattform skalierbar macht. DevOps ohne Plattform funktioniert in kleinen Teams. Plattform ohne DevOps-Kultur produziert Schatten-Tickets.

Welche Tools gehören 2026 zur Standard-Plattform?

Eine reife interne Plattform kombiniert üblicherweise einen GitOps-Workflow (ArgoCD oder Flux), eine Abstraktionsschicht (Crossplane oder eigenes Operator-Set), ein Developer-Portal (Backstage oder Eigenbau) und konsistente Observability (OpenTelemetry-Stack). Welches konkrete Werkzeug gewählt wird, ist weniger relevant als die Frage, ob die Plattform die fünf Schichten Abstraktion, Lifecycle, Reversibilität, Lead-Time und Trade-off-Disziplin sauber abbildet.

Wie überzeugt man Entwickler-Teams, die Plattform tatsächlich zu nutzen?

Über Reduktion, kaum jemals über Mandate. Wer eine Operation auf der Plattform um Faktor drei schneller als außerhalb erledigen kann, nutzt sie freiwillig. Plattform-Teams, die mit Pflicht-Anweisungen arbeiten müssen, haben in der Regel ein Substanz-Problem, kein Compliance-Problem.

Was tun, wenn die bestehende Plattform sich als Fassade herausstellt?

Ein Refactor ist meist günstiger als eine Neugründung. Der Fokus liegt darauf, die Lifecycle-Operationen schrittweise in die Plattform-Abstraktion zu ziehen, anstatt das UI weiter auszubauen. Wer in den nächsten sechs Monaten Reversibilität, eine harte Trade-off-Liste und eine Lead-Time-Messung verankert, gewinnt die meisten Plattformen zurück.

Bildquelle: KI-generiert (Mai 2026), C2PA-Zertifikat im Bild hinterlegt