Eigentlich definiert Architektur “nur” die Struktur der Software. Aber das Gesetz von Conway weißt schon auf den Zusammenhang zwischen Architektur und Organisation hin. Durch das Inverse Conway Maneuvre ist klar geworden, dass die geschickte Aufstellung der Organisation die Architektur maßgeblich beeinflussen kann. Dieser Vortrag zeigt auf, dass Team Topologie auch erhebliche Konsequenzen für die Architektur-Arbeit hat: Team Topologies fungiert nicht nur als Werkzeug für Architektur, sondern muss auch in die architektonische Planung einbezogen werden.

2025-05-30 Thumbnail

PeerTube Video - no Big Tech!

YouTube Video

Audio als Podcast

MP3 Download
Infos und Feeds zum Audio als Podcast

Hinweis: Die nachfolgenden Texte wurden mit KI erstellt und können somit Fehler enthalten.

Die Evolution von Architektur durch Team Topologies

Software-Architektur und Teamorganisation werden oft als separate Themen betrachtet. Doch Team Topologies zeigt, dass beide eng miteinander verwoben sind und sich gegenseitig beeinflussen. Dieser Episode beleuchtet, auf welche Weise Team Topologies eine natürliche Evolution der Software-Architektur darstellt.

Die Rolle der Kommunikation

Kommunikation ist sowohl essentiell als auch problematisch in der Softwareentwicklung. Einerseits ist sie die Basis für erfolgreiche Projekte - ohne vernünftige Kommunikation lassen sich Anforderungen nicht klären und Probleme nicht lösen. Andererseits kann zu viel Kommunikation den Fortschritt behindern, wenn Entwickler permanent in Meetings sitzen statt Code zu schreiben.

Die Herausforderung besteht darin, das richtige Maß an Kommunikation zu finden. Dokumentation ist wichtig, aber aufwendig zu erstellen und kann schnell veralten. Direkte Kommunikation ist oft effektiver, muss aber dosiert eingesetzt werden.

Software-Architektur als Kommunikationsoptimierer

Eine zentrale Aufgabe der Software-Architektur ist es, den Bedarf für Kommunikation zu reduzieren - nicht durch Einschränkung der Kommunikation, sondern durch geschickte Strukturierung des Systems. David Parnas beschrieb dies bereits 1971 in seinem wegweisenden Paper “Information Distribution Aspects of Design Methodology”.

Das Konzept des Information Hiding ist dabei fundamental: Module sollten so gestaltet sein, dass sie möglichst wenig Informationen nach außen preisgeben. Dies ermöglicht Änderungen am Modul, ohne dass andere Module davon betroffen sind. Ein klassisches Beispiel ist eine Bankkonto-Klasse, die intern entweder den Kontostand direkt speichern kann oder aus den Transkationen berechnen kann. Solange die öffentliche Schnittstelle beispielsweise zur Abfrage des Kontostands stabil bleibt, können die Implementierungen beliebig ausgetauscht werden.

Team Topologies als evolutionärer Schritt

Team Topologies erweitert diesen Ansatz, indem es verschiedene Teamtypen und deren Interaktionsmuster definiert:

Diese Teams interagieren über definierte Muster:

Neue Perspektiven auf Systemgrenzen

Team Topologies erweitert die klassische domänenorientierte Aufteilung um weitere “Fracture Planes” wie:

Dies ermöglicht eine flexiblere Organisation, die besser zur Realität vieler Unternehmen passt. Die strikte Zuordnung “eine Domäne = ein Team” ist oft nicht praktikabel oder sinnvoll.

Cognitive Load als zentrales Konzept

Ein wichtiger Beitrag von Team Topologies ist das Konzept des Cognitive Load: Teams sollten nicht mit zu vielen verschiedenen Aufgaben überlastet werden. Enabling Teams und Platform Teams helfen dabei, den Cognitive Load der Stream-aligned Teams zu reduzieren.

Fazit

Software-Entwicklung ist ein soziotechnisches System - technische und organisatorische Aspekte lassen sich nicht trennen. Team Topologies bietet einen pragmatischen Rahmen, um beide Dimensionen zu berücksichtigen und die Evolution von Architektur und Organisation gemeinsam zu gestalten.

Dabei ist wichtig zu verstehen, dass es keine universellen Lösungen gibt. Die konkrete Ausgestaltung muss immer im Kontext der Organisation, der Menschen und der technischen Anforderungen erfolgen. Team Topologies liefert dafür wertvolle Patterns und Konzepte, die aber flexibel angewendet werden müssen.

Die Evolution von Software-Architektur durch Team Topologies zeigt: Erfolgreiche Systeme entstehen durch das Zusammenspiel von technischer Exzellenz und effektiver Teamorganisation. Nur wer beide Aspekte berücksichtigt, kann nachhaltig erfolgreiche Software entwickeln.

Folge 265 - Die Evolution von Architektur durch Team Topologies

Wichtige Keytakeaways

Behandelte Kernfragen

Glossar wichtiger Begriffe

Vollständige Transkription

Hinweis: Dieses Transkript wurde mit KI erstellt und kann somit Fehler enthalten.

Folge 265 - Die Evolution von Architektur durch Team Topologies

Basis ist ein Vortrag, den ich in den letzten Jahren irgendwie öfter mal gehalten habe, und den wollte ich jetzt gerne nochmal im Stream halten.

Einführung in Team Topologies

Thema ist also die Evolution von Architektur durch Team Topologies.

Und genau, Fragen wie immer gerne im Chat oder sonst eben auch über das Formular auf der Webseite.

Und worüber möchte ich sprechen?

These der Evolution

Meiner Ansicht nach sind Team Topologies eine natürliche Evolution von Software-Architektur.

Und das ist in gewisser Weise eine etwas steile These, weil nicht Team Topologies hat etwas damit zu tun, wie Teams miteinander interagieren.

Und auf der anderen Seite steht Software-Architektur, und Software-Architektur hat eben scheinbar etwas damit zu tun, wie eben Software organisiert wird.

Und damit zu sagen, dass ein Team Topologies sozusagen der nächste logische Schritt ist in Bezug auf Software-Architektur, ist ein bisschen komisch.

Dazu sollten wir uns erstmal angucken, was eigentlich Software-Architektur genau ist.

Und dazu möchte ich nochmal kurz ausholen auf ein anderes Thema, und das ist die Geschichte mit der Kommunikation.

Kommunikation als Grundlage

Also ist Kommunikation eigentlich gut oder schlecht?

Und das ist tatsächlich etwas, was nicht ganz so einfach zu beantworten ist.

Kommunikation in der Softwareentwicklung

Also auf der einen Seite ist es so, dass Kommunikation die Basis für erfolgreiche Projekte ist.

Wenn wir nicht vernünftig miteinander reden, dann haben wir ein Problem.

Und wenn ich nicht vernünftig kommuniziere, kriege ich nicht raus, was ich eigentlich in dem Projekt erreichen möchte.

Dann habe ich eine große Menge an Schwierigkeiten.

Aber auf der anderen Seite ist es eben auch so, dass ich halt durch Kommunikation Fortschritt verhindern kann.

Und es dauert einfach.

Also gerade so EntwicklerInnen und TechnikerInnen sind, glaube ich, bekannt dafür, dass sie sagen, naja, ich sitze die ganze Zeit in Meetings.

Ich rede mit Menschen und eigentlich will ich wirklich etwas Sinnvolles tun.

Sprich, ich will Code produzieren.

Und dazu komme ich halt nicht, weil ich die ganze Zeit in Meetings sitze.

Und das zeigt so ein bisschen das Problem bei der ganzen Geschichte.

Also im Meeting sitzen kann wertvoll sein, weil ich eben dadurch herausbekomme, was zu bauen ist.

Aber auf der anderen Seite würde ich vielleicht arbeiten und schauen, dass ich tatsächlich Code generiere.

Und das bedeutet, Projekte sollten so viel kommunizieren, wie notwendig ist.

Und ich habe das Notwendige mal in Kursiv gesetzt, weil ich da jetzt sozusagen so eine Drehschraube habe.

Also viel Kommunikation ist ja nun tatsächlich notwendig.

Und es gibt so unterschiedliche Möglichkeiten, miteinander zu kommunizieren.

Dokumentationsformen

Also eine Möglichkeit ist halt tatsächlich geschriebene Dokumentation.

Das bedeutet halt, ich habe sehr viel Aufwand.

Das heißt, ich muss das irgendwie alles raufschreiben.

Ich muss das irgendwie reviewen.

Und Dinge halt irgendwie aufzuschreiben, ist halt aufwendig.

