Willkommen zu einer weiteren Episode der Microsoft Knowledge Nuggets auf M365FM. Ich bin der Gastgeber Milko Peters. Das heutige Thema ist etwas, von dem fast jeder schon gehört hat, das aber nur wenige wirklich verstehen. Plattform Engineering. Sie haben wahrscheinlich von DevOps gehört, der Idee, dass Entwickler und Betriebsteams nahtlos zusammenarbeiten. Doch irgendwo auf dem Weg wurde dieses Versprechen kompliziert. Entwickler landeten bei der Arbeit für den Betrieb und das System scheitert. Am Ende dieser Folge werden Sie verstehen, was bei DevOps schiefgelaufen ist, was eine interne Entwicklerplattform eigentlich ist, wie Golden Paths Teams einen klaren Weg ebnen und warum die klügsten Ingenieur-Teams bereits eine solche aufbauen. Das Chaos ist DevOps hinterlassen. Gehen wir zurück zum Anfängen. DevOps war eine großartige Idee mit einem einfachen Ziel, die Mauern zwischen Entwicklung und Betrieb einzureißen.

Kein Code mehr, der einfach über den Zaun geworfen wird, in der Hoffnung, dass alles gut geht. Shift-Left, Testsicherheit und Betrieb früher in den Prozess integrieren. Schnellere Bereitstellung, weniger Übergaben, mehr Eigenverantwortung. Auf dem Papier sah es perfekt aus. In der Praxis lief etwas schief. Shift-Left hat Verantwortlichkeiten nicht nur verlagert, sondern sie angehäuft. Der Entwickler, der früher Code schrieb und ein Ticket eröffnete, ist nun für Infrastruktur, Sicherheit, Monitoring, Kubernetes, CICCD-Pipeline, Secret Management und etwa 15 Cloud-Dienste zuständig, von denen er noch nie zuvor gehört hat, hat eine Person erledigt das alles und bald gleichzeitig das eigentliche Produkt. So sieht das im wirklichen Leben aus. Ein Team möchte eine neue Umgebung hochfahren, um eine Funktion zu testen. Vor DevOps hätten sie ein Ticket eingereicht und gewartet. Nach DevOps sind sie selbst dafür verantwortlich, was theoretisch toll klingt.

Aber jetzt müssen sie Terraform-Module schreiben, ein Kubernetes-Cluster konfigurieren, Netzwerkregeln festlegen, das Monitoring einbinden, das Secret Management regeln und sicherstellen, dass Sicherheitsrichtlinien angewendet werden. Was früher ein Ticket war, das jemand anderes in einer Stunde erledigte, kostet einen Entwickler nun drei Tage Zeigezeit. Drei Tage, in denen sie kein Produktcode schreiben. Sie kämpfen mit YAML-Dateien und debuggen, warum der Load-Balancer den Datenverkehr nicht richtig weiterleitet. Die mentale Belastung dabei ist enorm. Jedes Team baut am Ende seine eigenen Pipelines, Bereitstellungsskripte und Monitoring-Dashbots. Und weil alle überlastet sind, wird an Ecken und Enden gespart. Die Sicherheit wird übergangen, weil die Deadline am Freitag ist. Cloud-Rechnungen verdoppeln sich, ohne dass es jemand merkt, weil niemand daran gedacht hat, die Testumgebung herunterzufahren.

Und wenn um zwei Uhr morgens etwas kaputt geht, ist der Entwickler, der es gebaut hat, der Einzige, der es reparieren kann. Das ist nicht nachhaltig. Und hier ist der Grund, warum es wichtiger denn je ist. Die Komplexität der Cloud wächst ständig weiter. Jedes Jahr gibt es mehr Dienste, mehr Tools und mehr Entscheidungen zu treffen. KI-Programmiertools ermöglichen Entwicklern jetzt, Code schneller als hier zuvor bereitzustellen. 10, 20 oder sogar 30 Mal mehr Code pro Tag. Doch all dieser Code benötigt weiterhin Infrastruktursicherheit und Monitoring. Mehr Code ohne besseres System bedeutet lediglich schnelleres Chaos. Wenn Sie das Gefühl haben, in YAML und Terraform zu ertrinken, sind Sie damit nicht allein. Das ist kein persönliches Versagen. Das ist systembedingt. Das Modell hat das eigentliche Wesen von Platform Engineering verzerrt. Was ist da die Lösung? Sie nennt sich Platform Engineering und so kann man es sich am einfachsten vorstellen.

