Woran Platform Engineering scheitert

srcset="https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?quality=50&strip;=all 5426w, https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?resize=300%2C168&quality;=50&strip;=all 300w, https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?resize=768%2C432&quality;=50&strip;=all 768w, https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?resize=1024%2C576&quality;=50&strip;=all 1024w, https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?resize=1536%2C864&quality;=50&strip;=all 1536w, https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?resize=2048%2C1152&quality;=50&strip;=all 2048w, https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?resize=1240%2C697&quality;=50&strip;=all 1240w, https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?resize=150%2C84&quality;=50&strip;=all 150w, https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?resize=854%2C480&quality;=50&strip;=all 854w, https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?resize=640%2C360&quality;=50&strip;=all 640w, https://b2b-contenthub.com/wp-content/uploads/2025/10/mykhailo-pavlenko-shutterstock_2392598059_16z9.jpg?resize=444%2C250&quality;=50&strip;=all 444w" width="1024" height="576" sizes="auto, (max-width: 1024px) 100vw, 1024px">Platform-Engineering-Projekte in Schieflage sind kein seltenes Phänomen.mykhailo pavlenko | shutterstock.com



Geht es nach einigen Experten, ist der Trend Platform Engineering gerade in die Phase der Ernüchterung eingetreten. Ganz allgemein gesprochen, hat eine Kombination aus hoher kognitiver Belastung, mangelndem Business Alignment und Schwierigkeiten bei der Einführung interner Developer-Plattformen (IDPs), einen der ehemals heißesten Tech-Trends erkalten lassen.



Beim Platform Engineering gibt es unzählige bewegliche Komponenten – ein Fehler in der Anfangsphase kann deshalb diverse, erfolgsgefährdende Konsequenzen nach sich ziehen. In diesem Artikel werfen wir gemeinsam mit einigen einschlägig erfahrenen Experten einen Blick darauf, welche Fallstricke Sie in Sachen Platform Engineering unbedingt vermeiden sollten.



1. Frontend zuerst aufbauen



Ein grundlegendes Missverständnis, wenn es um Platform Engineering geht: Die Plattform ist nicht die visuelle Schnittstelle – also nicht dasselbe wie das Entwickler-Portal. Entsprechend sollte eine Platform-Engineering-Initiative auch mit dem Backend beginnen – nicht mit dem Frontend. Luca Galante, Kern-Contributor der Community von PlatformEngineering.org, empfiehlt: “Konzentrieren Sie sich darauf, ein solides Backend mit APIs und Orchestrierung aufzubauen, bevor Sie eine Benutzeroberfläche hinzufügen.”



Natürlich sind Frontend-Benutzeroberflächen wie Backstage ebenfalls ein Kernelement des Platform Engineering – aber eben nicht das einzige. Developer bevorzugen möglicherweise auch, außerhalb des GUI-Portals zu interagieren – etwa über ein CLI oder eine API.



“Es ist wichtig, keine Logik in Ihr Portal einzubauen. Damit beschränken Sie sich auf eine einzige Möglichkeit, auf Ihre Plattform zuzugreifen und sind an einen einzelnen Nutzungsmodus gebunden. Jeder Benutzer, der sich mehr Flexibilität wünscht, dürfte dadurch frustriert werden”, konstatiert Viktor Farcic, Developer Advocate beim Infrastrukturanbieter Upbound.



2. Produkt-Mindset vermissen lassen



Sich ein Produkt-Mindset anzueignen, ist schon fast zu einem Platform-Engineering-Klischee geworden – das aber treffend ist. Wird die Plattform nicht als Produkt betrachtet, wird sie ziemlich sicher in minimalem Ausmaß genutzt werden. “Schließlich verkaufen sich selbst die besten Produkte nicht von selbst”, postuliert Erica Hughberg, Managerin beim KI-Anbieter Tetrate. Laut Hughberg sei es zum Scheitern verurteilt, von Software Engineers zu erwarten, die Plattformakzeptanz ohne klaren Marketingansatz voranzutreiben. “Der Aufbau einer Nutzerbasis erfordert mehr, als man vielleicht denkt. Man benötigt interne Fürsprecher, das richtige Storytelling und muss Erfolgsgeschichten von Early Adoptern teilen.”