Und das ist etwas, wo ich häufig halt bemerke, dass halt Menschen sagen, naja, wenn ich halt neue MitarbeiterInnen einarbeiten will in ein Projekt, dann will ich eigentlich geschriebene Dokumentation haben.

Und ich finde das erstaunlich, weil ich würde behaupten, wenn man mit jemandem mal über das Thema spricht, dass man möglicherweise schneller und einfacher zu irgendeinem Ergebnis zu bekommen, als wenn man das irgendwie alles aufschreibt und dann anschließend lesen muss.

Für mich als Berater ist es halt super, wenn Sachen halt aufgeschrieben sind.

Dann kann man es mir einfach sozusagen vorlegen.

Gucke ich mir das halt irgendwie an oder wir gucken uns das an.

Und das ist halt dann, wenn es einmal geschrieben ist, nicht so wahnsinnig aufwendig.

Ich muss aber auch gestehen, dass ich solche Sachen mit Vorsicht anschaue.

Einfach deswegen, weil es eben sehr gut sein kann, dass die Sachen, die da halt in der geschriebenen Dokumentation stehen, veraltet sind und deswegen dann halt irgendwie am Ende falsch sind.

Kommunikationskanäle

Es gibt diese Idee, E-Mails zu verschicken, statt Meetings zu machen.

Finde ich auch ein bisschen problematisch, weil nicht am Ende sind Meetings.

Direkte Kommunikation ist doch vorteilhaft.

Und diese Idee, Jira-Tickets zu übertragen, zu schreiben, statt in einer direkten Kommunikation, das ist etwas, was ich tatsächlich, glaube ich, in einem YouTube-Kommentar gesehen habe von meinem Stream, wo also jemand im Projekt dazu gezwungen worden ist, letztendlich nur noch über Jira-Tickets mit anderen Menschen zu kommunizieren.

Und das ist halt im hohen Maße problematisch, denke ich.

Weil dadurch wird irgendwie alles verschriftlicht und wir verlieren einfach darüber Details.

Software-Architektur und Informationsfluss

So, und jetzt kommt halt Software-Architektur und meiner Meinung nach dient Software-Architektur eigentlich dazu, diesen Informationsfluss zu begrenzen und zu reduzieren.

Wenn ich jetzt nur Kommunikation begrenze, dann habe ich genau dieses Problem mit, naja, schreibe halt ein Jira-Ticket, statt mit Menschen zu reden, mache halt weniger Meetings.

Dann kriege ich halt am Ende Schwierigkeiten, weil ich eben zu wenig kommuniziere.

Das heißt, was ich eigentlich möchte, ist, ich möchte den Bedarf für Kommunikation reduzieren.

Also ich möchte, dass immer noch Menschen so viel kommunizieren wie notwendig, aber dass das weniger ist und dadurch eben weniger Kommunikation notwendig ist.

So, und da ist jetzt für mich ein wichtiger Punkt in diesem ganzen Software-Architekturbereich, dass die Struktur eines Systems die Notwendigkeit für Kommunikation reduzieren sollte.

Und das ist meiner Ansicht nach tatsächlich einer der wesentlichen Punkte, die hat Software-Architektur so ausmachen.

Und das habe ich mir nicht ausgedacht, sondern da gibt es den Herrn Parnas, haben wir auch schon im Stream, glaube ich, mehrfach diskutiert, der halt dieses Paper geschrieben hat über die Verteilung von Informationen als einen Ansatz für das Design von Software.

Also das Paper heißt Information Distribution Aspects of Design Methodology.

Und das ist ein Paper von 1971, wo eben der Herr Parnas, immerhin einer von den ganz großen Namen, die wir haben, sich genau über dieses Thema auslässt, also wie er Architektur Informationsfluss eben beeinflusst.

So, und was er halt dort schreibt ist, Module können halt frei geändert werden, wenn sie immer noch die Erwartungen von anderen Modulen oder von den Entwicklern in andere Module erfüllen.

Und dann schreibt er halt außerdem, andere Module werden eben alle Informationen benutzen, die halt dort sozusagen zur Verfügung stehen und die ich halt über das Modul habe.

Information Hiding

Und was er daraus ableitet, ist dieses Konzept von Information Hiding.

Also ich möchte so viele Informationen wie möglich verstecken.

Wenn ich weniger Informationen habe, die halt in andere Module geraten, dann ist es einfach, diese Module zu ändern, weil eben andere Module sich auf weniger Dinge verlassen.

Und das ist immer noch ein sehr fundamentales, valides Konzept.

Und das ist auch tatsächlich etwas, was sich sozusagen bestätigt hat, was also seit den 70ern, glaube ich, mittlerweile relativ unumstritten sein sollte.

Und der Gegenspieler, den es da irgendwie gab, war der Frederick Brooks, der halt in diesem sehr schönen Buch The Mythical Man-Month geschrieben hat, dass er entschieden hat, dass alle Entwickler eben alles Material über die Software, die sie da gebaut haben, das war das Betriebssystem für die IBM System 360, halt sehen durften.

Und das hat dazu geführt, dass sie halt so ein Projekt-Workbook hatten, mit immerhin 10.000 Seiten Umfang, wahrscheinlich inklusive den internen Funktionalitäten von irgendwelchen Modulen.

Und er hat halt gesagt, dass sie dieses Konzept von Partners, möglichst viele Informationen zu verstecken und möglichst wenig Informationen auszutauschen, dass sie das halt für einen Desaster gehalten hat.

Und er hat dann in der späteren Edition von The Mythical Man-Month geschrieben, dass Partners eben Recht hatte und er selber halt Unrecht hatte.

Historische Perspektive

Man muss dazu sagen, das ist so ein bisschen eine historische Geschichte.

Also mittlerweile sind wir, glaube ich, soweit, dass wir eigentlich anders bei Softwareentwicklung vorgehen und dass wahrscheinlich irgendwie Dokumentation grundsätzlich mittlerweile eigentlich gut ist.

Ihr scheint es so zu sein, dass irgendwie nicht alle Dokumentation vielleicht gute Dokumentation ist.

Da wäre es vielleicht noch mal interessant, sich das irgendwie anzusehen, was da genau in diesem 10.000 Seiten Buch drin stand.

Aber das hilft uns, glaube ich, in der aktuellen Situation nicht weiter.

In der aktuellen Situation ist es so, dass wir bei Information Hiding, glaube ich, in erster Linie reden darüber, dass wir zum Beispiel in Klassen Instanz-Variablen haben und öffentliche Methoden.

Und wenn der Zugriff auf so etwas halt auf eine Klasse durch diese öffentlichen Methoden stattfindet, dann kann ich das Datenmodell frei ändern.

Also wenn ich zum Beispiel ein Bankkonto habe, dann kann ich halt den Kontostand abspeichern oder ihn halt on the fly berechnen aus den einzelnen Überweisungen.

Das würde bedeuten, dass hier sich die Instanz-Variablen ändern.

Die öffentlichen Methoden bleiben halt so, wie sie sind.

Das heißt, ich kann diese Änderung machen, ohne dass andere Module davon beeinflusst sind, wenn sie eben nur die öffentlichen Methoden benutzen und nicht etwa die Instanz-Variablen.

Und darüber bekomme ich genau diese Freiheit in der Änderung.

Und das ist etwas, was jetzt bedeutet, dass ich das einfach tun kann, ohne dass ich mit anderen Leuten darüber sprechen muss.

Und das gilt auch für grobgranulare Module, sowas wie Microservices.

Da habe ich dann irgendwie die Datenbank, in der die Daten gespeichert sind.

Ich habe eine Schnittstelle und ich kann dasselbe Beispiel verwenden, wenn ich zum Beispiel einen Microservice habe, der dafür verantwortlich ist, Bankkonten zu verwalten.

Dann kann dieser Microservice entweder in der Datenbank den Kontostand aller Bankkonten haben oder den Kontostand ad hoc berechnen aus Überweisungen.

Selbe Idee hier nur irgendwie grobgranularer.

Und das führt zu dieser allgemeinen Idee, dass ich hier mein Modul habe, das intern ein Datenmodell hat mit irgendwelchen Daten.

Und draußen habe ich halt irgendwie eine Schnittstelle.

Und darüber komme ich eben dazu, dass ich jetzt irgendwie das System modularisieren kann und mit weniger Kommunikationsaufwand eben weiterentwickeln kann.

Und das ist etwas, was ich schon vor längerer Zeit im Stream irgendwie mal diskutiert habe.

Und wo es eben eine Episode gibt, genau über dieses Thema mit der Modularisierung.

Mittlerweile fast fünf Jahre alt, die Episode.

So jetzt ist halt die Frage, welche Art von Änderungen interessiert uns eigentlich?

Wo wollen wir da irgendwie hin?