Diese Disziplin schafft eine interne Ebene, die Komplexität von Entwicklern fernhält. Stellen Sie sich vor, Sie betreten ein großes Bürogebäude. Sie müssen sich keine Gedanken darüber machen, wer Zugang zu welcher Etage hat, welche Sicherheitskarte funktioniert oder wo die Notausgänge sind. Der Empfang erledigt all das für Sie und Sie können einfach hineingehen und mit der Arbeit beginnen. Genau das leistet Platform Engineering für Ihre Entwickler. Anstatt dass jeder einzelne Entwickler zum Experten für Kubernetes, Terraform, Netzwerke und Sicherheit werden muss, schafft ein zentrales Platform Team eine Ebene, die all diese Komplexität verwaltet. Der Entwickler erhält eine einfache Schnittstelle, ein Klick, ein Befehl, ein Formular und die Plattform kümmert sich um den Rest. Aber eines vorweg, das ist nicht dasselbe wie DevOps. DevOps forderte von jedem Team, seine eigene Infrastruktur zu verwalten, aber Platform Engineering sieht darin ein Rezept für Burnout.

Stattdessen bietet das Platform Team Paved Roads standardisierte, geprüfte und sichere Wege für gängige Aufgaben. Sie bauen und pflegen die Straße, während die Produktteams einfach darauf fahren. Das zentrale Ergebnis von Platform Engineering ist das sogenannte Internal Developer Platform, kurz IDP. Betrachten Sie es als Self-Service-System, das all diese repetitiven Aufgaben automatisiert. Infrastrukturbereitstellung, CICCD-Pipelines, Sicherheitsprüfungen und Monitoring sind fest integriert und standardisiert. Ein konkretes Beispiel. Wenn ein Entwickler ohne Plattform einen neuen Dienst bereitstellen möchte, verbringt er Tage damit, Infrastruktur aufzusetzen, Pipelines zu schreiben und Monitoring zu konfigurieren. Mit einer IDP klickt er einfach auf Deploy oder führt einen Befehl aus und die Plattform erledigt alles Bereitstellung. Tests, Monitoring, Deployment in Minuten statt in Tagen.

Ein. Was bedeutet das also für Sie? Sie hören auf, ein Allround-Infrastruktur-Experte zu sein und werden wieder zum Spezialisten für Ihr eigentliches Produkt. Ihre Arbeit konzentriert sich wieder auf Funktionen, die für Ihre Kunden wichtig sind. Statt darauf defekte Terraform-State-Files zu debuggen. Genau darum geht es. Die interne Entwicklerplattform ganz einfach erklärt. Schlüsseln wir also auf, was eine interne Entwicklerplattform eigentlich ist. Es ist die Maschine, die alles in einem System vereint. Ihre CIS-DD-Pipelines, Infrastrukturvorlagen, Sicherheitsrichtlinien, Monitoring und Logging. Anstatt sechs separate Tools, die Sie miteinander verbinden müssen. Ein Vergleich. Denken Sie an Kochen von Grund auf im Vergleich zu einem Verkaufsautomaten. Kochen von Grund auf bedeutet Zutaten kaufen, Gemüse schneiden, Gewürze abmessen, den Herd im Blick behalten, den Herd im Blick behalten.

