Was ist Software Architektur? Gibt es eine klare Antwort? Eine Betrachtung.

Wenn wir über Architektur sprechen, denken wir intuitiv, wir alle sprächen über das gleiche Thema. Jedoch gibt es viele Definitionen von Software Architektur und noch mehr Darstellungen derselben. Es gibt Architecural Views, Styles und Patterns, Architekturbeschreibungssprachen und -notationen und Architekturbewertungsverfahren. Ist Architektur immer auch Design und umgekehrt? Was tut ein Software Architekt den lieben langen Tag?

James: "Wir suchen einen Software Architekten!"
Dean: "Was werde ich am ersten Tag machen?"
James: "Wir wollen die Architektur unserer Software dokumentieren!"
Dean: "Kein Problem! In welchem Format?"
James: "Ich hoffte, das würdest Du uns sagen!"
Dean: "Ich kann mich ja mal in den Code einlesen..."

Es gibt viele Wege, Architektur zu beschreiben - sicher gibt es besser und schlechter geeignete Repräsentation, was ist aber nun wichtig, wenn man über Architektur spricht?

• Erstens sollten wir in einer Gruppe eine einheitliche Sprache entwickeln. Nach der Sapir-Whorf Hypothese schafft Sprache Wirklichkeit, und um uns nicht in einem semantischen Albtraum zu verlieren, ist es sinnvoll eine "Gesamtsprache" - so etwas wie die Ubiquitous Language (UL) aus dem Domain Driven Design Bereich - zu entwickeln. Erzeugen wir dieselben Bilder im Kopf, können wir zufrieden sein. Ein Bild sagt mehr als 1000 Worte - und darum ist eine grafische Architekturbeschreibung auch so sinnvoll.
• Zweitens sollten wir uns nicht panisch an postulierte Vorgaben halten - legt man alle Bücher zu Software Architektur aufeinander, kann man bald getrost dem Eiffelturm Konkurrenz machen. Gut ist, was gefällt - was unserem Problem in unserer Umgebung am Effektivsten zu Leibe rückt. Mut zum Anderssein - wenn es Sinn macht. Mut zum Experiment, wenn man das Gefühl hat, da ginge noch etwas besser - und Mut, sinnlose Ansätze formlos wieder zu verwerfen.
• Drittens sollten wir als Entwickler Architekten nicht vorsorglich verdammen und als Architekten Entwickler nicht bevormunden. Diversität der Meinungen und der konstruktive Dialog produzieren - ein Aufeinander hacken, sei es, um Justament Standpunkte zu verteidigen oder persönliche Überzeugungen aus Eigeninteresse zum Postulat hochzustilisieren, zerstört. Zerstörte Architektur ist auch Architektur - nur macht sie keinen Spaß. Erfahrene Architekten haben so ein ungutes Gefühl in der Magengegend, wenn ihnen ein zerrüttetes soziotechnisches System eine zerstörte Architektur als "einzig machbaren Weg" vorstellt - da weiß man, dass Arbeit auf einen zukommt.

Architektur (und Architekturmanagement) ist die Courage, aus einer Menge von möglichen Wegen einen gangbaren (viablen, würden die Konstruktivisten sagen) einzuschlagen, ihn konsequent zu verfolgen und evolutionär anzupassen. Dann wird der Weg durch den steinigen Entwicklungsalltag breiter und sicherer, das Produkt übersichtlicher und seine Evolution einfacher - und es macht bedeutend mehr Spaß, mit von der Partie zu sein.

Euer
JWR@coopXarch.