Seite 2: Erster Versuch eines Referenzmodells

Inhaltsverzeichnis

Ein einheitliches Referenzmodell für das Platform Engineering, auf das Unternehmen zurückgreifen können, existiert bisher nicht. Daher bleibt eine Beschreibung vorläufig abstrakt. Es besteht aber Konsens darüber, welche Teile die Plattform umfassen sollte. In der Regel muss sie in zwei grundlegende Workflow-Systeme integriert werden: Entwicklung (Dev) und Betrieb (Ops). Ersteres bildet die zu entwickelnden Funktionen und User Stories ab, Letzteres den operativen Workflow mit Serviceanfragen und -vorfällen. Als Beispiele für diese beiden Systeme lassen sich Atlassian Jira und die Cloud-Plattform von ServiceNow nennen.

Aus Entwicklersicht liefern beide Workflows Informationen für die auszuführenden Arbeiten und erfordern Aktualisierungen, sobald die jeweilige Arbeit abgeschlossen ist. Daher müssen beide integraler Bestandteil der Plattform sein, damit sich Aktualisierungen der Systeme auch vollständig automatisieren lassen.

Die beiden Workflow-Komponenten treffen in der Regel in der IDE auf dem Arbeitsrechner einer Entwicklerin oder eines Entwicklers zusammen. Im Idealfall erfolgen auch die meisten Interaktionen mit der Plattform direkt von dieser Workstation aus oder über ein dediziertes Entwickler-Portal. In jedem Fall sollten sie auf Self-Service-Basis und mit API-Support aufgebaut sein, um ein Tuning der Developer Experience durch Teams und Einzelpersonen zu ermöglichen

Die Schnittstelle zwischen der Developer Platform und den Entwicklungsteams ist von entscheidender Bedeutung, denn darüber müssen sowohl die Änderungen der angebotenen Funktionen konsumierbar als auch die Kommunikation bezüglich etwaiger Änderungen reibungslos möglich sein.

Neben den beschriebenen entwicklerseitigen Aspekten der Developer Platform sind auf der Infrastrukturseite vor allem die Bereiche Netzwerk, Speicher und Rechenleistung von Bedeutung. In einer reinen Cloud-Umgebung stehen der Developer Platform die Dienste der Public Cloud in der sogenannten Landingzone parat. Da viele Unternehmen in der Praxis aber auch eigene traditionelle Rechenzentren oder eine Private Cloud in die Plattformkonzeption einbeziehen müssen, ist es wichtig, von vorneherein eng mit den Eigentümern der jeweiligen Dienste zusammenzuarbeiten. Denn sowohl die Standards und verwendeten Vorlagen als auch die zulässigen Permutationen der Infrastrukturdienste können limitierende Faktoren für eine Developer Platform darstellen.

Eine weitere Komponente, die sich in der Softwareentwicklung einen festen Platz erobert hat, sind Container. Sie tragen zu beschleunigter Anwendungsentwicklung bei und stellen fortgeschrittene Funktionen für den Betrieb zur Verfügung – Container erfordern aber auch ein zusätzliches Management. Die Developer Platform sollte daher eine Schnittstelle anbieten, über die sich sowohl die bereitgestellten Dienste der Container-Plattform als auch konsistente Container-Templates nutzen lassen.

Eine dritte wichtige Dimension ist die Datenplattform, die den Zugriff auf die Daten des Unternehmens ermöglicht. In der Produktion dient sie als Datenbasis für alle Geschäftsprozesse des Unternehmens. Im Rahmen der Developer Platform stellt sie jene Daten bereit, die in Nicht-Produktionsumgebungen benötigt werden. Das schließt Funktionen wie Testdatenmanagement und Datenmaskierung ein, um Daten zu identifizieren und zu manipulieren, die für die verschiedenen Aspekte in der Softwareentwicklung und bei Tests erforderlich sind.