Viele Entscheidungen, viele Schritte, viele Möglichkeiten, Fehler zu machen. Ein Verkaufsautomat liefert das Ergebnis auf Knopfdruck. Weniger Entscheidungen, schnelleres Ergebnis, gleichbleibende Qualität. Ein EDP ist dieser Verkaufsautomat. Der Entwickler muss nicht wissen, wie Infrastruktur bereitgestellt oder wo Geheimnisse gespeichert werden. Er drückt einfach nur den Knopf. Was steckt in diesem Verkaufsautomat? Die Kernkomponenten sind ziemlich standardisiert. CICD-Vorlagen für konsistente Builds, Infrastrukturprovisionierung für automatische Umgebungen, Secret Management, damit Anmeldedaten nicht in Konfigurationsdateien herumliegen und Logging mit integrierter Observability, damit sie ohne Stress Fehler beheben können. Alles vorkonfiguriert, getestet und gewartet vom Plattformteam. Hier ein konkretes Beispiel. Ein Entwickler gibt Create New Service in die Befehlszeile ein oder klickt auf eine Schaltfläche in ein Portal.

Im Hintergrund erstellt der IDP ein neues Repository mit der richtigen Struktur, richtet eine Build-Pipeline ein, die automatisch Tests ausführt, stellt den Dienst in einer Entwicklungsumgebung bereit und fügt HealthCheck Endpunkte mit Logging hinzu, mit Logging hinzu. All das geschieht innerhalb von Minuten. Der Entwickler hat keine einzige Terraform-Datei angefasst oder ein Kubernetes-Manifest konfiguriert. Einfach ein Befehl getippt und einen laufenden Dienst erhalten. Warum ist das wichtig? Konsistenz ist der Hauptgrund. Wenn jedes Team seine eigenen Pipelines baut und eigene Deployment-Skripte schreibt, erhalten sie Snowflake-Konfigurationen. 50 verschiedene Dienste, 50 verschiedene Vorgehensweisen. Wenn etwas kaputt geht, kann es niemand außer dem Ersteller debuggen. Und wenn diese Person das Unternehmen verlassen hat, viel Glück. Ein IDP beseitigt dies, indem jeder Dienst denselben Mustern folgt, jedes Deployment dieselbe Pipeline nutzt und jedes Team dieselben Standardeinstellungen erhält.

Wenn etwas kaputt geht, sind dem Muster vertraut und die Lösung dokumentiert. Was bedeutet das also für Sie? Wenn Ihre Organisation 50 Teams hat, die auf 50 verschiedene Arten deployen, ist ein IDP die Lösung. Das bedeutet nicht, dass Teams ihre Autonomie verlieren. Es bedeutet, dass die langweiligen, repetitiven und fehleranfälligen Teile standardisiert werden, damit die interessante, kreative Arbeit variieren kann. Das ist ein Lohn der Kompromiss. Golden Paths, der Weg, kein Käfig. Lassen Sie uns über Golden Paths sprechen. Sie haben den Namen wahrscheinlich schon gehört, aber die Idee ist einfach. Ein Golden Path ist ein empfohlener, vorbefertigter Workflow, der den richtigen Weg zum einfachsten Weg macht. Ihr Plattformteam sagt, so empfehlen wir euch das Vorgehen. Wir haben es getestet, es funktioniert und wir unterstützen euch, falls etwas schief geht. Achtet auf das Wort empfehlen.

Golden Paths sind nicht verpflichtend. Entwickler können vom Pfad abweichen, wenn nötig, aber der Pfad ist der schnelle, sichere Standard. Er läuft bereits, ist unterstützt und dokumentiert. Ihr müsst nicht alles von Grund auf neu herausfinden. Stellt es euch wie Bahngleise statt wie Leitplanken vor. Leitplanken fangen einen auf, wenn man vor Unglück. Sie reagieren, sie halten einen davon ab, abzustürzen, aber sie helfen nicht beim Steuer. Bahngleise führen einen sanft entlang der Route, sodass man nicht entscheiden muss, wo man abbiegt. Golden Paths sind die Gleise. Sie bringen einen voran, anstatt einen nur beim Scheitern aufzufangen. Hier machen viele Teams einen Fehler. Sie bauen Golden Paths für das Plattformteam, nicht für die Entwickler. Sie optimieren auf architektonische Reinheit, Compliance oder interne Regeln, die außerhalb des Plattformteams niemand versteht. Das Ergebnis sieht auf dem Whiteboard großartig aus, ist aber in der Anwendung schreck.

