Das Inverse Conway Maneuver

1. Die Unauflöslichkeit des soziotechnischen Gefüges

In der modernen Softwareentwicklung hat sich ein Paradigmenwechsel vollzogen, der weit über die Einführung neuer Programmiersprachen oder Infrastrukturtechnologien hinausgeht. Es ist die Anerkennung der fundamentalen Realität, dass die Erstellung komplexer Softwaresysteme kein rein technischer, sondern ein zutiefst soziotechnischer Prozess ist.

Dieses Phänomen, bekannt als Conway’s Law, postuliert eine unvermeidliche Homomorphie zwischen der Organisationsstruktur und dem Systemdesign. Während dieses Gesetz über Jahrzehnte hinweg primär als deskriptive Beobachtung – oft mit einem fatalistischen Unterton – rezipiert wurde, hat sich in der jüngeren Vergangenheit eine normative Gegenbewegung formiert: das “Inverse Conway Maneuver” (ICM). Diese Strategie, propagiert von Vordenkern wie ThoughtWorks und kodifiziert durch methodische Rahmenwerke wie “Team Topologies”, kehrt die Kausalität um:

Anstatt zuzulassen, dass dysfunktionale Organisationsstrukturen monolithische und starre Software hervorbringen, zielt das ICM darauf ab, die Organisation proaktiv so zu gestalten, dass die gewünschte Softwarearchitektur – häufig modulare Microservices oder serviceorientierte Architekturen – als natürliches Emergenzphänomen entsteht.

Dieser Artikel beleuchtet die historischen Wurzeln und die empirische Evidenz der “Mirroring Hypothesis”, analysiert die methodischen Werkzeuge zur Umsetzung wie Kognitionspsychologie und Graphentheorie und untersucht kritisch die Fallstudien führender Technologieunternehmen wie Netflix und Amazon. Ziel ist es, ein differenziertes Bild der Wechselwirkungen zwischen “Org Chart” und “Deployment Diagram” zu zeichnen und die Risiken sowie die strategischen Potenziale des ICM für die moderne Produktentwicklung offenzulegen.

2. Historische Genese und theoretisches Fundament

Um die Tragweite des Inverse Conway Maneuver zu verstehen, ist eine archäologische Betrachtung seiner theoretischen Grundlagen unabdingbar. Das Konzept entstand nicht im Vakuum, sondern basiert auf einer soziologischen Einsicht, die ihrer Zeit weit voraus war.

2.1 Melvin Conways ursprüngliche These (1967)

Im Jahr 1967 reichte der Computerwissenschaftler Melvin Conway einen Artikel mit dem Titel “How Do Committees Invent?” bei der renommierten Harvard Business Review (HBR) ein. In diesem Manuskript formulierte er eine These, die später das Verständnis von Systemarchitektur revolutionieren sollte. Conway argumentierte, dass der Designprozess kein rein intellektueller Akt ist, der in einem sozialen Vakuum stattfindet, sondern durch die Kommunikationsstrukturen der entwerfenden Organisation determiniert wird. Seine zentrale Aussage lautete:

Organisationen, die Systeme entwerfen, sind gezwungen, Entwürfe zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.

Interessanterweise lehnte die HBR das Manuskript ab, mit der Begründung, Conway habe seine These nicht ausreichend bewiesen. Dies zeugt von der damaligen vorherrschenden Sichtweise, die Management und Technik als getrennte Sphären betrachtete. Conway veröffentlichte den Artikel schließlich im April 1968 im Magazin Datamation.

Die Logik hinter Conways Beobachtung ist bestechend in ihrer Einfachheit und doch komplex in ihren Implikationen. Sie basiert auf der Notwendigkeit der Interaktion: Damit zwei Softwaremodule A und B zur Laufzeit korrekt miteinander kommunizieren können, müssen die Autoren von Modul A und Modul B während der Entwurfszeit miteinander kommunizieren, um Schnittstellen, Datenformate und Protokolle abzustimmen. Existiert zwischen diesen Autoren – etwa aufgrund von Abteilungsbarrieren, geografischer Distanz oder bürokratischen Hürden – keine Kommunikationslinie, so wird auch im technischen System keine direkte, funktionale Schnittstelle entstehen. Stattdessen werden Workarounds, Duplikationen oder monolithische Blöcke entstehen, die die soziale Isolation widerspiegeln.

