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

Innovationsregeln

Es gibt eine bekannte Zusammenstellung von einfachen Regeln (40 Wege vom Trivialen zum genialen) aus der Kreativitätstechnik TRIZ. Diese Regeln sind nach meiner Recherche bisher noch nicht in praktische Beispiele zur Erstellung von IT-Systemarchitekturen angewandt worden. Software Patterns bieten im Grunde das Pendant dazu für reine Software Architekturen. Für die Kombination aus Software und Hardware fehlen einfache Regeln zur Konstruktion einer "guten" Systemarchitektur. Ich werde versuchen in meinem Wiki eine solche Regelsammlung aufzustellen.

Was ist Software?

Je mehr ich über Systemarchitekturen und vor allem die mit ihrer Herstellung, Erhaltung und Weiterentwicklung verbundenen Tätigkeiten nachdenke, desto dringender wird mein Bedürfnis nach eine Metapher für Software. Ich suche nach einer Projektion von Software und Ihrer Architektur auf physische Gegenstände.
Im Extreme Programming ist es einer der Schlüsselmomente, wenn das Team eine Metapher für die zu erstellende Software entwickelt. Es können verbale Beschreibungen für die grundlegende Funktionalität entstehen, wie z. B.:
"Diese Optimierungssoftware arbeitet eigentlich wie jemand, der wertvolle Gegenstände unterschiedlicher Größe in einen kleinen Rucksack packen soll, um einen möglichst großen Gesamtwert mitzunehmen". So eine "Einbrecher-Metapher" für eine Optimierungssoftware erleichtert das Verständnis und den Gesamtüberblick für das gesamte Team ungemein.
Schauen wir aber auf das gesamte Thema Software, so wird die Luft schon dünner. Fragt man Google so drehen sich alle Definitionen um Programme und Daten, die auf elektronischen Rechnern ablaufen. Das hilft aber überhaupt nicht, wenn man jemandem die Aufgabe stellt, Software herzustellen. Wonach soll er sich richten? Ist Softwareherstellung eine Ingenieursleistung wie in der Automobilindustrie, wo man sich an Produktlinien, Teamstrukturen und Konstruktionsprozesse halten kann? Ist Software eher ein Konsumgut und gehorcht den Regeln von Angebot und Nachfrage, hat ein Haltbarkeitsdatum und wird am Fließband aus Grundelementen hergestellt? Oder ein Pharmazieprodukt, welches jahrelang in aufwändigen Testreihen erprobt wird, bevor es auf den Rest der Menschheit (mit weitgehend bekannten Nebenwirkungen) losgelassen wird?
Vergleichen wir das mal mit Musik. Was sind die Voraussetzungen zur Herstellung von Musik? Man benötigt ein Instrument und man sollte dieses tunlichst beherrschen, d. h. es sollten keine unvorhersehbaren Ergebnisse aus seiner Bedienung entstehen. Ein guter Musiker ist jemand, der nicht nur die Grundtechniken Rhythmus und Melodie sondern auch einen kreativen Aspekt, Komposition oder Interpretation, beherrscht. Ein guter Softwarearchitekt sollte ebenfalls eine Art Handwerkszeug zur Verfügung haben, aber was ist das? Sind das die gesammelten Werke Donald Knuths? Um ehrlich zu sein, ich weiß es nicht. Ich selbst bewege mich bei allen Systemarchitekturen, die ich je entworfen habe auch immer in der Gewissheit, dass sie im Moment des Entwurfs meine beste Idee für die Lösung des Problems war. Schon eine kleine Änderung der äußeren Parameter aber reicht, dass ein System komplett versagt. Bei der Häufigkeit von Änderungen und der Gewissheit, niemals alle Anforderungen an ein System vorausahnen zu können wäre also "Robustheit" eine Eigenschaft, die ein Systemarchitekt unbedingt in seinem Entwurf berücksichtigen sollte. Fangen wir also damit an, einfache Techniken zur Robustheit von Architekturen zu sammeln.

