Team Topologies V - Platform as a Product

Recap Team Topologies - Teil III und IV

Zentrale Träger der Wertbildung und -schöpfung in der Softwareentwicklung sind die stream-aligned teams. In großen und auf Skalierung und Entwicklungsgeschwindigkeit optimierten E-Commerce-Systemen verantworten diese Teams häufig eine fachlich definierte Vertikale. Team Topologies nennt diese kunden- und nutzerorientierten Vertikalen streams of change . Streams und die damit garantierte Konzentration auf "Wesentliches" sind das erste Werkzeug zur Erhöhung der Entwicklungsgeschwindigkeit in Softwareprojekten. Im E-Commerce erscheint uns die Orientierung am gestifteten Kundenwert das zentrale Schnittmuster, erlaubt sie den Teams doch nicht nur schnell, sondern auch gerichtet zu beschleunigen. Team Topologies wirkt am besten sobald die Effizienz in etablierten Geschäftsprozessen (McKinsey Horizont 1) gesteigert werden soll. Klar voneinander unterschiedene Kommunikationstypen (von der Kollaboration bis zur vereinfachenden generalisierten API) erlauben die jeweils passende Kommunikation zwischen Teams zu wählen. Die Auswahl der geeigneten Kommunikationsform ist das zweite Werkzeug der Team Topologies. Sie erlaubt den Teams damit die eigene kognitive Kapazität auf die zentrale fachliche Domäne, den germane cognitive load zu konzentrieren und unterstützt den durch Isolation und der Konzentration auf den richtig geschnittenen stream entstandenen Fokus. Enabling Teams unterstützen dabei.

Ziel: Gerichtete Geschwindigkeit

Das zweite Feld zur optimierten Nutzung der kognitiven Kapazität der stream-aligned teams ist die Entlastung von Aufgaben, die nicht im fachlichen Fokus stehen. Neben dem immer wieder zu erneuernden Handwerkszeug der Softwareentwicklung (intrinsic cognitive load), das durch selbstgesteuerte Weiterbildung und ggfs. Enabling Teams adressiert wird, gibt es technische basics und durch organisatorische Aufgaben verursachte technische specifics, die als extraneous cognitive load an der begrenzten Gesamtkapazität des Teams zehren.

Das dritte Werkzeug der Team Topologies ist darum die Auslagerung dieser Strukturen in zuliefernde Teams, die den stream aligned team Leistungen zur Verfügung stellen. Geschwindigkeit und Fokus entstehen danach durch Platform Teams und Teams, die sich um komplizierte Subsysteme kümmern.

Versuchen wir zunächst die Plattformen zu beschreiben.

Der Plattformbegriff im E-Commerce

Grenzen wir den Plattformbegriff pragmatisch ab: Wenn der Fokus der stream aligned teams auf Aufgaben liegt, die kundendomänenspezifisch dem germane cognitive load zugerechnet werden können, wären alle Aufgaben, die nie oder nur äußerst selten teamspezifisch angepasst werden müssen (also "stabil sind"), Themen für eine Verlagerung in eine Plattform. Auch Änderungen, die zwar häufig nötig sind, aber aufwändig und kompliziert bleiben, sind solche Kandidaten. Hier kann Kompliziertheit gekapselt und vereinfacht mittels API änderbar gemacht werden. Hinsichtlich Effizienz sind Themen, die von mehreren Teams in identischer Form abstrahiert werden können, natürlich besonders interessant.

Aufgaben, die zwar teamspezifisch sein können, jedoch aufgrund ihrer langen Halbwertszeiten der Plattform zugerechnet werden können, sind

• Networking (Isolation von Netzen (eigene Subnetze), Verbinden von Netzen (VPN), Zugriffswege ändern)
• AccessManagement: On-/Offboarding von Mitarbeitenden
• Security (Authentifizierung, Stichworte: Gateways, Oauth, SingleSignOn)
• Application-Routing/-Loadbalancing (Stichworte: nginx, ingress)

Die hier genannten Aufgaben können entweder zu platform teams oder in die stream aligned teams wandern. Voraussetzung für eine dauerhafte Entlastung ist die Möglichkeit zur einfachen Lösung der teamspezifischen Anforderungen. Zentral ist wieder, dass die stream-aligned teams durch die Abgabe von Aufgaben an platform teams nicht relevant verlangsamt werden. D.h. im Wesentlichen, dass sobald zu häufige Interaktion mit einem platform team auftritt, entweder fehlende Self-Service-Schnittstellen entwickelt werden müssen oder die Aufgabenverteilung überdacht werden muss.