2.2 Die Kanonisierung durch Fred Brooks

Der Begriff “Conway’s Law” wurde nicht von Conway selbst geprägt, sondern von Fred Brooks, dem legendären IBM-Architekten und Autor von “The Mythical Man-Month”. Brooks zitierte Conways Aufsatz und erhob die Beobachtung in den Rang eines “Gesetzes”. Er erkannte, dass die Struktur des Systems zwangsläufig kongruent zur Struktur der Organisation sein muss. Brooks leitete daraus frühe Management-Empfehlungen ab: Wenn man ein bestimmtes Systemdesign anstrebt, muss man bereit sein, die Organisation entsprechend zu ändern.

Flexibilität in der Organisation ist somit eine Vorbedingung für Flexibilität im Design.

2.3 Die Definition des Inverse Conway Maneuver

Während Conway und Brooks das Phänomen beschrieben, formulierten Jonny LeRoy und Matt Simons von ThoughtWorks im Dezember 2010 im Cutter IT Journal erstmals explizit die Handlungsanweisung, die heute als “Inverse Conway Maneuver” bekannt ist.

Das ICM ist die normative Umkehrung des deskriptiven Gesetzes. Es besagt: Wenn wir wissen, dass die Organisation die Architektur diktiert, und wir eine spezifische technische Architektur (z.B. lose gekoppelte Services für hohe Wartbarkeit und Skalierbarkeit) anstreben, dann dürfen wir nicht versuchen, gegen die soziale Struktur anzukämpfen. Stattdessen müssen wir die soziale Struktur – die Teams, ihre Größen und ihre Interaktionspfade – so umbauen, dass die gewünschte Architektur der Weg des geringsten Widerstands wird.

Es handelt sich um einen bewussten Eingriff in das soziotechnische System. Anstatt Architekturdiagramme zu zeichnen und zu hoffen, dass die Teams diese umsetzen, “zeichnet” man das Organisationsdiagramm neu, im Wissen, dass die Architektur folgen wird. Ziel ist eine Isomorphie zwischen der Geschäftsstrategie (Business Architecture) und der technischen Architektur.

3. Empirische Evidenz: Die Spiegelungshypothese (Mirroring Hypothesis)

Die Akzeptanz des ICM in der Industrie beruht nicht nur auf anekdotischer Evidenz, sondern wird durch robuste akademische Forschung gestützt. Wissenschaftler der Harvard Business School und des MIT haben Conways These unter dem Begriff “Mirroring Hypothesis” empirisch validiert.

3.1 Die Studien von MacCormack, Rusnak und Baldwin

In einer wegweisenden Reihe von Studien, beginnend mit “Exploring the Duality between Product and Organizational Architectures” (2008), untersuchten Alan MacCormack und seine Kollegen die Beziehung zwischen Organisationsform und Softwaremodularität. Sie nutzten einen methodisch eleganten Ansatz (“Natural Experiment”), indem sie Softwareprodukte verglichen, die funktional identisch waren, aber von radikal unterschiedlichen Organisationen entwickelt wurden.

Der Vergleich konzentrierte sich auf:

1. Proprietäre Software (Closed Source): Entwickelt von fest angestellten Teams in hierarchischen Firmenstrukturen, oft co-loziert.
2. Open-Source-Software: Entwickelt von lose gekoppelten, global verteilten Communities, die primär asynchron kommunizieren.

Die Forscher fanden heraus, dass Open-Source-Software modularer war, nicht weil die Entwickler “besser” waren, sondern weil die Organisationsstruktur (verteilte Freiwillige) eine monolithische Architektur unmöglich machte. Man kann keinen Monolithen warten, wenn man sich nie trifft. Die soziale Entkopplung erzwang die technische Entkopplung.

3.2 Die “Mirroring Trap” und Actionable Transparency

Die Studien identifizierten jedoch auch Risiken. Die strikte Spiegelung kann zur “Mirroring Trap” führen: Unternehmen, die ihre Organisation perfekt auf ihre aktuelle Architektur optimieren, verlieren die Fähigkeit zur Innovation, wenn sich die technologischen Anforderungen ändern. Sie werden blind für Architekturen, die nicht in ihr Organigramm passen.

