Die Straße bauen, auf der andere fahren
Eine interne Plattform wird nicht daran gemessen, wie viel sie kann, sondern daran, wie viele Teams sie freiwillig benutzen, statt sich daneben ihren eigenen Weg zu bauen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Ohne Nutzer ist eine Plattform nur ein weiteres System, das jemand betreiben muss
Der übliche Anfang: Ein Team baut eine Vorlage, eine Pipeline und ein paar Bausteine, und danach soll der Rest des Hauses damit arbeiten. Genutzt wird es von zwei Teams, die übrigen bauen weiter ihr eigenes, weil ihr Sonderfall nicht abgedeckt ist. Jetzt gibt es beides, und beides muss gepflegt werden.
Der zweite Fehler ist die Warteschlange. Wenn eine neue Umgebung, ein Zugang oder eine Datenbank per Ticket beim Plattformteam beantragt wird, ist die Plattform kein Selbstbedienungsangebot, sondern ein Betriebsteam mit neuem Namen. Der Engpass wandert dann nur, er verschwindet nicht.
Was das kostet, zeigt die Zeit bis zum ersten Produktivgang eines neuen Dienstes. Wo jedes Team Pipeline, Überwachung, Rechte und Zertifikate selbst zusammensucht, vergehen Wochen, und jede dieser Varianten ist später eine eigene Baustelle bei jedem Sicherheitsupdate.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet was zwischen Plattform und Anwendungsteams
Die meisten Konflikte in Plattformteams entstehen nicht an der Technik, sondern an der Frage, wie weit die Zuständigkeit der Plattform reicht. Die Übersicht ordnet die wiederkehrenden Themen zu.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Was in den goldenen Pfad aufgenommen wird | Das Plattformteam, auf Basis des Bedarfs mehrerer Anwendungsteams | Das Plattformteam selbst, mit einem der Anwendungsteams als erstem Nutzer | Ein Sonderwunsch eines einzelnen Teams landet im Pfad und muss danach für alle gepflegt werden. |
| Wer im Störungsfall gerufen wird | Eine vorher festgelegte Grenze zwischen Plattform und Anwendung | Beide Seiten mit eigener Bereitschaft und einem gemeinsamen Eskalationsweg | Die Grenze ist nur mündlich vereinbart, und im Ernstfall diskutieren zwei Teams über Zuständigkeit statt über die Ursache. |
| Abweichung vom Pfad | Das Anwendungsteam, das die Folgen dann selbst trägt | Das Anwendungsteam, mit dokumentierter Begründung und eigener Wartung | Die Abweichung wird stillschweigend erlaubt, und beim nächsten Sicherheitsupdate fehlt genau dieser Dienst in der Übersicht. |
| Versionswechsel des Unterbaus | Das Plattformteam, mit angekündigtem Zeitfenster und Übergangsfrist | Die Anwendungsteams, unterstützt durch Vorlagen und Prüfläufe | Der Wechsel wird verschoben, bis der alte Stand keine Sicherheitsaktualisierungen mehr bekommt, und dann ist es ein Notfall. |
| Kosten der Umgebungen | Die Stelle, die das Budget trägt, auf Basis einer verursachungsgerechten Zuordnung | Das Plattformteam über Grenzen, Ablaufdaten und automatisches Abräumen | Die Kosten laufen zentral auf, kein Team sieht die eigenen, und deshalb räumt niemand auf. |
Was in den goldenen Pfad aufgenommen wird
- Wer entscheidet
- Das Plattformteam, auf Basis des Bedarfs mehrerer Anwendungsteams
- Wer setzt um
- Das Plattformteam selbst, mit einem der Anwendungsteams als erstem Nutzer
- Stolperfalle
- Ein Sonderwunsch eines einzelnen Teams landet im Pfad und muss danach für alle gepflegt werden.
Wer im Störungsfall gerufen wird
- Wer entscheidet
- Eine vorher festgelegte Grenze zwischen Plattform und Anwendung
- Wer setzt um
- Beide Seiten mit eigener Bereitschaft und einem gemeinsamen Eskalationsweg
- Stolperfalle
- Die Grenze ist nur mündlich vereinbart, und im Ernstfall diskutieren zwei Teams über Zuständigkeit statt über die Ursache.
Abweichung vom Pfad
- Wer entscheidet
- Das Anwendungsteam, das die Folgen dann selbst trägt
- Wer setzt um
- Das Anwendungsteam, mit dokumentierter Begründung und eigener Wartung
- Stolperfalle
- Die Abweichung wird stillschweigend erlaubt, und beim nächsten Sicherheitsupdate fehlt genau dieser Dienst in der Übersicht.
Versionswechsel des Unterbaus
- Wer entscheidet
- Das Plattformteam, mit angekündigtem Zeitfenster und Übergangsfrist
- Wer setzt um
- Die Anwendungsteams, unterstützt durch Vorlagen und Prüfläufe
- Stolperfalle
- Der Wechsel wird verschoben, bis der alte Stand keine Sicherheitsaktualisierungen mehr bekommt, und dann ist es ein Notfall.
Kosten der Umgebungen
- Wer entscheidet
- Die Stelle, die das Budget trägt, auf Basis einer verursachungsgerechten Zuordnung
- Wer setzt um
- Das Plattformteam über Grenzen, Ablaufdaten und automatisches Abräumen
- Stolperfalle
- Die Kosten laufen zentral auf, kein Team sieht die eigenen, und deshalb räumt niemand auf.
Fünf Merkmale eines Pfads, den Teams freiwillig nehmen
- 01 Ein neuer Dienst startet aus einer Vorlage statt aus einer Anleitung.
- 02 Umgebungen entstehen per Selbstbedienung ohne Ticket.
- 03 Überwachung und Protokolle sind von Anfang an angeschlossen.
- 04 Sicherheit und Rechte stecken im Weg, nicht in einem Prüfschritt.
- 05 Der Ausstieg aus dem Pfad bleibt möglich und ist dokumentiert.
Was du mitnimmst
Du bekommst die Denkweise, die diese Rolle von reinem Betrieb unterscheidet, und die Kriterien, an denen du erkennst, ob deine Plattform benutzt wird oder nur existiert.
Interne Nutzer ernst nehmen
Du sprichst regelmäßig mit den Entwicklungsteams, bevor du etwas baust, und behandelst ihre Rückmeldungen wie Anforderungen an ein Produkt.
Selbstbedienung statt Antragsweg
Du gibst Umgebungen, Zugänge und Datenbanken über eine Schnittstelle heraus, die ohne dich funktioniert, sonst bleibt dein Team der Engpass.
Den Pfad attraktiv machen
Du sorgst dafür, dass der vorgezeichnete Weg der bequemste ist, weil ein Verbot der Abkürzung nur den Umgehungsweg unsichtbar macht.
Leitplanken statt Sperren
Du legst Sicherheit, Rechte und Kostenzuordnung in die Vorlage, damit sie mitkommt, ohne dass jemand sie einzeln beantragen muss.
Den Unterbau planbar erneuern
Du planst Versionswechsel der darunterliegenden Plattform als wiederkehrende Arbeit ein, weil sie sonst als Notfall stattfindet.
Nutzung messen, nicht Funktionsumfang
Du erhebst, wie viele Teams den Weg nutzen und wie lange ein neuer Dienst bis zum ersten Produktivgang braucht.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was diese Rolle von DevOps Engineer und Site Reliability Engineer trennt
Die drei Begriffe beschreiben verschiedene Dinge, auch wenn dieselbe Person sie in einem mittelgroßen Haus alle drei ausfüllt. DevOps ist eine Arbeitsweise, die als Stellentitel zweckentfremdet wurde, und meint im Alltag meistens Betrieb mit hohem Automatisierungsanteil. Site Reliability ist eine Vereinbarung mit Zahlen: Zuverlässigkeitsziele, ein Fehlerbudget und die Konsequenz, wenn es aufgebraucht ist. Plattformarbeit ist ein Produkt mit internen Nutzern.
Aus dieser Unterscheidung folgt der Alltag. Ein Plattformteam führt Gespräche mit Entwicklungsteams, pflegt eine Art Fahrplan, schreibt Dokumentation und baut Vorlagen. Der CNCF-Leitfaden zu Plattformen sagt das offen: Eine Plattform ist ein Produkt, sie existiert für die Anforderungen ihrer Nutzer, und Anweisungen von oben ohne deren Beteiligung erzeugen Widerstand statt Nutzung.
Die häufigste falsche Erwartung ist, das Plattformteam sei die Stelle, die Zugänge vergibt. Wer diese Rolle so besetzt, bekommt einen internen Dienstleister mit Wartezeiten. Das Ziel ist das Gegenteil: Die Plattform soll den Weg so vorzeichnen, dass die meisten Anfragen gar nicht erst entstehen.
Woraus ein goldener Pfad tatsächlich besteht
Am Anfang steht die Vorlage für einen neuen Dienst: Verzeichnisstruktur, Pipeline, Prüfschritte, Protokollierung, Überwachung, Rechte und ein Eintrag im Katalog, alles aus einem Guss. Ein Entwicklerportal wie Backstage bündelt das, weil es Katalog, Vorlagen, Zuständigkeiten und Dokumentation an eine Stelle bringt. Der Wert liegt weniger im Portal selbst als in der Frage, die es beantwortet: Wem gehört dieser Dienst, und wo läuft er.
Der zweite Baustein ist die Bereitstellung von Infrastruktur. Statt Tickets für Datenbanken, Warteschlangen oder Speicher zu bearbeiten, hinterlegst du sie als anforderbare Bausteine, etwa über eine Steuerungsebene wie Crossplane oder über eine Beschreibung als Code. Die Kunst ist der Zuschnitt: zu grob, und die Teams brauchen doch wieder Hilfe, zu fein, und du hast eine zweite Programmiersprache erfunden, die niemand kennt.
Der dritte Baustein sind die Leitplanken. Vorgaben zu Rechten, Netzwerkzugriff, Herkunftsnachweisen und Kostenzuordnung wirken am besten, wenn sie im Pfad stecken und nicht in einer Freigabe am Ende. Wichtig bleibt der Ausgang: Ein Team muss die Plattform verlassen können, wenn sein Fall nicht passt, sonst entsteht ein Schattenweg, den niemand kennt.
Woher die amtliche Zahl auf dieser Seite kommt
Für Plattformarbeit gibt es keine eigene Berufsgattung. Die Zelle unten stammt aus der IT-Organisation auf dem Anforderungsniveau Spezialist, weil diese Rolle Abläufe für andere Teams verantwortet und nicht einzelne Systeme betreut. Das ist eine Näherung und keine Messung dieser Rolle.
Anforderungsniveau bedeutet dabei Zuschnitt der Stelle und nicht Berufserfahrung der Person. Ein Vergleich mit den Zellen auf den Nachbarseiten zu Site Reliability und Auslieferung wäre deshalb ein Vergleich von Berufsgruppen und nicht von Rollen: Dort ist die Näherung IT-Systemadministration beziehungsweise Softwareentwicklung, und die Unterschiede zwischen diesen Zellen sagen nichts darüber, welche der drei Rollen ein Haus höher bewertet.
Es sind Bruttomonatsverdienste von Vollzeitbeschäftigten ohne Sonderzahlungen, der Jahresverdienst liegt also über dem Zwölffachen, sobald es Weihnachts- oder Urlaubsgeld gibt. Der Median ist die belastbarere Größe, weil einzelne sehr hohe Verdienste den Durchschnitt nach oben ziehen.
Der Weg hinein und was dabei zählt
Die meisten kommen aus dem Betrieb, einige aus der Entwicklung. Aus dem Betrieb bringst du mit, wie ein System sich unter Last und im Fehlerfall verhält, und dir fehlt oft der Blick dafür, wie ein Entwicklungsteam arbeitet. Aus der Entwicklung ist es umgekehrt: Du weißt, was im Alltag stört, und unterschätzt, was der Betrieb einer Plattform an wiederkehrender Arbeit bedeutet.
Der Unterschied zu beiden Herkünften ist die Produktdenke, und die lässt sich nicht als Werkzeug lernen. Gemeint ist die Bereitschaft, den eigenen Entwurf zu verwerfen, wenn zwei Teams ihn nicht benutzen, und stattdessen zu fragen, warum. Wer aus dieser Haltung heraus arbeitet, sammelt schnell Belege für Gespräche: Zeit bis zum ersten Produktivgang, Zahl der Teams auf dem Pfad, Zahl der Sonderwege.
Nachweise gibt es für dieses Feld nur mittelbar. Die verbreiteten Prüfungen betreffen den Unterbau, also Containerplattform, Automatisierung und Infrastruktur als Code. Sie belegen Handwerk und keine Plattformarbeit, ersparen dir aber die technische Diskussion im Bewerbungsgespräch.
Woran du wächst und wohin die Rolle führt
Zwei Leute mit gleicher Berufsdauer unterscheiden sich daran, ob sie Nein sagen können, ohne die Nutzer zu verlieren. Jeder aufgenommene Sonderfall macht den Pfad breiter und die Pflege teurer. Wer alles aufnimmt, betreibt am Ende fünf Varianten, wer nichts aufnimmt, sieht den Teams beim Danebenbauen zu.
Das zweite Unterscheidungsmerkmal ist die Bereitschaft, eine Abstraktion wieder abzuschaffen. Eine Vorlage, die mehr verbirgt, als sie erklärt, wird zum Problem, sobald ein Fehler auftritt, den niemand mehr zurückverfolgen kann. Gute Plattformarbeit lässt den darunterliegenden Stand sichtbar.
Weiter geht es Richtung Architektur, Richtung Site Reliability, wenn dich Messbarkeit und Betrieb mehr reizen, oder in die fachliche Leitung eines Plattformbereichs. In Häusern mit eigener Entwicklung ist Plattformarbeit inzwischen häufig der Weg, auf dem Betriebsleute in eine Produktrolle kommen, ohne die Technik zu verlassen.
Dazu passende Kurse
Wie so ein Pfad entsteht und was in die Vorlage gehört, üben Kurse, in denen du einen vorgezeichneten Weg für Entwicklungsteams anlegst .
Damit Umgebungen nicht mehr von Hand zusammengesetzt werden, helfen Trainings, in denen Umgebungen aus einer Beschreibung entstehen .
Die amtlichen Zahlen zu dieser Rolle
Die Zahl stammt aus der Berufsgattung IT-Organisation auf dem Anforderungsniveau Spezialist, weil diese Rolle Abläufe für andere Teams verantwortet und nicht einzelne Systeme betreut. Eine eigene Gattung für Plattformarbeit gibt es nicht, die Zelle ist also eine Näherung und keine Messung dieser Rolle. Das Anforderungsniveau beschreibt den Zuschnitt der Stelle und nicht die Berufserfahrung der Person. Es sind Vollzeitwerte ohne Sonderzahlungen, und der Median trägt weiter als der Durchschnitt, den einzelne Spitzenverdienste anheben.
Amtliche Medianverdienste, April 2025
Brutto im MonatStatistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.
KldB 43333, Durchschnitt 6.334 €, gerundet rund 72.000 € im Jahr ohne Sonderzahlungen
- Vollzeitbeschäftigte, Bruttomonatsverdienst ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld, Prämien und Boni sind nicht enthalten, der Jahresverdienst liegt also über dem Zwölffachen.
- Das Anforderungsniveau beschreibt den Zuschnitt der Stelle, nicht die Berufserfahrung. Fachkraft, Spezialist und Experte sagen etwas über die Komplexität der Tätigkeit aus, nicht über Dienstjahre.
- Die Erhebung geht regional nur bis auf die Bundeslandebene. Für einzelne Städte gibt es keine amtlichen Zahlen, weil der Zufallsfehler zu groß wäre.
Quelle: Statistischer Bericht Verdienste , Statistisches Bundesamt (Destatis). Den eigenen Fall prüfst du im Entgeltatlas der Bundesagentur für Arbeit . Beachte dort: Entgelte oberhalb der Beitragsbemessungsgrenze sind der Statistik nicht bekannt, bei gut bezahlten IT-Rollen steht deshalb nur eine Untergrenze.
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Was ist der Unterschied zwischen Platform Engineer und DevOps Engineer?
Ab welcher Größe lohnt sich ein eigenes Plattformteam?
Brauche ich Kubernetes-Kenntnisse für die Rolle?
Woran messe ich, ob die Plattform etwas bringt?
Passt thematisch dazu
Vor der Rolle steht die Entscheidung für die Sache, und dazu gehört die Frage, wann sich ein eigenes Plattformteam überhaupt rechnet .
Weil Umgebungen selten von selbst verschwinden, lohnt der Blick darauf, wo in einer Containerplattform das Geld verschwindet .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Eine Plattform lebt von den Teams, die sie benutzen
Wie ein vorgezeichneter Weg entsteht, wie ein Entwicklerportal ihn sichtbar macht und wie Infrastruktur zur Selbstbedienung wird, lässt sich Schritt für Schritt aufbauen.
Passt dazu
- DevOps Engineer: eine Rolle, die es als Beruf offiziell nicht gibt
- Site Reliability Engineer: Verfügbarkeit ist ein Ziel mit Zahl
- Softwarearchitekt: du triffst Entscheidungen, die man später schwer zurücknimmt
- Release Engineer: zwischen dem letzten Commit und dem ersten Nutzer