Und ich würde behaupten, eine gute Domänenarchitektur sollte Änderungen an der Geschäftslogik ermöglichen.

Das ist eigentlich das, worauf wir insbesondere optimieren.

Denn die Geschäftslogik und die Features sind der primäre Wert, den unsere Software für irgendwelche Kundinnen und Benutzer und andere Stakeholder repräsentiert.

Und ich könnte jetzt sagen, ich habe ein Team, ein Team hat eine Domäne und damit einen Teil von dem Code.

Und das ist das, was, glaube ich, immer noch sehr viele Menschen als naiven, optimalen Ansatz für Softwarearchitektur sehen.

Und das ist gar nicht so abwegig, weil was ich dann halt erreiche, ist, dass ich zum Beispiel eine Domäne habe.

Also zum Beispiel das Bearbeiten von Bestellungen.

Da habe ich dann ein Team, was für diese Domäne zuständig ist.

Die haben einen Teil des Codes und die können darüber jetzt letztendlich, wenn irgendetwas geändert werden muss, eben genau diesen Teil Code ändern.

Dafür sind sie zuständig.

Das heißt, eine Änderung geht jetzt genau an dieses eine Team und beeinflusst diesen einen Teil des Codes.

Und dadurch kriege ich halt relativ leicht änderbare Software.

Hört sich also irgendwie logisch an.

Meiner Ansicht nach ist das naiv.

Das ist genau der Grund, weswegen ich hier nochmal über Team Topologies reden möchte.

Und hat aber erstmal was für sich.

Und auch da habe ich im Stream schon ein paar Sachen darüber erzählt.

Vor allem eben diese Episode zum Thema fachliche Architektur, auch mittlerweile gute fünf Jahre alt.

Die also dann genau sich um dieses Thema kümmert.

Die Episode 4 ist das sogar, eine von den sehr frühen Episoden.

Und da schimmert schon so ein bisschen dieses Gesetz von Conway durch, was halt sagt, die Architektur kopiert die Kommunikationsstrukturen der Organisation.

Also ich habe hier ein Team.

Das ist wahrscheinlich etwas, was intensiver miteinander redet und deswegen eben so auf dieser Ebene von Kommunikationsstrukturen existiert.

Und darüber, das ist gleichzeitig ein Teil meiner Architektur.

Also ich habe ein Team, was sich jetzt um den Bestellprozess kümmert.

Und damit werde ich wahrscheinlich auch einen Teil im Code haben, der sich halt um diese Bestellsachen kümmert.

Denn die Architektur wird halt diese Kommunikationsbeziehungen kopieren.

Und die Kommunikationsbeziehungen sind eben so, dass ich wahrscheinlich Menschen habe, die enger miteinander kommunizieren, die für den Bestellprozess zuständig sind.

Die werden also dann wahrscheinlich sich in der Architektur sozusagen niederschlagen.

Und das ist genau das, was dieses Inverse-Conway-Manöver sagt.

Ich setze also ein Team auf.

Dem gebe ich halt irgendeine Aufgabe, also zum Beispiel den Bestellprozess.

Und dann kommt halt ein Teil des Codes raus.

Und darüber habe ich jetzt eben mein System sozusagen aufgeteilt.

Da gibt es jetzt verschiedene Themen.

Eines der Themen ist, dass das ein bisschen eine Fehlinterpretation von Conway ist.

So kann man argumentieren, weil Conway eben Dinge beschreibt.

Also der sagt, es gibt diesen Zusammenhang.

Der sagt nicht unbedingt, dass man das sozusagen so konstruktiv benutzen muss.

Aber sei es drum.

Und es ist etwas, was man, also diesen Ansatz, dass man jetzt ein fachliches Team hat, dass darüber die Architektur determiniert ist.

Das ist eine Geschichte, die jetzt mittlerweile durch diese ganzen Microservices-Geschichten seit, ich glaube, zehn Jahren ein bisschen Standard ist.

Und damit ist das also eigentlich ein Ansatz, der jetzt erstmal grundsätzlich, glaube ich, eine gute Idee ist.

Und der sich erstmal sinnvoll anhört.

Ist aber irgendwie immer noch naiv.

Und jetzt kommt irgendwie Team Topologies und sagt, ja, also warum überhaupt Team Topologies?

Was sagt das eigentlich?

Also irgendwie müssen Teams halt miteinander kollaborieren.

Und Team Topologies hat jetzt dort einen Ansatz, der, glaube ich, nicht so wahnsinnig kompliziert ist.

In dem Sinne, dass halt die Anzahl der Patterns nicht so wahnsinnig groß ist.

Das ist eine subjektive Aussage.

Also das ist zum einen so, dass unterschiedliche Menschen das unterschiedlich komplex wahrnehmen können.

Und das andere ist, ich weiß gar nicht, ob die Anzahl der Patterns halt das Problem ist.

Das Problem ist, glaube ich, die Umsetzung in erster Linie.

Deswegen sind wir die Frage, ob diese Kategorisierung von Komplexität als etwas, wo es halt nicht viele Patterns gibt, ob das halt sozusagen ausreichend ist.

Und ich würde behaupten, dass es halt für mich zumindest auch intuitiv, aber da können halt Menschen auch unterschiedlich sein.

Es gibt dort mehr Fracture Planes als nur die Domänen.

Also das, was wir jetzt sehr implizit ja gesagt haben, ist, das fachliche Modell ist das zentrale Modell.

Danach teilen wir unsere Teams auf und Team Topologies sagt jetzt, nein, wir haben andere Fracture Planes, andere Möglichkeiten, Teams aufzuteilen.

Und das ist, glaube ich, erstmal spannend.

Und es hat eben mehr Teams als nur Entwicklungsteams.

Das heißt, es ist auf der einen Seite immer noch relativ einfach, auf der anderen Seite aber eben mächtiger.

Teamtypen

Das heißt also, dass es so ist, dass wir dort zum Beispiel Streamline Teams haben.

Streamline Teams sind Teams, die einen wertvollen Strom von Arbeit vollrichten.

Also letztendlich sollten die eben dazu in der Lage sein, irgendein Stück Software zu ändern von der Analyse, bis es halt in Produktion geht.

Dann gibt es diese Enabling Teams, die irgendwie rumlaufen und halt den Streamline Teams helfen mit irgendwelchem Fachwissen und die dort irgendwie befähigen.

Dann gibt es Plattform Teams, die eine wertvolle Plattform zur Verfügung stellen und sie dadurch halt unterstützen.

Und die Complicated Subsystem Teams, das sind Teams, die jetzt vielleicht irgendwelche komplizierten Algorithmen oder andere Dinge, die halt irgendwie kompliziert sind, irgendwie abbilden.

Und hier ist jetzt eine Maßgabe, dass eben diese Streamline Teams so einen Änderungsstrom verantworten.

Nicht unbedingt, wie wir jetzt gesehen haben, für sowas wie einen Bestellprozess, sondern das kann auch anders aufgeteilt sein, zum Beispiel nach Technologie oder sowas.

Und wenn ich das jetzt denen sozusagen gebe, wenn ich denen also sage, ihr seid jetzt verantwortlich dafür, diesen Änderungsstrom vollständig abzudecken, das ist halt super kompliziert.

Die müssen Architektur-Know-how haben, die müssen Wissen haben darüber, wie Infrastruktur funktioniert, und so weiter und so weiter.

Und das kann eigentlich nicht funktionieren.

Deswegen gibt es eben genau diese Enabling Teams, die die halt unterstützen.

Die Plattform Teams, die eine Plattform anbieten und darüber halt etwas lösen.

Und die Complicated Subsystem Teams, die halt dabei helfen, irgendwelche komplexen Algorithmen da sozusagen reinzubekommen.

Interaktionsmuster

So und da gibt es jetzt irgendwie verschiedene Arten von Interaktionen.

Eine Interaktion ist Access to Service.

Access to Service bedeutet, ich habe eine Schnittstelle.

Und das ist eigentlich das, was wir gerade eben diskutiert haben bei Partners in Information Hiding.

Wir haben also eine Schnittstelle und dahinter ist irgendwie der Rest versteckt.

Das heißt, ich habe hier ein Complicated Subsystem Team, die bieten eine Schnittstelle an, tatsächlich im Sinne einer programmatischen Schnittstelle.

Und dahinter ist eben diese Komplexität von diesem Complicated Subsystem Team versteckt.

Dann gibt es das Plattform Team, das Access to Service auch machen kann, wo ich also jetzt vielleicht auch eine Schnittstelle habe im Sinne einer Programmierschnittstelle, aber vielleicht auch eine Benutzerschnittstelle.

Die ist mir jetzt ermöglicht, weiß ich nicht, zum Beispiel Kubernetes Cluster oder sowas irgendwie aufzusetzen.