Darüber hinaus kann die Datenplattform auch Daten aufnehmen, die innerhalb der Developer Platform betriebsrelevant sind, wie Logs, Metriken und Traces oder die SDLC-Daten rund um den Software Development Life Cycle oder Testmetriken. Die SDLC-Daten werden in der Regel allerdings separat in einer als Software Engineering Intelligence Platform (SEIP) bezeichneten Plattform gespeichert und verwaltet (den Begriff hat das Marktforschungsunternehmen Gartner geprägt).

Zu guter Letzt muss die Developer Platform noch die für den Anwendungsbetrieb relevanten Komponenten wie Observability und Monitoring sowie andere geschäftsspezifische Funktionen berücksichtigen.

Im Zentrum aller Unternehmensfunktionen

Das Einrichten einer erfolgreichen Developer Platform setzt eine umfassende Planung der Architektur voraus und erfordert ein hohes Maß an Zusammenarbeit, da sie im Zentrum aller Unternehmensfunktionen steht. Das Kernelement für die Orchestrierung einer Developer Platform in der hier beschriebenen Referenzarchitektur bildet die Software Engineering Platform (siehe Abbildung 3). Ihre Aufgabe ist es, die zum Software Deployment erforderlichen SDLC-Funktionen zu orchestrieren und sie auf ökonomische Weise bereitzustellen. Da für nahezu jede der Funktionen gleich mehrere Tools sowie Anbieter existieren können, muss die Software Engineering Platform vor allem die damit verbundene Komplexität beherrschbar machen. Sie sollte mindestens die folgenden Fähigkeiten bereitstellen:

• Codegenerierung: Die Fähigkeit, Code zu generieren, um den Arbeitsaufwand der Entwicklungsteams zu verringern. Auch das Refactoring von Code zählt dazu. In jüngster Zeit eröffnen generative KI-Funktionen Unternehmen in diesem Bereich neue Optionen.
• Scannen der Codequalität: Überprüfung der Einhaltung von Programmierstandards.
• Sicherheitsscans: Statische Code-Analyse, Analyse der Softwarezusammensetzung, Scannen von Containern, dynamisches Testen der Anwendungssicherheit und mehr.
• Softwarekonfigurations- und -änderungsmanagement (SCM): Die Fähigkeiten, alles als Code zu speichern, sowie Branching und Merging fallen in den Bereich SCM.
• Funktionstests: Die Möglichkeit, Code automatisch auf funktionale Korrektheit zu testen.
• Continuous Integration / Build: Kompilieren des Codes und Erstellen einsatzfähiger Softwarepakete.
• Continuous Delivery / Deployment: Das technische Bereitstellen von Software und / oder Infrastrukturpaketen von Anwendungen.
• Release Management: Die Fähigkeit, Softwareversionen freizugeben. Manchmal ist ein vollständiges Bereitstellen der Anwendung erforderlich, manchmal nur das Aktivieren von Funktionen durch Feature-Flag-Mechanismen.
• Leistungstests / Performance Monitoring: Validierung der Anwendungsleistung, idealerweise aus Sicht des Kunden.
• Accessibility / Usability Testing: Sicherstellen, dass Anwenderinnen und Anwender die Funktionen der Software nutzen können.
• Betriebsbereitschaftstests / Chaos Engineering: Funktionen einer Anwendung sind nutzlos, wenn sie nicht zuverlässig arbeiten. Im Zuge des Software Life Cycle Managements ist daher zu prüfen, ob der Betriebsprozess und die Anwendung selbst zuverlässig und reif für den Einsatz in Produktion sind.
• Testdatenmanagement: Das Beschaffen geeigneter Testdaten sowie das Maskieren von Daten, die außerhalb der Produktion nicht sichtbar sein sollen, und das Erstellen von Datensätzen mit angemessener Größe (so wenig wie möglich, so viel wie nötig) sind Aspekte des Testdatenmanagements.
• Infrastrukturautomatisierung: Automatisches Aufbauen und Konfigurieren von Computer-, Netzwerk- und Speicherinfrastruktur für unterschiedliche Umgebungen (Development, Staging, Produktion etc.).
• Dashboarding / Insights: Das Erfassen technischer Daten, die es Unternehmen ermöglichen, Einblicke in Bereiche mit Verbesserungsbedarf zu gewinnen, sollten in einer Developer Platform ebenfalls nicht fehlen.