Ein interessantes Nebenresultat war das Konzept der “Actionable Transparency”. In Fällen, in denen die Spiegelungshypothese nicht zutraf (ca. 31% der Fälle in einigen Datensätzen), fanden die Forscher Mechanismen, die es Entwicklern erlaubten, die soziale Distanz zu überbrücken, ohne die Architektur zu koppeln. Dies geschah durch extrem transparente Dokumentation und Standards, die es ermöglichten, Wissen zu teilen, ohne direkte Kommunikation zu benötigen – ein Prinzip, das für das ICM von zentraler Bedeutung ist.

4. Methodische Operationalisierung: Team Topologies

Während Conways Gesetz das “Warum” liefert, fehlte lange Zeit das “Wie”. Wie genau schneidet man Teams, um eine bestimmte Architektur zu fördern? Mit dem Erscheinen des Buches “Team Topologies” von Matthew Skelton und Manuel Pais (2019) erhielt die Industrie das Vokabular und die Methoden, um das ICM präzise anzuwenden.

4.1 Kognitive Belastung (Cognitive Load) als Design-Constraint

Ein zentraler Beitrag von Team Topologies zur Theorie des ICM ist die Integration der Kognitionspsychologie, spezifisch der “Cognitive Load Theory” von John Sweller (1988). Die Autoren argumentieren, dass Conways Gesetz nicht nur durch Kommunikationspfade wirkt, sondern auch durch die begrenzten kognitiven Ressourcen eines Teams.

Wenn ein Team für ein Software-Subsystem verantwortlich ist, das die kognitive Kapazität des Teams übersteigt (zu viele Kontexte, zu komplexer Code), leidet die Qualität. Das Team verfällt in einen reaktiven Modus, baut technische Schulden auf und schafft eng gekoppelte “Spaghetti-Architekturen”, um kurzfristig zu überleben. Das ICM nach Team Topologies fordert daher, die Architektur so zu schneiden, dass jedes Teilmodul “in die Köpfe” des zuständigen Teams passt. Softwarearchitektur wird somit zur Funktion der kognitiven Kapazität der Organisation.

4.2 Die vier fundamentalen Team-Typen

Um eine auf Flow optimierte Architektur zu erzwingen, definiert Team Topologies vier spezifische Team-Typen. Die Wahl dieser Typen ist ein direkter Akt des Inverse Conway Maneuver:

1. Stream-aligned Team: Dies ist der primäre Team-Typ. Es ist auf einen kontinuierlichen Strom von Arbeit ausgerichtet (z.B. ein Feature, eine User Journey, ein Produktsegment).

   • Architektonische Implikation: Um “Stream-aligned” zu sein, muss das Team in der Lage sein, Änderungen unabhängig in Produktion zu bringen. Dies erzwingt eine Architektur, die vertikal geschnitten ist (Microservices oder Self-Contained Systems) und entkoppelt von anderen Streams ist.

2. Enabling Team: Experten, die Stream-aligned Teams helfen, neue Technologien oder Praktiken zu adaptieren.

   • Architektonische Implikation: Sie verhindern, dass Stream-aligned Teams “das Rad neu erfinden” oder aus Unwissenheit schlechte Architekturen bauen. Sie sind Katalysatoren für sauberes Design.

3. Complicated Subsystem Team: Verantwortlich für Teile des Systems, die so komplex sind (z.B. ein mathematisches Modell, eine Video-Processing-Engine), dass sie spezielles Expertenwissen erfordern.

   • Architektonische Implikation: Dieses Team kapselt Komplexität. Das Subsystem muss über eine strikte Schnittstelle verfügen, damit die konsumierenden Stream-aligned Teams sich nicht mit der internen Komplexität belasten müssen. Dies fördert Modularität durch Kapselung.

4. Platform Team: Bereitstellung von internen Services (Infrastruktur, Tools), die von Stream-aligned Teams konsumiert werden.

   • Architektonische Implikation: Dies ist der Schlüssel zu modernen Cloud-Architekturen. Die Plattform wird als Produkt behandelt (“Thinnest Viable Platform”). Sie ermöglicht den Stream-aligned Teams Autonomie, indem sie kognitive Last (z.B. “Wie betreibe ich Kubernetes?”) in die Plattform verlagert und über APIs abstrahiert.

4.3 Interaktionsmodi als Steuermechanismus

