Die Veranstaltung richtet sich an ein internationales Publikum, so dass alle Vorträge auf Englisch gehalten wurden – auch wenn sicherlich ein Großteil der Teilnehmer als auch Redner deutschsprachig waren. Zielgruppe sind primär Softwarearchitekten – von denen das iSAQB laut eigener Aussage übrigens seit 2008 schon 30.000 zertifiziert hat.

Die Agenda umfasste ca. 45 Programmpunkte, darunter 4 Keynotes, 8 Workshops und 33 Vorträge. Die Workshops fanden am ersten und letzten Tag statt, während Keynotes morgens und abends an den mittleren Tagen gehalten wurden. Die parallelen Vortrags-Tracks machten einen Besuch aller Vorträge unmöglich, unsere zweiköpfige Präsenz erlaubte uns aber eine recht gute Abdeckung.

Ein inhaltlicher Blick auf die Agenda der Konferenz zeigt eine bunte Mischung an Themen, wobei “Künstliche Intelligenz” (KI) – oh Wunder – dieses Jahr dominierte. 8 Vorträge oder 18 % des Programms beschäftigten sich explizit mit KI. Indirekt kam das Thema sogar in fast der Hälfte der Vorträge vor. Das Top-Thema der vergangenen Dekade – Microservices – ist mit nur noch 4 ausdrücklichen Erwähnungen in der Agenda damit vom Thron gestoßen, obwohl sie auch noch in mindestens drei weiteren Sessions, in denen sie zwar nicht im Titel aufgeführt waren, thematisiert wurden. Agile und DevOps sowie Security waren mit jeweils 4 bzw. 3 Vorträgen vertreten. Abgerundet wurde das Programm durch Themen wie bspw. Legacy-Modernisierung oder Teamstrukturen im Umfeld Softwareentwicklung.

Der Kreis der Vortragenden bot wenig Überraschungen, es handelte sich um eine Mischung aus Vertretern der Industrie sowie Beratung und den “üblichen Verdächtigen” der Szene wie z.B. Carola Lilienthal, Gernot Starke, Eberhard Wolff, Michael Plöd, Rebecca Parsons oder Uwe Friedrichsen.

Vorträge

Die erste Keynote von Dr. Gernot Starke, „Tiger Alert: Better Run Away!“ [2], begann vielversprechend, entpuppte sich jedoch größtenteils als Zusammenfassung von Daniel Kahnemanns bekanntem Buch „Thinking, Fast and Slow“. Obwohl die Zusammenfassung gut präsentiert und mit zusätzlichen Quellen angereichert war, fehlte uns hier neben der Aktualität der Bezug zur Softwarearchitektur. Kahnemanns Werk ist zweifellos wertvoll, aber auf einer Konferenz, die sich an Softwarearchitekten richtet, hätten wir uns mehr Transferleistung, also Einblick in die Anwendung dieser Konzepte auf Herausforderungen in unserem Bereich gewünscht.

Als ein mögliches Beispiel könnten wir hier die Schwachstelle CWE-1007 [3] aufzeigen, bei der Anwender, und dazu zählen in diesem Fall auch Entwickler und Architekten, durch visuell ähnliche Zeichen in die Irre geführt werden. Hierbei wird einem nicht das berühmte X für ein U, sondern bspw. eine Null für ein “O” oder das lateinische „e“ für das zum Verwechseln ähnliche kyrillische „е“ vorgemacht. Kahnemans System 1, die Intuition bzw. der Autopilot schlagen hier zu und wir klicken als Anwender auf die gefälschte URL, wodurch z.B. ein Trojaner heruntergeladen wird. Als Entwickler wird uns im Sourcecode so bspw. eine ähnlich lautende Methode mit anderer Funktionalität untergeschoben. Was kann ich als Softwarearchitekt dazu beitragen, damit so etwas nicht passiert? Bspw. darauf hätten wir uns als Teilnehmer dieses Vortrags Antworten erhofft.

Als nächsten Vortrag haben wir uns “Generative AI Meets Software Architecture” von Lars Röwekamp [4] angeschaut. Über Fragen der Modellauswahl und -integration sowie Grundlegendem zum Prompting führt der rote Faden hier zielgerichtet zum Thema Retrieval Augmented Generation (RAG) um aktuelles und Domänen-spezifisches Wissen in GenAI-Abfragen zu integrieren.

Für Anfänger im Umfeld Integration von GenAI, an die sich dieser Vortrag richtet, gab er einen durchaus interessanten Überblick.

Ein für uns interessanter, aber unbestätigter Fakt aus dem Vortrag besagt, dass der Bau der großen Large Language Modelle rund 50 Millionen USD alleine an Rechenkapazitäten kosten soll. Was aber erklären würde, warum die unserer Wahrnehmung nach oft leichtfertig dahin gesagte Aussage „Dann bauen wir eben unser eigenes Modell“ in der Praxis für die meisten Unternehmen absehbar nicht umsetzbar sein wird – und es wohl beim RAG bleibt.

Unser Fazit – aus dem Vortrag, aber auch allgemein zum Thema:

• GenAI ist mächtig – aber teuer.
• (Gutes) Prompting ist der Schlüssel.
• Jedes Modell hat seinen eigenen Charakter.
• RAG, um Domänenwissen einzubinden und aktuell zu bleiben.
• GenAI ist auch nur Software – behandle sie auch so.
  

Sowohl inhaltlich als auch hinsichtlich des Anspruchsniveaus (“Intermediate”) anschließend, war dann Robert Glasers “The Architecture of Reliable AI: RAG” [5]. Wenn auch technisch detaillierter hergeleitet, lautet aber auch seine Aussage, dass RAG das Mittel der Wahl für GenAI im Unternehmenseinsatz ist: “Put everything in the prompt”. Hier kommen allerdings die Begrenzungen der verschiedenen Modelle zum Tragen. Was u.a. erklärt, warum ich nicht einfach mein ganzes Unternehmens-Intranet in jede meiner GenAI-Abfragen packen kann, sondern relevante sogenannte Chunks finden (“retrieve”) muss, um die ich meine Abfrage (“Prompt”) erweitere (“augment”).

Für das Retrieval setzt der Redner auf einen hybriden Ansatz aus klassischer Volltextsuche (für spezifische Anfragen) und Vector-Suche mit Embeddings (für allgemeine Anfragen), deren Funktionsweisen er jeweils gut erläutert. Die Vorteile der Vector-Suche liegen demzufolge darin, dass sie immer Ergebnisse liefert, diese nach Ähnlichkeit sortiert, sprachübergreifend aufgrund semantischer Ähnlichkeit funktioniert und relevante Inhalte trotz unterschiedlicher Formulierungen findet. Ergänzt wird dies durch die klassische Volltextsuche, die insbesondere die Unschärfe in vektorbasierten Ergebnissen ausgleichen soll.