Hier wird ein bereits ein wichtiges Pattern in der Abgrenzung zwischen Plattform und Domäne angesprochen. Die Ansprüche der Teams tendieren in Richtung spezifische Lösungen, die Ansprüche eigenständiger platform teams tendieren in Richtung Standard. Die Aushandlung dieser Ansprüche wird möglich, wenn man sich an den Regeln der Produktentwicklung orientiert. Produktentwicklung stellt den Nutzer, den Kunden und die hier gestifteten Werte in den Vordergrund. Dieser Aspekt macht externe Referenz auch für die Plattform Teams erst möglich. Wir halten den Produktgedanken bei der Plattformdefinition für eine unbedingte Voraussetzung für den Erfolg.

Verstärkt werden die Wirkungen der Produktperspektive auf die Plattform durch die iterative Vorgehensweise bei der Entwicklung. Ausgehend von einer ersten, für die stream aligned teams wertstiftenden Lösung (thinnest viable platform, just good enough), wird “along the way” immer wieder angeboten, nachgefragt, ausgehandelt und ergänzt. So ist evolutionäre Plattformentwicklung sichergestellt.

Für uns liegt im Fokus der stream aligned teams auf die Endkunden und dem ähnlichen (aber nicht gleichen) Fokus der platform teams auf die nutzenden Teams als Kunden der Schlüssel für zielgenaue Schnitte und schnelle Entwicklung der richtigen Software.

Die Entscheidung, ob ein Thema noch in den germane oder intrinsic Anteil der Aufgaben des stream-aligned teams gehört oder in ein Platformprodukt wandern kann oder soll, wird innerhalb des stream aligned teams getroffen. Theoretisch ist kein Team gezwungen, eine von einem Team bereitgestellte Plattform zu nutzen. Das Management der eigenen kognitiven Kapazität obliegt dem Team selbst. Es hat hier alle Freiheiten und trägt damit auch die verantwortung für die Entscheidungen. Eine Analyse der eigenen kognitiven Last ist der entscheidende Zugang, um hierzu Fragen stellen und selbst beantworten zu können.

Aufgaben die zum Teil und im weiteren Verlauf zwischen Dienstleistungsteams (platform oder complicated subsystem) oder stream-aligned teams ressortieren sind z. B. :

• Intelligente DDOS-Erkennung-Abwehr (z. B. Login-Angriffe, Datendiebstahl, Ausspähungen)
• Teamindividuelle Deployment-Infrastruktur kann auf aktuellen und gepatchten Base-Images eines Plattform Teams kommen, während die Teams via Docker die Spezifika hinzufügen können. Ein Beispiel wäre gitlab-ci als Deployment-Tool, mit Anforderungen, die über simple Konfigurationen hinausgehen: Z.B. spezifische Lasttests und Akzeptanztests mit spezifischer Infrastrukturanforderungen und Setups.
• Auch das Patching ist auszuhandeln. Hat das stream-aligned team alles in der eigenen Hand, muss es auch alles patchen (können). Z.B. JVM, OS etc.). Auch hier könnte ein Baseimage vom Plattform Teams kommen, mit dem die Standardarbeit erledigt wird. Abstimmungsbedarfe sind spätestens bei der Aushandlung von Standardangeboten des Plattform Teams und spezifischen Bedarfen des Entwicklungsteams gegeben. Wenn z.B. ein Team in Kubernetes permanente Speicherung wünscht treten Interessenkonflikten von stream-aligned teams und Plattform Teams auf.

Plattform Features können inzwischen auch via Angeboten von Drittanbietern in das System der Teams eingeführt werden. Fast alle Cloudanbieter haben ihr Leistungsangebot erweitert und als entsprechende Self Services konfiguriert. platform teams übernehmen nun das, was vom Anbieter (noch) nicht bedient werden kann, weil es z. B. keinen passenden SaaS gibt. Es kann das eigene Produkt auch auf die oben angesprochenen häufig änderbaren Themen erweitern, wenn sie einen guten Self Service ermöglichen.