Eine Enabling Team kann keine Schnittstelle anbieten, die sollen halt Leute enablen.

Das heißt, die können sowas machen wie Facilitating.

Die laufen also jetzt rum und unterstützen die Teams in irgendeiner Art und Weise und versuchen herauszufinden, welche Skills da sozusagen passen.

Und Collaboration wäre eine andere Möglichkeit, wo also dann tatsächlich eine Person aus diesem Enabling Team rübergeht in ein Stream Align Team und mit denen zusammen Dinge sozusagen löst.

Genau, Tasklog hat ein paar Fragen gestellt.

Ich befürchte, ich sehe nicht so ganz, wie die sozusagen im Stream reinpassen.

Müssen wir am Ende mal schauen.

Vielleicht beantworte ich die da dann nochmal.

Ich würde jetzt gerne noch ein Beispiel machen für dieses Team Topologies Thema.

Also ich könnte jetzt irgendwelche Stream Align Teams haben.

Also zum Beispiel ein Stream Align Team, was sich halt um Rechnungsstellungen kümmert.

Also wäre das halt verantwortlich dafür, also das sind verschiedene fachliche Domäne.

Das heißt, ich benutze im Prinzip dasselbe immer noch als Maßgabe, wie auch bei diesem Inverse-Combo-Manöver.

Jetzt kommt halt das Complicated System Team und da habe ich zum Beispiel so eine Delivery Optimization, also etwas, wo ich sage, wenn wir das anders ausliefern, dann schaffen wir es, Geld zu sparen oder da irgendwie effizienter zu sein.

Und dann ist es eben so, dass diese Delivery Optimization zum Beispiel eine Schnittstelle anbieten wird.

Also die werden ein Modul haben, dem schmeiße ich vor die Füße, was ausgeliefert werden soll und das sagt jetzt, wie es ausgeliefert wird.

Und da hätte ich jetzt eben tatsächlich eine programmatische Schnittstelle.

So, dann gibt es ein Plattform-Team, das zum Beispiel Kubernetes und CI anwendet.

Das hat jetzt also dementsprechend auch eine Schnittstelle, vielleicht eher eine Benutzerschnittstelle und das Architektur-Team, das läuft jetzt irgendwie rum und unterstützt die Stream Align Teams mit ihrem Wissen, indem sie also rumlaufen und schauen, welche zusätzlichen Architekturskills eigentlich notwendig sind und die irgendwie in die Teams reinbringt und eben Collaboration, also vielleicht irgendwie Leute auch Ausleit dahin.

So und Tasa hat gerade gefragt, also entsteht jetzt aus jedem Team eine Schnittstelle?

Nein, weil es Teams gibt, die sozusagen nicht Software produzieren.

Also dieses Team hier, das Architektur-Team produziert nicht Software, sondern hat irgendwie Wissen, was es halt in die anderen Teams reinbringen will.

Das kann ich nicht über eine programmatische Schnittstelle lösen.

Das ist genau einer der Punkte, wo sich das jetzt von diesem Inverse Combi-Manöver unterscheidet, das eben eigentlich nur in Richtung geht, dass es sozusagen Teams betrachtet, die halt direkt an der Arbeit beteiligt sind, um das Projekt sozusagen oder die Software direkt zu bauen und nicht solche unterstützenden Teams, Enabling Teams für irgendwie ein Architektur-Team beispielsweise.

Dazu hatte ich halt irgendwie auch eine Episode gemacht, mittlerweile auch schon wieder ein Jahr her.

Und das ist eben dann genau dort, habe ich das nämlich noch weiter diskutiert.

Und ich will hier auf jeden Fall noch mal eine Warnung loswerden.

Also Team Topologies definiert eben Magneten.

Das heißt, was wir jetzt hier haben, sind sozusagen Richtungen, in die sich Teams bewegen sollten, wo die also hingehen sollten.

Aber es bedeutet nicht, dass ich einfach nur das umsetze, was halt zu der Frage führt, wie viele Organisationen das denn exakt so vollständig und dem Buch entsprechend umgesetzt haben.

Wahrscheinlich wenige oder keine.

Aber ich weiß halt auch nicht, ob das relevant ist.

Wir werden halt irgendeine Organisation haben, die halt irgendwie Software entwickelt.

Sonst können wir keine Software entwickeln.

Und jetzt ist halt nur die Frage, wie werden wir dort besser?

Und da kann uns Team Topologies halt helfen, indem es eben sagt, das ist ein Konzept, wie wir glauben, wie es sozusagen besser werden kann.

Und was ich bei Team Topologies halt auch schön finde, ist, dass wir tatsächlich dort die Möglichkeit haben, oder dass dort irgendwie auch informelle Beziehungen zwischen Menschen wahrgenommen wird, dass es die halt erstmal gibt.

Bin mir nicht so sicher, ob daraus so viel konstruktive Sachen abgeleitet werden, aber die werden zumindest diskutiert.

Und ich selber hatte dazu ja auch eine Episode gemacht, wo ich gesagt habe, wir können halt Softwareentwicklung verbessern, wenn wir den menschlichen Faktor verbessern, was also irgendwie eher so ein softes Ding ist.

Also Team Topologies hat immer noch etwas, was sehr stark so in Richtung von Organigramm und formaler Aufteilung der Teams ausgeht.

Wir müssen halt auch diese softe Seite, wie Menschen miteinander umgehen, uns um die eigentlich kümmern.

Und das ist etwas, was eben ich in dem Talk dort diskutiere und wo ich auch gerade mit dem Kunden ein Konzept entwickle, wie man dort für den Kunden halt sozusagen besser werden kann, also wie man dafür sorgen kann, dass eben dort die Menschen besser kommunizieren und besser halt arbeiten durch eine systematische Ausbildung an der Stelle.

Jetzt ist halt die Frage, was ist denn eigentlich jetzt die Beziehung zwischen Softwarearchitektur und Team Topologies?

Also wir haben auf der einen Seite ein Konzept Team Topologies, was über Organisation spricht.

Wir haben auf der anderen Seite ein Konzept, was eigentlich ja über Softwareorganisation spricht und das scheinen zwei unterschiedliche Dinge zu sein.

Ja, das ist eben genau die Frage.

Also es geht eigentlich in beiden Bereichen um Kommunikation.

Das heißt also Team Topologies sagt, wie wir kommunizieren, wie wir miteinander kollaborieren, hat diese drei unterschiedlichen Mechanismen von Kollaboration.

Softwarearchitektur versucht auch, das Bedürfnis für Kommunikation zu reduzieren und Team Topologies hat dieses Ex-as-a-Service, wo also ein Team eine Schnittstelle anbietet, entweder eine Schnittstelle als eine Software-Schnittstelle oder eben als eine Schnittstelle als Benutzerschnittstelle, also nicht programmatisch oder Benutzerschnittstelle, hat also darüber eigentlich diese Idee von Softwarearchitektur mit drin.

Aber es ist eine Obermenge.

Also es ist eben so, dass da noch mehr drin ist, weil eben nicht nur gesagt wird, Teams haben eben eine Schnittstelle, sondern ich kann eben dort mehr haben.

Ich kann also dort eben auch sowas wie Facilitation oder so haben.

Und das ist ja genau das, was das Task-Log vorhin auch irgendwie fragte.

Also ob eben dadurch Teams nicht nur Schnittstellen liefern können, sie können eben auch Facilitäten und da halt sozusagen andere Sachen machen.

So jetzt schreibt, da ist eine anonyme Frage gekommen im Formular und da liegt die Naivität, Einfachheit, Einfachgestricktheit vom fachlichen Team nun darin, dass das Team sich um zu viele Dinge eben wie Plattformen kümmern muss.

So würde ich es nicht formulieren.

Die Frage ist eine gute, weil das habe ich tatsächlich nicht tief diskutiert.

Ich finde das Modell mit Inbus Conway deswegen naiv und komisch, weil wir da draußen Teams haben, wie zum Beispiel ein Plattform-Team, das eine Plattform anbietet.

Und das wissen wir glaube ich alle.

Und Inbus Conway sagt halt darüber nichts aus.

Und das finde ich halt an der Stelle problematisch.

Das bedeutet nämlich, dass das, was wir da draußen haben, Plattform-Teams sind etwas, was da draußen existiert, dass das eben durch Inbus Conway irgendwie ignoriert wird.

Und der andere Punkt ist halt, auch darüber habe ich eine Episode gemacht, ich verlinke dir auch noch mal, das ist diese Geschichte, wo ich über Architektur und Organisation in der Praxis spreche.

Es gibt Gründe, warum mehr als ein Team an einer Fachlichkeit arbeiten muss, vielleicht, weil es zum Beispiel Termindruck gibt.