In der Praxis können diese Vorgaben gegebenenfalls zu Irritationen führen, denn es gibt unterschiedliche Möglichkeiten, diese Fähigkeiten zu gruppieren, und einige Unternehmen verwenden womöglich auch individuelle Begriffe für einige dieser Fähigkeiten. Das vorgestellte Gerüst einer Referenzarchitektur lässt sich in jedem Fall nutzen, um eine erste Developer Platform in Unternehmen zu definieren und diese bei Bedarf später zu ergänzen oder anzupassen. Das Referenzmodell macht zudem deutlich, wo und wie Platform Engineering ansetzt, um das Problem wachsender Komplexität auf strukturierte Weise zu zähmen.

Beispiele für das Umsetzen in der Praxis

Wie die Umsetzung in der Praxis gelingen kann, lässt sich anhand zweier Beispiele nachvollziehen. Im ersten Unternehmen trug das Platform-Engineering-Team die Verantwortung für das Einrichten aller SDLC-Tools, einschließlich Sicherheitsscans, Build, Bereitstellung und Infrastruktur. Das Unternehmen vertraute auf einen komplexen Technologie-Stack mit einer Mischung aus Software-as-a-Service (SaaS), paketierten und kundenspezifischen Anwendungen, die sowohl im eigenen Rechenzentrum als auch in der Public Cloud gehostet wurden. Das Platform-Engineering-Team arbeitete mit den Anwendungsteams zusammen, um die neue Developer Platform in die Arbeitsweise der Teams einzubetten, und wo Änderungen erforderlich waren, wurde ein Kompromiss gesucht und gefunden. Das Unternehmen durchlief in dieser Phase eine Umstellung auf vertikal integrierte Value Stream Teams, die eigenständig Verantwortung für unterschiedliche Geschäftsprozesse wie Infrastruktur oder Software-Support übernehmen. Die Developer Platform sollte dazu beitragen, diese Teams unabhängiger aufzustellen.

Der Zustand des SDLC-Prozesses ließ sich im Zuge der Implementierung der Developer Platform nachvollziehbar erfassen, sodass die Teams im gemeinsamen Dashboard ihre Entwicklungsfortschritte nachverfolgen konnten. Sie erlangten somit größere Unabhängigkeit innerhalb einer komplexen Organisation – eines der strategischen Ziele der Developer Platform war damit erfüllt. Das Unternehmen konnte ein Maß an Transparenz und Eigenverantwortung auf der Ebene des Wertstroms schaffen, das zuvor nicht möglich war. Auch wenn in der Praxis nur langsam Fortschritt erzielt wurde, hat das bewusste Einbeziehen der Anwendungsteams zur Stabilität und zum Erfolg der Developer Platform beigetragen.

Im zweiten Beispiel verfolgte ein Unternehmen das ehrgeizige Ziel, alle seine Anwendungen in die Cloud zu verlagern. Konkret ging es um einige Hundert Anwendungen, die aus einer Mischung individuell entwickelter sowie fertig paketierter Software bestanden. Das Unternehmen schuf eine integrierte Developer Platform, die auf gängigen Open-Source-Tools basierte. Darüber hinaus forcierte der technische Leiter den Einsatz Cloud-nativer Funktionen. Die gewählten Standards waren ausgelegt auf eine Migration in die Cloud inklusiver vollständiger Automatisierung der Infrastruktur und sämtlicher Anwendungen. Das ambitionierte Vorzeigeprojekt des Teams umfasste die vollständige End-to-End-Automatisierung für Infrastruktur, Anwendung und Tests.

Im weiteren Verlauf erwiesen sich die Standards dann offenbar doch als zu hoch angesetzt. Die Einstiegshürde lag so hoch, dass nur wenige Teams die neue Plattform tatsächlich nutzten. Teams, die zuvor ohne Probleme das Management ihrer Anwendungen meisterten, mussten nun plötzlich den Umgang mit dem IaC-Tool Terraform lernen, mit Helm-Diagrammen umgehen und die Ergebnisse von Sicherheitsscans interpretieren. Die hohe Lernkurve und die kognitive Belastung erwiesen sich als echtes Hindernis.