Das Ganze wird an einem Beispiel aus dem Leben eines Softwarearchitekten (“Wie kam es zu der Architektur unseres Online-Shops?”) durchgängig verdeutlicht – in Summe also ein runder Vortrag.

Technischer wurde Allard Buijze in seinem Vortrag “Event Sourcing – Technical Detail or Architectural Powerhorse?” [6]. Nun ist Event Sourcing kein ganz neues Pattern, Martin Fowler erwähnt es bspw. bereits 2005 [7], wir nehmen es in deutschen Softwareorganisationen seit rund 10 Jahren vermehrt wahr. Somit ist der Ansatz aber etabliert genug, um aus Softwarearchitektursicht zu hinterfragen, ob es sich dabei eher um ein zu vernachlässigendes Implementierungsdetail handelt oder er sich vielleicht doch zum Allzweckmittel (“Zugpferd”) des modernen Softwarearchitekten gemausert haben könnte.

In dem Vortrag wurde über eine historische Einordnung des Themas den Anwesenden zunächst der Spiegel vorgehalten. So hat sich sicherlich jeder Softwarearchitekt schon mal dazu hinreißen lassen, einer klassischen Mehrschichtarchitektur einfach eine weitere Abstraktionsschicht hinzugefügt zu haben, um das gerade anstehende Problem “elegant”, also schnell, gelöst zu bekommen. Meist dauert es dem Redner zufolge dann nicht lange und es werden in den Schichten Caches aufgebaut, um die – durch die vielen Schichten langsamer werdenden – Zugriffe wieder zu beschleunigen. Am Ende entsteht auch so dann doch wieder der gern zitierte Big Ball of Mud der Softwareentwicklung, für den es auch in diesem Vortrag ein schönes Bild gab:

Die Umsetzung von Änderungen an der Software werden bei diesem Architekturstil also zwangsläufig über die Zeit länger dauern. (Etwas) Besserung kam dann mit Domain-Driven Design (“DDD”) [8] ins Spiel:

Im weiteren Verlauf des Vortrags wurden dann Event-Sourcing und die dazugehörigen Konzepte wie Event-Streaming, CQRS, Messaging, etc. und insb. ihre Vorteile wie z.B. Testbarkeit, Skalierbarkeit, einfache Anpassung an veränderte Business-Anforderungen (insb. in Kombination mit DDD) ausführlich dargestellt. Nicht ganz verwunderlich, da er Gründer und CTO einer Softwarefirma für Tools zum Event Sourcing ist, kommt der Redner zum Schluss des durchaus guten Vortrags zu der Erkenntnis, dass Event Sourcing sowohl Implementierungsdetail als auch Allzweckmittel für Softwarearchitekten sei.

Wir sehen die Vorteile von Event Sourcing und kennen auch zahlreiche erfolgreiche Implementierungen, sehen aber auch deren Komplexität und wissen, dass sie nicht immer passen, sondern es, wie so oft, auf den Use Case ankommt.

Gregor Hohpe hat in seiner Keynote „Architects Aren’t the Smartest People in the Room“ [9] einen Nerv bei uns getroffen. Wir stören uns schon länger daran, dass ein guter Softwarearchitekt laut manchen Quellen so etwas wie der mysteriöse Superheld eines jeden IT-Projekts ist. So soll dieser (laut ChatGPT) über

• technische Fähigkeiten von Programmierkenntnissen, über Designprinzipien, Cloud- und Sicherheitsarchitekturen, DevOps und CI/CD bis hin zu Expertise in Datenbank-Systemen (natürlich relational wie auch non-relational) und Schnittstellendesign,
• analytische und Problemlösungsfähigkeiten, insbesondere natürlich Komplexitätsmanagement und Abstraktionsvermögen,
• Kommunikations- und Sozialkompetenzen, wie etwa Präsentations- und Moderationsfähigkeiten, Verhandlungskompetenzen, Erfahrungen im Stakeholdermanagement sowie idealerweise auch Führungserfahrung,
• strategische Kompetenzen sowie
• Expertise in agiler sowie klassischer Projektmanagementmethodik

verfügen. Natürlich hätten wir alle gerne nur solche Kolleginnen und Kollegen in unseren Projekten, jedoch ist diese Beschreibung wenig hilfreich, um das ohnehin schon überladene Bild eines Software Architekten [10] besser einzugrenzen.

Gregor Hohpe hat sich in seinem Vortrag nun in gewohnt launiger und kurzweiliger Art mit genau diesem Punkt beschäftigt. Wie bereits der Titel angibt, seien Architekten hierbei nicht die schlauesten Personen im Raum. Im Gegenteil: Es sei genau die Kernaufgabe eines Architekten, sein Umfeld smarter zu machen.

Hierzu stehen einem guten Architekten verschiedene Werkzeuge zur Verfügung, beispielsweise über Abstraktion oder Analogien (Gregor selbst liebt Analogien zu Automotoren), komplexe technische Fragestellungen diskutier- und entscheidbar zu machen. An dieser Stelle wurde der Vortrag für unseren Geschmack ein wenig generisch / oberflächlich, was aber für eine Keynote, die ein möglichst großes Publikum ansprechen soll, absolut im Rahmen war.

Insbesondere ein Prinzip ist uns lebhaft im Gedächtnis geblieben, vermutlich weil wir uns auch ein wenig ertappt gefühlt haben: “Don’t dumb things down”. Laut dem Redner gehören Top-Entscheider oftmals zu den am besten ausgebildeten, intelligenteren sowie hochmotivierten Personen innerhalb eines Unternehmens. Trotzdem neigen IT-Experten dazu, Zusammenhänge im Austausch mit IT-fremden Entscheidern sehr stark zu vereinfachen. Dass sie hierbei wirklich, wie humorvoll angemerkt wurde, beginnen besonders langsam zu sprechen, wenn eine Erklärung beim ersten Mal nicht verstanden wird, haben wir zwar noch nicht beobachten können, aber der Quintessenz, dass man diesem Gegenüber durchaus eine gewisse Komplexität zutrauen kann und es unsere Aufgabe als Architekten ist, sie genau zu dieser Diskussion zu befähigen (bspw. mit Abstraktion und Analogien), stimmen wir absolut zu.

Fazit

Dies war nur ein Auszug einiger der von uns besuchten Vorträge auf dem iSAQB Software Architecture Gathering 2024, welche unserer Einschätzung nach aber einen guten Eindruck von der Konferenz geben.

