Die Digitalisierung schreitet voran, Anwendungen werden komplexer und mit ihnen die Anforderungen an Teams, die sie entwickeln und betreiben. Begriffe wie „Platform Engineering“, „Internal Developer Platform“ oder „Self-Service Infrastructure“ tauchen immer häufiger auf. Große Tech-Unternehmen zeigen, wie mächtig eine gut gebaute Plattform sein kann: Entwickler arbeiten schneller, unabhängiger und sicherer. Doch lohnt sich dieser Aufwand für jedes Unternehmen? Hier geht's zum zweiten Teil unserer Blogreihe "Wie viel Plattform passt zu mir?" Im zweiten Teil hatten wir definiert, welche Reifegrad Modelle es für eine Plattform gibt und welche Faktoren in der Organisation die Plattform beeinflussen. Im diesem Teil schauen wir uns das Vorgehen an, um zu einer idealen Plattform Größe und Abstraktion zu gelangen.
Der Weg zu meiner perfekten Plattform
Nachdem wir uns erarbeitet haben, was Platform Engineering ist, die verschiedenen Reifegrade der Plattform vorgestellt haben und die Einflussfaktoren definiert haben, widmen wir uns nun der Frage, wie ich zu einer Plattform komme, die einen guten Umfang für meine Organisation hat.
Wie bei vielen Software-Projekten hilft uns auch hier ein iteratives Vorgehen, um zügig Mehrwert zu schaffen, schnell zu lernen und so das Risiko einer nicht passenden Plattform zu minimieren.
Das Plattform Team
Bevor wir uns das erste Plattform Komponente widmen, müssen wir unser Plattform Team definieren. Dabei haben wir folgende Rollen zu vergeben:
Head of Platform Engineering: Ist verantwortlich für das Plattform Team und die Plattform. Die Rolle hat dafür Sorge zu tragen, dass jedes Teammitglied seine Aufgaben erfüllen kann und die Plattform Ziele erreicht werden.
Platform Product Manager: Kümmert sich um die Vision, Strategie und Features der Plattform. Kann analog zu einem Product Owner in einem Scrum Team gesehen werden.
Infra Platform Engineer: Vertreter der Infrastruktur, Operations und z. B. Security Teams. Tragen dafür Sorge, dass Software so deployed ist, wie es von dem Infrastruktur Team unter Einhaltung der Compliance & Governance vorgesehen ist.
DevEx Platform Engineer: Vertreter der Entwickler Teams. Sie verstehen den Entwicklungsprozess und kümmern sich darum, dass dieser in der Plattform bestmöglich umgesetzt ist, damit sinnvolle Abstraktionen geschaffen werden.
Je nach Unternehmensgröße, Vorhaben und Investitionsbereitschaft ist das Team unterschiedlich groß.
Es können auch mehrere Rollen von einer Person ausgefüllt werden, zum Beispiel die Management Rollen: Head of Platform Engineering und Platform Product Manager. Ein anderer Weg ist, die Teammitglieder nur für eine gewisse Zeit abzustellen, an denen sie an der Plattform arbeiten. Bei geringer Kritikalität der Plattform Komponenten ein durchaus gangbarer Weg.
Ferner kann aber auch ein dediziertes Plattform Team aufgebaut werden. Dies kostet meist Zeit bis die Teammitglieder rekrutiert wurden und mit dem Bau der Plattform gestartet werden kann, hat dann aber den Vorteil, dass man ein schlagkräftiges Team hat, welches sich voll auf die Plattform konzentrieren kann, um die Entwicklerteams bestmöglich zu unterstützen.
Um diesen Prozess zu beschleunigen, sind wir bei unseren Kunden angefangen die Plattform aufzubauen und nach und nach die eigenen Platform Engineers des Kunden anzulernen und die Plattform zu übergeben.
Planung der Umsetzung
Nachdem unser Platform Engineering Team steht, kümmern wir uns darum die ersten Aufgabenpakete zu definieren, dabei können folgende Fragen als Orientierung dienen:
Welche wiederkehrenden Aufgaben rauben meinem Team Zeit?
Welche Prozesse könnten von Automatisierung oder Self-Service profitieren?
An welchen Stellen ist der Bedarf an Governance, Security und Compliance groß?
Wie viel Aufwand können wir in den Aufbau einer Plattform investieren?
Wie reagieren die Entwickler auf neue Tools und Standards?
Die Herausforderung ist, nicht zu früh zu viel Plattform aufzubauen — sonst entstehen ungenutzte Features und Mehraufwand. Außerdem sollten wir uns darum kümmern, zu erheben, wie viel unsere Plattform Komponenten genutzt werden und welchen Mehrwert sie bringen, damit wir unser Vorhaben stets hinterfragen und den Erfolg sichtbar machen können.
Umsetzung der ersten Plattform-Komponente
Nachdem wir unsere erste Plattform Komponente definiert haben, geht es darum eine geeignete Abstraktion zu finden und diese umzusetzen. Nehmen wir einmal folgendes Beispiel an: Das Plattform Team hat herausgefunden, dass das Deployment neuer Softwareversionen viel Zeit beansprucht, weil es bisher ein manueller Prozess ist. Sie haben definiert ein Pipeline Step zur Verfügung zu stellen, womit dieser Prozess automatisiert ist.
Nach der Implementierung ist es sinnvoll diesen Step mit einem Team auszuprobieren und Feedback zu sammeln. Sobald der Pipeline Step rund wirkt, kann die gesamte Organisation darüber informiert werden.
Es ist wichtig, dass bei Problemen diesen Step zu benutzen, die Schwelle für Support niedrigschwellig ist. Bestenfalls gibt es einen Kanal, über den sofort ein Teammitglied des Platform Engineering Teams erreicht werden kann, welcher bei der Umsetzung unterstützt oder gegebenenfalls den Step auf die Anforderungen anpasst. Die Erkenntnis, dass die Abstraktion nicht zu dem Use Case des Entwicklungsteams passt, ist auch ok. Entscheidend für den Erfolg der Plattform ist, dass sich die Entwicklungsteams nicht mit der Plattform allein gelassen werden.
Abbildung 1: Erreichen der idealen Plattform Größe durch iteratives Vorgehen
Risiken und Anti-Pattern
Platform Engineering bietet viele Vorteile, doch wie jede Veränderung birgt auch der Aufbau einer Plattform Risiken und Fallstricke. Wer diese kennt, kann ihnen gezielt vorbeugen und den Erfolg der Plattform sicherstellen.
Die Overengineering Falle
Ein häufiges Risiko ist die sogenannte Overengineering-Falle. Plattformen werden manchmal zu groß, zu komplex oder mit Features vollgestopft, die kaum genutzt werden. Das kostet viel Zeit und Geld – und führt oft dazu, dass Entwickler die Plattform meiden und eigene Lösungen basteln. Eine Plattform, die niemand nutzt, bringt aber keinen Nutzen.
Das „Big Bang“ Problem
Eng damit verbunden ist das „Big Bang“-Problem: Der Versuch, von heute auf morgen eine umfassende Plattform einzuführen, scheitert meist. Organisationen unterschätzen den Aufwand für Design, Umsetzung und vor allem Akzeptanz. Eine Plattform muss wachsen und sich Schritt für Schritt an die Bedürfnisse der Nutzer anpassen.
Die fehlende Verantwortlichkeit
Ein weiteres Anti-Pattern ist die fehlende Verantwortlichkeit. Wenn nicht klar ist, wer das Plattform Team ist und wer welche Rolle innehat, gibt es keine klare Linie in der Entwicklung. Bugs, fehlende Dokumentation oder fehlende Weiterentwicklung führen dazu, dass die Plattform stagniert oder sogar zur Belastung wird.
Die Ignoranz gegenüber der Nutzerperspektive
Auch die Ignoranz gegenüber der Nutzerperspektive ist problematisch. Plattformen müssen für Entwickler intuitiv und hilfreich sein. Wenn Anforderungen der Nutzer zu wenig berücksichtigt werden, entsteht ein Werkzeug, das den Arbeitsalltag eher erschwert als erleichtert. Feedbackschleifen sind daher essenziell.
Die Unterschätzung der kognitiven Last
Nicht selten wird auch die kognitive Last für Entwickler unterschätzt. Ziel von Platform Engineering ist es, diese Last zu reduzieren – nicht zu verlagern. Eine Plattform mit zu vielen komplizierten Abstraktionen oder undurchsichtigen Prozessen kann genau das Gegenteil bewirken.
Das Risiko von Insellösungen
Schließlich sollte man das Risiko der Insellösungen im Auge behalten: Wenn einzelne Teams eigene Plattform-Komponenten oder Tools bauen, ohne diese zu integrieren, entsteht Wildwuchs und Komplexität. Plattformen leben von Standardisierung und Wiederverwendbarkeit – das muss sich in der Organisation widerspiegeln.
Ausblick Teil 3:
Wir haben ein Verfahren kennengelernt, wie man iterativ Plattform-Komponenten baut und diese durch ständiges Feedback zu einer Plattform heranreifen lässt.
Platform Engineering ist ein Feld, in dem noch viel Innovation und Entwicklung stattfindet, daher schauen wir uns im vierten Teil an, wie die Zukunft des Platform Engineerings aussehen kann und welche Themen ggf. schon heute mitgedacht werden sollten.
Nachdem wir uns erarbeitet haben, was Platform Engineering ist, die verschiedenen Reifegrade der Plattform vorgestellt haben und die Einflussfaktoren definiert haben, widmen wir uns nun der Frage, wie ich zu einer Plattform komme, die einen guten Umfang für meine Organisation hat.
Wie bei vielen Software-Projekten hilft uns auch hier ein iteratives Vorgehen, um zügig Mehrwert zu schaffen, schnell zu lernen und so das Risiko einer nicht passenden Plattform zu minimieren.
Das Plattform Team
Bevor wir uns das erste Plattform Komponente widmen, müssen wir unser Plattform Team definieren. Dabei haben wir folgende Rollen zu vergeben:
Head of Platform Engineering: Ist verantwortlich für das Plattform Team und die Plattform. Die Rolle hat dafür Sorge zu tragen, dass jedes Teammitglied seine Aufgaben erfüllen kann und die Plattform Ziele erreicht werden.
Platform Product Manager: Kümmert sich um die Vision, Strategie und Features der Plattform. Kann analog zu einem Product Owner in einem Scrum Team gesehen werden.
Infra Platform Engineer: Vertreter der Infrastruktur, Operations und z. B. Security Teams. Tragen dafür Sorge, dass Software so deployed ist, wie es von dem Infrastruktur Team unter Einhaltung der Compliance & Governance vorgesehen ist.
DevEx Platform Engineer: Vertreter der Entwickler Teams. Sie verstehen den Entwicklungsprozess und kümmern sich darum, dass dieser in der Plattform bestmöglich umgesetzt ist, damit sinnvolle Abstraktionen geschaffen werden.
Je nach Unternehmensgröße, Vorhaben und Investitionsbereitschaft ist das Team unterschiedlich groß.
Es können auch mehrere Rollen von einer Person ausgefüllt werden, zum Beispiel die Management Rollen: Head of Platform Engineering und Platform Product Manager. Ein anderer Weg ist, die Teammitglieder nur für eine gewisse Zeit abzustellen, an denen sie an der Plattform arbeiten. Bei geringer Kritikalität der Plattform Komponenten ein durchaus gangbarer Weg.
Ferner kann aber auch ein dediziertes Plattform Team aufgebaut werden. Dies kostet meist Zeit bis die Teammitglieder rekrutiert wurden und mit dem Bau der Plattform gestartet werden kann, hat dann aber den Vorteil, dass man ein schlagkräftiges Team hat, welches sich voll auf die Plattform konzentrieren kann, um die Entwicklerteams bestmöglich zu unterstützen.
Um diesen Prozess zu beschleunigen, sind wir bei unseren Kunden angefangen die Plattform aufzubauen und nach und nach die eigenen Platform Engineers des Kunden anzulernen und die Plattform zu übergeben.
Planung der Umsetzung
Nachdem unser Platform Engineering Team steht, kümmern wir uns darum die ersten Aufgabenpakete zu definieren, dabei können folgende Fragen als Orientierung dienen:
Welche wiederkehrenden Aufgaben rauben meinem Team Zeit?
Welche Prozesse könnten von Automatisierung oder Self-Service profitieren?
An welchen Stellen ist der Bedarf an Governance, Security und Compliance groß?
Wie viel Aufwand können wir in den Aufbau einer Plattform investieren?
Wie reagieren die Entwickler auf neue Tools und Standards?
Die Herausforderung ist, nicht zu früh zu viel Plattform aufzubauen — sonst entstehen ungenutzte Features und Mehraufwand. Außerdem sollten wir uns darum kümmern, zu erheben, wie viel unsere Plattform Komponenten genutzt werden und welchen Mehrwert sie bringen, damit wir unser Vorhaben stets hinterfragen und den Erfolg sichtbar machen können.
Umsetzung der ersten Plattform-Komponente
Nachdem wir unsere erste Plattform Komponente definiert haben, geht es darum eine geeignete Abstraktion zu finden und diese umzusetzen. Nehmen wir einmal folgendes Beispiel an: Das Plattform Team hat herausgefunden, dass das Deployment neuer Softwareversionen viel Zeit beansprucht, weil es bisher ein manueller Prozess ist. Sie haben definiert ein Pipeline Step zur Verfügung zu stellen, womit dieser Prozess automatisiert ist.
Nach der Implementierung ist es sinnvoll diesen Step mit einem Team auszuprobieren und Feedback zu sammeln. Sobald der Pipeline Step rund wirkt, kann die gesamte Organisation darüber informiert werden.
Es ist wichtig, dass bei Problemen diesen Step zu benutzen, die Schwelle für Support niedrigschwellig ist. Bestenfalls gibt es einen Kanal, über den sofort ein Teammitglied des Platform Engineering Teams erreicht werden kann, welcher bei der Umsetzung unterstützt oder gegebenenfalls den Step auf die Anforderungen anpasst. Die Erkenntnis, dass die Abstraktion nicht zu dem Use Case des Entwicklungsteams passt, ist auch ok. Entscheidend für den Erfolg der Plattform ist, dass sich die Entwicklungsteams nicht mit der Plattform allein gelassen werden.
Abbildung 1: Erreichen der idealen Plattform Größe durch iteratives Vorgehen
Risiken und Anti-Pattern
Platform Engineering bietet viele Vorteile, doch wie jede Veränderung birgt auch der Aufbau einer Plattform Risiken und Fallstricke. Wer diese kennt, kann ihnen gezielt vorbeugen und den Erfolg der Plattform sicherstellen.
Die Overengineering Falle
Ein häufiges Risiko ist die sogenannte Overengineering-Falle. Plattformen werden manchmal zu groß, zu komplex oder mit Features vollgestopft, die kaum genutzt werden. Das kostet viel Zeit und Geld – und führt oft dazu, dass Entwickler die Plattform meiden und eigene Lösungen basteln. Eine Plattform, die niemand nutzt, bringt aber keinen Nutzen.
Das „Big Bang“ Problem
Eng damit verbunden ist das „Big Bang“-Problem: Der Versuch, von heute auf morgen eine umfassende Plattform einzuführen, scheitert meist. Organisationen unterschätzen den Aufwand für Design, Umsetzung und vor allem Akzeptanz. Eine Plattform muss wachsen und sich Schritt für Schritt an die Bedürfnisse der Nutzer anpassen.
Die fehlende Verantwortlichkeit
Ein weiteres Anti-Pattern ist die fehlende Verantwortlichkeit. Wenn nicht klar ist, wer das Plattform Team ist und wer welche Rolle innehat, gibt es keine klare Linie in der Entwicklung. Bugs, fehlende Dokumentation oder fehlende Weiterentwicklung führen dazu, dass die Plattform stagniert oder sogar zur Belastung wird.
Die Ignoranz gegenüber der Nutzerperspektive
Auch die Ignoranz gegenüber der Nutzerperspektive ist problematisch. Plattformen müssen für Entwickler intuitiv und hilfreich sein. Wenn Anforderungen der Nutzer zu wenig berücksichtigt werden, entsteht ein Werkzeug, das den Arbeitsalltag eher erschwert als erleichtert. Feedbackschleifen sind daher essenziell.
Die Unterschätzung der kognitiven Last
Nicht selten wird auch die kognitive Last für Entwickler unterschätzt. Ziel von Platform Engineering ist es, diese Last zu reduzieren – nicht zu verlagern. Eine Plattform mit zu vielen komplizierten Abstraktionen oder undurchsichtigen Prozessen kann genau das Gegenteil bewirken.
Das Risiko von Insellösungen
Schließlich sollte man das Risiko der Insellösungen im Auge behalten: Wenn einzelne Teams eigene Plattform-Komponenten oder Tools bauen, ohne diese zu integrieren, entsteht Wildwuchs und Komplexität. Plattformen leben von Standardisierung und Wiederverwendbarkeit – das muss sich in der Organisation widerspiegeln.
Ausblick Teil 3:
Wir haben ein Verfahren kennengelernt, wie man iterativ Plattform-Komponenten baut und diese durch ständiges Feedback zu einer Plattform heranreifen lässt.
Platform Engineering ist ein Feld, in dem noch viel Innovation und Entwicklung stattfindet, daher schauen wir uns im vierten Teil an, wie die Zukunft des Platform Engineerings aussehen kann und welche Themen ggf. schon heute mitgedacht werden sollten.