Zwar hatten sich alle Teams der gemeinsamen Vision verschrieben, doch für die erfolgreiche Umsetzung der Pläne fehlte es an ausreichender Unterstützung für ihre sorgfältige Einarbeitung. Der Fall zeigt, dass eine solide technologische Grundlage allein nicht ausreicht, wenn der Kundenfokus fehlt. Die Bedürfnisse der internen Teams wurden nicht in ausreichendem Maße erfüllt, um das Produkt – die Developer Platform – erfolgreich zu machen. Das Unternehmen hat die Plattform schließlich aufgegeben, da es ihr an Akzeptanz und Nutzung durch die Teams fehlte.

Die beiden Fallstudien machen deutlich, dass die Schaffung einer Developer Platform kein Implementierungsprojekt im herkömmlichen Sinne ist. Es handelt sich vielmehr um eine Übung zum Aufbau von Fähigkeiten, die in angemessenen Schritten erfolgen muss und sich an den Prinzipien der Produktentwicklung orientieren sollte. Ein entscheidender Aspekt dabei ist, die Developer Plattform den Entwicklungsteams "richtig zu verkaufen". Dazu braucht es ein überzeugendes Branding und ein in der gesamten Organisation etabliertes Produktänderungsmanagement. Unternehmen, denen all das gelingt, haben zumindest bessere Chancen, eine Developer Platform erfolgreich umzusetzen und so die zunehmende Komplexität zu meistern.

Platform Engineering hat nicht alle Probleme gelöst

Akzeptanz ist ein ausschlaggebendes Kriterium für den Erfolg neuer Ansätze im Unternehmen – das gilt auch für eine Developer Platform. Hat die Einführung eines einheitlichen, von einer starken zentralen Hand gelenkten Tooling-Ansatzes nicht funktioniert, warum sollte es dann bei der Plattformentwicklung anders sein? Es haben sich allerdings bereits eine Reihe bewährter Verfahren herauskristallisiert, die zu einer höheren Akzeptanz für das Platform Engineering beitragen. Der erste Schritt besteht darin, die Platform Engineers und andere Beteiligte im Unternehmen wie Kunden zu behandeln, und dabei bewährten Praktiken aus dem Produktmanagement zu folgen. Die Developer Platform hat immensen Einfluss darauf, wie und was die IT-Abteilung im Unternehmen entwickelt. Daher ist es sinnvoll, sie auch als eines der wichtigsten Geschäftsprodukte zu betrachten.

Unternehmen sollten daher zunächst sorgfältig untersuchen, welche Funktionen für die internen Kunden erforderlich sind. Das Spannungsverhältnis besteht darin, den Platform Engineers bei der Lösung ihrer Probleme zu helfen und gleichzeitig die erforderlichen Sicherheitsstandards zu erreichen. Das Gleichgewicht zwischen Standardisierung und Flexibilität zu erhalten, ist eine ständige Aufgabe für das Entwicklungsteam der Plattform. Stärkere Standardisierung reduziert die Kosten und die Komplexität der Plattform. Gleichzeitig steigt aber die Gefahr, dass Platform Engineers sich nicht ausreichend unterstützt fühlen. Mehr Flexibilität schafft ein besseres Kundenerlebnis, erhöht aber die Kosten für den Aufbau und die Wartung der Plattform.

Da es keine optimale Lösung für dieses Problem gibt, ist ein Ansatz nach dem Motto "einatmen, ausatmen" ratsam. Diese Methode lässt ein begrenztes Maß an Experimenten auf der gesamten Plattform zu, erfordert aber, in regelmäßigen Abständen alle nicht standardisierten Komponenten infrage zu stellen und neu zu bewerten. Dadurch ergeben sich Phasen, in denen die Plattform wächst ("einatmen"), gefolgt von Phasen, in denen sie schrumpft ("ausatmen"), wenn Ausnahmen für Komponenten, die sich nicht bewährt haben, wieder entfallen. Die Rigorosität dieses Prozesses ist ein entscheidender Faktor, der letztlich die Kosten der Developer Platform und deren Wartbarkeit mitbestimmt.