Durch die Corona-Pandemie sicherlich erzwungenermaßen, aber auch thematisch war es die vergangenen Jahre recht ruhig rund um Softwarearchitektur. Der ”KI”-Hype bietet unserer Zunft hier nun nach längerer Zeit wieder mal ein echtes Thema – “KI” ist schließlich auch “nur” Software – was es architekturell zu verstehen gilt. Echte Neuheiten bot die Konferenz in dem Umfeld allerdings nicht, durchgängiges Thema war Retrieval Augmented Generation (“RAG”), welches hier als das Mittel der Wahl beim Unternehmenseinsatz von generativer “KI” besprochen wurde – aber tatsächlich auch schon seit über einem Jahr diskutiert wird:

Das iSAQB Software Architecture Gathering bietet insgesamt eine gute Gelegenheit, sich einen umfassenden Überblick über aktuelle Themen und Trends im Bereich der Softwarearchitektur zu verschaffen. Allerdings hätten wir uns eine größere inhaltliche Vielfalt gewünscht – insbesondere bei tiefergehenden Formaten. Stellvertretend dafür steht die Tatsache, dass das Veranstaltungsprogramm ausschließlich Vorträge und Workshops der Kategorien „Beginner“ und „Intermediate“ umfasste.

Trotzdem ist das Gathering eine wertvolle Plattform für Softwarearchitekten verschiedener Erfahrungsstufen. Wir sind gespannt darauf, wie sich die Konferenz in den kommenden Jahren weiterentwickeln wird.

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Quellenangaben

[1]: https://conferences.isaqb.org/software-architecture-gathering/ (abgerufen: 5. Dez. 2024).

[2]: https://www.youtube.com/watch?v=u5XMypmSXVQ (abgerufen: 19. Dez. 2024).

[3]: https://cwe.mitre.org/data/definitions/1007.html (abgerufen: 16. Dez. 2024).

[4]: https://conferences.isaqb.org/software-architecture-gathering/session/generative-ai-meets-software-architecture/ (abgerufen: 30. Dez. 2024).

[5]: https://conferences.isaqb.org/software-architecture-gathering/session/the-architecture-of-reliable-ai-rag/ (abgerufen: 30. Dez. 2024).

[6]: https://conferences.isaqb.org/software-architecture-gathering/session/event-sourcing-technical-detail-or-architectural-powerhorse/ (abgerufen: 11. Jan. 2025).

[7]: https://martinfowler.com/eaaDev/EventSourcing.html (abgerufen: 11. Jan. 2025).

[8]: https://martinfowler.com/bliki/DomainDrivenDesign.html (abgerufen: 11. Jan. 2025).

[9]: https://conferences.isaqb.org/software-architecture-gathering/session/architects-arent-the-smartest-people-in-the-room/  (abgerufen: 11. Jan. 2025).

[10]: https://atra.consulting/blog/die-vielen-gesichter-von-softwarearchitekten/ (abgerufen: 13. Jan. 2025).

Die Auswahl an wohltätigen Organisationen und karitativen Einrichtungen ist riesig. Alleine eine kurze Online-Suche nach dem Stichwort „Weihnachtsspende“ ergibt unzählige Treffer – mit vielen wunderbaren Projekten, die jede Unterstützung verdient hätten. Doch die schiere Vielfalt macht es schwierig, gezielt auszuwählen.

Da wir als IT-Beratungsgruppe täglich im technologischen Umfeld arbeiten, möchten wir unsere Spende deshalb auf einen Bereich konzentrieren, der direkt zu unserem beruflichen Alltag passt. Unsere Wahl fiel auf Open-Source-Software (OSS). Durch OSS werden nicht nur moderne Technologien ermöglicht, sondern auch Innovationen und Stabilität in der IT-Infrastruktur gefördert. Uns ist es wichtig, auch hier einen Beitrag zu leisten und uns für eine „karitative Technologie-Spende“ zu engagieren, die sich für viele Menschen langfristig positiv auswirken kann.

Das Rückgrat unserer digitalen Welt

Open-Source-Software ist das unsichtbare Rückgrat der digitalen Welt, auf das sich viele unserer Projekte und Technologien stützen. Oft denken wir gar nicht daran, dass hinter dieser Software kleine Entwicklerteams oder sogar Einzelpersonen stehen, die diese Infrastruktur ehrenamtlich und ohne finanzielle Rückendeckung aufrechterhalten.

Die Open-Source-Community sieht sich einem Spannungsfeld gegenüber: Auf der einen Seite ist “ihre Software” enorm erfolgreich und weit verbreitet. So läuft Android, ein auf dem Linux-Kernel basierendes Betriebssystem, auf über 2 Milliarden Geräten weltweit. Linux selbst, mittlerweile 25 Jahre alt, ist aus der digitalen Welt nicht mehr wegzudenken. Sein Einsatzgebiet reicht von Alltagsgeräten wie Smartphones und Druckern über Webserver und Cloudinfrastruktur bis hin zu Supercomputern, wo es auf 498 der 500 leistungsstärksten Systemen läuft. Die Weltherrschaft von Linux ist unbestritten.

Linux und Android sind zwar bekannte Beispiele, aber bei weitem nicht die einzigen. Die Datenbank SQLite, beispielsweise, ist außerhalb der IT-Welt kaum jemandem ein Begriff. Trotzdem wird sie Schätzungen zufolge auf über einer Billion Geräten aktiv genutzt.

Schattenseiten: Herausforderungen in der Open-Source-Welt

Obwohl Open-Source-Software das unsichtbare Rückgrat unserer modernen digitalen Welt darstellt, gibt es auch weniger beachtete Schattenseiten. Dieses Rückgrat ruht auf den Schultern engagierter Freiwilliger, die ihre Arbeit mit Leidenschaft und ohne kommerziellen Anreiz der Allgemeinheit zur Verfügung stellen. Doch von dieser Arbeit können sie oft nicht leben. Kritische Software-Infrastruktur wird deshalb häufig von Einzelpersonen in späten Nachtstunden oder am Wochenende – zusätzlich zu ihrem regulären Job – entwickelt und gepflegt.

Ein markantes Beispiel hierfür ist die Programmbibliothek OpenSSL, die rund zwei Drittel des gesamten Internetverkehrs verschlüsselt und damit eine Schlüsselrolle in der digitalen Sicherheit einnimmt. Ein über Jahre unentdeckter Fehler in OpenSSL führte zum berühmten Heartbleed-Bug, der eine erhebliche Sicherheitslücke darstellte und private Daten im Internet anfällig für Angriffe machte. Nach der Behebung des Bugs machte das Entwicklungsteam deutlich auf die strukturellen Probleme in der Open-Source-Welt aufmerksam und bat um Hilfe.