Moderne Cloudanbieter bieten bereits einen großen Katalog an Plattformfunktionen. Ergänzt sind sie um einen ganzen Markt an Drittanbieter. Beide Gruppen stellen bereits eine am Markt etablierte (oder sich gerade etablierende) Self-Service-Schnittstelle für stream-aligned teams dar. Interessant für die eigen Organisationsstruktur sind dann die Themen, die solche Anbieter (zum jeweiligen Zeitpunkt) noch nicht in benötigter Qualität bzw. zu gewünschten Konditionen abdecken. Beispiele dafür sind:

• Etablierte Cloud-Infrastruktur (typischerweise IaaS wie VMs, Networking, Storage etc., sowie PaaS wie Datenbanken oder Web Services)
• Logging-System (z.B. ELK-Stack)
• Monitoring-System (z.B. Prometheus)
• Code-Verwaltung (z.B. Gitlab)
• Artefakt-Verwaltung (z.B. Nexus Repository)
• Tools für übergreifende Kommunikation wie Wikis, digitales Projektmanagement
• Backup-Verwaltung jenseits nativer Cloud-Funktionalität
• Team-unspezifische Security (z.B. Teamisolation, DDOS-Abwehr)

Die genannten Produkte und Lösungen müssen dauerhaft betrieben, beobachtet und an quantitativ und qualitativ wachsende Ansprüche angepasst werden. Sie sind aber wegen ihrer Allgemeingültigkeit nahezu ohne Teamkommunikation verwaltbar.

In die stream-aligned teams gehören alle Themen, die zwar technisch auch in Plattformen oder in Basisinstallationen zur Verfügung gestellt werden, die aber aufgrund ihrer (kunden)spezifischen Ausprägung in den Bereich der intrinsic und germane Aufgaben gehören. Die API des stream aligned teams macht diese Unterscheidung sichtbar. Ein Grund, warum dieses Artefakt unbedingt erstellt und immer wieder überprüft werden sollte.

Plattform als Produkt

Nachdem wir jetzt wissen, was Teil einer Plattform ist und was vielleicht nicht dazugehört, stellt sich die Frage: Wie kann ein platform team sicherstellen, dass es genau das schafft: Die richtige Balance zwischen Standardisierung und Spezialisierung unter Berücksichtigung des Gesamt-Flows zu finden. Dabei hilft es, die Plattform als ein Produkt zu verstehen, dessen Kunden die stream aligned teams sind.

Die Plattform-Roadmap ist also dann erfolgreich, wenn sie für die Kunden den maximalen Wert (Entfernen von extranous cognitive load) erfüllt und das für alle stream aligned teams gleichzeitig. Dafür wird der Begriff der “Developer Experience” (DevX) eingeführt. Nur wenn Produkte gebaut werden, die von Entwickelnden mit Freude und Erfolg genutzt werden können, werden sie sich ohne Anschlusszwang verbreiten.

Die oben aufgeführten Elemente von Plattformen für E-Commerce-Entwicklungen gliedern sich entlang der Achse mit den Endpunkten "generalisierte Kommunikation / standardisierte Vorgabe" und "spezifischer Ausprägung von Kollaboration".

Von der einfachen Handreichung der zu verwendenden Cloudprodukte über die Bereitstellung von allgemeinen Features, Basisinstallationen, Self-Service-Angeboten bis zur engen, kundenindividuellen Kooperation mit dem Kunden "Entwicklungsteam" - jedenfalls am Anfang - ist alles denkbar. Unsere Erfahrung sagt auch hier: der Kommunikationstrend verläuft von Kollaboration zur Generalisierung. Werden enge und aufwändige Kommunikationsformen auf beiden Seiten nicht durch Api oder x-as-a-Service abgelöst, sollte die Grenzziehung und Aufgabenteilung zwischen den beteiligten Teams (also das Schnittmuster) überprüft werden. Die Entkopplung und damit verbundene Unabhängigkeit ist der zentrale Beitrag eines platform teams zur gerichteter Geschwindigkeit in stream-aligned teams.

platform teams als Produktentwickler*innen?

Das Kalkül aus Sicht der stream-aligned teams für den Einsatz von Plattformen ist einfach: dem Verlust an Freiheitsgraden steht ein Zugewinn an Zeit und Wissen für Kundenfeatures gegenüber. Die Teams können ihre kognitive Kapazität zielgenauer einsetzen. Dabei gilt auch weiterhin, dass der richtige fachliche Schnitt (also des richtigen streams) entscheidet. Unter dieser Bedingung bietet die Plattform eine Entlastung durch Vereinfachung. Die Entwicklungsteams verlagern Kompliziertheit und Häufigkeit ins platform team, sie vereinfachen per Api, müssen das Groundwork aber trotzdem verstehen.