Eine weitere Lektion aus dem Produktmanagement ist das Branding. Die interne Developer Platform erfordert ein gewisses Maß an "Verkaufsunterstützung", um positiv wahrgenommen zu werden. Erfolgreiche Plattformteams verfolgen einen echten Marketingansatz, indem sie der Plattform einen einprägsamen Namen geben und Sensibilisierungs- und Kundenbindungskampagnen auf den Weg bringen. Dabei kann es sich um interne Podcasts, Blogposts oder vergleichbare Medien handeln, die sich an die Stakeholder der Plattform richten. Wichtig für die Markenbildung ist zudem das Feedback der Nutzerinnen und Nutzer an das Entwicklungsteam der Plattform (siehe Abbildung 4). Dazu sollte die anstehende Roadmap transparent sein, und idealerweise sollten auch Funktionswünsche von allen Plattformnutzenden gesammelt werden. Die sorgfältige Auswahl der Funktionen in Verbindung mit den erforderlichen Verbesserungen aus Sicht der Plattform und /oder der Sicherheit sowie weiterer Stakeholder trägt zur Legitimität der Plattform innerhalb des Unternehmens bei.

Die zweite nennenswerte Herausforderung ist die Komplexität der Plattform. Leider folgen die in einer IT-Organisation verwendeten Tools nicht alle einem Standard für Daten und Integration. Das ist angesichts der Fragmentierung des IT-Tooling-Marktes, auf dem ständig neue Produkte und Anbieter auftauchen, nicht überraschend (siehe Abbildung 5). Die Komplexität der Integration aller erforderlichen Werkzeuge in die Plattform wächst dadurch auf ein Maß, das mit den Integrationsbemühungen für Geschäftsanwendungen vergleichbar ist.

Bevor es an die Integration aller IT-Tools in die Developer Platform geht, sollte das geeignete Prozess- und Datenmodell feststehen. Die notwendigen Arbeitsabläufe in den verschiedenen Tools lassen sich nur dann sinnvoll planen, wenn definiert ist, wie die Prozesse aussehen und welche Daten zu verwenden und zu erfassen sind. Das Aufrechterhalten eines konsistenten Daten- und Prozessmodells ist vor allem bei einer wachsenden Plattform wichtig – es zieht aber auch zusätzlichen Erstellungs- und Wartungsaufwand nach sich. Darüber hinaus ist zu beachten, dass einige kommerzielle Werkzeuge Datenmodelle und Prozesse vordefinieren, die mit den eigenen Prozessen und dem eigenen Datenmodell in Einklang zu bringen sind. Die Fähigkeit zur Integration und Anpassung des Datenmodells ist daher ein wichtiger Aspekt bei Architekturentscheidungen hinsichtlich der Plattform.

Ein unternehmensweit einheitliches Prozess- und Datenmodell für IT-Prozesse bietet darüber hinaus weitere Vorteile: So lassen sich beispielsweise auch die Bereitstellungszyklen von SAP- und Java-Anwendungen vergleichen, selbst wenn diese unterschiedliche Tools verwenden – solange beide demselben übergeordneten Prozess- und Datenmodell folgen. In einem solchen Szenario lässt sich zudem ein zentrales Engineering-Dashboard einrichten, das allen agilen Entwicklungsteams zur Verfügung steht. Damit entsteht eine gemeinsame Sprache, die die Zusammenarbeit zwischen den verschiedenen Technologie-"Stämmen" im Unternehmen erleichtert.

Um die Komplexität der Tool-Landschaft überschaubar zu halten, haben sich Unternehmen in der Vergangenheit häufig auf einen einzigen Tool-Anbieter festgelegt. Doch obwohl viele der Anbieter ihre Werkzeuge kontinuierlich um neue Funktionen erweitern, bleibt es eher die Ausnahme, dass ein Anbieter alleine für alle Anforderungen im Unternehmen die passenden Tools bereithält. Das Erstellen eines eigenen Prozess- und Datenmodells erscheint daher vernünftig, bis sich ein Industriestandard herauskristallisiert. Platform Engineering hat das Potenzial dazu, als Katalysator auf dem Weg zu einem Industriestandard zu wirken.