Inbus Conway sagt, eine Fachlichkeit, ein Team.

Und das finde ich halt irgendwie auch naiv.

So, dann bestätige ich weiter.

Oder gibt es weitere Gründe, was so ein Team naiv macht?

Also das ist nicht das Team, was naiv ist, sondern es ist sozusagen als Werkzeug naiv.

Ich glaube, dass wir halt in Wirklichkeit viel mehr und viel kompliziertere Sachen dort haben.

Und dass in der Realität es eben nicht so ist, dass man einfach sagt, eine Fachlichkeit, ein Team, dann hat sich das.

Wie ich schon sagte, es gibt eben Teams, die keine Fachlichkeit haben.

Manchmal wird eine Fachlichkeit auf mehrere Teams verteilt.

Und das ändert sich auch noch über die Zeit, weil ich eben Fachlichkeiten habe, die halt über die Zeit wichtiger oder weniger wichtig werden.

Und da muss ich halt mehr oder weniger Menschen da sozusagen dran setzen.

Dann schreibt der oder die Fragesteller in weiter zum Beispiel klassische Organisationen, die nicht kostenfunktional sind.

Das ist auch, das ist noch ein anderer Aspekt.

Und das ist einer von den Aspekten, die ich bei Team Topologies, sagen wir, zumindest mal interessant finde.

Da ist die Aussage, dass ein Team einen Änderungsstrom verantworten muss.

Und ich kann Teams haben, also ein Stream Aligned Team, deswegen heißt es Stream Aligned, das sollte irgendwie einen Änderungsstrom verantworten.

Und es kann jetzt zum Beispiel ein UI Team geben, was die UI verantwortet.

Und das ist nicht kostenfunktional, sondern das hat jetzt eben eine Technologie oder irgendwie sowas in dem Dreh und arbeitet jetzt daran.

Und was jetzt Team Topologies sagt, ist, das ist okay.

Und ich sehe da draußen auch, dass solche Teams irgendwie aufgebaut werden.

Man kann jetzt darüber diskutieren, ob das eine gute oder eine schlechte Idee ist.

Also es kann eine schlechte Idee sein, weil dann wird eine Fachlichkeit vielleicht über mehrere Teams verteilt.

Und ich gehöre mit zu den Menschen, die halt irgendwie sagen würden, ich will eher Teams haben, die Fachlichkeiten autonom umsetzen können.

Aber es gibt diese Ansätze.

Sie funktionieren auch im Wesentlichen.

Und da ist eben Team Topologies wieder im Vorteil, nach meinem Empfinden, weil es eben das auch abdeckt.

Also es sagt halt, okay, wir können Teams haben, die zum Beispiel eine UI umsetzen.

Und wir müssen nicht nur Teams haben, die eben etwas Fachliches umsetzen.

Genau, ich hoffe, das erklärt es.

Und ansonsten vielen Dank für die Frage.

Dann können wir mal weitermachen.

Achso, genau.

Das heißt, also das, worauf ich jetzt hinaus wollte, war, dass Team Topologies sozusagen anfängt und sagt, okay, es gibt irgendwie Teams.

Softwarearchitektur fängt an und sagt, okay, es gibt irgendwie Module.

Und in einem Modul habe ich halt ein Datenmodell und nach draußen eine Schnittstelle.

Und Team Topologies sagt, naja, das Team hat ein XSS-Service.

Und für den Fall habe ich jetzt hier sozusagen dasselbe.

Also ich würde sagen, okay, die Schnittstelle bedeutet XSS-Service.

Das Ding hier wird von diesem Team irgendwie bearbeitet.

Das ist etwas, was ich ausliefern kann.

Und das ist sozusagen fast dasselbe.

Oder es ist ein sehr ähnlicher Ansatz.

So, und da nehmen wir, und das bei der Softwarearchitektur, ein Modul.

Das heißt also, wir haben jetzt in beiden Fällen so etwas, wo wir halt Systeme in Module oder Teams aufteilen.

Und das, so sagt ja auch Conway, ist halt nahezu dasselbe Thema.

Softwarearchitektur sagt, also wir haben diese Module.

Team Topologies sagt jetzt, es gibt Streamline-Teams, die also tatsächlich einen Änderungsschrumpf antworten, Enabling-Teams, Platform-Teams und Complicated-Subsystem-Teams.

Und das führt dazu, dass wir jetzt tatsächlich hier einen Ansatz haben bei Team Topologies, der halt bei der Aufteilung des Systems, ja, wie soll ich sagen, ein bisschen breiter ist.

Also Architektur sagt halt im Wesentlichen, wir teilen das System nach Domänen auf.

Stimmt nicht ganz.

Es gibt ja auch Ansätze, wie zum Beispiel hexagonale Architektur, die irgendwie sagen, dass man Systeme nach bestimmten technischen Maßstäben aufteilt.

Also nicht, dass ich jetzt sage, es gibt irgendwie so einen Persistenz-Adapter oder sowas und irgendwie den Geschäftslogik-Kern.

Aber häufig sind irgendwie die Domänen, dass wir darauf ja halt den Fokus legen.

Team Topologies impliziert, dass es hier Module mit unterschiedlicher Funktionalität gibt, weil es ja Teams mit unterschiedlichen Ansätzen gibt, zum Beispiel am Platform-Team.

Und sowas wie ein Complicated-Subsystem, also das Ding, was zum Beispiel die Lieferoptimierung berechnet, das ist sicherlich ein eigenes Modul.

Ein Platform-Team wird auch vermutlich ein eigenes Modul anbieten, irgendein Kubernetes oder was auch immer Ding, was das halt irgendwie hübsch macht und besser benutzbar macht.

Das heißt, die produzieren Software und ein Enabling-Team produziert irgendwie vielleicht nur Wissen und Unterstützung, vielleicht keine Module.

Aber ich kriege hier jetzt also letztendlich die Aussage, Teams, die halt technische Dinge umsetzen, wie zum Beispiel am Platform-Team, solche Teams werden dort auch betrachtet.

Und Teams, die halt nur in Anführungsstrichen Algorithmus umsetzen, wie Complicated-Subsystem-Teams, auch die sind denkbar und werden hier sozusagen mit betrachtet.

Dennoch fokussiert Team Topologies auf die Stream-Aligned-Teams, also diese Änderungsströme.

Das ist der Teamtyp, von dem es am meisten geben soll.

Das ist genau so ein Strom vom Erheben der Requirements bis in Produktion.

Und das ist halt der ganze Punkt von diesen Stream-Aligned-Teams, dass die eben so einen Änderungsstrom verantworten.

Und das ist das, wo sie sagen, hier gehe ich keine Kompromisse ein.

Das heißt also, das war ja auch vorhin die Frage, muss ich jetzt cross-funktionale Teams haben?

Nee, muss ich nicht.

Die müssen halt nur ein Stück Software in Produktion bringen können.

Also wäre zum Beispiel ein UI-Team etwas, was in Team Topologies denkbar ist.

Das führt jetzt irgendwie zu so einem Problem, weil das ja bedeutet, dass ich in eine andere Richtung optimiere.

Ich optimiere jetzt nicht in die Richtung von kann eine Fachlichkeit unabhängig von einem anderen umsetzen, sondern ich optimiere in eine Richtung von kann irgendwas in Produktion bringen und verantwortet einen vollständigen Änderungsstrom.

Warum dieser Fokus auf diese Ströme?

Weil ich darüber Feedback bekomme von den BenutzerInnen.

Direktes Feedback und kann irgendwie so ein Product-Market-Fit hinbekommen.

Das heißt also, ich bin dafür verantwortlich, die Sachen in Produktion zu bekommen.

In Produktion bekomme ich Feedback von den Menschen, die es benutzen.

Das kann ich nutzen, um dafür zu sorgen, dass meine Software, mein System besser wird.

Und ich bekomme auch Feedback von Tests, von Produktion und von den verschiedenen Staging-Umgebungen.

Dadurch bekomme ich bessere Produktivität.

Das ist etwas, wo es diese berühmten DORA-Studien gibt, über die ich auch eine Episode gemacht habe, die also sagen, wenn ein Team dazu in der Lage ist, so einen Strom möglichst vollständig zu verwalten, dann wird es bessere Produktivität hinbekommen.

Der Grund dafür ist, wenn das Team konstant neue Features in Produktion bringt, dann weiß das Team, wo die Bottlenecks sind.

Vielleicht ist Testing nicht optimal.

Das heißt, ich sollte Testing automatisieren.

Dann ist Testing weg automatisiert und verbessert.

Dann komme ich als Nächstes darauf, dass ich aus Monitoring in Produktion nicht genügend Informationen bekomme.

