Architectural Blueprint
03.11.2006 Permalink Im Moment arbeite ich wieder an der Architektur eines recht überschaubaren Systems, das in den nächsten Monaten das Licht der Welt erblicken soll. Obwohl wir nicht frei in der Auswahl unserer technischen Plattform sind (und uns etwas anderes gewünscht hätten), haben wir bei allem, was sich darin abspielt, gute Chancen, ein sauberes Stück Software zu entwerfen.Dabei setze ich in dieser frühen Phase diesmal bewusst ein Mittel ein, das mir in vergangenen Projekten als Architectural Blueprint begegnet ist. Es ist letztlich "nur" eine Sammlung weniger Diagramme, anhand derer sich aber die Ideen und der grobe Aufbau des Systems leicht erläutern lassen.
Wozu nutzt mir das?
Ich finde die Bilder praktisch, um z.B. gegenüber dem Management zu
kommunizieren, an welchen Stellen Probleme sind, wobei man die Stellen schön mit
dem Finger zeigen kann. Oder wenn es darum geht, neue Leute an Bord zu nehmen:
man kann die Ausdrucke herumreichen, und sehr schnell vermitteln, worum es geht.
Für die Zerlegung von Gesamtaufgaben zu Teilaufgaben für kleinere Teams sind sie
ebenfalls geeignet. Und für die Einrichtung von Strukturen zum
Konfigurationsmanagement sind sie auch praktisch.
Und in den nächsten Tagen brauche ich die Bilder, um im Team die Building Blocks
zu diskutieren, denn wir erfinden das System gerade erst.
Woraus besteht der Blueprint?
Das ist grundsätzlich individuell, in der Praxis dürfte die Schnittmenge
zwischen verschiedenen Projekten aber recht groß sein. Häufige Darstellungen
sind:
- Architekturschichten in einem Blockdiagramm.
- Abhängigkeitsgraph der Toplevel/Secondlevel Packages.
- Verteilung der Architekturschichten auf logische Knoten (Maschinen).
- Umsysteme, zu denen das eigene Schnittstellen besitzt.
- Anwenderrollen und die wichtigsten UseCases
In einem Backend-System als zentrale "Datenschleuder" und Prozesssteuerer habe ich sogar mal ein Dataflow-Diagramm aus der Strukturierten Analyse verwendet, um die Kernprozesse in Verbindung mit den Umsystemen darzustellen.
Diese Handvoll Abbildungen ersetzt kein DV-Konzept oder Architekturpapier, in dem neben dem Blueprint auch die Lösungen zu einzelnen technischen Themen beschrieben sind. Der Blueprint ersetzt schon gar nicht die Darstellung des Fachdesigns, also wie konkrete UseCase-Realisierungen zerlegt und auf Elemente der technischen Architektur abgebildet werden. Aber häufig reichen die fünf Blätter aus, um sich viele Worte und ein paar Mißverständnisse zu sparen.