Die letzte Herausforderung, die es zu meistern gilt, ist das Problem der Kosten. Wer zahlt für die Developer Platform und wie? Natürlich gibt es immer die Möglichkeit, ein separates Budget dafür bereitzustellen, und es ist der naheliegendste Schritt, die Arbeiten als Kostenkomponente über das Gesamt-IT-Budget zu finanzieren. Das bedeutet aber, neue Kosten einzuführen – was die Bereitstellung ausreichender Mittel häufig erschweren kann. Zieht man hingegen in Betracht, wer am meisten von der Developer Platform profitiert, ist es sinnvoll, zumindest einen Teil des Budgets aus den Bereichen Technik, Infrastruktur und Sicherheit zu verwenden.

Aus eigener Erfahrung in der Praxis kann der Autor dieses Artikels bestätigen, dass diese Vorgehensweise gut funktioniert, wenn die Plattform als wichtiger Faktor für aktive Veränderungen im Unternehmen betrachtet wird. Dann ist es auch sinnvoll, die Plattformkosten als Kapitalkosten und nicht als Betriebskosten zu sehen. Um die laufende Weiterentwicklung der Plattform zu finanzieren, könnte für jedes Projekt und jede neue Funktion eine Gebühr in Rechnung gestellt werden. Das ist mit der Situation vergleichbar, wenn ein Techniker im agilen Team sitzt und die internen DevOps-Tools des Teams wartet, seine Kompensation aber auf das Projekt gebucht wird. Im Fall der Developer Platform wandert jedoch ein Teil der Mittel in einen zentralen Pool zur Finanzierung der unternehmensweiten Plattform.

Das Modell hat jedoch Vor- und Nachteile. Einerseits kann die Plattform bei einer veränderungsbasierten Finanzierung dynamisch auf eine Zu- oder Abnahme der IT-Aktivitäten insgesamt reagieren, da der Mittelzufluss entsprechend ansteigt oder fällt. Andererseits kann die Abhängigkeit vom Umfang der IT-Aktivitäten dazu führen, dass insbesondere die anfänglichen Investitionen in die Plattform zu langsam fließen, um den kontinuierlichen Ausbau zu gewährleisten. Sollten die IT-Aktivitäten insgesamt sogar stark zurückgehen, droht die Gefahr, dass nicht ausreichend Mittel fließen, um den Fortbestand der Plattform zu sichern.

Unverzichtbar für das Plattformentwicklungsteam ist es daher, die positiven Effekte der Plattform zu messen. Dabei kommen alle drei bisher behandelten Aspekte zusammen: Erfolgreiches Messen gelingt nur auf Basis eines einheitlichen Datenmodells, die Messwerte lassen sich heranziehen, um Investitionen in die Plattform zu rechtfertigen, und sie können darüber hinaus helfen, das Produkt "Developer Platform" innerhalb des Unternehmens effektiver zu verkaufen.

Als naheliegende Metrik für den Nutzen der Plattform bieten sich die Arbeits- beziehungsweise Kosteneinsparungen durch die Automatisierung an. So lässt sich etwa ermitteln, wie viele Arbeitsstunden im Zuge der Einführung der Plattform weggefallen sind. Darüber hinaus ist es sinnvoll, das durch Standardtechnologievorlagen verringerte Risiko und die verbesserte Sicherheitslage zu messen. Schließlich bedeutet jedes Sicherheitsrisiko ein Geschäftsrisiko, das sich bewerten lässt. Um dafür konkrete Werte zu formulieren, ist eine enge Abstimmung mit den Risiko- und Sicherheitsbeauftragten notwendig. Der dritte Bereich, der in die Messungen einfließen sollte, ist die Auswirkung auf den Endkunden. Die Effekte der Plattform können sich an dieser Stelle unter anderem in Form einer schnelleren Lieferung, erhöhter Zuverlässigkeit in der Produktion oder generell in den Geschäftskennzahlen widerspiegeln.