Die Evolution der Softwareentwicklung ist eng begleitet von Abstraktionsschichten. Betriebssysteme, Compiler, Virtuelle Maschinen, Bibliotheken, Shared Services, Cloud-Services – ohne diese Schichten würden wir heute noch mühsam in Assemblersprache programmieren (meine, Gregors, IT-Karriere begann mit 6502-Assembler-Programmierung). Gleichzeitig steigen aber auch die Ansprüche an moderne Software: Verteilte Systeme, mithilfe von APIs und SaaS-Applikationen integriert, sind heute der Standard. Dazu kommen grafische Benutzeroberflächen, Multi-device-Schnittstellen, und das Ganze bitte portabel und von GenAI unterstützt. Software von solcher Komplexität und Flexibilität können wir nur entwickeln, weil wir ein mächtigeres Werkzeug zur Hand haben.
Es scheint aber, dass auf jeden erfolgreichen Ansatz, Komplexität zu verringern, neue Arbeitsweisen oder Architekturen folgen, die uns wieder an unsere intellektuellen Grenzen bringen. Monolithen wurden in Microservices gespalten, die jetzt noch einmal in einzelne Serverless-Funktionen aufgeteilt werden. Solche feingranularen Architekturen möchten hochautomatisiert sein und per Continuous Delivery hundertfach am Tag aufgefrischt werden. Solche Applikationen sind gut skalierbar, resilient und leicht erweiterbar, aber auch komplex.
"Mental Load" (oder auch "Cognitive Load", siehe Kasten 1) ist somit ein wichtiges Schlagwort geworden, denn Software wird (noch) von Menschen gebaut, und diese skalieren genau wie technische Komponenten nicht unbegrenzt.
| Mentale Belastung bezeichnet die Menge an geistigen Ressourcen, die gebunden werden, um eine bestimmte Aufgabe zu bewältigen. Komplexe Problemstellungen erfordern eine höhere mentale Belastung, aber auch die Vermischung mehrerer Aufgaben kann zu einer mentalen Überlastung führen, die meist mit einer schlechteren Leistung oder erhöhten Fehlern einhergeht. Umgangssprachlich werden „Cognitive Load“ und „Mental Load“ oft gleichgesetzt, aber die kognitive Last ist nur ein Teilaspekt der gesamten mentalen Last. |
Die intellektuelle Beanspruchung der Entwickler wird zusehends zum limitierenden Element der Softwareentwicklung, denn die Speicherkapazität eines Servers zu erweitern, ist letztendlich einfacher, als die kognitive Kapazität der Entwicklungsteams zu erhöhen. Die Belastung der Teams wird durch moderne Entwicklungsmethoden weiter erhöht. Der beliebte Shift-Left-Ansatz (siehe Kasten 2) zielt darauf ab, Reibungsverluste und Missverständnisse zwischen Teams zu mindern, macht dabei aber Entwicklungsteams für eine breite Themenspanne von Domänenmodellierung über Softwaredesign und -betrieb (DevOps) bis zu Sicherheitsaspekten verantwortlich.
|
Die Softwareentwicklung durchläuft naturgemäß mehrere Phasen, vom Design zum Programmieren, Testen, Deployment und Betrieb. Sind diese Phasen über mehrere Teams verteilt, gibt es Reibungen bei der Übergabe, wie das bekannte „über den Zaun werfen“ von ungetesteter Software in den Betrieb. Betrachtet man den Entwicklungsprozess linear von links nach rechts (siehe Abbildung 1), dann kann diese Reibung reduziert werden, wenn weiter rechts liegende Schritte (wie Tests, Deployment oder Laufzeitanalyse) nach vorne, also nach „links“, geschoben werden (vgl. [SLA]). Probleme werden so früher erkannt und können schneller adressiert werden, aber ein Team befasst sich nun mit mehr und auch komplexeren Aufgaben. |
Wenn die Teams dadurch an ihre mentalen Grenzen stoßen, teilen sie sich intern die Aufgaben auf, was wiederum die Grundidee crossfunktionaler Teams rückgängig macht.
Plattformen als selbst gebaute Wunderschicht?
Die Antwort auf die exzessive mentale Belastung liegt schnell parat: dem Fundamental Theorem of Software Engineering [FTSE] folgend, muss eine neue Schicht her, die die verbleibende Komplexität durch bessere Abstraktionen reduziert. Und wenig überraschend tummeln sich Hersteller und Open-Source-Initiativen mit eifrig entwickelten Abstraktionen und Frameworks. Die CNCF-Landkarte [Cnc24] ist mittlerweile selbst auf einem 32-Zoll-Bildschirm nur noch mit Anstrengung lesbar. Dennoch befassen sich zusehends viele Unternehmen mit dem Bau einer eigenen "Inhouse"-Plattform, oft unter dem Label Internal Developer Platform oder Platform Engineering. Warum sollte man ausgerechnet in einem fast schon gesättigten Markt eine eigene Abstraktionsschicht bauen wollen? Und wie unterscheidet sich eine solche Schicht von bisherigen Ansätzen?
Der Grundgedanke liegt nicht fern: Innerhalb des Unternehmens ist das Anforderungsprofil schmaler als für ein generisches Framework oder eine gesamte Cloud-Plattform. Dazu kommen etablierte Prozesse und gegebenenfalls branchenspezifische Regulatorik. Wenn man also diese Ansätze in eine neue Schicht gießen kann, dann können sich Entwickler auf die funktionale Logik konzentrieren und die betrieblichen und Compliance-Aspekte der Plattform überlassen. Dadurch sinkt die mentale Belastung, die Produktivität steigt und die Betriebssicherheit profitiert auch noch. So zumindest die Theorie.
Eine solche Plattform zu bauen, ist allerdings ein delikates Unterfangen. Denn die Anforderungen lesen sich höchst widersprüchlich: Die Plattform soll Entwicklungsarbeit beschleunigen und gleichzeitig robusten Betrieb sicherstellen; sie soll wie ein Framework den Entwicklern viele Arbeiten abnehmen, ohne jedoch die Lösungen, die auf ihr entwickelt werden, unnötig einzuschränken; sie soll die Innovation fördern, aber gleichzeitig harmonisieren. Und da die Welt nicht still steht, entwickelt sich diese Plattform gemäß den Erwartungen der Entwicklungsteams und des technischen Fortschrittes weiter.
Von Skalen- zu Geschwindigkeitseffekten
Selbstverständlich ist die Idee, gemeinsame Elemente in eine separate Schicht zu verpacken, nicht neu. Viele Unternehmen haben bereits ihre Infrastruktur in eine Cloud-Schicht ausgelagert oder ihren internen Betrieb in eine eigene Infrastrukturschicht. Wie Plattformen auch, zielen solche Schichten auf eine Standardisierung ab, allerdings aus einem anderen Blickwinkel. In der Vergangenheit sollte weniger Auswahl Skaleneffekte und Wiederverwendung bringen. Wenn alle Teams die Datenbank des gleichen Herstellers verwenden, ist es leichter, Rabatte zu verhandeln oder Entwickler von einem Team in ein anderes zu transferieren. Auch erspart die Nutzung gemeinsamer Komponenten Entwicklungskosten – je mehr Teams die gleichen Komponenten nutzen, desto größer die Ersparnis. Betriebswirtschaftlich spricht man hier von den sogenannten Skaleneffekten (Economies of Scale).
Moderne Plattformen fokussieren sich indes auf Economies of Speed, also auf Geschwindigkeitseffekte (vgl.: [Hoh22, Kap 2]). Denn indem sie die kognitive Last reduzieren und manuelle Prozesse automatisieren, machen sie Entwicklungsteams produktiver und beschleunigen die Wertlieferung an die Kunden. Wie Plattformen die Schwächen vergangener Ansätze vermeiden, ist in Kasten 3 beschrieben.
|
Beschleunigung durch Wiederverwendung, das haben wir sicher schon einmal gehört, denn dieser Wunsch ist genauso alt, wie unerfüllt [Fri15]. Theoretisch kann Wiederverwendung den Aufwand reduzieren und die Entwicklungsarbeit beschleunigen, denn die gleichen Probleme werden nicht erneut gelöst. Aber selbst beliebte Frameworks für Webanwendungen wie Ruby on Rails oder Django haben sich für die Entwicklung moderner Geschäftsanwendungen als unvollständig (z. B. bei Bedarf nach einer nativen Mobile-App) oder gar unpassend (z. B. wenn viele Teams die gleiche Anwendung entwickeln) herausgestellt. Können Plattformen das besser erledigen? Während klassische Ansätze wie Java EE versuchten, möglichst viele technische Details vor den Nutzenden zu verstecken (und dadurch Tradeoffs für und eventuell gegen die Bedürfnisse der Anwender getroffen haben), rücken bei modernen Plattformen die Kundenbedürfnisse ins Zentrum der Architekturentscheidungen. Stand damals die Technik im Vordergrund, ist es heute die Fachdomäne. Die Entwicklung der Plattform „Stack Exchange“, die aus der Stack-Overflow-Anwendung hervorging, bietet ein gutes Beispiel. Die Anwendungen basieren auf Gemeinsamkeiten wie Stellen von Fragen und Erstellen von Antworten. Doch es wurde eine Wiederverwendung von Code nur dann in Betracht gezogen, wenn drei Anwendungen das gleiche Bedürfnis gezeigt haben. Jeff Atwood, einer der Gründer von Stack Overflow, hat diese Strategie mit seiner „Rule of Three“ [Atw13] kodifiziert: „Um etwas wirklich Wiederverwendbares zu bauen, musst Du erst drei verschiedene Anwendergruppen davon überzeugen, es intensiv zu verwenden1 .“ |
Weniger Auswahl = mehr Innovation?
Lose von Henry Ford geleitet („Kunden können jede Farbe haben, solange es schwarz ist“2), nahm die klassische IT-Standardisierung bei der Suche nach Skaleneffekten Einschränkungen in Kauf: Entwickler können jede Laufzeitumgebung verwenden, solange es Applikationsserver Version 9.1.1.3 aus dem Standardkatalog ist. Innovation wurde damit selten gefördert, denn die Standardisierung wurde vom Einkauf oder den Infrastrukturteams vorangetrieben, die auf Kostenersparnis abzielten.
Plattformen ändern hier maßgeblich die Spielregeln, indem sie das ewige Spannungsfeld zwischen Standardisierung und Innovation auflösen:
- "Plattformen fördern Innovation, obwohl (oder gerade weil) sie wichtige Elemente harmonisieren." [Hoh23]
Interessanterweise bietet wiederum die Automobilindustrie ein Paradebeispiel, wenn auch ein halbes Jahrhundert nach dem Ford Model T. In den 70er Jahren begannen Volkswagen und andere Hersteller, Fahrzeuge aus einer technischen Basisplattform und verschiedenen "Hüten" zu produzieren. Durch diesen Ansatz der Harmonisierung (die sich zu einer Modularisierung weiterentwickelte) konnte die Modellvielfalt maßgeblich erhöht und es konnten diverse Käufergruppen angesprochen werden. Die Basisplattform beschleunigte gleichzeitig die technische Innovation dank einer breiteren Anwendung über Modellreihen hinweg.
Denselben Effekt kennen wir auch aus der IT: Gemeinsame APIs zu standardisieren, erlaubt es uns, Applikationen aus Modulen mit unterschiedlichen Programmiersprachen oder Basistechnologien zu kombinieren. Das Extrembeispiel ist das Internet, welches durch die Standardisierung auf das HTTP-Protokoll der IT den wahrscheinlich größten Innovationsschub überhaupt gegeben hat. Cloud-Plattformen folgen dem gleichen Prinzip, denn auf einer gemeinsamen Technologieplattform lassen sich vielfältige Applikationen entwickeln. Auch eine Standardisierung auf Container oder OCI als Deployment-Format erlaubt Teams mehr Freiheit, Lösungen in Produktion zu bringen, die sich dennoch leicht integrieren und betreiben lassen. Wie frühere Ansätze auch, sucht eine Plattform nach gemeinsamen Elementen. Das können gemeinsame Laufzeitelemente wie eine relationale Datenbank, eine Container-Orchestrierung, eine uniforme CI/CD-Pipeline oder eine Bibliothek sein. Die Kernmotivation moderner Plattformen unterscheidet sich aber maßgeblich von bisherigen Ansätzen:
- Plattformen geben gezielt Vielfalt auf, um in anderen Bereichen mehr Vielfalt zu fördern.
Wie schaffen Plattformen diesen Spagat? Klassische Ansätze folgen meist der Vision einer Pyramide (siehe Abbildung 2), wo auf einer breiten, gemeinsamen Basis (Common Things) lediglich ein bisschen konfiguriert wird.
Abb. 2: Plattformen fördern diverse Applikationen auf einheitlichen Schnittstellen (Quelle: [Hoh23])
Low-Code-Systeme verfolgen einen ähnlichen Ansatz in sehr spezifischen Domänen. Was gut auf Papier aussieht, entlarvt sich in der Realität oft als Illusion. Denn ein solches Basisprojekt müsste die Bedürfnisse aller Nutzer vorhersehen. Das ist bereits extrem schwierig, fällt aber komplett auseinander, wenn die Projekte innovativ sein sollen, also selbst neue Anforderungen entdecken möchten, die Wert an Kunden liefern.
Plattformen verfolgen daher den Ansatz einer Doppelpyramide (rechts in Abbildung 2 dargestellt): Exzessive Komplexität wird hinter einer einheitlichen Schnittstelle verborgen, aber auf dieser Schnittstelle besteht große Freiheit, Lösungen zu entwickeln. Auch wenn Plattformen keine direkten Wunder vollbringen, verfolgen sie dennoch einen neuen Ansatz, um gemeinsame Schichten zu isolieren:
- "Plattformen versuchen nicht, alle Use Cases vorherzusehen." [Hoh23]
Der gleiche Effekt begleitet Cloud-Plattformen: Sie absorbieren die Komplexität des Infrastrukturmanagements, lassen den Applikationen aber sehr weiten Lauf. Diese Ideen sind in der IT nicht immer ganz so neu, wie sie aussehen, wir kennen diesen Ansatz vielmehr bereits von Betriebssystemen. Heutige Betriebssysteme sind hochgradig harmonisiert: Der Großteil unserer modernen Applikationen läuft auf einer kleinen Handvoll von Betriebssystemvarianten, die uns dennoch enorm produktiv und innovativ machen. Viele Applikationen, die heute auf einem Betriebssystem laufen, existierten nicht einmal, als das Betriebssystem als Plattform konzipiert wurde. Man denke nur an KI, Serverless, NoSQL-Datenbanken oder Crypto-Mining. Wir dürfen also Betriebssysteme im Nachhinein als extrem erfolgreiche Plattformen betrachten.
Da die Verlockung hoch ist, existierende Schichten einfach als Plattformen umzutaufen (mehr dazu im nächsten Abschnitt), hilft es Plattformteams, den folgenden Test anzuwenden:
- "Wenn Deine Nutzer nichts gebaut haben, was Dich überrascht, dann hast Du wahrscheinlich keine echte Plattform entwickelt." [Hoh23]
2 Original: "You can have it in any color as long as it‘s black."
Alles umbenannt, aber doch wenig erreicht
In vielen Organisationen werden Plattforminitiativen von Infrastrukturteams vorangetrieben. Denn auf den ersten Blick sind sie ja eine weitere Schicht „unter“ der Applikationsentwicklung. Solche Ansätze führen aber leider selten zum Erfolg, denn moderne Entwicklungsplattformen haben gänzlich andere Eigenschaften als der klassische Betrieb. Weil die klassische Infrastruktur von einer strikten Trennung zwischen Entwicklung und Betrieb ausgeht, basiert sie auf stabilen Anforderungen. Interne Plattformen hingegen sind integraler Teil des Entwicklungs- und Deployment-Prozesses und entwickeln sich kontinuierlich weiter, das heißt, sie werden als internes Produkt entwickelt, nicht als ein starres Projekt.
Plattformen setzen auf Selfservice, wohingegen der Betrieb auf einem Ticketsystem basiert, das oft Wartezeiten von mehreren Wochen in Kauf nimmt. Selfservice kann dabei viele Formen annehmen, zum Beispiel kann gute Dokumentation bereits als eine "Thinnest Viable Platform" betrachtet werden [Ske19].
Dass Applikationsteams sich auf Geschäftslogik fokussieren und die Infrastrukturteams Ressourcen für einen reibungslosen Ablauf bereitstellen, klingt zunächst nach einer logischen Arbeitsteilung. Leider entspricht sie aber nur noch selten den Anforderungen moderner Applikationen: Um dynamisch zu skalieren, können Applikationsteams kaum ein Ticket aufmachen und wochen- oder monatelang auf Hardware warten. Auch entstehen viele betriebliche Probleme wie Ausfälle oder schlechte Performance bereits bei der Entwicklung und können durch die Infrastruktur nur bedingt adressiert werden. Und viele Cloud-Services agieren mittlerweile auf der Applikationsebene (man denkt an Event Routing oder Image Detection), sodass Entwickler direkte Kontrolle über solche Ressourcen benötigen.
Eine große Gefahr besteht daher, wenn Organisationen der Versuchung erliegen, eine vorhandene Infrastrukturschicht als "Plattform" umzubenennen. Dies passiert leider zu oft, weil man ja den Trend nicht verpassen mag, aber gleichzeitig nicht ausreichend Budget oder die erforderlichen Skills zur Verfügung hat. Das kann nicht gut gehen, denn eine moderne Plattform ist ziemlich genau das Gegenteil der bisherigen Infrastruktur (siehe Abbildung 3).
Abb. 3: Plattformen sind keine verbesserte Infrastrukturschicht (Quelle: [Hoh23])
Abstraktion: leichter gesagt als getan
Damit interne Plattformen die Entwicklung beschleunigen können, müssen sie die Komplexität, der die Entwickler ausgesetzt sind, also die mentale Belastung, reduzieren, ohne die Teams in ihrer Kreativität einzuschränken. Ein beliebter, aber leider auch naiver Ansatz, besteht darin, Entwicklern Cloud-Dienste anzubieten, bei denen mehrere Parameter, wie die Datencenter-Lokalität, fixiert sind. Dies alleine bietet allerdings eine unzureichende Abstraktion der Cloud-Schicht und wird die kognitive Belastung kaum reduzieren. Zudem empfinden Entwicklungsteams solche Ansätze eher als Einschränkung statt einer Produktivitätssteigerung.
Anstelle der Voreinstellungen von Parametern eines Cloud-Dienstes sollten sich interne Plattformen an einer Domänensprache orientieren, die den Anforderungen der Entwickler und des Betriebs folgt. Betriebssysteme bieten wiederum ein klassisches Beispiel: Ein Betriebssystem bietet keine bessere Schnittstelle zum Lesen und Schreiben von Festplattensektoren an, sondern eine Abstraktion bestehend aus Dateisystemen und Input-Output-Streams. Diese Abstraktion hebt das Programmiermodell auf eine andere Ebene, womit sie in der Tat den Namen Plattform verdient.
Dementsprechend müssen interne Plattform-Teams überlegen, wie Entwickler über die technische oder auch die fachliche Domäne nachdenken, das heißt, sie arbeiten basierend auf den Anforderungen der Entwickler, nicht der Basistechnologie. Die richtige Frage lautet also nicht "Wie binde ich einen SMTP-Server an die Anwendungen an?", sondern "Wie gelangen Dokumente oder Benachrichtigungen an den Kunden?" In einer Bank oder Versicherung könnte die Plattform stattdessen eine Möglichkeit anbieten, Kunden ein Schreiben zukommen zu lassen, ohne dass der konkrete Postweg (z. B. Digitales Postfach, E-Mail, Schneckenpost) spezifiziert werden muss. Vielmehr kann eine Kombination aus Schutzbedürfnis der Informationen und Nutzerpräferenzen in der Plattform bestimmen, über welches Medium ein Schreiben zugestellt wird. Die Entwicklung einer Plattform ist daher stark mit fachlich getriebenem Design (Domain-Driven Design) verknüpft. Hier wird jedoch nicht die komplette Business-Domäne modelliert (das machen die Applikationsentwickler), sondern überwiegend technische Komponenten, auf denen die Applikationen aufsetzen. Diese Einsicht führt aber auch zu einer Warnung, die besonders bereits existierende Infrastrukturteams betrifft, die sich an Plattformen versuchen:
- Wenn Plattformteams mit der fachlichen und technischen Domäne nicht vertraut sind, wird die Plattform kaum Wert liefern.
Die Schnittstelle zwischen fachlicher und technischer Domäne wird an einem Beispiel aus dem Finanzwesen klar. Wenn eine Plattform eine „Datenbank mit Kundendaten“ bereitstellt, dann ist dies erheblich ausdrucksstärker als eine Cloud-Datenbank mit fixierten Parametern. Eine solche Plattformkomponente stellt den Nutzen klar: Diese Datenbank ist so aufgestellt, dass sie betriebliche Anforderungen an Lokalität, Verschlüsselung und Datensicherung für Kundendaten beinhaltet. Cloud-Anbieter können eine Datenbank in dieser Form nicht anbieten, weil die Anforderungen zur Handhabung von Kundendaten nach Land, Industrie und Unternehmen variieren:
- Cloud-Anbieter können keine Dienste anbieten, die den fachlichen Ansprüchen diverser Unternehmen entsprechen. Daher finde diese Übersetzung in einer Inhouse-Plattform statt.
Trotz der geringen Anpassung entwickelt sich aus dem generischen Cloud-Dienst "Datenbank" ein betriebsinternes Konzept, das heißt, es hat eine wertvolle Abstraktion stattgefunden. Die Plattformdomäne basiert oft auf einem Vokabular von Referenz- oder Makroarchitekturen (vgl. [ISA]) wie Change Data Capture, Message Queues, oder Push-vs-Pull-Kontrollfluss für verteilte Systeme.
Plattformen sind kein reines Technologiethema
Interne Plattformen haben enormes Potenzial, die Softwareentwicklung zu beschleunigen. Eine interne Plattform erlaubt es, diese speziell auf den Kontext und die Komplexitäten des Unternehmens zuzuschneiden. Deshalb wird eine solche Plattform als Produkt entwickelt, das sich basierend auf Anforderungen der Entwicklungsteams weiterentwickelt. Für viele IT-Teams, die mit einem "Buy over build"-Ansatz groß geworden sind und Stabilität bevorzugen, ist dies eine komplette Kehrtwende. Das bedeutet, dass, wie so oft, die neue Technologie auch einen Wechsel in der Arbeitsweise und der Grundeinstellung erfordert, um die gewünschten Ergebnisse zu liefern.
Ein klassisches "Neu trifft auf Alt"-Szenario spielt sich zum Beispiel dann ab, wenn eine Cloud-Plattform, die der internen Plattform als Basis diente, Funktionalität einführt, die bisher in der Plattform implementiert war. [Hoh23] beschreibt diese Situation als „die Plattform ist unter Wasser“. Teams müssen nun entscheiden, ob sie diese Funktionalität aus der internen Plattform entfernen, das heißt, "Oben drauf schwimmen", oder die interne Plattform so lassen, wie sie ist, und sie zum U-Boot werden lassen (siehe Abbildung 4).
Abb. 4: Plattformteams entscheiden, ob sie schwimmen oder untertauchen wollen (Quelle: [Hoh23])
Ein traditioneller Ansatz fokussiert sich schnell auf die "sunk cost", also die bisherigen Investitionen in die interne Plattform, mit dem traurigen Ergebnis, dass die interne Plattform nun die Funktionalität einer Cloud dupliziert und mit deren Innovation nicht mithalten kann. Somit zeigt sich, dass die Einführung einer Plattform nicht nur die Entwicklungs- und Infrastrukturteams beeinflusst, sondern auch interne Funktionen wie Budgetierung oder Finanzwesen.
Transformation geht nicht über den Einkauf
Interne Plattformen können althergebrachte Widersprüche durchbrechen.
Dank Harmonisierung können Entwicklungsteams schneller innovative Software liefern. Solche Effekte zeigen sich aber nicht, weil eine Box mit dem Label „Plattform“ im Architekturdiagramm auftaucht oder ein Plattformteam aus dem Boden gestampft wird. Stattdessen müssen Plattformteams gut eingespielte Projektteams sein, die sowohl die technische Domäne von Cloud-Laufzeitumgebungen und verteilten Systemen als auch die Business-Domäne sehr gut verstehen. Diese Teams müssen ihre Expertise so verpacken, dass sie von den Entwicklungsteams im Selfservice reibungsfrei konsumiert werden können.
Interne Plattformen zu bauen, ist ein delikates Unterfangen, das ein eingespieltes Team erfordert. Eine bekannte Falle besteht daher, wenn Unternehmen versuchen, eine Plattform zu bauen, auf der ihre wenig talentierten Entwickler lukrative Produkte entwickeln sollen. Der Mangel an Talent rächt sich nämlich verstärkt beim Entwurf und Bau der Plattform, sodass die Idee nie zum Tragen kommt.
Organisationen dürfen Plattformen nicht als die neueste Wunderlösung für alte Probleme sehen, sondern müssen sich im Klaren darüber sein, auf welche Ergebnisse sie abzielen, sei es höhere Produktivität, bessere Compliance oder schnellere Innovation. Die Kernmechanismen der Plattformen können dann dazu eingesetzt werden, die gewählten Metriken zu verbessern, wobei konstantes Experimentieren ausdrücklich erwünscht ist.
Weitere Informationen
[Atw13] J. Atwood, The Rule of Three, 18.7.2013, siehe:
blog.codinghorror.com/rule-of-three/
[Cnc24] Cloud Native Landscape, siehe:
landscape.cncf.io/
[Fri15] U. Friedrichsen, The broken promise of re-use, 13.10.2015, siehe:
www.codecentric.de/wissens-hub/blog/the-broken-promise-of-re-use
[FTSE] en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering
[Hoh22] G. Hohpe, Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration, Independently published
[Hoh23] G. Hohpe, Platform Strategy: Innovation Through Harmonization, Independently published
[ISA] Independent Systems Architecture, siehe:
isa-principles.org/
[Par72] D. Parnas, On the Criteria to Be Used in Decomposing Systems into Modules, in: Com. of the ACM, siehe:
dl.acm.org/doi/10.1145/361598.361623
[Sch18] R. A. Schneider, Baukastenstrategien im Automobilbereich, Schriftenreihe Projektmanagement Universität Kassel, 2018
[Ske19] M. Skelton, M. Pais, What is a Thinnest Viable Platform (TVP), siehe:
teamtopologies.com/key-concepts-content/what-is-a-thinnest-viable-platform-tvp
[SLA] Shift-Left-Ansatz, siehe:
de.wikipedia.org/wiki/Shift-Left-Ansatz