Ein etwas aktuelleres Beispiel wurde von Heise gar als größtes Fiasko in der Geschichte des Internets bezeichnet, dem wir gerade so entgangen sind. Vermutlich staatliche Akteure nutzten eine technisch hochentwickelte Methode, um die Paketierungssoftware XZ zu kompromittieren. Dabei setzten sie auf raffiniertes Social Engineering, indem sie die angeschlagene psychische Gesundheit von Lasse Collin, dem Hauptentwickler der Software, gezielt ausnutzten. Diese Aktion, die zunächst unscheinbar wirken mag, hätte fast eine Backdoor in nahezu jedes System weltweit geöffnet.

Open Source: Stärke durch Transparenz, aber wer trägt die Verantwortung?

An dieser Stelle möchten wir betonen: Open Source Software ist nicht per se unsicherer oder weniger nachhaltig als kommerzielle Software (Closed Source Software). Ganz im Gegenteil – die breite und öffentliche Aufarbeitung, wie im Fall von XZ, sehen wir als eine Stärke, die langfristig Sicherheit und Stabilität fördert. Gleichzeitig wirft dies aber auch die wichtige Frage nach einer fairen Lastenverteilung auf – ein Punkt, der in folgendem xkcd-Comic auf amüsante Weise illustriert wird.

Ob insbesondere große Unternehmen, alleine in Deutschland nutzen 71% dieser Open-Source-Software, sowie Staaten hier zum Erhalt unseres digitalen Rückgrats genug investieren und „zurückgeben“, ist ein sehr berechtigter Aspekt dieser Frage, bspw. erst kürzlich wieder von der Wikimedia gestellt.

Das Spannungsfeld zwischen der erfolgreichsten Idee der IT-Geschichte und vielen engagierten “stillen Helden” ist auch hier offensichtlich. Glücklicherweise werden auch Themen wie Burnout immer offener diskutiert.

Weihnachtsspende: Immer noch viel Auswahl

Nun gibt es auch bei der Suche nach geeigneten Spendenzielen im Open-Source-Bereich unzählige inspirierende Organisationen und Projekte, die jede Unterstützung verdienen. Statt selbst eine Auswahl zu treffen, haben wir innerhalb von atra.consulting eine kleine Umfrage gestartet. Der Rahmen war einfach: Für jedes Teammitglied stand eine Spendensumme von 50 € zur Verfügung. Alle Kolleginnen und Kollegen waren eingeladen, ihr persönliches Herzensprojekt vorzuschlagen. Anschließend wurde gemeinsam über die eingereichten Vorschläge abgestimmt.

So starten wir die Weihnachtszeit nun mit Spenden an folgende Projekte:

Signal – Der sichere, E2E-verschlüsselte Open-Source-Messenger überzeugte unser Team auf ganzer Linie. Neben innovativer Entwicklung, etwa im Bereich Post-Quantum-Verschlüsselung, leistet die Signal Foundation unschätzbare Arbeit. Mit Abstand auf Platz 1 erhält Signal 50 % der Spendensumme.

Wikipedia – Zwar keine klassische Open-Source-Software, aber ein unverzichtbares Open-Knowledge-Projekt. Es bereichert unseren Alltag und ist eine essenzielle Grundlage, auch für die Entwicklung moderner Technologien wie LLMs. Wikipedia erhält 30 % der Spendensumme.

Notepad++ – Ein einfacher, aber wertvoller Texteditor, der für viele von uns tägliches Werkzeug ist. Notepad++ erhält 20 % der Spendensumme und würdigt damit die Bedeutung kleiner, effektiver Tools.

Mit unserer Spendenaktion möchten wir nicht nur einen Beitrag leisten, sondern auch das Bewusstsein für die Bedeutung von Open-Source-Software schärfen. Wir laden alle ein, sich dieser Idee anzuschließen und die Open-Source-Community aktiv zu unterstützen.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Einleitung

Bei der Besetzung von Rollen in IT-Projekten ist eine gewisse Findungsphase mit dem Auftraggeber nicht unüblich. Während viele Rollen im Lehrbuch (recht) eindeutig definiert sind, spricht die Praxis oftmals eine andere Sprache. Eine besonders komplexe Rolle hierbei ist die des Softwarearchitekten, bei welcher sich Anforderungen und Erwartungen von Organisation zu Organisation teils stark unterscheiden. Dies hat sicherlich auch damit zu tun, dass selbst der Begriff von Softwarearchitektur in der Literatur nicht einheitlich und erst recht nicht präzise definiert ist. Gleichzeitig trägt die Rolle aber wesentlich zum Erfolg von IT-Projekten bei. Grund genug für uns, den vielen Facetten von Softwarearchitektur eine kleine Blogserie zu widmen.

Einleiten wollen wir diese Blogserie mit einer nicht ganz ernst gemeinten Betrachtung verschiedener (Stereo-)Typen von Softwarearchitekten, wie sie die meisten Menschen, die sich im Kontext von IT-Projekten bewegen, wohl schon erlebt haben. Die durchaus sinnvollen Unterscheidungen zwischen Enterprise, Solution und Technical Architecture klammern wir an dieser Stelle erst einmal bewusst aus, da sich unserer Erfahrung nach untenstehende Typen auf eigentlich jedem Abstraktionslevel finden lassen. Aber Achtung – der Beitrag kann Spuren von Ironie enthalten. 

Der Powerpoint-Architekt

Für ihn bestehen Softwaresysteme aus Kästchen und Pfeilen. Alles andere sind doch auch nur lästige Implementierungsdetails. Wird von agilen Teams häufig nach oben weggelobt und zeichnet seine Powerpoints nun auf höherer Ebene.

Der Elfenbeinturm-Architekt

Durchaus verwandt mit dem Powerpoint-Architekten befindet sich der Elfenbeinturm-Architekt im… nun ja, in seinem persönlichen Elfenbeinturm. Oftmals zeichnen Elfenbeinturm-Architekten sich gleichzeitig durch ein tiefes, zumeist akademisch geprägtes Fachwissen auf der einen und eine komplette Ignoranz für die (Projekt-)Bedürfnisse der Entwicklungsteams auf der anderen Seite aus. Liebt Gremien, in welchen die Entwicklungsteams sich ihre Architekturen abnehmen lassen müssen. Oder es zumindest versuchen. Der natürliche Feind agiler Teams.

Der Chronisten-Architekt