Das Kalkül der platform teams ist zwiespältiger: Die Kundenorientierung ist - da es sich zumeist um nicht marktförmig vermittelte interne Beziehungen handelt, nicht naturwüchsig gegeben.

Um das Mindset zu entwickeln, empfiehlt sich auch hier eine Ergänzung: hinter platform-as-a-product steht das Pattern der thinnest viable platform und des just big enough. Ist der Auftrag so formuliert, wirkt er disziplinierend:

Löse [als platform team] nur die Probleme der Software entwickelnden Teams, die diese haben. Löse diese so schnell wie möglich. Beschäftige Dich nicht mit Dingen, von denen du glaubst, dass die Kunden diese haben sollten oder in ferner Zukunft haben wollen. Deine Lösung sei einfach und für alle mit dem geringsten aktuell notwendigen Aufwand verbunden.

Starke Vertikalen sind in diesem Kontext in der Lage, die eigenen zentralen Aufgaben zu formulieren und den Leistungsumfang von platform-as-a-product entsprechend einzufordern.

Dabei kann die thinnest viable platform zunächst auch nur ein einfaches How-to sein. Bei einem unserer Kundenteams wird erst jetzt, nach mehr als zwei Jahren erfolgreicher Arbeit in Vertikalen, das Produkt Plattform aus den Teilen der technischen Werkzeuge entwickelt, die die Teams auslagern wollen. Hier entstand das platform team sozusagen als buy out aus den stream aligned teams.

Diese stream aligned teams sind starke Kunden. Die Kommunikation über den Leistungsumfang der Plattform fällt ihnen leicht, sie muss aber auf der Seite der platform teams auf eine ebenso große Souveränität und Sachkunde treffen, um die Wünsche in Lösungen übersetzen zu können.

Auch eine Gilde der "plattform-affinen Entwickelnden" kann hier hilfreich sein. Kurz getaktete, stetig angelegte Formate für Diskussion über die Plattform sind hilfreich. Roadmaps auf Ebene von mehreren Sprints können hilfreich sein, um die gewünschten Features zeitnah in das Produkt zu integrieren.

platform teams als Kommissionäre

stream aligned teams kommunizieren mit den platform teams mittels des Produktes Plattform. Die Entwicklungsteams formulieren ihre Bedürfnisse bzw. das platform team erkundet diese. In diesem dialogischen Prozess entsteht das Produkt. Soweit so gut. Allerdings haben sich, wie es bei Produktmärkten üblich ist, auch im Markt der Plattform in den letzten Jahren neue und starke Akteure etabliert.

