08.04.2021

Legacy Architektur Modernisierung mit Strategic DDD

Nick Tune beschreibt in seinem Paper Legacy Architecture Modernisation With Strategic Domain-Driven Design einen Ansatz zur Architekturmodernisierung von Legacy-Systemen mit Werkzeugen des Domain-Driven Design. Der Ansatz stellt das Business-Ziel der Anwendung in den Fokus der Modernisierung und leitet aus diesem Ziel die erforderlichen Architekturverbesserungen ab.

In der ersten Phase des Vorgehens, dem Business Strategy Alignment, geht es darum sich einen Überblick über das existierende und das zukünftige Geschäftsmodell zu verschaffen. Das Paper schlägt dafür die Erstellung von zwei Business Model Canvas vor, eines zur Dokumentation des Ist- und ein zweites zum Entwurf des Sollzustands.

In der zweiten Phase, dem Target Architecture Design, geht es um den Entwurf einer Zielarchitektur, die die zukünftige Business-Strategie unterstützt. Die initiale Portfolio-Analyse verschafft einen Überblick über die existierenden IT-Services. Als Werkzeug werden Core Domain Charts vorgeschlagen, mit deren Hilfe Subsysteme und Services gemäß ihrer Business-Differenzierung und Komplexität klassifiziert werden. Es werden je ein Ist- und ein Soll-Chart erstellt. Ziel dieser Aktivität ist es herauszubekommen, welche Subsysteme und Services wirklich wichtig sind.

Die Portfolio-Analyse liefert die Kernsysteme des Geschäftsmodells, auf die es sich im Zuge der Architekturmodernisierung zu konzentrieren gilt. Für diese Systeme wird im nächsten Schritt eine moderne, Domänen-orientieren Softwarearchitektur entworfen, die die Business-Vision des initialen Alignments unterstützt. Das Paper schlägt dafür die Durchführung eines Big Picture Event-Storming vor, das dabei hilft die Domäne und die Bounded Contexts des Systems zu entdecken.

Die folgenden beiden Aktivitäten der Target Architecture-Phase fokussieren die technischen Aspekte der Zielarchitektur. So werden mit dem Entwurf der Platform Architecture Entscheidungen über die Zielplattform getroffen, wie z.B. der Cloud- oder On-Premises-Betrieb. Das Paper schlägt für diese Entscheidungen die Verwendung von Thoughtworks’ Digital Platform Strategy Blueprint vor. Mit der Technical Architecture werden ergänzend die technischen Aspekte der Services festgelegt, wie z.B. die Programmiersprache, Protokolle oder die zu verwendenden Frameworks. Als Werkzeuge werden die Architektur-Visualisierungsmethode C4 von Simon Brown und Quality Storming von Michael Plöd vorgeschlagen.

Den Abschluss des Target Architecture Designs bildet der Entwurf einer Organisatorischen Architektur. In ihr wird beschrieben, wie die Teams um die Bounded Contexts der Zielarchitektur herum organisiert werden. Diesem Aspekt misst das Paper besondere Bedeutung zu, da die Organisation der Teams maßgeblichen Einfluß auf den Entwicklungsfluß, die Gesamtproduktivität sowie die Teammoral im Sinne von Eigenverantwortlichkeit haben. Als Werkzeuge werden erweiterte Core Domain Chars, Team Topologies und DDD Context Maps genannt. Außerdem empfiehlt Tune das Durchspielen von Team-übergreifenden End-to-End Value Flows mit Hilfe der EventStorming Team Flow-Methode. Auf diese Art lassen sich etwaige Brüche oder falsche Zuordnungen von Verantwortlichkeiten frühzeitig erkennen.

Das Architecture Roadmap Planning bildet die letzte der drei Phasen der Architekturmodernisierung. Ziel ist die Entwicklung eines sich ggf. über Jahre erstreckenden Modernisierungsplans, der beschreibt, wie die aktuelle Architektur in die modernisierte Architektur überführt werden soll. Die zentralen Tätigkeiten dieser Phase sind Priorisierung und Prozessfindung. Bei der Priorisierung gilt es, die identifizierten Maßnahmen in eine Reihenfolge zu bringen, die sicher stellt, dass sich der Fokus jeweils auf die Maßnamen mit dem größten Mehrwert richtet. Im Rahmen der Prozessfindung werden die Rollen, Regeln und Verantwortlichkeiten für die Zusammenarbeit der Teams diskutiert und festgelegt.

Das Paper betont explizit, dass das beschriebene Vorgehen ein iterativer Prozess ist, der ständig beobachtet und angepasst werden muss. Technologien, Business-Ziele und Teams ändern sich über die Zeit. Jede Änderung kann Auswirkungen auf die Zielarchitektur und damit auf die Planung haben.

Das Paper enthält aus meiner Sicht ein zentrale Kernaussage: Technologie ist kein Selbstzweck, sondern muss sich immer an Business-Zielen orientieren. Aus diesem Grund ist die initiale Erstellung der Business Canvas gefolgt von der Portfolio-Analyse sehr wichtig. Resultierend aus diesen Aktivitäten erhalten wir einen Überblick über den aktuellen und zukünftigen fachlichen Zweck der Systeme und können aus eine Vogelperspektive heraus bewerten, welche Subsysteme geändert werden müssen, um den zukünftigen fachlichen Zweck zu gewährleisten. Aus diesem Zweck leitet sich Architektur gefolgt vom Doing ab, so dass Technologie immer dem Business folgt.

Veröffentlicht von Ralf Wirdemann im April 2021.

Zurück