Sieht sich als Wächter der Dokumentation, welche in ihrer Bedeutung der Bibliothek von Alexandria quasi in nichts nachsteht. Etwas, was nicht ausführlich dokumentiert ist, existiert für ihn nicht und kann auf gar keinen Fall funktionieren. Idealerweise wird die Architektur und ihre Dokumentation in mehrstufigen Gremien freigegeben. Im Gegensatz zum Elfenbeinturm-Architekten sieht der Chronisten-Architekt seine Rolle aber eher in der Vorbereitung und Dokumentation der Gremienarbeit.

Der Podcast-Architekt

Hört wirklich jeden Architektur – und Technologie-Podcast auf dem Markt. In mehr als einer Sprache. Der Podcast-Architekt predigt die neuesten Technologien und Methoden und versucht, jeden in seinem Umfeld davon zu überzeugen. Hält sich auch liebend gerne auf Konferenzen und Meetups auf. Seine Wahrnehmung in den Projektteams variiert stark – manche lieben ihn und seine Impulse, manche möchten doch einfach nur das Projekt zu Ende bringen.

Der Prototypen-Architekt

Dieser Architekten-Typus ist der natürliche Gegenpart zum Powerpoint-Architekten. Architektur findet für ihn direkt im Code statt, neue Pattern oder Ideen stellt er am liebsten als Prototyp direkt in seinem Repo zur Verfügung. Die Entwicklungsteams lieben ihn, auch wenn sein sonstiges Umfeld sich durchaus ein wenig mehr Dokumentation und Struktur wünschen würde.

Der U-Boot-Architekt

Nicht zu verwechseln mit dem Elfenbeinturm-Architekten, ist sein natürliches Wirkungs-Habitat der Besprechungsraum. Hier weiß er zu brillieren und durch die geschickte Platzierung von Fragen und Prüfaufträgen jede noch so kleine Entscheidung zielsicher zu torpedieren. Nur um dann wieder abzutauchen – bis zum nächsten Mal.

Der basisdemo­kra­tische Architekt

Architektur ergibt sich für ihn nur evolutionär aus der Diskussion im Team und hat sich dem Code unterzuordnen. Vorabentschei­dungen sind unbedingt zu vermeiden, zentrale Beschlüsse oder übergreifende Einschränkungen werden als persönlicher Affront aufgefasst. Auf diese Weise hat der basisdemokratische Architekt immer ein lokales Optimum fest im Blick – oftmals jedoch nicht das große Ganze. 

Uns selbst laufen eigentlich alle oben genannten Typen regelmäßig in Rein- oder Mischform in unseren Projekten über den Weg. Sehr gerne denke ich an einen großen Kunden zurück, bei dem der Auf­trag­geber selbst von 3-6 Monaten Onboarding ausge­gangen ist, um die komplexen Dokumentations- und Prozess­anforderungen an die Entwicklung der Software­architektur zu verinnerlichen. Ein typischer Fall von (in diesem Fall gewollten) Chronisten-Architekten. 

Aber was lernen wir nun aus den verschiedenen Typen von Softwarearchitekten? Auch wenn die Darstellung bewusst überspitzt war, verdeutlicht die Betrachtung sehr schön, mit welchen komplexen Anforderungen sich ein Softwarearchitekt konfrontiert sieht. Persönlich mag ich das Bild des Softwarearchitektur-Aufzuges von Gregor Hohpe, in welchem der Architekt sich vom Maschinen­raum im Keller (Technik, Programmiersprache, Design Pattern) bis zum Vorstands-Penthouse auf dem Dach (IT-Transformation, Organisationsentwicklung) bewegt. Auch wenn man durchaus hinterfragen kann, ob es sinnvoll ist, so viele Aufgaben und Anforderungen in eine einzige Rolle zu projizieren. Im nächsten Blogpost beschäftigen wir uns etwas ausführlicher damit, was Softwarearchitektur für uns eigentlich bedeutet – ganz ohne Ironie.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Die in diesem Artikel verwendeten Bilder wurden mit Hilfe von DALL·E 2, einer KI zur Bildgenerierung, erstellt.

Während Agilität mit dem de-facto Standard Scrum auf Teamebene oftmals relativ leicht umzusetzen ist, stellt Skalierung der agilen Vorgehensweisen Organisationen regelmäßig vor größere Herausforderungen. Viele Frameworks wie etwa SAFe oder LeSS liefern interessante und gute Ansätze hierfür. Jedoch scheitern Organisationen regelmäßig bei der Einführung dieser, aufgrund heterogener Teams, Anforderungen und Produktlandschaften. So ist beispielsweise ein Team, welches den Checkout-Prozess eines Onlineshops verantwortet, ganz anders zu betrachten als das Team, welches die interne Cloudplattform oder einen Data Lake entwickelt. Jedes dieser Teams hat unterschiedliche Anforderungen an eine teamübergreifende Planung und Zusammenarbeit. Aufgrund der abweichenden Herausforderungen benötigt es ein anpassbares Vorgehensmodell. 

Die Strukturierung und Interaktion von Teams ist eine der größten Herausforderungen in agilen Organisationen. Besonders in der IT müssen Teams häufig komplexe Aufgaben bewältigen und dabei flexibel bleiben. Matthew Skelton und Manuel Pais bieten mit ihrem Buch „Team Topologies“ eine klare Methode, wie Teams organisiert und ihre Schnittstellen gestaltet werden können, um Effizienz, Zusammenarbeit und Anpassungsfähigkeit zu maximieren.

Die Grundidee hinter Team Topologies

• Klare Verantwortlichkeiten: Jede Teamkategorie hat definierte Ziele und Aufgaben, was den Fokus und die Effizienz erhöht. 
• Verbesserte Zusammenarbeit: Gut durchdachte Kommunikationswege und Schnittstellen reduzieren Missverständnisse. 
• Schnelle Anpassung: Enabling-Teams helfen anderen Teams, neue Technologien oder Methoden schneller einzuführen. 
• Optimierte Ressourcennutzung: Plattform-Teams schaffen gemeinsame Infrastruktur, damit sich andere Teams auf ihre Kernaufgaben konzentrieren können.

Auf diese Weise soll der Ansatz der Teamkategorien eine praxisnahe und flexible Methode bieten, um skaliertes Agilitätsmanagement in komplexen Organisationsstrukturen zu implementieren und nachhaltig zu verankern.

In kurzen Worten: Team Topologies soll die Entwicklung von Organisationen im Laufe der Zeit unterstützen, wann immer sich die Bedingungen ändern. 
Moderne Organisationsprinzipien werden gefördert und Softwareanpassungen können schneller umgesetzt werden. In der Realität bleibt es bei der immer gleichen Herausforderung, den Teams dafür entsprechend Zeit zum Testen & Lernen einzuräumen.