Dann kann ich das Monitoring verbessern und so weiter.

Das heißt, ich komme in einen Feedback-Zyklus, wo ich aus den verschiedenen Stages Feedback bekomme, das weg optimieren kann.

Dadurch verbessere ich tatsächlich den Software-Entwicklungsprozess.

So wie eine Firma, die zum Beispiel Autos produziert, sich auch dann automatisch optimiert, wenn man eine Fabrik hat, da irgendwie Eisenerz reinkippt und vorne kommen die Autos raus.

Dafür sorgt das, dass das konstant im Fluss ist und konstant das da sozusagen durchläuft.

Ich stehe vielleicht an der Produktionsstraße.

Ich baue an dauernden Türen ein.

Ich habe wenig Türen auf Lager.

Das führt jetzt dazu, dass wenn die Produktion von Türen ein Problem ist, dann steht die Straße und ich werde das optimieren müssen.

Wenn ich merke, dass mit den Türen etwas nicht stimmt, dann kann ich die Produktion anhalten und sagen, wir haben ein Problem.

Dann werde ich das weg optimieren.

Hier ist es ähnlich.

Dadurch, dass ich die komplette Pipeline unter Kontrolle habe, kann ich Probleme, die ich möglicherweise habe, versuchen, weg zu optimieren.

Tatsächlich bekomme ich dadurch auch weniger Burnout.

Tatsächlich ist es eben auch so, dass diese Idee, konstant Softwareproduktion zu bekommen, sehr gut reproduzierbar ist.

Techniker sagen zumindest, dass das die Art und Weise ist, wie sie Software entwickeln wollen.

Umgekehrt bedeutet, wenn man seine Arbeit hassen will und Burnouts produzieren will, dann sollte man nicht Continuous Delivery machen.

Also das Vorgehen nicht konstant in der Produktion bringen.

Das ist genau das, was ich in dieser Episode über DevOps-Studie, auch eine von den sehr frühen Episoden, bereits gesagt habe.

Das heißt also, dieser Fokus auf den Änderungsstrom ist insofern nachvollziehbar.

Der Punkt, den ich jetzt schon angesprochen habe, ist ein bisschen indirekt.

Das sind diese Fracture Planes.

Fracture Planes

Teams werden also nach Fracture Planes Bruchflächen aufgeteilt.

Aufteilungskriterien

Das kann die Domäne sein.

Dann hätte ich tatsächlich das, was ich vorhin sagte.

Also ich habe ein Team, das verantwortlich ist für Rechnungsstellungen.

Ein anderes Team, das verantwortlich ist für Lieferungen oder was auch immer.

Ich kann auch so etwas haben wie regulatorische Compliance.

Also es gibt ja zum Beispiel PCI DSS.

Das ist der Standard, wie ich Kreditkarteninformationen speichern muss.

Ich habe dann vielleicht ein Team, was sich exakt damit auskennt und darum kümmert.

So etwas wie Änderungshäufigkeit.

Etwas, was ich selber ein bisschen problematisch finde, weil ich es immer schwer finde vorherzusehen, wo Änderungen häufiger sind und wo Änderungen weniger häufig sind.

So etwas wie Team-Lokationen, wo also Teams sind.

Kann so eine Bruchfläche sein, wenn man also tatsächlich Menschen hat, die sich im Büro treffen.

Dann ist es vielleicht gut, wenn ein Team in einem Büro sitzt.

Und wenn ich jetzt verschiedene Standorte habe, dann will ich eben vielleicht für die verschiedenen Standorte verschiedene Teams haben und es darüber aufteilen.

Oder Risiko, zum Beispiel so etwas wie Kundinnen halten oder neue Kunden gewinnen.

Und das ist halt tatsächlich etwas sehr Spannendes, weil das sind ja Dinge, wo fachlich nicht klar ist, wann ein Feature sozusagen in die eine oder andere Kategorie gehört.

Also ich würde behaupten, Features, die halt dazu führen, dass neue Kunden das attraktiv finden, sind vielleicht auch Features, die Bestandskunden gut finden.

Da ist ja nicht so klar, wie die jetzt unterschiedliche Teile der Software ändern können.

Aber ein Team kann ja tatsächlich eine Story, die hat dazu geführt, dass eben die Software für Bestandskunden zum Beispiel attraktiver wird, durchführen und in Produktion geben.

Also kann es für ein Streamline Team dafür geben.

Performance, unterschiedliche Performance oder eben so etwas wie auch Technologie.

Also ich könnte jetzt sagen, ich habe die JavaScript-Entwicklung, die jetzt zum Beispiel im JavaScript können.

Und es gibt dann mit den Stream-Aligned Teams umgesetzt werden.

Ja, aber warum?

Also die Idee von Complicated Subsystem Teams ist gerade oder von Complicated Subsystems ist gerade dafür zu sorgen, dass das Stream-Aligned Team entlastet wird, weniger zu tun hat.

Deswegen sollte es das eben nicht selber umsetzen.

Man kann natürlich sozusagen zumindest für einige Zeit diese beiden Teams erst mal zusammenlegen und dann sozusagen daraus später dann ein eigenes Complicated Subsystem Team entwickeln.

Also ich könnte jetzt in diesem Beispiel, wo ich diesen Delivery-Algorithmus habe, kann ich erst mal dafür sorgen, dass ich halt in dem Delivery-Team, in dem Stream-Aligned Team mehr die ersten Überlegungen dazu mache und dann das Team sozusagen da irgendwie rauslöse.

Vorteile zum Beispiel kein separater Betrieb.

Subsystems kommt dorthin, wo das Domain-Wiss vorhanden ist.

Es gibt sicher Fälle, in denen der Ansatz Complicated Subsystem sinnvoll ist.

Aber sollte es nicht eher selten sein?

Also, ja, die Stream-Aligned Teams sollten die dominierenden Teams sein und das ist auch nachvollziehbar.

Ich würde auch hier behaupten, dass das eigentlich ein Pattern ist, was wir in der Realität halt häufig sowieso sehen.

Also klassisch, was mir sofort einfällt, ist dieses Rechenkern von irgendwelchen Versicherungen, der also jetzt Tarife ausrechnet.

Und das ist genau so was.

Da gibt es also ein kompliziertes Ding mit Versicherungsmathematik.

Und das will ich halt, wenn ich jetzt eine Versicherung abschließen möchte und ich halt dafür verantwortlich bin, dieses abschließend zu implementieren, dann habe ich keinen Bock darauf, das halt vollständig zu verstehen.

Dafür gibt es also das andere Team.

Und da gibt es eine Schnittstelle, wo ich irgendwelche Daten reinwerfe und der gibt mir aus, wie viel Geld ich denn nun das Red kostet und wie viel Geld ich von der Versicherung wiederbekomme.

Das ist halt sozusagen Standardansatz und ich finde den auch sinnvoll.

Von daher würde ich behaupten, dass das etwas ist, was da draußen existiert.

Und Patterns sind ja eigentlich Beschreibungen von Lösungen, die da draußen funktionieren.

Und ich finde, da macht das halt Team Topologies einen guten Job an der Stelle.

Also es ist sofort so, dass einem Beispiele einfallen, wo sowas halt sinnvoll ist mit so einem Complicated Subsystem Team.

Gut, so was bedeutet das jetzt?

Also wenn wir jetzt weitergehen mit diesem Vergleich zwischen Softwarearchitektur und Team Topologies.

Das heißt, wir haben bei Softwarearchitektur klassisch, zumindest typischerweise, diese Aufteilung nach Domänen.

Hier sagen wir jetzt, wir haben andere Fracture Planes, also zum Beispiel auch die Location.

Ich habe vielleicht ein Team in Kaiserslautern, ich habe eins in Hamburg.

Die sitzen jeweils in irgendwelchen Offices und arbeiten dort.

Und ich kann dann möglicherweise eine gemeinsame Verantwortung für irgendwelchen Code haben oder für eine Domäne.

Also wenn ich ein UI-Team habe, dann wird dieses UI-Team auch bestimmte Teile der Domäne, nämlich den UI-Anteil einer Domäne umsetzen und nicht das Backend-Team wird irgendwie den Backend-Teil der Domäne umsetzen.

Das heißt also, da habe ich eine gemeinsame Verantwortung für eine Domäne und vielleicht auch für Code.

Wenn ich jetzt zum Beispiel sage, ich habe Bestandskunden und Neukunden und wir die halt beide beackern von zwei unterschiedlichen Teams, dann werden die vielleicht einen gemeinsamen Code auch tatsächlich ändern müssen.

Da ist jetzt noch eine Frage über das Formular reingekommen.

Und die Frage ist, wie ist deine Ansicht zu Context Switch in den jeweiligen Teams?