Eine Produktmentalität zu etablieren, hilft außerdem auch dabei, die Plattform im Laufe der Zeit sukzessive zu verbessern, wie Galante festhält: “Starten Sie mit einer Minimal Viable Platform, die Sie auf der Grundlage von Feedback iterieren und anpassen. Dabei sollten Sie auch nicht vergessen, den Impact der Plattform zu erfassen, respektive zu messen.”



3. Diktatur errichten



Top-Down-Vorgaben für neue Technologien können Developer leicht abschrecken, insbesondere, wenn dabei bestehende Workflows verändert werden. Wenn Entwickler keine Möglichkeit bekommen, einen Beitrag zu leisten und zu iterieren, wird sich die Plattform von deren Bedürfnissen entfernen. Entsprechende Workarounds sind die Folge.



“Gestehen Sie Ihren Teams etwas Eigenverantwortung zu, statt ihnen Ihren Willen aufzudrängen”, empfiehlt Tom Barkan-Benkler, Director of Product Management bei Spotify. Wie der Manager preisgibt, wird das bei seinem Arbeitgeber täglich praktiziert: Die Developer des Streaming-Giganten dürften demnach selbständig agieren und etwa auch Plugins für ihr IDP erstellen. Daraus ist beispielsweise ein selbstentwickeltes Plugin entstanden, das bei Spotify inzwischen eingesetzt wird, um neuen Code im Rahmen eines Continuous-Development-Prozesses zu validieren. “Wenn die Engineers die Plattform selbst aufbauen und anpassen können, werden sie Teil des Prozesses – und nutzen auch die Plattform eher”, unterstreicht Barkan-Benkler.



Von einem Übermaß an Top-Down-Kontrolle raten auch andere Experten ab. Etwa Jay Jenkins, CTO für Cloud Computing beim Sicherheitsanbieter Akamai: “Eine starke Governance ist wichtig. Aber diese sollte befähigen, nicht einschränken.”



4. User nicht befragen



Ebenso kann ein mangelndes Verständnis der Nutzerschaft Ihrer Platform-Engineering-Initiative abträglich sein. Andreas Grabner, DevOps Actvist beim Softwareanbieter Dynatrace, erklärt: “Wenn Sie etwas entwickeln, ohne Ihre Zielgruppe zu kennen oder zu wissen, wie Sie diese unterstützen können, wird dieses Unterfangen nicht effizient ablaufen können. Plattform-Architekten sollten versuchen, die Endbenutzer und ihre Problemstellungen so genau wie möglich zu verstehen.”



Weil jedes Unternehmen anders ist und unterschiedliche Anforderungen an verschiedene Benutzergruppen stellt, ist das zugegebenermaßen diffizil. So unterscheide sich laut Grabner beispielsweise die User Experience, die ein Java-Entwickler erwartet, ganz grundsätzlich von der eines Qualitätssicherungsexperten oder der eines Site Reliability Engineers. “Das unterstreicht, wie wichtig es ist, Feedback für spezifische User-Gruppen einzuholen”, so der Experte.  



“Das Gefühl, gehört und verstanden zu werden, ist für die Benutzer äußerst wichtig”, fügt Zohar Einy, CEO des Lösungsanbieters Port, hinzu. Seiner Meinung nach sorge das auch dafür, dass die User gegenüber der Plattform aufgeschlossener sind. Um das zu bewerkstelligen, empfiehlt es sich, die Benutzer der Plattform genau zu analysieren und im Vorfeld Umfragen unter Entwicklern durchzuführen. So lassen sich die Bedürfnisse sämtlicher Stakeholder ermitteln und Plattformen schaffen, die sich optimal in bestehende Workflows einfügen und die Produktivität tatsächlich steigern. 



5. Falsche Kennzahlen heranziehen



“Alles, was Sie entwickeln, sollte messbar sein”, meint Dynatrace-Experte Grabner. Geht es um Platform-Engineering-Projekte ist darüber hinaus essenziell, dass Entscheidungen auch auf Grundlage der richtigen Metriken getroffen werden. DORA-Kennzahlen sind Grabner zufolge aus Platform-Engineering-Perspektive eher als nachlaufende Indikatoren einzuordnen. Er fügt hinzu: “Ebenso kann ein hoher Onboarding-Prozentsatz unter Entwicklern nur einen oberflächlichen Erfolgsindikator darstellen, der nicht notwendigerweise den tatsächlichen ROI für das Unternehmen widerspiegelt.”