Schauen wir uns das Konzept in der notwendigen Tiefe an, um zu erfahren, wie diese Konzepte auch in den eigenen Teams angewendet werden könnten: 

Inhalt:

1. Conway’s Law
2. Team First
3. Vier grundlegende Topologien
4. Team-Interaktionsmodi
5. Organisatorisches Gespür
6. Topologieentwicklung
7. Team-API

1. Conway’s Law

Conway’s Law besagt:

»Jede Organisation, die ein System entwirft, wird zwangsläufig einen Entwurf erstellen, der eine Kopie ihrer Kommunikationsstruktur ist.« 

Anders formuliert: Die Organisationsstruktur und die Kommunikationswege zwischen den Teams spiegeln sich direkt in der Systemarchitektur wider. Ein einfaches Beispiel dazu zeigt die folgende Grafik.

Während Conway’s Law oft als reine Beobachtung beschrieben wird, geht der Ansatz von Team Topologies einen Schritt weiter: Es wird als aktives Gestaltungsprinzip verstanden. Anstatt zu akzeptieren, dass die Architektur die bestehenden Teamstrukturen widerspiegelt, lassen sich Teams gezielt so gestalten, dass sie eine gewünschte Architektur aktiv fördern.

Möchte man beispielsweise eine modulare, lose gekoppelte Architektur, sollten die Teams entsprechend strukturiert werden. Dies gelingt durch den Aufbau autonomer, funktionsübergreifender Teams sowie durch die Etablierung klarer Schnittstellen und definierter Verantwortlichkeiten. Dieses Prinzip wird als Inverses Conway’s Law bezeichnet. In unserem Projektalltag begegnen wir diesem Phänomen immer wieder.

Ein Beispiel aus der Praxis: Selbst sehr erfahrene Entwickler entwerfen zum Teil monolithische, fehleranfällige Strukturen – nicht aufgrund mangelnden Könnens, sondern weil:

• Architekturbausteine mit zu viel Funktionalität überladen werden, da Entwickler in diesen Bereichen besonders vertraut sind.
• Hoher Lieferdruck führt dazu, dass eigentlich isolierte Funktionalitäten schnell in bestehende Strukturen integriert werden, statt sauber gekapselt zu werden.

Ob traditionelles oder inverses Conway’s Law: Das „Störgefühl“, wenn die Softwarearchitektur nicht mehr zur Teamstruktur passt, kennt fast jeder. Sich dieses Zusammenhangs bewusst zu sein, ist der erste Schritt, um sowohl die Architektur als auch die Organisation gezielt weiterzuentwickeln.

(Mehr dazu hier: Conway´s Law – EN  / Conway´s Law DE)

2. Team First

Bei Team Topologies wird ein Team als eine stabile Gruppe von Menschen betrachtet, die am gleichen Ziel arbeiten. Verantwortlichkeiten werden keinen Einzelpersonen zugewiesen, sondern Teams.

Die Anzahl der Teammitglieder ist entscheidend, um Vertrauen zu bilden. Ein effektives Team umfasst laut Team Topologies 7 bis 9 Personen. 

Bis eine einigermaßen geschlossene Einheit entsteht, dauert es bis zu drei Monate. Es ist kaum sinnvoll, Teams nach Abschluss eines Projekts, an dem sie ein halbes Jahr gearbeitet haben, neu zu strukturieren. Die emotionale Anpassung an die Arbeitsgewohnheiten und Sichtweisen neuer Kollegen hat einen gravierenden Einfluss auf die Leistung. Nur wenn das Vertrauen in eine Organisation hoch ist, ist ein Teamwechsel einmal im Jahr ohne negative Auswirkungen möglich.

Die Autoren betonen, dass es wichtig ist, die kognitiven Fähigkeiten des Teams zu maximieren, durch die Verbesserung der Arbeitsumgebung, des Führungsstils und die Minimierung von Ablenkungen.

Diese Ansicht wird bereits in vielen bekannten Team-Konstellationen angewandt, wie beispielsweise in Projektteams, Enabling oder Transformationsteams. Die Vorteile von Teams mit klarem Fokus ohne Ablenkungen von “außen” sind nicht von der Hand zu weisen. 

John Sweller bezeichnet Kognitive Belastung mit: „Die Gesamtmenge an geistiger Anstrengung, die im Arbeitsgedächtnis aufgewendet wird.“

Drei Arten der kognitiven Belastung werden benannt:

• Intrinsische kognitive Belastung – bezieht sich auf die Faktoren, die für die Lösung der Aufgabe bedeutend sind. Beispiel: Wie kreieren wir eine neue Methode?
• Externe kognitive Belastung – bezieht sich auf die Voraussetzungen, in der die Aufgabe ausgeführt wird. Beispiel: Wie konfigurieren wir diesen Service?
• Lernbezogene kognitive Belastung – bezieht sich auf Inhalte, die erlernt werden müssen, um die Aufgabe zu lösen. Beispiel: Wie funktionieren Bank Transfers?

Mehr dazu hier: Cognitive Load Theory – DE.

Team Topologies spricht davon, die Verantwortlichkeit des Teams so zu beschränken, dass es die maximale kognitive Belastung des Teams nicht überschreitet.

Aus unserer Sicht wird es entscheidend sein, wie viel Zeit den Teams eingeräumt wird, um zu lernen, wie alltägliche Herausforderungen gemeistert werden, ohne die maximale kognitive Belastung zu überschreiten. Der Lieferdruck auf Teams und das Problem, dauerhaft an zu vielen Aufgaben parallel zu arbeiten, macht evident, wie wichtig es ist, in den Teams zu lernen, die Verantwortlichkeiten klar zu definieren und zu beschränken.

 Das Lernen im Tagesgeschäft  “nein” zu sagen, erweist sich unter hohem Lieferdruck, meist als nicht überwindbares Unterfangen und wird selten vom Management in Drucksituationen akzeptiert. Die Akzeptanz auf Managementebenen ist aber maßgeblich, um die Theorie auch in der Praxis umsetzen zu können. Hier zeigt sich für uns klar, dass die gesamte Organisation “lernen” muss.   

Eine Möglichkeit könnte der Team-First-Ansatz sein. Durch den Team-First-Ansatz soll Mitarbeitern die Möglichkeit gegeben werden, in einer Organisation erfolgreich zu sein. Anstatt ein dickes Fell oder Belastbarkeit zu benötigen, um in einer Organisation zu überleben, haben Mitarbeiter in einer Team-First-Organisation den Raum und die Unterstützung, ihre Fähigkeiten und Praktiken zu entwickeln.