Wäre es sinnvoll, auf eine feste oder einige bevorzugte Domänen zu achten?

Oder sollte es in der Regel unterschiedliche Domänen bearbeiten können?

Also eigentlich ist das so eine typische Frage, die ich mit Depends beantworten wollen würde.

Es ist ja nicht umsonst so, dass diese Idee von diesem Inverse Convey und diese sehr starke Fokussierung auf cross-funktionale Teams und Teams, die halt eine fachliche Verantwortung haben, das ist ja nicht umsonst so, dass wir das haben als einen Ansatz.

Das wäre jetzt glaube ich falsch zu sagen, Team Topologies kommt jetzt und sagt, das ist Unsinn.

Team Topologies sagt nur, es gibt Alternativen, die da draußen in der Praxis ja auch genutzt werden, aus irgendwelchen Gründen.

Vielleicht ist es eben gut, wenn ich ein UI-Team habe.

Das ist ja vom Fall abhängig.

Und es sind am Ende eben Menschen.

Das heißt, wenn Menschen besonders gut zusammenarbeiten, weil sie zum Beispiel in einer Location sitzen, dann will ich vielleicht das als Team als Ansatz für das Aufbauen des Teams mit betrachten.

Und das ist zumindest meine Interpretation, was also nicht bedeutet, dass man jetzt auf jeden Fall Context Switches haben muss und dass die Teams auf jeden Fall unterschiedliche Domänen bearbeiten sollen, sondern ich sehe das halt eher so, dass sozusagen gesagt wird, naja, das passiert ja in der Praxis.

Also sollten wir vielleicht auch mal in den Patterns sagen, dass das eben passiert und das irgendwie auch abbilden können.

Das wäre halt mein Eindruck dazu.

Und hier ist auch gleich das Beispiel, was dazu passt.

Praktische Beispiele

Also ich hätte jetzt vielleicht ein UI-Team, was in Indien sitzt.

Dann habe ich halt irgendwelche Backends in Kaiserslautern und Hamburg.

Und die können jetzt Änderungen deployen.

Das UI-Team in Indien kann eben die UI deployen.

Die können zwei unterschiedliche Backends deployen.

Und ich habe jetzt das nach Lokation aufgeteilt, was eben bedeutet, wenn ich das nicht so machen würde, wenn ich also versuchen würde, cross-funktionale Teams zu bekommen, dann wäre halt dieser Bruch in der Lokation in jedem Team.

Und in diesem Fall würde es irgendwie dafür sorgen, dass wir Schwierigkeiten haben, überhaupt ein Stand-up zu machen, weil wir unterschiedliche Zeitzonen haben und auch deutlich unterschiedliche Zeitzonen.

Und wir haben halt darüber hinaus so ein Problem, dass halt die Teams auf jeden Fall irgendwie alle Englisch sprechen müssen, was vielleicht ja auch nicht so gut ist.

Wenn ich also in Kaiserslautern oder Hamburg Menschen habe, die halt nur Deutsch sprechen und auf Deutsch schnell miteinander reden können.

Und dann ist meine Alternative jetzt, die Teams alle dazu zu zwingen, Englisch und einen Bruch in der Lokation zu haben.

Und das ist die Frage, ob es das wert ist gegenüber dem cross-funktionalen Team.

Und ich glaube, das passt auch zu der Frage, die gerade eben gekommen ist.

Hier ist der Preis für das cross-funktionale Team und für das Team, was eine Domäne bearbeitet, relativ hoch.

Und dann ist irgendwie die Frage, ob ich das wirklich bezahlen möchte.

Was hier irgendwie bedeutet, immer Teams nach Domänen aufzuteilen, ich habe jetzt geschrieben, ist unmöglich.

Also nicht.

Theoretisch kann man das natürlich irgendwie immer tun, aber es wird halt irgendwann sehr teuer und sehr aufwendig.

Und genauso schwierig ist es eben auch, Module immer nach Domänen aufzuteilen.

Es gibt eben auch technische Maßstäbe, nach denen ich etwas aufteile.

Und das muss nicht nur eine Infrastruktur sein, wie jetzt Kubernetes oder so.

Also ein Team, das ein UI-Modul umsetzt, kann also sinnvoll sein.

Vielleicht ist das halt auch so ein Punkt, ich würde immer noch nachfragen und versuchen zu verstehen, warum das jetzt irgendwie umgesetzt wird, weil das eben tatsächlich die Autonomie ein bisschen beschädigt.

Und auf der anderen Seite ist es ja irgendwie so, dass Architektur eben auch nach Schichten oder hexagonal Systeme aufteilt.

Und das machen wir typischerweise nicht auf der Team-Ebene, aber ich muss auf jeden Fall technische Aussagen treffen, wie ich Systeme aufteile.

Und die könnte ich ja jetzt irgendwie auch nehmen, um das nach Teams aufzuteilen.

Cognitive Load

Da gibt es auch das Konzept von Cognitive Load.

Das ist auch so ein Team Topologies Konzept.

Das heißt, wenn ich so einen kompletten Strom verantworte, dann ist das halt aufwendig und schwierig.

Und da ist der Begriff, dass ich zu viel Cognitive Load habe.

Also nehmen mir andere Teams Teile von diesem Cognitive Load ab.

Unterstützung statt Kontrolle

Was halt bedeutet, dass ich unterstützen sollte, nicht kontrollieren.

Team-Autonomie

Also die Idee ist, dass eine Architektur, ein Architektur-Team eben unterstützen sollte.

Ein Enabling-Team ist und keine Architektur-Polizei.

Das heißt also, was nicht passieren sollte, ist, dass das Team sagt, das ist aber nicht architekturkonform.

Und dass sozusagen die Architektur ein purer Selbstzweck ist, sondern was dieses Team jetzt irgendwie machen sollte, ist zu sagen, okay, ich verstehe, ihr wollt irgendwie Software aufteilen und Architektur betreiben.

Was sind denn eure Herausforderungen?

Wie kann ich euch unterstützen?

Und dadurch wird irgendwie klar gesagt, dass halt diese Stream-Aligned-Teams die sind, um die es eigentlich tatsächlich geht.

Und das ist etwas, was in anderen Bereichen sonst oft eben so nicht umgesetzt wird und dadurch irgendwie problematisch ist.

Führt also zu der Frage, was sollten wir denn jetzt tatsächlich anders machen?

Erstmal auch traditionelle Software-Entwicklung, Software-Architektur versucht, das Kommunikationsproblem zu lösen.

Und man kann jetzt die Frage stellen, werde ich das nur mit technischem Ansatz lösen können?

Also nur dadurch, dass ich Module geschickt wähle, kriege ich dadurch eine bessere Kommunikation?

Es wäre überraschend, wenn das so wäre.

Also werde ich wahrscheinlich mehr machen müssen.

Was also bedeutet, dass Software-Entwicklung ein soziotechnisches Thema ist.

Ich habe also die Teams als soziale Komponente.

Ich habe den Modul als technische Komponente und ich muss mir beides anschauen.

Und tatsächlich ist das so eine von den Sachen, wo ich merke, dass meine Wahrnehmung manchmal eine andere ist als die von anderen Menschen.

Also für mich ist eine Schnittstelle immer eine Kommunikation, sozial, Menschen reden über eine Schnittstelle und auch eine Interaktion von Modulen auf der Architekturebene.

Und das ist ja auch das, was letztendlich das Gesetz von Conway sagt.

Was also bedeutet, wenn wir eine Schnittstelle haben, dann bedeutet es, dass wir potenziell mit den Menschen sprechen müssen, die diese Schnittstelle verwenden.

Da kann man natürlich sagen, ja, aber ich habe eine Schnittstelle im Internet, ich spreche mit den Leuten nicht.

Naja, also es wird einen Bug-Tracker geben oder die werden halt anderweitig über Social Media oder so Feedback geben.

Das heißt also, ich habe auch dort eine Kommunikation.

Das ist nicht dieselbe Kommunikation wie bei internen Teams, die halt regelmäßige Stand-Ups und regelmäßige Kollaborationstreffen haben.

Aber ich werde auch bei einer Schnittstelle, die halt scheinbar anonym im Internet ist, Feedback bekommen und darüber eine Kommunikation haben.

Und Information Hiding als der Ansatz, über den klassische Architektur halt zentral spricht, ist nur eine Möglichkeit, um Cognitive Load zu reduzieren.

Und da gibt uns jetzt eben Team Topologies andere Ansätze.

Was so ein bisschen bedeutet, naja, wir müssen jetzt irgendwie eigentlich uns auch um Teams kümmern.

Und da kommt halt häufig diese Geschichte mit.