Kaspar von Grünberg, Gründer und CEO des Platform-Engineering-Spezialisten Humanitec, weiß, worauf es ankommt: “Eine erfolgreiche Plattform sollte die Time-to-Market verkürzen, Kosten senken und Innovationen fördern. Die Ausgangsbasis dafür liefert eine korrekte ROI-Berechnung, die stattfinden sollte, bevor die Plattform aufgebaut wird.”



6. Fremde Ansätze kopieren



Die Platform-Engineering-Fallstudien von Unternehmen wie Spotify oder Expedia mögen auf dem Papier beeindrucken. Das heißt allerdings nicht, dass sich deren Strategien auf andere Organisationen und Unternehmen übertragen lassen. Ganz besonders nicht, wenn es um eher mittelgroße oder kleine Umgebungen geht. “Denken Sie an den Return on Investment und kopieren Sie nicht einfach das, was größere Akteure tun”, lautet der simple Ratschlag von Himanshu Mishra, Produktmanager beim Softwareanbieter Harness.



IDP-Referenzarchitekturen können zwar eine allgemeine Vorstellung davon vermitteln, was für erforderlich ist, um eine Plattform aufzubauen. Von der universellen Nutzwertigkeit dieser Referenzarchitekturen ist allerdings nicht jeder überzeugt. Beispielsweise Camille Fournier, VP of Engineeriung beim KI-Spezialisten CoreWeave: “Aus meiner Sicht können IDP-Referenzarchitekturen das diffizile Problem der Infrastrukturabstraktion nicht lösen. Die Herausforderung, dass jedes Team verstehen muss, wie es seinen gesamten Anwendungs-Stack skalieren und supporten kann, bleibt weiterhin bestehen.”



7. Overengineering by Design



Statt vom Start weg zu versuchen, Unmögliches zu erreichen, empfiehlt es sich laut Harness-Experte Mishra, zunächst grundlegende, konkrete Entwickler-Touchpoints und CI/CD zu optimieren – und dann schrittweise zusätzliche Komplexität einzuführen. Sein Tipp: “Optimieren Sie immer mit Blick auf die Entwicklerzeit, nicht die Plattform-Engineering-Zeit.”



Eine schrittweise Entwicklung sehen auch andere Experten als den Schlüssel für eine erfolgreiche Platform-Engineering-Initiative. Etwa Fournier: “Lösen Sie erst einmal die Probleme von heute und konzentrieren Sie erst dann auf die Zukunft, wenn Sie erfolgreich sind. Fokussieren Sie sich zunächst auf Shared Software bei der es an fokussierter Ownership mangelt.”



Akamai-Manager Jenkins ergänzt an dieser Stelle: “Wenn die Plattformentwicklung mehr Arbeit verursacht, als sie einspart, stimmt etwas nicht.” Dem Experten zufolge sollten Plattformen keine unnötigen Tools, starren Prozesse oder schwerfällige Templates einführen, die die Entwickler ausbremsen. “Die besten Plattformen sind nahezu unsichtbar”, konstatiert er.



8. Teams “rebranden”



Ein Platform-Engineering-Projekt, das erfolgreich sein will, bedarf mehr, als ein Operations-Team einfach nur mit einem schicken neuen Namen auszustatten. Dieses Phänomen konnte Paula Kennedy, Mitbegründerin und Chief Operating Officer beim Dev-Spezialisten Syntasso, schon mehrfach miterleben: “Betriebs- oder Infrastruktur-Teams werden einfach zu Platform-Engineering-Teams umfirmiert – ohne dass sich für das Unternehmen etwas geändert hätte oder daraus Vorteile entstanden wären.”



Wie unzählige andere Projektmisserfolge lassen sich auch Platform-Engineering-Fehlschläge allzu oft auf einen Mangel an klaren Anforderungen und schlechtes Management zurückführen. Laut CoreWeave-Managerin Fournier erfordert Platform Engineering allerdings einen umfassenden kulturellen Wandel, der keinesfalls unterschätzt werden sollte: “Unternehmen sollten Platform Engineering deswegen nicht als traditionelle Kostenstelle wahrnehmen, sondern als einen neuartigen Ansatz, um Software-Engineering-Probleme zu lösen.” (fm)









Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!