IT-Architektur-Beratung
IT-Architektur anhand Domain-driven Design, Architekturmuster und ARC42
Meine bevorzugte Vorgehensweise, die IT-Architektur von Software-Systemen zu entwickeln basiert auf der Kombination aus „Domain-driven Design“ sowie den Architekturmustern „Ports&Adapters“ bzw. „Clean Architecture“. Entscheidend ist es dabei natürlich, die bekannten Muster und Ansätze im konkreten Kontext so anzuwenden und anzupassen, dass es für die Gegebenheiten der kundenseitigen Systemlandschaft bzw. das zu entwickelnde System optimal ist.
Für die Dokumentation der IT-Architektur hat sich der ARC42 Ansatz als sehr sinnvoll und zielführend erwiesen.
Refactoring-Analyse für monolithische Altanwendungen
Häufig kann ein langjährig gewachsenes, großes und monolithisches Softwaresystem nicht im Rahmen eines einzelnen, zeitlich überschaubaren Projekts abgelöst werden. Stattdessen muss davon ausgegangen werden, dass große Teile des Altsystems noch über Jahre weiterbetrieben werden müssen und nur Step by Step einzelne Teile herausgelöst werden können. Dies geht häufig damit einher, zumindest die gravierendsten „Pain-Points“ der Altanwendung zu identifizieren und konkret umsetzbare Verbesserungsvorschläge zu erarbeiten.
Beratung zur Fachlichen Analyse
Ob „Grüne Wiese“- oder ein Refactoring-Projekt: Architektur und Design von Software-Systemen basiert grundsätzlich auf qualitativ hochwertigen fachlichen Anforderungen. Es gibt in dieser Hinsicht zwei Varianten, wie ich Ihr Projekt begleiten kann:
Review der Fachliche Analyse aus Sicht des IT-Architekten
Idealerweise begleitet ein IT- bzw. Software-Architekt oder Lead-Entwickler das Projekt bereits in einer frühen Phase, also sobald die Ermittlung der fachlichen Anforderungen beginnt. Mit seinem technischen Blickwinkel und dem Wissen, welche Problemstellungen sich im IT-Design und der Umsetzung ergeben werden, bringt er viele Fragestellungen ein, die sich gravierend auf die fachliche Analyse auswirken können und ansonsten oft erst unnötig spät auf den Tisch kommen.
So wird unnötiger Mehraufwand vermieden, der entsteht, weil fachliche Themen, die bereits abgehakt schienen, nochmal neu beleuchtet werden müssen. Sofern die fachlichen Anforderungen bereits erhoben sind, ist ein Review dieser Anforderungen durch den Architekten notwendig.
Federführende Durchführung der Fachlichen Analyse
Effective Usecases plus strukturierte Requirements
Als Methode für die fachliche Analysephase präferiere ich aus langjähriger eigener Erfahrung nach wie vor einen Usecase-zentrierten Ansatz – im Sinne der „Effective Usecases“ von Alistair Cockburn. Hierbei wird ein Fachprozess schnell und effizient hierarchisch strukturiert. Wünscht der Kunde eine grafische Darstellung – z.B. in Form von BPMN – erscheint es dennoch sinnvoll, die ersten Analyse-Iterationen zuerst textuell zu erfassen. Der Einstieg in die grafische Modellierung erfolgt erst ab einer gewissen Stabilisierung der „Summary-Level-Usecases“. Dies ist schlicht und ergreifend dem deutlich höheren Änderungsaufwand geschuldet, der entsteht, wenn man von Anfang an grafisch modelliert.
Agilität und Usecases
Dabei ist die Usecase-basierte Vorgehensweise kein Widerspruch zu agilen Vorgehensweisen, im Gegenteil: Aus den Usecases können sehr gut Userstories abgeleitet werden. Es ist jedoch erforderlich, zuerst mit einem Usecases-Grundstock in die Breite zu gehen (Pattern „Breadth Before Depth“) um anschließend sukzessive auch in die Tiefe der Usecases einzusteigen und dabei immer einen ausreichenden Vorsprung vor der Entwicklung zu bewahren. Somit lässt sich vermeiden, dass das Entwicklungsteam nicht aufgrund eines leeren Backlogs ins Stocken gerät.
Das Problem mit Prosa-Fachkonzepten
Ich habe mehrmals erlebt, dass in Projekten, in denen keine Usecases aufgeschrieben wurden (Stichwort „Prosa-Fachkonzept“), letztlich der Überblick über komplexere Zusammenhänge verloren ging und immer wieder unnötige die Diskussionen über Details entstanden, weil man sich über den Kontext nicht klar war oder aneinander vorbei redete. Ebenso wird eine saubere und vollständige Formulierung späterer Änderungswünsche im Falle von Prosa-Konzepten deutlich schwieriger .
Das klassische Beispiel schlechthin sind die „Variationen“ des sog. „Haupterfolgsszenarios“ eines Usecase. Hat man keine Usecases, werden häufig diverse Nebenabläufe übersehen. Dies führt unweigerlich dazu, dass dieser Teil der Anforderungen erst später entdeckt wird und somit weitere Änderungswünsche erst in einer noch späteren Entwicklungsphase nachgeschoben werden müssen.
Negative Auswirkungen auf Termin und Code-Qualität
Da der erwartete „Produktionstermin“ dann oft schon viel näher gerückt ist, steckt hier das negative Potential, dass die Entwickler unter dem Zeitdruck ihre eigenen Qualitätsstandards (sofern sie welche haben) über Board werfen um vermeintlich schneller ausliefern zu können. Dies ist insbesondere dann der Fall wenn die Qualitätsstandards nicht fest vom Kunden vorgegeben sind sondern vom individuellen Know-how des einzelnen Entwicklers abhängen. Entwickler, die die „Clean-Code-Prinzipien“ und Tools wie Sonarqube gewissenhaft einsetzen, sollten hierfür zwar nicht anfällig sein, leider sind jedoch insbesondere die Prinzipien in der von „Uncle Bob“ konsolidierten Form nach wie vor (noch?) nicht sehr weit verbreitet.
Alles in allem kann ich Ihr Projekt im Hinblick auf die Vorgehensweise zur fachlichen Analyse beraten und gerne für das „Doing“ den Lead übernehmen.