3. Die vier grundlegenden Teamtopologien

Es gibt sehr viele Teamtypen in Organisationen. Der Einfachheit wegen werden diese auf vier Haupttypen reduziert. Diese betrachten das Verhalten und die Fähigkeiten der Teams und lauten wie folgt:

Stream-aligned Team: Das Team, das auf die Geschäftsveränderung ausgerichtet ist, mit einem funktionsübergreifenden Kompetenzmix und der Fähigkeit, signifikante Inkremente zu liefern, ohne auf ein anderes Team warten zu müssen.

Enabling-Team: Das Team, das andere Teams bei der Einführung und Änderung von Software im Rahmen einer Übergangs- oder Lernphase unterstützt.

Complicated-subsystem Team: Das Team mit einer besonderen Aufgabe für ein Subsystem, das zu kompliziert ist, als dass es von einem normalen Stream-ausgerichteten Team oder Plattformteam bearbeitet werden könnte. Optional und nur dann verwendet, wenn es wirklich notwendig ist.

Plattform Team: Das Team, das an der zugrunde liegenden Plattform arbeitet und Stream-ausgerichtete Teams bei der Bereitstellung unterstützt. Die Plattform vereinfacht komplexe Technologie und reduziert die kognitive Belastung für Teams.

Nehmen wir hier nochmal als Beispiel ein klassisches Unternehmen aus dem e-Commerce Bereich:

• Ein Stream-aligned Team könnte den gesamten Checkout-Prozess des Onlineshops verantworten, einschließlich der Integration neuer Payment-Dienstleister und der UX-Optimierung.
• Das Unternehmen möchte verstärkt die Vorteile der Cloud-native Entwicklung nutzen. Ein Enabling Team könnte hierbei bei der Einführung der Technologie und notwendigen Architekturmuster helfen, beispielsweise durch Schulungen, Bereitstellung von Prototypen oder Definition von Architekturpattern.

• Als complicated-subsystem-Team entwickelt eine Gruppe von Spezialisten einen hochspezialisierten Empfehlungsalgorithmus, welcher Kundinnen und Kunden passgenaue Produktempfehlungen zur Verfügung stellt.
• Unser fiktives Unternehmen hat direkt zwei Plattform-Teams, welche zum einen die interne Developer-Cloudplattform und zum anderen einen Unternehmensweiten Data-Lake zur Verfügung stellen.

4. Team-Interaktionsmodi 

Ineffektivität wird in vielen Organisationen durch schlecht definierte Interaktionen verursacht. Laut TeamTopologies läuft die Beziehung zwischen den Teams auf zwei Dinge hinaus: Wird durch die Zusammenarbeit mit einem anderen Team ein Ziel erreicht oder bietet es dem Team einen Service an. Auf diese Weise werde drei Möglichkeiten festgelegt, wie Teams interagieren können:

Zusammenarbeit enge Zusammenarbeit mit anderen Teams. Dies ist besonders nützlich, wenn Teams neue Technologien oder Techniken erforschen. Die Zusammenarbeit ermöglicht die schnelle Entdeckung neuer Dinge, da kostspielige Übergaben vermieden werden. Am besten verwendet, wenn ein hohes Maß an Anpassungsfähigkeit zwischen zwei Teams erforderlich ist.

X-as-a-Service etwas mit minimaler Zusammenarbeit nutzen oder bereitstellen.
Dieser Interaktionsmodus kann die Liefergeschwindigkeit erhöhen. Team A braucht etwas, um seinen Wert zu liefern, Team B hat eine Dienstleistung ohne großen Aufwand bereitgestellt. Es sind keine langwierigen Gespräche, Besprechungen oder Vorbereitungen erforderlich.

Unterstützen: Einem anderen Team helfen und umgekehrt, Hindernisse zu beseitigen. Der unterstützende Interaktionsmodus eignet sich am besten in Situationen, in denen ein Team die Hilfe eines anderen benötigt. Das Enabling Team versetzt zum Beispiel ein anderes Team in die Lage, effektiver zu sein, schneller zu lernen, eine neue Technologie besser zu verstehen oder Hindernisse zu entdecken und zu beseitigen.  Domain-Driven Design kann hier ein gutes Hilfsmittel sein.

5. Organisatorisches Gespür

Mit “Organisatorisches Gespür” ist gemeint: die Situation zu erkennen und anzupassen. Unternehmen müssen flexibel sein, um sich an Veränderungen anzupassen. Dazu gehört die Anpassung der Struktur und Abläufe. Eine Organisation sollte in der Lage sein, die richtigen Teamstrukturen und Interaktionsmodi anzuwenden.

Woran erkennt man also, dass eine Organisation sich weiterentwickeln muss?

1. Die Software wird für ein Team zu komplex. Während am Anfang jeder ein umfassendes Verständnis davon hat, was vor sich geht, wird das immer schwieriger. Dadurch verlagert sich der Fokus von echten Prioritäten auf den Versuch, Leute zu finden, die kompetent genug sind, um ein bestimmtes Problem zu lösen.
2. Die Lieferfrequenz verlangsamt sich. Die Teammitglieder sehen, dass eine Lieferung mehr Zeit und mehr Schritte erfordert. Um dies zu vermeiden, müssen Teams autonom sein und dürfen nicht darauf warten, dass andere Teams eine neue Infrastruktur erstellen.
3. Mehrere Geschäftsdienste basieren auf einer großen Anzahl zugrunde liegender Dienste. In einigen Sektoren wie Finanzen, Versicherungen, Regierung usw. können hochrangige Dienste auf Dienste auf niedrigerem Niveau angewiesen sein. Die Lösung könnte darin bestehen, die Dienste auf niedrigerer Ebene zu “plattformisieren” und für jeden Dienst auf hoher Ebene Stream-ausgerichtete Teams einzusetzen.

Hier spricht man von der Kompetenz der OrganisationswahrnehmungDies ist die Fähigkeit, die Organisationsituation so zu erfassen oder zu spüren, dass das Überleben der Organisation sichergestellt wird. Einige der Dinge, die eine Organisation „spüren“ muss, sind:

• Müssen die Teaminteraktionsmodi geändert werden?
• Was behindert den Arbeitsfluss für ein bestimmtes Team?
• Sollen wir ein bestimmtes Tool bauen oder können wir es von einem Anbieter bekommen?

Es gibt nicht wenige Systeme, die über viele Jahre hinweg entstanden sind. Diese Systeme haben Abhängigkeiten, die nicht außer Acht gelassen werden können. Die Teaminteraktionsmodi passen sich an das System an und nicht umgekehrt. Die Frage, die sich stellt, ist: Was kann oder muss ich tun, um die Komplexität des Systems zu verringern, damit die Vorteile der Teaminteraktionsmodi zum Tragen kommen, und ist dies aufgrund der Größe des Systems überhaupt möglich?

