Zurück zur Übersicht

Wissen, 16. Juni 2022

Legacy-Software Modernisieren mit Strategic DDD

Dieser Beitrag beschreibt eine Idee von Nick Tune [1] 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.

Überblick verschaffen

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.


Zielarchitektur entwerfen

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.

Domänen- und Kontextanalyse mit Event-Storming

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.

Entwurf der Technischen Architektur: C4

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.

Entwurf der Organisatorischen Architektur

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 Einfluss auf den Entwicklungsfluss, 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.

Planung der Architektur-Roadmap

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ßnahmen 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.


Fazit: Technologie ist kein Selbstzweck

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.

Links

Autor:

Ralf Wirdemann
Software-Entwickler
  • Schwerpunkt Go und Java

  • Software-Architektur und -Modernisierung

  • Autor und Vortragender

Auch spannend