Meta-Architektur

Telepolis schreibt über Architekturkenntnisse für Spieleentwickler . An diese Art von Architektur habe ich noch gar keinen Gedanken verschwendet. Kenntnisse über die Struktur und Konstruktion von Gebäuden innerhalb eines Computerspiels. Wenn es jetzt ein Computerspiel gäbe, in dem es darum ginge, ein Computerprogramm zu entwickeln, welches eine besonders gute Architektur besitzt... da tun sich ja Goldgruben auf :-)

Grundsteine legen

SystemARCHITEKTUR. Ist es möglich, aus dem Vergleich mit dem klassischen Architekturbegriff Nutzen für die Systemarchitektur von IT-Systemen zu ziehen? Die Übersetzung des Wortes "Architekt" als "oberster Zimmermann/Handwerker" weist schon auf die Bedeutung der Architekturdisziplin als maßgebliche Tätigkeit bei der Konstruktion und Erstellung von Gebäuden hin. Bei der Beschreibung der Erstellung von komponentenorientierter Software wird ebenfalls häufig auf die Haus-Metapher zurückgegriffen. Grundsätzlich ist die Frage zu klären, wann wir "bloß programmieren" und wann wir bewusst architektonisch arbeiten.
Nach Vitruv (römischer Architekt) beruht Architektur auf Stabilität, Nützlichkeit und Anmut. Übertragen auf Software würde das bedeuten, dass zu den beiden pragmatischen Aspekten auch ein ästhetischer hinzu kommt. Aber was bedeutet es denn, "schöne" Softwaresysteme zu erschaffen? Wodurch werden Systemarchitekturen schön oder elegant? Sind es übergreifende Konzepte oder pfiffige Details?
Unstrittig ist, glaube ich, dass es tatsächlich schlecht entworfene Systeme gibt ("Applications come and go, but bad architecture stays"), aber meine Recherchen haben bisher keine Häufung von Mutwilligkeit bei schlechten Architekturen zutage gebracht. Meistens sind die Architekten von Dingen überrascht worden, die sie zum Entwurfszeitpunkt entweder übersehen hatten, oder ihre Architektur war ganz einfach für den zukünftig auftauchenden Anwendungsfall nicht geeignet. Es ist zwar makaber, aber ich habe ein Interview mit einem der Architekten des World Trade Centers gesehen, der gefragt wurde, ob man solche Ereignisse wie am 11. September nicht bei der Konstruktion des Gebäudes eingeplant hatte. Er sagte, natürlich hätten sie das, aber nicht für Flugzeuge mit mehr als 100 Passagieren an Bord...
Die Kenntnis von Mechanismen, die zu schlechter Architektur führen und deren Vermeidung sollte also automatisch die Architektur verbessern.
Vielleicht ist es zunächst tatsächlich einfacher, darüber nachzudenken, was man nicht tun sollte, als alles zu finden, was wünschenswert ist...

Am Anfang war das Bit.
Das Erstellen von Software für Computer bestand darin, mit Schaltern Bits einzustellen und wortweise in Hauptspeicher zu schreiben. Die Systemarchitektur war individuell vom jeweilig benutzten System geprägt. Es gab keine Vernetzung und keine Notwendigkeit das System aus Hard und Software über den jeweiligen physischen Rahmen hinaus zu betrachten.
Seitdem hat sich viel getan. In jeder Dekade haben wir eine zusätzliche "Schicht" an Programmierparadigmen hinzugefügt. Assembler, funktionale Sprachen, objektorientierte Entwicklung, modellbasierte Entwicklung, Orchestrierung von Services zu Business Prozessen.
Mehr denn je ist es erforderlich, dieses komplexe System aus Schichten und Silos von Soft- und Hardware zu organisieren und seine Weiterentwicklung unter ingenieurtechnischen und wirtschaftlichen Gesichtspunkten voran zu treiben.
Für eine solche Aufgabe braucht man einen Systemarchitekten.