Für allgemeine bzw. der verallgemeinerbare Plattform Features konkurriert das interne platform team mit externen Anbietern. Die faktischen Standards der Anbieter von Cloudservices sind wirkmächtig. Nicht nur weil dort Netzwerkeffekte wirken (“alle Teams nutzen xyz von abc, unsere Zulieferer auch, also nutzen wir das ebenfalls") und passende Vertriebsmuster greifen, sondern auch, weil die Angebote in der Regel funktionieren, die Kundenprobleme (mindestens in großen Teilen) gut lösen, als Zukaufprodukte die Aufwände gut sichtbar sind und nicht zuletzt nach Bedarf skaliert werden.

Für die stream aligned teams ist es sinnvoll, sich auf ihr (durch die Domäne beschriebenes) Kerngeschäft zu konzentrieren. Ob sie nun die allgemein verfügbare Leistung direkt oder via platform team einkaufen, ist nur mehr eine organisatorische Entscheidung. Und ob die notwendige Ergänzung der allgemeinen Plattformbestandteile (häufig anzupassen, spezifisch in der Anwendung, kompliziert), genug Arbeit für ein eigenes Plattformteam hergibt, ist unterschiedlich.

Wir beobachten jedenfalls verschiedenen Strategien mit Plattformen und platform teams umzugehen, wobei sich der Fokus vom Produkt entwickelnden zum Produkt kommissionierenden platform team zu verschieben scheint.

Im Kern bilden sich hier die Standards und Normen der fortschreitenden Digitalisierung ab. In unserer Domäne sind bestimmte Leistungen (Registrierung, Nutzerverwaltung, Securityfeatures, BI-Basiucs, data engineering etc.) inzwischen auf dem Weg, ubiquitär und standardisiert verfügbar zu werden. Dass sich damit der Produktentwicklungsfokus von der strikten Orientierung am Kundenwert hin zu einer eher pro domo ausgerichteten Exploitation-Strategie des Plattformanbieters wandeln kann, ist sicher auch nicht von der Hand zu weisen.

Und - um es mit einem alten Entwicklerkollegen zu sagen - “Standardprodukte lösen nur Standardprobleme. Kann gut sein, kann nicht gut sein.” Und mit Zuliefernden umzugehen, haben die meisten Unternehmen im E-Commerce gelernt, insbesondere wenn möglicherweise Anbieteroligopole entstehen.

platform teams: Aufgaben, Anwandlungen, Antipatterns

Wir wollen hier kurz einige Beobachtungen rund um platform teams teilen, die viele Practioner kennen. Wir sind uns nicht sicher, welche Bedeutung diese Anekdoten bezogen haben, wir bemerken sie lediglich als Einfluss, Hindernis oder Gefahr und nennen sie deshalb Aufgaben, Anwandlungen und Antipatterns für platform teams. Letztlich befassen sie sich alle mit dem Produktbegriff und der Ausrichtung der nachfragenden Teams als “Kund:innen”.

Thickest Possible Platform oder die “Everything Platform”

Eine Anwandlung oder ein Anttipattern ist die Verankerung aller "Plattformthemen" durch die Hausspitze im neuen mächtigen Team. Nicht "thinnest viable" sondern "maximaler Umfang", nicht "just good enough" sondern "alle Eventualitäten abdeckend" markiert das Selbstverständnis - sobald die Diskussion über Plattformthemen in diese Richtung abgleiten und nicht von starken Vertikalenteams herausgefordert werden können, muss eskaliert werden. Hier werden Weichen auf Gleise gestellt, die im weiteren Verlauf nur äußerst schwierig zu korrigieren sind.

Tit for tat und die Welt der Gefallen

Die Option "am Produkt vorbei zu entwickeln" gehört zum Leistungsumfangs des platform teams hinzu. Es stellt ein Risiko oder eine Anwandlung dar. Individuelle Features, technisch noch nicht abgedeckte Anforderungen können - in kleinerem Maßstab - durch die stream-aligned teams selbst entwickelt und genutzt werden oder vorab von den Kolleg:innen im platform team gebaut werden. Ob und wann sie als Feature in das Produkt Plattform wandern, wird ausgehandelt. In unserer Diskussion fragen wir uns in diesem Zusammenhang oft, wann der Pfad der Produktentwicklung verlassen wird und die Entwicklung als Tit-for-tat Kommunikation zwischen Entwickler:innen erfolgt. Wir meinen: Wenn es keine “Produktmanager:innen” gibt (als Rolle oder geteiltes Mindset), besteht die Gefahr, dass die informellen Beziehungen das Geschehen bestimmen und die Vorteile der Justierung der Plattformentwicklung via gestifteten Kundenwert verloren gehen.

Der zerfasernde Produktbegriff

Wir beobachten platform teams, die sich sehr schnell nicht mehr um ein überschaubares Produkt sondern ein Konvolut von 20 einzelnen Diensten kümmern müssen. Es ist nur zu verständlich, das in einem solchen Fall der Fokus des Teams vom Produkt und dessen Nutzen für die verwendenden Entwicklungsteams hin zur möglichst reibungsfreien Orchestrierung der Dienste wechselt. Statt Erträge bei den Nutzer:innen zu optimieren, wird die Optimierung der eigenen Aufwandsstruktur in den Blick genommen.

Die möglichen Lösungsideen sind noch nicht ausreichend. Weder kann das zur Hilfe gerufene Produktentwicklungsteam wirklich helfen (denn schließlich sind die vielen Dienste ja schließlich zu leisten), noch nutzt es über eine simple Einführung von Preisen (im Maximum der Ausgründung der eigenen Plattform) nachzudenken. Es gibt weder einen Markt noch eine echte Kundensituation. Und Simulationen helfen nicht wirklich weiter.

Team Topologies bietet den Ausweg der differenzierten Binnenstruktur der Plattform an - aus nachvollziehbaren Gründen ist das eher eine, wenn auch zunächst hilfreiche, Verlagerung des Problems, aber keine Silver-Bullit. Komplizierte konzernweite Plattformkonstrukte werden irgendwann eben genau das: kompliziert.

Ein weiterer Lösungsraum ergibt sich theoretisch daraus, dass Teams über die Selbststeuerung in den Stand der “Optimierung” gelangen können. In der Diskussion der agile fluency verändern Teams mit diesen Fähigkeiten die Organisation selbst. Abgesehen davon, dass diese Reife sogar von den Autoren seltenst beobachtet werden konnte, scheinen die Vorbedingungen für derartig handlungsfähige Teams doch eher schwer zu erfüllen.

Behelfen wir uns erstmal so: das Verständnis der eigenen Arbeit als ein Wertbeitrag zu einem Zweck (wir wollen das einmal "Outcome" nennen) wird sich weder alleine durch Änderungen in der Organisation oder Zielvorgaben der Unternehmensleitung noch durch die Einführung von Werten als Rechnungsgröße oder einer Team Topology durchsetzen. Aber umgekehrt könnte es so sein, dass ein Fehlen jedes einzelnen dieser Aspekte eine nachhaltige Verankerung dieser Ideen immer unwahrscheinlicher macht.

der Anschlusszwang

Ein echtes Antipattern ist die zu weitgehende Vorgabe von technischen Lösungen ohne Diskussion mit den stream-aligned teams auf technischer Ebene. Erst wenn diese Teams verstanden haben, was ihre fachliche Aufgabe ist, sind sie zu Plattformthemen diskussionsfähig. Im Falle des schon mehrfach zitierten platform team als buy out aus den stream aligned teams, haben sich die Teams sogar erst sprachfähig gemacht, bevor ein platform team etabliert wurde. Ein platform team kann - Erfahrung vorausgesetzt - zeitgleich mit den unstreitig allgemeinen Features für eine thinnest viable platform (Sprint 0 in manchen unserer Backlogs und Story Mappings) beginnen, muss aber diesen Vorsprung nutzen, um ein attraktives Angebot zu unterbreiten. Falls das platform team seine Zeit damit verbringt fein auszislierte Regelwerke zu schreiben, die sich damit beschäftigen, wer wann was nutzen muss, ist eine Klärung angeraten.

verdeckte Architekten

Eher in der Zone der Gefährdungen und Anwandlungen gehört ein Phänomen der Teamdynamik: Querschnittsteams ziehen vielseitig interessierte Kolleg:innen an. Hier treffen sich starke Persönlichkeiten, die Führung anbieten wollen. Plattformdiskussionen arten in dieser Konstellation gerne in Architekturfragen aus. Sobald Festlegungen für die Architektur als Plattformentscheidungen maskiert werden, ist eine Klärung nötig. Grob gesagt: Architektur gehört in die Teams, sprachfähig werden die Teams via Gilden.

Fazit

platform teams entlasten stream-aligned teams, damit diese ihre kognitive Kapazität auf die fachlich-technischen Aufgaben konzentrieren können. Dabei gilt: Je klarer eine Aufgabe als extraneous erkannt wird, umso eher kann Kompliziertheit und Häufigkeit in eine Plattform verlagert und durch API und x-as-a-Service einfach änder- und nutzbar gemacht werden.

Plattformen entwickeln sich dabei organisch und bieten im Laufe der Entwicklung immer mehr, immer spezifischere und immer flexiblere Schnittstellen und Services an.

Wenn man mit der thinnest viable platform startet, die Wertstiftung betont und die Plattform als Produkt auf die streams of change ausrichtet, dann ist der zentrale Beitrag von Plattformen für optimierten Flow unstreitig.

Im proklamierten platform as a product verbirgt sich mehr Aufgabe als Lösung, mehr Suchraum als Vorgabe. Der Ruf nach einem Produktentwicklungsteam kann hier jedenfalls nur der Einstieg sein.

Wir könnten vermuten: Schnitte (und damit stream aligned teams) können sich ändern, komplizierte Subsysteme können einfacher, überflüssig und vereinfacht werden - Plattformen und deren Schnittstellen als vereinfachter Zugang zu komplizierten Groundwork werden dauerhaft bleiben - auch wenn sich die Techniken jeweils ändern können.