Entwickler suchen still, schweigen nach Umwegen. Die Akzeptanz sinkt und das Plattformteam wundert sich, warum niemand die Mühe zu schätzen weiß. Die Lösung ist einfach, aber schwer umzusetzen. Ihr braucht Notausgänge. Wenn der Pfad nicht zum Anwendungsfall eines Entwicklers passt, brauchen sie einen Ausweg. Eine Möglichkeit, einen Standard zu überschreiben, eine eigene Pipeline zu nutzen oder die Plattform ganz zu verlassen. Und hier kommt der wichtige Teil. Wenn sie vom Pfad abweichen, ist das kein Scheitern, sondern Feedback. Jedes Mal, wenn ein Entwickler den Golden Path verlässt, erfahrt ihr etwas Reales. Entweder fehlt dem Pfad eine Funktion, die er haben sollte, oder der Anwendungsfall gehört tatsächlich nicht dorthin. Beide Signale sind wertvoll. Ein guter Golden Path sieht in der Praxis so aus. Ein Team möchte einen neuen Backend-Dienst bereitstellen. Sie nutzen den Pfad. Er bietet ihnen ein Repository-Template mit der richtigen Struktur, eine bereits getestetes CICT-Pipeline, integriertes Logging und Monitoring sowie ein Ein-Klick-Rollback.

Das Ganze dauert Minuten statt Tage und da das Plattform-Team dem Pfad wartet, beheben sie Fehler selbst. Selbst. Der Entwickler muss kein Experte für Pipeline-Debugging werden. Was das für euch bedeutet, weniger Überraschungen. Ihr liefert schneller, weil der Pfad getestet ist. Ihr liefert sicherer, weil Sicherheit und Monitoring eingebaut sind. Ihr liefert mit Zuversicht, weil Rollbacks nur einen Klick entfernt sind. Der Pfad existiert, um euch zu helfen, nicht um euch aufzuhalten. Nutzt ihn. Die kognitive Belastung reduziert. Hier zeigt sich der eigentliche Nutzen. Wenn eine Plattform die Schwerstarbeit übernimmt, können sich Entwickler endlich auf den Code konzentrieren. Sie müssen nicht wissen, welche Kubernetes-Version gerade läuft. Sie müssen keine Terraform-Module aktualisieren, nur weil ein Cloud-Anbieter die API ändert. Ich schreibe einfach Funktion. Plattform-Ingenieurs fangen diese Komplexität an.

Sie entscheiden, was Entwickler sehen müssen und was besser verborgen bleibt. Das ist eine echte Designentscheidung, nicht nur eine technische. Es geht darum, herauszufinden, welche Details für den Nutzer der Plattform wichtig sind und welche nur stören. Hier ein konkretes Beispiel. Ein Entwickler, der einen neuen Service bereitstellt, interessiert sich nicht für Cluster-Notgrößen, Instanztypen oder Autoscaling-Schwellenwerte. Sie interessieren sich dafür, ob ihr Service läuft und wie schnell er reagiert. Daher konfiguriert die Plattform dies alles basieren auf der Anwendungsebene. Kleiner Service, hier ist das passende Setup. Service mit Home-Traffic, hier ist eine andere Konfiguration. Der Entwickler trifft diese Entscheidung nicht, weil er es nicht muss. Warum ist das wichtig? Weil das Burnout-Risiko sinkt, wenn Entwickler nicht 15 verschiedene Baustellen gleichzeitig jonglieren müssen.

Einige ausgereifte Plattform-Teams konnten die kognitive Belastung fast halbieren. 40 bis 50 Prozent weniger mentaler Overhead. Das ist eine enorme Veränderung. Es ist der Unterschied zwischen Feierabend mit noch vorhandener Energie und dem Starren auf ein Terminal um 22 Uhr, während man sich fragt, warum die Pipeline fehlgeschlagen ist. Aber hier ist eine Warnung. Schafft keine Illusionen. Manche Plattform-Teams tappen in eine Falle. Sie verstecken Einstellungen, ohne den Entwicklern eine Möglichkeit zu geben, die Vorgänge im Hintergrund zu verstehen. Das ist keine Abstraktion, das ist Täuschung. Und es rächt sich, sobald etwas schief geht. Entwickler stoßen gegen eine Mauer, durch die sie nicht blicken können und plötzlich wirkt die Plattform wie eine Blackbox, die gegen sie arbeitet. Der Fachbegriff dafür ist eine undichte Abstraktion. Man verbirgt Komplexität, aber irgendwann sickert diese Komplexität durch.

