BLOG
Viele Architekturvorhaben beginnen mit einer scheinbar einfachen Frage:
Können wir das noch mit einem Team umsetzen?
Spätestens bei größeren Migrationen, Modernisierungen oder Legacy-Ablösen wird klar, dass mehrere Teams parallel arbeiten müssen. Doch damit entstehen auch neue Herausforderungen:
Software Teams und deren Architekt:innen stehen dabei nicht nur vor einer technischen, sondern auch vor einer organisatorischen Herausforderung.
Mehr Teams bedeuten nicht automatisch mehr Geschwindigkeit.
Wer Arbeit parallelisieren möchte, muss zuerst verstehen:
Welche Teile des Systems können überhaupt unabhängig voneinander entwickelt werden?
Genau an dieser Stelle wird Architektur zu einem Werkzeug für Planung und Koordination.
Ein Teil eines bestehenden Systems soll abgelöst werden. Mehrere fachliche Entitäten müssen in eine neue Lösung überführt werden. Zusätzlich fachliche Anpassungen wie z. B. Validierungs- oder Strukturänderungen sind notwendig. Einige Schnittstellen verbleiben zunächst noch im Altsystem, wodurch beide Welten vorübergehend parallel betrieben werden müssen. Teilablösen in diesem Muster sind Bekannt als Strangler Fig Pattern.
Das verantwortliche Team erkennt früh, dass die geplante Umsetzung innerhalb des vorgegebenen Zeitrahmens nur schwer zu schaffen sein wird. Zusätzliche Teams stehen zur Unterstützung bereit.
Hierarchische Dekomposition ist eine bewährte Methode, um große Aufgabenstellungen in kleinere, überschaubare Teilprobleme zu zerlegen. In diesem Fall bedeutet das: Das Legacy-Ablöseprojekt wird in Migration, Administration und Datenrückspielung zerlegt.
Aus einem komplexen Vorhaben entstehen dadurch klar abgrenzbare Arbeitspakete, die analysiert, priorisiert und später einzelnen Teams zugeordnet werden können.
Eine solche Zerlegung hilft dabei:
Für diese konkrete Aufgabenstellung ergab sich folgende Zerlegung – vereinfacht und unvollständig, aber praxisorientiert. Eine wichtige Beobachtung: Die Zerlegung ist nicht perfekt separiert, sondern spiegelt sowohl fachliche als auch technische Herausforderungen wider. Dies ist typisch für Architekturdekompositionen in der Praxis: Organisatorische und technische Realität überschneiden sich, und diese Vermischung muss in der Zerlegung abgebildet werden.
Die Problemdekomposition ergab drei zentrale Bereiche:
Achtung – die Zerlegung umfasst nicht nur fachliche Aspekte, sondern auch konkrete technische Herausforderungen, die für die beteiligten Teams relevant waren.
Bei solchen Problemzerlegungen werden oft mehrere Perspektiven genutzt:
Technische Perspektive: Identifizierung von Grenzen anhand von Datenflüssen und Schnittstellen – also Stellen, an denen Daten von einem Bereich in einen anderen fließen und sich die Zuständigen Systeme ändern.
Fachliche Perspektive: Prozesse, die von einer Nutzergruppe in einem System abgeschlossen werden, bilden oft sinnvolle Zerlegungspunkte.
Organisatorische Perspektive: Berücksichtigung der vorhandenen Team-Kompetenzen und des geplanten Know-how-Aufbaus:
Für die Technische und Fachliche Perspektive hat sich Eventstorming und Boundary Events in der Praxis bewährt, für die organisatorische Perspektive helfen uns Prinzipien aus Team Topologies.
Diese Perspektiven zusammen führen zu einer Zerlegung, die sowohl technisch, fachlich als auch organisatorisch sinnvoll ist.
Die Datenmigration war von folgenden Themen geprägt:
Langfristiger fachlicher Know-how-Aufbau war hier nicht notwendig.
Prinzipiell war es sehr simpel – einige Entitäten mit Create/Read/Update/Delete erstellen und persistieren. Jedoch gab es architektonische Herausforderungen, ein Angular UI und ein AngularJS UI zu integrieren und ebenfalls die aktuellsten .NET-Versionen zu verwenden.
Fachlich war dies herausfordernd, da die bestehende Umsetzung im Altsystem einige Schwächen hatte. Beispielsweise gab es an einigen Stellen zu viele Validierungen, während an anderen wichtige Prüfungen fehlten. Auch Workflow und Navigation waren für die Nutzer:innen nicht optimal. Hier galt es, die Gelegenheit zu nutzen, bestehende Schwächen zu adressieren und die Lösung für ihre Nutzer:innen zu verbessern, anstatt eine reine 1:1-Ablöse umzusetzen.
Bei der Datenrückspielung ins Altsystem wird ein technischer Mechanismus zwischen den Systemen für den Datentransport benötigt. Ebenfalls wird ein Team benötigt, das das Mapping von neuer Struktur auf die alte Struktur versteht. Die primäre Herausforderung hier ist das Verständnis der alten Struktur.
Diese Zerlegung war die Grundlage dafür, später Teamgrenzen zu ziehen und die Zielarchitektur zu definieren.
Nach der Theorie kommt die Praxis
Jetzt selbst ins Training einsteigen und die Methoden und Inhalte, hands-on vertiefen.
Sobald klar ist, welche Probleme gelöst werden müssen, stellt sich die nächste Frage:
Wo verlaufen die natürlichen Grenzen für eine Aufteilung der Arbeit? Diese Frage lässt sich nur schwer anhand von Texten, Tickets oder Anforderungen beantworten. Architekturvisualisierung schafft hier die notwendige Transparenz.
Das C4-Modell bietet einen pragmatischen Ansatz, um Architekturen auf verschiedenen Ebenen sichtbar zu machen:
Für die Planung einer parallelen Umsetzung sind insbesondere Container- und Component-Diagramme hilfreich.
Sie machen sichtbar:
Statt abstrakt über Systeme zu sprechen, entsteht ein gemeinsames Bild der angestrebten Zielarchitektur.
Ausgehend von der Problemzerlegung und der Ist-Architektur ergibt sich die Zielarchitektur – eine von vielen möglichen Lösungen, geprägt von Rahmenbedingungen und strategischen Investments. Einige Entscheidungen werfen bei verschiedenen Stakeholdern Fragen auf und werden über Architecture-Decision Records dokumentiert.
Bei der Erstellung dient die Problemzerlegung als praktische Checkliste. Die zentrale Frage lautet:
Wo im System ist diese Problemstellung gelöst?
Diese Frage führt zu wertvollen Erkenntnissen: Sie zeigt, welche Probleme bereits gelöst wurden, und macht deutlich, welche Komponenten welche Logiken erhalten. Gleichzeitig entsteht eine klare Übersicht der Schnittstellen zwischen den Systemen – eine Eigenschaft, die für die Arbeitsaufteilung erheblich hilft.
Mit der Zielarchitektur lassen sich nun die Teams auf die Komponenten verteilen. In einer solchen Zuordnung entstehen typischerweise Hotspots – Stellen, wo interessante Entscheidungen notwendig werden und wo die Architekturvisualisierung ihren Wert beweist.
Im neuen System entstehen technische Herausforderungen bei der Integration verschiedener UI-Frameworks und moderner .NET-Versionen. Zusätzlich einen Messagebus wie RabbitMQ zu implementieren, würde zuviel Lernkruve für das Team an dieser Stelle bedeutet. Eine sinnvolle Strategie: Ein separates Team übernimmt die Implementierung und den Know-how-Aufbau für RabbitMQ und arbeitet mit Dummy-Werten, während das Anwendungs-Team zunächst mit simplen REST-Schnittstellen arbeitet. Diese Aufteilung reduziert Cognitive Load und ermöglicht paralleles Arbeiten.
Ein Migration Report gehört logisch ins Migrationstool. Oft sind die genauen Anforderungen an solche Reports erst während der Implementierung klar – es ist unklar, wie viele Fehler tatsächlich auftreten und welche Fehlertypen relevant sind. In einer solchen Situation macht es Sinn, die Report-Entwicklung dem Team mit dem fachlichen Know-how zuzuordnen, nicht dem Team, das die technische Migration umsetzt. So kann fachliche Validierung und technische Umsetzung getrennt werden.
Das Diagramm für die bestehende Zielarchitektur lässt sich nun mit Teams hinterlegen. Für diese Illustration gehen wir von einer vereinfachten Zuordnung zu 3 Teams aus. Im echten Projekt gab es noch temporäre Plattform Teams für die Erarbeitung des Messagebus und eines Nuget Packages für diesen. Dies ist keine Standardmäßige Verwendung von C4 Diagrammen, sie erweist sich aber in der Praxis regelmäßig als sehr hilfreich.
Das Teammapping macht Bereiche sichtbar, die besondere Aufmerksamkeit benötigen, um eine reibungslose parallele Entwicklung zu ermöglichen:
Das zentrale Problem bei Multi-Team-Projekten ist klar: Parallele Arbeit funktioniert nur, wenn die Architektur die Unabhängigkeit ermöglicht.
Mit einer klaren Zielarchitektur lässt sich erkennen:
Dies führt zu einem wichtigen Perspektivwechsel: Statt „Wie verteilen wir die Arbeit auf mehrere Teams?“ zu fragen, gestalten wir die Architektur so, dass Teams unabhängig arbeiten können. Aus dieser Umkehrung entstehen natürliche, koordinierbare Teilaufgaben – und die Architektur wird vom Dokumentationsinstrument zum Planungsinstrument.
Die Diagramme und Teamzuordnung ermöglichen:
Solche Visualisierungen und Problemdekomposition helfen den verschiedenen Stakeholdern – technisch und nicht-technisch – die Komplexität und gegenseitigen Abhängigkeiten zu verstehen. Sie werden zur Grundlage für Projektplanung und Fortschrittskommunikation.
Wer Architektur nicht nur als Dokumentationsaufgabe versteht, sondern als Werkzeug zur Gestaltung komplexer Vorhaben einsetzt, profitiert von Methoden wie Hierarchischer-Dekomposition, Architekturvisualisierung und systematischer Analyse von Abhängigkeiten.
Diese Fähigkeiten helfen nicht nur dabei, Arbeit auf mehrere Teams zu verteilen und komplexe Vorhaben planbar zu machen. Sie sind auch die Voraussetzung, um moderne AI-Werkzeuge effektiv einzusetzen.
Denn bevor AI bei Analyse, Dokumentation, Implementierung oder Planung unterstützen kann, müssen Systeme, Verantwortlichkeiten und Problemstellungen verständlich strukturiert sein. Architekturarbeit schafft genau diese Transparenz.
Wer Probleme zerlegen, Zusammenhänge sichtbar machen und klare Grenzen zwischen Komponenten definieren kann, schafft die Voraussetzungen dafür, dass sowohl Teams als auch AI-Assistenten effizient und parallel an derselben Lösung arbeiten können.
Methoden wie Architektur-Dekomposition, C4-Modellierung und Architekturvisualisierung sind daher nicht nur Werkzeuge für heutige Softwarearchitekt:innen – sie gehören zu den Schlüsselkompetenzen für die Entwicklung komplexer Systeme in einer AI-unterstützten Zukunft.
Mit anschließender Zertifizierungmöglichkeit