Das ICM wird nicht nur durch die statische Existenz von Teams umgesetzt, sondern durch die dynamische Gestaltung ihrer Interaktion. Team Topologies definiert drei Modi, die unterschiedliche architektonische Ergebnisse fördern:

• Collaboration (Zusammenarbeit): Zwei Teams arbeiten eng zusammen, um Neues zu entdecken. Die Grenzen verschwimmen.

  • Einsatz im ICM: Notwendig in frühen Phasen, um API-Grenzen zu finden. Wenn jedoch dauerhaft beibehalten, führt dies zu eng gekoppelten Monolithen, da keine klare Schnittstelle entsteht.

• X-as-a-Service: Ein Team konsumiert die Leistung eines anderen wie einen externen Dienst (über API/Dokumentation).

  • Einsatz im ICM: Das Ziel für stabile Architekturen. Es erzwingt klare Schnittstellen, Versionierung und Entkopplung. Das ICM besteht oft darin, Teams von “Collaboration” zu “X-as-a-Service” zu bewegen.

• Facilitating (Unterstützung): Ein Team hilft einem anderen, Hindernisse zu beseitigen.

Die bewusste Wahl des Interaktionsmodus ist ein Werkzeug des Architekten: Will ich Entkopplung erzwingen? Dann wähle ich X-as-a-Service und verbiete (oder erschwere) direkte Kollaboration auf Code-Ebene.

5. Fallstudien und industrielle Praxis

Die Theorie des ICM wurde in der Praxis von einigen der erfolgreichsten Technologieunternehmen der Welt validiert, oft bevor der Begriff selbst populär wurde.

5.1 Netflix: Die radikale Zersplitterung des Monolithen

Netflix wird häufig als das ultimative Beispiel für die erfolgreiche Anwendung des ICM zitiert. Der Übergang von einer monolithischen DVD-Verleih-Architektur zu einer globalen Streaming-Plattform basierend auf Microservices war untrennbar mit einer organisatorischen Transformation verbunden.

• Organisatorischer Wandel: Netflix führte kleine, autonome Teams ein, die nach dem Prinzip “Freedom and Responsibility” agierten. Jedes Team war vollständig verantwortlich für seinen Service, vom Design bis zum Betrieb (“Full Cycle Development”). Es gab keine separaten QA- oder Ops-Departments, die als Silos hätten wirken können.
• Die Spiegelung: Da jedes Team autonom agieren musste und keine gemeinsamen Datenbanken oder Release-Trains nutzen konnte (um die Unabhängigkeit zu wahren), entstand eine Architektur aus Hunderten von winzigen, lose gekoppelten Microservices. Die API-Grenzen entsprachen exakt den Teamgrenzen. Als Netflix beispielsweise entschied, dass das “Digital Onboarding” flexibler sein muss, schufen sie nicht nur Code, sondern ein dediziertes Team dafür, was zu einer entkoppelten Onboarding-Architektur führte.
• Tooling als Enabler: Um zu verhindern, dass Autonomie in Chaos endet, schuf Netflix “Paved Paths” (gepflasterte Wege) – Plattform-Tools, die Teams nutzen konnten, aber nicht mussten. Dies ist ein Beispiel für ein starkes Platform Team, das die kognitive Last der Stream-aligned Teams reduziert.

5.2 Amazon: Das API-Mandat und Two-Pizza Teams

Vielleicht das berühmteste historische Beispiel für ein diktiertes ICM ist das “API Mandate” von Jeff Bezos bei Amazon um das Jahr 2002.

• Der Befehl: Bezos ordnete an, dass alle Teams ihre Daten und Funktionalitäten ausschließlich über Service-Schnittstellen (APIs) exponieren durften. Direkte Datenbankzugriffe, Shared Memory oder Hintertüren waren streng verboten. Wer sich nicht daran hielt, wurde entlassen.
• Two-Pizza Teams: Parallel dazu führte Amazon die “Two-Pizza Rule” ein: Kein Team sollte größer sein, als dass es von zwei Pizzen satt würde (ca. 6-10 Personen).
• Die ICM-Logik: Die Beschränkung der Teamgröße limitierte die kognitive Kapazität und die Kommunikationsbandbreite. Ein kleines Team kann keinen riesigen Monolithen warten. Es muss sich auf einen kleinen, überschaubaren Service konzentrieren. Das API-Mandat erzwang die Formalisierung der Kommunikation zwischen diesen Teams.
• Resultat: Das Ergebnis war eine massive Service-Orientierte Architektur (SOA), die so robust und entkoppelt war, dass Amazon sie später als Produkt (AWS) extern verkaufen konnte. Die interne organisatorische Entkopplung war die Vorbedingung für die externe Cloud-Plattform.