Eine Datenbank wird langsam, ein Deployment schlägt fehl, eine Sicherheitsrichtlinie blockiert etwas Unerwartetes. Und der Entwickler hat kein mentales Modell der Vorgänge, weil die Plattform ihm keines vermittelt hat? Transparenz ist wichtig. Zeigt den Entwicklern, was sie wissen müssen, genau dann, wenn sie es wissen. Versteckt nicht einfach alles in der Hoffnung, dass schon alles gut gehen. Was das für euch bedeutet, weniger Kontextwechsel und mehr Flow. Man beginnt den Morgen nicht mit der Sorge, ob der Kubernetes-Cluster ein Upgrade braucht, sondern arbeitet direkt an der Funktion, die nächste Woche fertig sein muss. Der Job wird wieder zur eigentlichen Arbeit. Die Plattform, die ein Produkt behandeln. Heute sprechen wir über etwas, das die Funktionsweise interner Tools grundlegend verändert. Die meisten Leute halten ein Plattform-Team nur für ein Infrastruktur-Team. Das ist nicht. Ein Plattform-Team ist ein Produkt-Team.

Und die Entwickler, die die Plattform nutzen, sind ihre Kunden, nicht Leute, die Tickets einreichen. Das ändert alles. Ein Produkt-Team spricht mit seinen Kunden, findet heraus, wo der Schuh wirklich drückt, priorisiert Funktionen nur nach tatsächlichen Bedarf, misst die Nutzung und baut nicht einfach etwas, um es dann zu vergessen, sie iterieren kontinuierlich. Wie sieht also ein Produkt-Team in der Praxis aus? Sie arbeiten nicht wie ein Helpdesk. Ein Entwickler reicht ein Ticket ein und das Plattform-Team erledigt es manuell. Das ist kein Plattform-Engineering, das ist nur zentralisierter Betrieb mit neuem Namen. Es ist nicht skalierbar, es reduziert nicht die kognitive Belastung, es verschiebt den Engpass nur von einem Team zum anderen. Ihr ist, was Sie stattdessen tun. Sie messen die richtigen Dinge. Zeit bis zum ersten Deployment. Onboarding-Geschwindigkeit für neue Teammitglieder. Zufriedenheitswerte der Entwickler.

Das sind die Kennzahlen, die zeigen, ob die Plattform den Leuten wirklich hilft oder nur eine weitere Komplexitätsebene hinzufügt. Spotify ist ein gutes Beispiel. Ihr Plattform-Team arbeitet wie eine echte Produktorganisation. Sie haben Roadmaps, Sie haben OKRs, Sie sprechen mit Entwicklern darüber, was funktioniert und was nicht und was nicht. Sie betrachten die Plattform als etwas, dass sich seine Akzeptanz jeden Tag aufs Neue verdienen muss und genau das ist der Kernpunkt. Eine Plattform, die niemand nutzt, ist nur ein Projekt, das in der Ecke verstaubt. Akzeptanz ist die ultimative Bestätigung. Wenn Entwickler ihre Plattformen den eigenen Werkzeugen vorziehen, haben sie es geschafft. Wenn Sie sie meiden, kann auch technische Exzellenz daran nichts ändern. Was bedeutet das für Sie? Es bedeutet, wenn Sie eine Plattform aufbauen, beginnen Sie nicht mit Architekturdiagrammen, nicht mit Kubernetes-Clustern oder Terraform-Modulen, sondern mit Nutzerinterviews.