Aber ich kann ja irgendwie Teams nicht beeinflussen.

Ich bin ja nur Architekt und Architektin.

Und das finde ich halt irgendwie spannend, weil es ist meiner Ansicht nach auf jeden Fall die Pflicht von uns als Architektinnen und TechnikerInnen, Feedback zu geben auf das, was da eben passiert.

Das heißt also, erstmal wäre meine Aussage, ich muss auf jeden Fall nicht, wenn jemand sagt, wir bauen halt folgendermaßen die Teams auf.

Und ich habe halt das Gefühl, das macht aus irgendwelchen Gründen keinen Sinn, weil halt Änderungen an ganz vielen Teams hängen.

Und wenn man das halt ohne Schwierigkeiten so machen könnte, dass ein Team für eine Änderung verantwortlich ist, dann sollte ich halt Feedback geben.

Und das andere, was ich spannend finde, ist, das bedeutet also, ich kann mich jetzt eben hinstellen und kann sagen, das ist ja der Umkehrschluss.

Wir benutzen jetzt folgende Technologie.

Und das ist vielleicht etwas, wo wir glauben, dass wir das tatsächlich auch können.

Und halt sagen können, wir benutzen folgende Technologie, wir benutzen folgenden Architekturansatz.

Aber ich führe da keine Diskussion über irgendwelche Entwickler und mit anderen Architekten.

Und das glaube ich halt irgendwie nicht.

Und das bedeutet, ich habe eigentlich immer kollaborative Entscheidungen.

Und deswegen haben wir ja ganz viele Episoden zum Thema mit der Kommunikation.

Was ich damit meine, ist folgendes.

Wenn ich mich jetzt hinstelle und sage, wir benutzen Spring Boot, Punkt.

Das ist wahrscheinlich nicht besonders schlau.

Es ist irgendwie schlau, darauf zu achten, was die anderen Menschen denn sagen, warum sie vielleicht nicht Spring Boot benutzen wollen.

Sondern vielleicht ergibt sich darüber ja ein sinnvoller Grund.

Da muss ich halt darüber nachdenken.

Und das macht auf jeden Fall Sinn, diese Kommunikation zu haben.

Und das ist bei einer technischen Entscheidung.

Genau genommen ist es sogar so, dass ich technische Entscheidungen eben durchkommunizieren muss.

Und dafür sorgen muss, dass ich auch bei technischen Entscheidungen anderer Leute Gesichtspunkte mit einbeziehe.

Wir wollen dieses JavaScript Framework benutzen.

Was weiß ich, React.

Ja, wir haben aber mehr Erfahrung mit Angular.

Ja, aber React ist vielleicht die bessere Lösung.

Das ist also eine Diskussion.

Und das ist irgendwie schlau, diese Diskussion zu führen und nicht zu sagen, ich entscheide das jetzt mal kurz.

Und da ist so ein bisschen dieses Problem, dass ich nicht verstehe, warum jetzt plötzlich diese technischen Entscheidungen anders sein sollen, als die Entscheidung über irgendwelche Organisationsgeschichten.

Weil da passiert ja dasselbe.

Also irgendjemand sagt, ich entscheide das jetzt mal.

Und im Extremfall sagt halt irgendwie das Team oder die Menschen, die es betrifft, nö, wir ignorieren das halt.

So, dann passiert halt gar nichts.

Das ist genau das, was Architekten auch passieren kann.

Dass sie halt irgendwie irgendwas entscheiden und dann irgendwie feststellen, die haben aber irgendwas anderes gemacht.

Die haben halt mal eine Entscheidung ignoriert oder was auch immer.

Das heißt also, ich habe eigentlich immer gemeinsame Entscheidungen, was ja auch Sinn macht, weil ich verschiedene Aspekte betrachten möchte.

Und wir haben dazu eine Episode gemacht, zu diesem Fairness-Change-Thema, wo man also strukturiert jetzt mit informellen Mechanismen dafür sorgen kann, dass man Entscheidungen in eine bestimmte Richtung bringt.

Also was das bedeutet, ist Folgendes.

Ich bin Architektin.

Darf ich offiziell die Organisation der Teams definieren?

Nein, darf ich nicht.

Habe ich die Möglichkeit, das zu beeinflussen?

Ja, weil ich kann mit den Menschen reden und kann durch so etwas wie Fairness-Change habe ich eben die Möglichkeit, sogar das strukturiert zu tun und mir halt verschiedene Ansätze, verschiedene Ideen anzuschauen, wie ich das eben tatsächlich umsetzen kann.

Bedeutet halt, dass so etwas wie das Aufsetzen von Teams etwas ist, was die Entwicklung, Management und Architekten sich kümmern.

Und das führt irgendwie genau zu dieser Aussage meiner Ansicht nach, dass irgendwie eine Domäne, ein Team wahrscheinlich nicht wirklich möglich ist, weil wenn ich zum Beispiel einen Änderungsschwerpunkt habe, also nicht, wir müssen jetzt aber, weiß ich nicht, das neue Liefersystem implementieren, dann schicke ich vielleicht mehrere Teams auf irgendwie dieses Thema und irgendwann tue ich das halt nicht mehr.

Und dann ist eine Domäne etwas, was halt mehrere Teams verantworten und irgendwann hört das auch wieder auf.

Aber ich kann jetzt nämlich schlecht sagen, aufgrund von meiner überlegenen Architektur darf nur ein Team an dieser Sache halt arbeiten.

Und wenn das bedeutet, dass wir die Deadlines nicht schaffen, dann ist das eben so.

Das ist meiner Ansicht nach offensichtlich kein guter Ansatz.

Also werde ich andere Aspekte, wie zum Beispiel Deadlines oder so, damit auch mit beachten müssen.

Und da ist es wieder hilfreich, wenn halt andere Menschen genau diese Aspekte halt sich angucken.

Aber natürlich habe ich irgendwie die Möglichkeit, da irgendwie Einfluss zu nehmen.

So, das führt irgendwie dazu, dass man jetzt sagen kann, na ja, nicht alles ist irgendwie, it depends.

Das heißt, die Frage, die man sich jetzt stellen kann, ist, was sind eigentlich Dinge, die halt nicht verhandelbar sind?

So, und da ist halt eine Sache, die Team Topologies sagt, dass dieser Änderungsstrom etwas ist, was eben ein Team umsetzen soll.

Das hat viele Vorteile.

Das ist also etwas, was tatsächlich eigentlich nicht verhandelbar ist.

Diese Teams sollten von den anderen Teams unterstützt werden.

Da sollte also der Cognitive Load reduziert werden.

Und das bedeutet jetzt, dass wir zum Beispiel mit Teams arbeiten können, die keinen direkten Business Impact haben.

Also ein Plattform-Team wird Streamline-Teams helfen, wird aber selber nicht dafür sorgen, dass jetzt bessere Umsatz oder sonst was halt generiert wird.

Und es bedeutet eben auch nicht, dass jetzt Teams nur nach Domänen aufgeteilt werden.

Ein Plattform-Team ist ein technisches Team.

Ein Abling-Team ist ein Team mit bestimmten Kompetenzen.

Die sind also auf jeden Fall schon mal anders.

Und selbst Teams, die halt sozusagen einen Domänen-Code schreiben, könnte ich nach anderen Maßstäben, also z.B. nach Technologien z.B. aufteilen.

Team Topologies sagt, dass es diese Infomain-Strukturen gibt.

Das sollten wir verbessern und damit halt irgendwie arbeiten und die halt irgendwie auch verwenden.

Das ist genau der Punkt, weswegen ich nochmal auf Fearless Change und diese Thema irgendwie eingegangen bin.

Gut, damit bin ich sozusagen am Ende meiner Folien.

Vielen Dank für die Aufmerksamkeit.

Vielen Dank für die Diskussion.

Ich muss gestehen, an so einem Brückentag ist das immer so ein bisschen, wie soll ich sagen, bin ich mal gespannt, ob überhaupt jemand kommt.

Von daher freut es mich, dass eben da Fragen und Diskussionen waren.

Nächste Woche haben wir dieses Thema, sollen wir LLMs für Software-Architektur verwenden?

Da werden Ralf und ich uns, also wir haben da unterschiedliche Standpunkte, da werden Ralf Demüller, Müller und ich uns über dieses Thema unterhalten.

Und da bin ich gespannt, was dabei sozusagen rauskommt.

Ich glaube, weitere Fragen hatte ich nicht.

Also Fragen, die halt sozusagen noch zu beantworten wären.

Dann würde ich sagen, vielen Dank für die Aufmerksamkeit, vielen Dank für die Fragen und ich hoffe, dass wir uns nächste Woche dann wiedersehen.

Schönes Wochenende, bis dahin.