5.3 Spotify: Modell vs. Realität

Das “Spotify-Modell” (Squads, Tribes, Chapters, Guilds) ist ein weiteres Beispiel für den Versuch, Organisation und Architektur in Einklang zu bringen. Squads sollten autonom sein wie Startups, was eine entkoppelte Architektur voraussetzt.

Viele Unternehmen kopieren die Namen (Tribes, Squads), ohne die technische Architektur zu ändern (der sog. “Cargo Cult”). Sie haben “autonome Squads” auf dem Papier, aber einen monolithischen Mainframe im Hintergrund. Das Resultat ist oft katastrophal: Die Organisation suggeriert Unabhängigkeit, aber der Code erzwingt Abhängigkeit. Dies illustriert, dass das ICM scheitert, wenn es nur als HR-Maßnahme ohne technische Begleitung verstanden wird.

6. Implementierungsstrategien: Der Weg zur Isomorphie

Wie wendet man das Inverse Conway Maneuver konkret an? Es ist kein einmaliger “Re-Org”, sondern ein Prozess. Basierend auf den Erfahrungen von ThoughtWorks und den Prinzipien von Team Topologies lassen sich folgende Schritte synthetisieren.

6.1 Assessment und Shared Language

Bevor Teams verschoben werden, muss eine Analyse des Status Quo erfolgen.

• Flow-Analyse: Wo stockt die Wertschöpfung? Wo warten Teams aufeinander? Diese Wartezeiten (Wait Times) sind oft Indikatoren für Schnittstellen, die im Code fehlen, aber in der Organisation existieren (oder umgekehrt).
• Gemeinsame Sprache: Es ist essenziell, Begriffe wie “Stream-aligned” oder “Kognitive Last” im Management und in der Entwicklung zu etablieren. Das ICM erfordert, dass HR, Business und Tech am selben Tisch sitzen.

6.2 Definition der Ziel-Architektur (Bounded Contexts)

Das ICM beginnt nicht mit dem Organigramm, sondern mit der Architekturvision. Basierend auf Domain-Driven Design (DDD) müssen die “Bounded Contexts” (abgegrenzte Domänen) identifiziert werden. Welche Teile des Systems können logisch getrennt werden? Ein “Inverse Conway Maneuver” ohne eine Vorstellung der Ziel-Architektur führt lediglich zu Chaos, nicht zu Modularität.

6.3 Team-Design und Pilotierung

Anstatt die gesamte Organisation umzuwerfen, empfiehlt sich ein evolutionärer Ansatz.

• Pilot-Teams: Man bildet ein erstes “Stream-aligned Team”, das vertikal für einen Bounded Context zuständig ist.
• Reverse Engineering der Kommunikation: Man beobachtet, mit wem dieses Team kommunizieren muss. Wenn es ständig mit dem Datenbank-Team reden muss, ist die Architektur noch nicht entkoppelt. Das Ziel ist es, diese Abhängigkeiten in “X-as-a-Service” Beziehungen umzuwandeln oder die Kompetenz (z.B. DB-Wissen) in das Team zu holen.

6.4 Die Rolle der Plattform (Thinnest Viable Platform)

Ohne eine funktionierende Plattform ist das ICM oft zum Scheitern verurteilt. Wenn man monolithische Strukturen aufbricht, steigt die Komplexität der Infrastruktur für die einzelnen Teams. Ein dediziertes Plattform-Team muss diese Komplexität absorbieren, sonst “ertrinken” die Stream-aligned Teams in kognitiver Last (“Cognitive Load Overload”). Die Plattform ist der Enabler der Autonomie.

7. Kritische Diskursanalyse und Risiken

Trotz der Popularität des ICM gibt es signifikante Kritik und Risiken, die in einer wissenschaftlichen Betrachtung nicht fehlen dürfen.

7.1 Der logische Fehlschluss (Normativ vs. Deskriptiv)