Sondern mit Nutzerinterviews. Sprechen Sie mit den Entwicklern, die Ihre Plattform nutzen werden. Finden Sie heraus, wo es wirklich schmerzt. Bauen Sie eine Sache, die ein echtes Problem löst und iterieren Sie dann. So baut man etwas, das die Leute auch wirklich nutzen wollen. Warum gerade jetzt? Die KI-Welle. Warum sprechen wir also genau jetzt darüber? Warum nicht schon vor fünf Jahren? Die Antwort ist KI. KI-Programmiertools wie GitHub-Copilot ermöglichen es, Entwicklern Code in einem Tempo zu liefern, das wir noch nie zuvor gesehen haben. Zehn oder zwanzigmal mehr Code pro Tag, als vor ein paar Jahren noch möglich war. Das klingt fantastisch. Und das ist es auch. Aber hier ist der Haken. All dieser Code benötigt immer noch eine Infrastruktur. Er benötigt immer noch Sicherheit. Er muss immer noch bereitgestellt, getestet und betrieben werden. Mehr Code ohne ein besseres System macht sie nicht schneller.

Es sorgt nur dafür, dass das Chaos schneller entsteht. Wenn Ihre Entwickler bereits in YAML und Terraform ertrinken, löst KI das nicht. Es bedeutet nur, dass Sie schneller ertrinken, während Sie mehr Code produzieren, der unterstützt werden muss. Aktuell haben bereits etwa 55 Prozent aller Unternehmen Plattform-Engineering in irgendeiner Form eingeführt. Gartner prognostiziert, dass diese Zahl bis Ende 2026 auf 80 Prozent steigt. Das ist kein langsamer Trend. Das ist ein Wandel, der genau jetzt stattfindet. Unternehmen erkennen, dass sie ihre Engineering-Teams ohne eine Plattform-Ebene nicht skalieren können. Der alte Ansatz, bei dem jedes Team alles selbst macht, funktioniert einfach nicht, wenn man Code in KI-Geschwindigkeit ausliefert. Hier ist etwas, was viel übersehen. KI schafft nicht nur den Bedarf an Plattformen. Sie hilft auch dabei, sie aufzubauen. Plattform-Teams nutzen KI, um Terraform-Module zu generieren, Dokumentation zu schreiben und Pipelines zu debuggen.

Dieselbe Technologie, die den Handlungsdruck erzeugt, liefert auch die Werkzeuge, um ihn zu lösen. Doch ein Wort der Vorsicht. KI verstärkt das, was bereits vorhanden ist. Wenn die Grundlagen solide sind, etwa durch eine gute Architektur und eine durchdachte Plattform, macht KI sie zwei- bis dreimal produktiver. Sind die Fundamente jedoch schwach, hilft Ihnen die KI nur dabei, größere Fehler schneller zu machen. Fehlkonfigurationen, Sicherheitslücken, defekte Infrastruktur, alles landet in der Produktion, bevor es jemand bemerkt. KI behebt keine schlechten Fundamente. Sie legt sie offen. Ein echtes Beispiel. Ein Unternehmen mit einer guten internen Entwickler-Plattform kann nicht Technikern erlauben, KI-Tools sicher bereitzustellen. Die Plattform bietet Leitklang. Sie setzt Sicherheitsrichtlinien durch. Sie kümmert sich um die Infrastruktur. So kann ein Produktmanager einen KI-gestützten Prototypen starten, ohne Kubernetes- oder Cloud-Netzwerke verstehen zu müssen.

Das ist beeindruckend. Das ist genau das, was Teams, die für das KI-Zeitalter bereit sind, von den Teams unterscheidet, die den Anschluss verlieren werden. Was bedeutet das für Sie? Das Zeitfenster für den Aufbau einer Plattform schließen. Nicht, weil die Technologie verschwindet, sondern weil die Lücke zwischen Teams mit und ohne Plattformen schnell größer wird. Mit jedem Monat des Wartens ziehen die Teams mit Plattformen weiter davon. Sie liefern schneller aus, sind weniger ausgebrannt und passen sich schneller an neue Werkzeuge an. Die Teams ohne Plattformen fallen immer weiter zurück. Sie haben die Wahl. Beginnen Sie mit einem Golden Path. Wo fängt man also tatsächlich an? Wenn Sie glauben, eine komplette interne Entwicklerplattform von Grund auf neu bauen zu müssen, hören Sie auf. Das ist der schnellste Weg, Ihr Projekt zu zerstören, noch bevor es beginnt. Der größte Fehler von Teams ist der Versuch, alles auf einmal zu bauen.