6. Topologieentwicklung

Sobald eine Organisation auf neue Herausforderungen reagiert, ist davon auszugehen, dass Teams untereinander anders als zuvor interagieren werden.

Dies kann bedeuten, dass Teams neu strukturiert oder neu zusammengesetzt werden, um spezifische Probleme anzugehen oder neue Technologien zu implementieren. Gleichzeitig können sich die Arbeitsabläufe und Prozesse ändern, um die Zusammenarbeit zwischen den Teams zu verbessern. Das übergeordnete Ziel besteht darin, sicherzustellen, dass die Teams flexibel genug sind, um sich an veränderte Anforderungen anzupassen, und dass ihre Interaktionen effektiv sind, um die Ziele der Organisation zu erreichen. Dies erfordert eine kontinuierliche Bewertung und Anpassung der Teamstrukturen und -interaktionen im Einklang mit den sich ändernden Anforderungen und Zielen der Organisation.

7. Team-API 

Eine Beschreibung der Interaktionen mit dem jeweiligen Team: Code, Versionierung, Wiki und Dokumentation, Praktiken und Prinzipien, Kommunikation, Arbeitsinformationen und einiges mehr. Ziel ist es, anderen Teams transparent und in einem einfachen Überblick zu zeigen, an was, wie, mit wem, das Team arbeitet. Ein gutes Beispiel für eine Team API hat Team Topologies selbst auf Github.com veröffentlicht.

Zusammenfassung

Die sieben Grundideen von Team Topologies bieten Vorteile, die die Effektivität der Teamarbeit in Unternehmen steigern können. 

Die Fähigkeit zur Flexibilität und Anpassungsfähigkeit, denn durch die Strukturierung von Teams können Unternehmen schnell auf Veränderungen reagieren und neue Anforderungen integrieren. 

Das Übertragen von Verantwortlichkeiten an eigenständige Teams fördert die Autonomie und Eigenverantwortung, beschleunigt die Entscheidungsfindung und fördert agile Reaktionen auf Herausforderungen (siehe 3. Grundidee), wenn das Management mit einbezogen wird und Verantwortung an die Teams weitergibt.
Ferner ermöglicht Team Topologies die Bildung hochspezialisierter Teams, die sich auf bestimmte Aufgaben oder Technologien konzentrieren können, die Entwicklung von Expertise fördert und die Effizienz steigert. 

Teams dieser Art gibt es bereits zuhauf in Organisationen. Die große Herausforderung sind die Abhängigkeiten der Teams, des Produkts und nicht zuletzt, wie viel Zeit den Teams eingeräumt wird, um zu wachsen und die Fähigkeiten zu entwickeln, die es benötigt. 

Wenn spezialisierte Teams in ihren eigenen Bereichen isoliert arbeiten und den Informationsaustausch behindern, können Kommunikationsbarrieren entstehen. Das Entstehen von Silos innerhalb des Unternehmens, wenn einzelne Teams isoliert arbeiten und der Gesamtüberblick über Projekte verloren geht, steigt.
Dies kann die Synergien zwischen den Teams behindern und die Effizienz beeinträchtigen. Zudem kommt die zunehmende Komplexität und der Koordinationsaufwand, wenn eine Vielzahl spezialisierter Teams gleichzeitig agiert. Eine klare Fokussierung auf gemeinsame Ziele kann dieses Problem mindern. Hierbei könnten sich die Vorgehensweisen von Team Topologies als klarer Vorteil erweisen. Zwar sind nicht alle Ideen von Team Topologies neu, jedoch ermöglicht die globale Sicht auf die Teams eine einheitliche strategische Ausrichtung und ein gemeinsames Vokabular für IT-Projekte. 

Zusammenfassend hier eine Kurzübersichtskarte: QRC Team Topologies

Herausforderungen bei der Umsetzung

Die Theorie von Team Topologies ist vielversprechend, aber wie bei jedem Ansatz gibt es auch Herausforderungen:

• Management-Unterstützung: Ohne ein Management, das die Prinzipien von Autonomie und psychologischer Sicherheit versteht und fördert, wird es schwer, die Teams nachhaltig zu etablieren. Ein Führungsstil der Haltung “Servant Leadership” ist eine Grundvorraussetzung für den Erfolg und die Produktivität der Teams.
• Silos und Abhängigkeiten: Oft arbeiten Teams isoliert voneinander. Hier braucht es gezielte Interaktionsmodi, um Synergien zu fördern.
• Zeit und Ressourcen: Teams benötigen Raum und Zeit, um ihre Arbeitsweisen zu entwickeln und zu verbessern. Teams müssen mit entsprechenden Personen besetzt und “ausgebildet” werden. Dies wird häufig unterschätzt.

Schlussfolgerung und Einladung zur Diskussion zur Verbesserung ihrer Teams Team Topologies bietet eine mächtige Grundlage, um Teams effektiver, autonomer und besser miteinander vernetzt zu gestalten. Die Implementierung erfordert jedoch eine bewusste Anpassung an die jeweilige Organisation und ein Management, das diese Ansätze aktiv unterstützt.  

Diskussionsfragen an den Leser: 

• Wie sieht es bei Euch im Unternehmen aus? Welche Erfahrungen haben Sie mit der Strukturierung von Teams gemacht, und welche Ansätze haben bei Ihnen besonders gut funktioniert?
• Wie können Organisationen sicherstellen, dass ihre Teamstrukturen nicht nur effizient, sondern auch anpassungsfähig sind?
• Welche Herausforderungen sehen Sie bei der Implementierung der vier Teamarten in Ihrem eigenen Umfeld?

Kaschef Yawar

Geschäftsbereichsleitung »Handel« Prokurist

Kaschef Yawar ist ein erfahrener agiler Coach und Berater mit über 15 Jahren Erfahrung in der IT-Branche. In seinen Rollen als Scrum Master, Agiler Coach und Trainer hat er erfolgreich agile Methoden in verschiedenen Unternehmen und auf unterschiedlichen Ebenen eingeführt und begleitet. Sein Fokus liegt dabei hauptsächlich auf Scrum und Kanban, sowie der Arbeit in skalierbaren Frameworks wie SAFe, LeSS und Nexus. Besonders wichtig ist ihm die wertgetriebene Entwicklung, bei der er stets darauf achtet, dass die entwickelten Produkte und Dienstleistungen einen echten Mehrwert für die Kunden schaffen.

k.yawar@atra.consulting    

• LinkedIn