Kritiker wie Patricia Aas weisen darauf hin, dass das ICM auf einem logischen Fehlschluss beruhen könnte. Conway’s Law ist deskriptiv: “Wenn Organisation A, dann Architektur A”. Daraus folgt logisch nicht zwingend: “Wenn Organisation B, dann gute Architektur B”.

Es ist möglich, Teams zu trennen (Organisation B), und als Resultat eine Architektur zu erhalten, die zwar getrennt, aber dysfunktional, inkonsistent und fehlerhaft ist. Trennung allein garantiert keine Qualität. Das ICM kann, naiv angewendet, zu “Distributed Monoliths” führen – Systemen, die alle Nachteile von verteilten Systemen (Latenz, Komplexität) und alle Nachteile von Monolithen (enge Kopplung) vereinen.

7.2 “MonolithFirst” und verfrühte Optimierung

Martin Fowler und Stefan Tilkov debattieren seit langem über den richtigen Startpunkt. Fowler argumentiert für “MonolithFirst”: Man sollte mit einem Monolithen starten, um die Domänengrenzen zu lernen, und erst dann, wenn man die Grenzen kennt, das System (und die Organisation) aufsplitten.

Wendet man das ICM zu früh an (auf ein neues Produkt), zieht man Grenzen an den falschen Stellen. Da Organisationsgrenzen schwerer zu verschieben sind als Codezeilen (“Organizational Rigidness”), zementiert man so eine falsche Architektur, die später enorme Kosten verursacht.

7.3 Kulturelle Trägheit und Psychologische Sicherheit

Das ICM ist ein Eingriff in das soziale Gefüge. Es zerstört bestehende Teams und Loyalitäten. Die Forschung von Google (Project Aristotle) und DORA zeigt, dass “Psychologische Sicherheit” der wichtigste Faktor für Team-Performance ist. Ein aggressives ICM, das Teams als Schachfiguren betrachtet, kann diese Sicherheit zerstören. Wenn Menschen Angst haben oder sich isoliert fühlen, kommunizieren sie schlechter – und nach Conway’s Law führt schlechte Kommunikation zu schlechterer Software. Eine Reorganisation ohne kulturelle Begleitung (“Change Management”) ist daher kontraproduktiv.

7.4 Legacy-Systeme (Brownfield)

Das ICM funktioniert am besten auf der “Grünen Wiese” (Greenfield). In der Realität haben Unternehmen jedoch existierende, starre Monolithen (Brownfield). Mathias Verraes warnt: “Conway’s Law doesn’t apply to rigid designs” in dem Sinne, dass eine Änderung der Organisation den Code nicht magisch ändert. Wenn der Code physisch nicht trennbar ist, führt die Trennung der Teams nur zu Frustration. Team A kann nicht deployen, weil Team B den Code blockiert, obwohl sie laut Organigramm unabhängig sein sollten. In solchen Fällen muss technische Refaktorisierung der organisatorischen Trennung vorausgehen oder parallel laufen.

8. Fazit und Ausblick

Das Inverse Conway Maneuver repräsentiert eine der wichtigsten strategischen Entwicklungen im modernen Software-Engineering. Es hebt die künstliche Trennung zwischen Organisationsentwicklung und Systemarchitektur auf und bietet einen Hebel, um in einer zunehmend komplexen Welt handlungsfähig zu bleiben.

Die wissenschaftliche Evidenz durch die Mirroring Hypothesis und die Erfolge von Unternehmen wie Amazon und Netflix validieren das Kernkonzept: Organisation und Technik sind zwei Seiten derselben Medaille. Wer schnelle, skalierbare und modulare Software will, muss eine schnelle, skalierbare und modulare Organisation bauen.

Doch das ICM ist kein Allheilmittel. Es erfordert Demut vor der Komplexität sozialer Systeme und Respekt vor den bestehenden technischen Altlasten. Es darf nicht als mechanistischer Prozess missverstanden werden (“Wir splitten die Teams, dann wird der Code gut”), sondern muss als kontinuierlicher, evolutionärer Prozess der Anpassung verstanden werden, der Kognitionspsychologie, technische Exzellenz und empathische Führung vereint. In der Zukunft wird die Fähigkeit, das “Organigramm zu refaktorisieren”, für CTOs und Architekten genauso wichtig sein wie die Fähigkeit, Code zu refaktorisieren.