Tools für Architekturmanagement
Schon seit einiger Zeit beschäftige ich mich damit, pragmatische und nützliche Darstellungsformen von Systemarchitekturen zu finden. Aus der Gebäudearchitektur kennen wir Baupläne, aber auch Schnitte, Installationspläne, Statikberechnungen etc. Solche Pläne entstehen bevor das Bauwerk gebaut wird. Im Software Engineering haben wir diese auch. Es sind Modelle, die bei der Model Driven Architecture erstellt werden und als Grundlage für die Generierung und die Dokumentation der Software dienen. Eine Ebene höher wird wohl irgendwann einmal die SysML greifen, wenn sie sich auf breiter Front durchgesetzt hat.
Aber was machen wir mit Systemen, die schlecht oder gar nicht dokumentiert wurden und jetzt zur Änderung oder Ablösung anstehen? Vollständige Nachdokumentation ist immens teuer. Was ist also der minimale Dokumentationsaufwand, der ausreicht, um die Software ablösbar zu machen?
Nähern wir uns dem Problem pragmatisch vom Ziel aus. Die vollständige Ablösung einer Software wird unzweifelhaft in eine Serie von kleineren Änderungen zerfallen. Damit jede dieser Änderungen erfolgreich durchgeführt werden kann, muss klar sein, welche Teile des Systems von ihr betroffen sind. Eine "Impact Analyse" muss möglich sein. Für diese Analyse braucht man Dokumentation über:
Die genaue Kenntnis der Geschäftslogik scheint mir im ersten Schritt von untergeordneter Bedeutung zu sein, falls die Funktionen als "Black Boxes" beschrieben werden können. Das bedeutet, wenn ich von jeder Funktion weiß, was, wann und wie es rein und raus geht (Datenstruktur, Protokoll, Schnittstelle) kann ich auch sagen, welche Auswirkungen die Entfernung, Umstrukturierung oder Veränderung einer Funktion zur Folge hat.
Die Frage, die bleibt ist jetzt: Wie dokumentiere ich dieses Wissen?
Eine Idee, die ich seit einiger Zeit verfolge, verwendet eine Topic Map um beliebige Abhängigkeiten und Verbindungen zwischen den Entitäten einer Systemarchitektur zu modellieren und zu instanzieren. Eine erste "quick and dirty" Implementation existiert bereits. Doch der Schlüssel zu einem Erfolg liegt nicht in der Form der Datenspeicherung sondern in den Analysemöglichkeiten.
Aber was machen wir mit Systemen, die schlecht oder gar nicht dokumentiert wurden und jetzt zur Änderung oder Ablösung anstehen? Vollständige Nachdokumentation ist immens teuer. Was ist also der minimale Dokumentationsaufwand, der ausreicht, um die Software ablösbar zu machen?
Nähern wir uns dem Problem pragmatisch vom Ziel aus. Die vollständige Ablösung einer Software wird unzweifelhaft in eine Serie von kleineren Änderungen zerfallen. Damit jede dieser Änderungen erfolgreich durchgeführt werden kann, muss klar sein, welche Teile des Systems von ihr betroffen sind. Eine "Impact Analyse" muss möglich sein. Für diese Analyse braucht man Dokumentation über:
- die funktionale Struktur,
- die Datenstrukturen und
- die Abhängigkeiten zwischen ihnen.
Die genaue Kenntnis der Geschäftslogik scheint mir im ersten Schritt von untergeordneter Bedeutung zu sein, falls die Funktionen als "Black Boxes" beschrieben werden können. Das bedeutet, wenn ich von jeder Funktion weiß, was, wann und wie es rein und raus geht (Datenstruktur, Protokoll, Schnittstelle) kann ich auch sagen, welche Auswirkungen die Entfernung, Umstrukturierung oder Veränderung einer Funktion zur Folge hat.
Die Frage, die bleibt ist jetzt: Wie dokumentiere ich dieses Wissen?
Eine Idee, die ich seit einiger Zeit verfolge, verwendet eine Topic Map um beliebige Abhängigkeiten und Verbindungen zwischen den Entitäten einer Systemarchitektur zu modellieren und zu instanzieren. Eine erste "quick and dirty" Implementation existiert bereits. Doch der Schlüssel zu einem Erfolg liegt nicht in der Form der Datenspeicherung sondern in den Analysemöglichkeiten.