Sie verbringen Monate damit, die perfekte Plattform zu entwerfen und mit jedem erdenklichen Feature vollzustoffen. Dann veröffentlichen Sie diese und hören nichts. Niemand benutzt sie. Warum? Weil Sie Probleme löst, nach denen niemand gefragt hat und schon der Einstieg ein ganzes Handbuch erfordert. Kurz gesagt, tun Sie das nicht. Waren Sie sich stattdessen klein an. Sprechen Sie tatsächlich mit Entwicklern, nicht mit Architekten, nicht mit Managern, nicht mit Ihren eigenen Annahmen. Finden Sie die Leute, die täglich Features schreiben. Fragen Sie sie, wo es weh tut. Finden Sie den einen Arbeitsablauf, der am längsten dauert, die meisten Leute frustriert oder öfter übersprungen wird, als er sollte. Bauen Sie dann genau einen goldenen Pfad durch den gesamten Prozess. Vielleicht ist es das Erstellen und Bereitstellen eines neuen Microservices. Vielleicht ist es das Einrichten einer Entwicklungsumgebung von Grund auf.

Vielleicht ist es das Ausliefern eines Hotfixes in die Produktion, ohne etwas zu beschädigen. Wählen Sie das, was am meisten schmerzt und bauen Sie einen Pfad, der diesen Schmerz beseitigt. Bauen Sie es, testen Sie es mit echten Nutzern, sammeln Sie Feedback, iterieren Sie. Fügen Sie dann einen weiteren Pfad hinzu und danach noch einen. Versuchen Sie nicht, jedes Problem auf einmal zu lösen. Lösen Sie ein Problem wirklich gut und lassen Sie sich vom Schwung vorwärts tragen. Woher wissen Sie, dass es funktioniert? Messen Sie die richtigen Dinge. Zeit von der Idee bis zum ersten Deployment. Anzahl der eliminierten manuellen Schritte und freiwillige Adoptionsraten. Wenn Entwickler Ihren Pfad dem eigenen Bauen vorziehen, gewinnen Sie. Wenn Sie ihn meiden, hören Sie zu und ändern Sie die Richtung, wie es die vermeiden soll. Machen Sie die Plattform nicht verpflichtend. Zwingen Sie Entwickler auf Ihren Pfad und Sie werden sich dagegen wehren.

Sie werden Wege finden, ihn zu umgehen. Sie werden Ihre eigenen Skripte bauen, unter die Sie vor Ihnen verstecken. Machen Sie den Pfad stattdessen einfach. Machen Sie ihn schneller als die Alternative. Machen Sie ihn zur offensichtlichen Wahl, aber niemals zur einzigen. Der erste Pfad ist immer der schwerste. Er lehrt Sie alles über Produktdenkweise. Sie lernen, wie man mit Nutzern spricht, wie man priorisiert. Und dass etwas zu bauen, das Leute wirklich wollen, viel schwerer ist, als etwas zu bauen, das nur funktioniert. Aber sobald Sie es einmal geschafft haben, wird der zweite Pfad einfacher und der dritte noch einfacher. Sie bauen eine Plattform nicht auf einen Schlag. Sie bauen sie Pfad für Pfad auf. Das ist also das System. Plattform Engineering bedeutet, die befestigte Straße zu bauen, damit Entwickler sich aufs Fahren konzentrieren können, statt Schlaglöcher zu flicken. Wenn Sie es leid sind, gegen die Infrastruktur zu kämpfen, fangen Sie damit an, einen goldenen Pfad in Ihrem Team zu finden nur ein.

Teilen Sie dies mit jemandem, der es hören muss und abonnieren Sie für weitere Analysen wie diese.