Fassen wir die einzelnen Schritte zur Erstellung einer Architektur zusammen, so kommen wir auf lediglich 8 Stichworte. Bis zur Abgabe des fertigen Produktes wird dieser Vorgang iterativ durchgeführt.
- Anforderungen sammeln
- Risiken abschätzen
- Konzept und Struktur erstellen
- Dokumentation/en erstellen
- Dokumentationen kommunizieren
- Umsetzung überwachen
- Architektur Bewerten
- Anpassen / Erweitern
Bild 1 dient uns als Gedächtnisstütze, da sich vermutlich die meisten von uns Bilder eher einprägen können als einfachen Text.
Bild 1 - Entstehung der Architektur
Führen wir nun diese 8 Stichworte weiter aus, so sieht man allerhand Arbeit, die auf einen Software Architekten zukommt. Allerdings ist auch nicht verlangt, dass wir als Software Architekten die ganze Abeit alleine erledigen, sondern - im gegenteil - die Architektur im Team und nicht isoliert (fernab der Realität) entstehen lassen. Auch soll die Aufgabe nicht verkrampft angegangen werden mit dem Ziel von Anfang an alles richtig zu machen, denn eine Architektur soll an sich und am Produkt mitwachsen.
Anforderungen sammeln
Ideal wäre es, wenn der Kunde bereits zu 100% wüsste was er eigentlich genau möchte. Das Problem ist hier jedoch, dass der Kunde dies nicht immer wissen kann und einfach eine grobe Idee, von dem was er sich ungefähr wünscht, hat. Die Aufgabe des Architekten ist es nun (unter anderem) die Idee zu erfassen und zusammen mit dem Kunden die Idee zu verfeiner. Betrifft die Idee oder der Wunsch ein bestehendes Produkt, so kann man beratend Einfluss auf die Anforderungen nehmen. Der Kunde kann in diesem Falle noch nicht wissen, was das System so alles kann und welche seiner Wünsche und Anforderungen überhaupt umgesetzt werden können - oder allenfalls bereits abgedeckt sind.
In diesem Schritt können erste Abklärungen mit anderen Stakeholdern (Lieferanten Fremdsysteme, Betrieb, Kundendienst, Entwickler etc.) ebenfalls initiiert und getätigt werden.
Nichtfunktionale Anforderungen sollten ebenfalls bereits zu diesem Zeitpunkt definiert werden. In Summe erhalten wir dadruch die Qualität des Produktes. Nicht vergessen sollte man hier zu jedem Punkt die Messbarkeit zu definieren. Nur so kann man dem Kunden (und auch den anderen Stakeholdern) beweisen, dass die Qualität des Systemes genau so ist wie man sich das vorgestellt hat.
Beispiele für solche NFA's sind:
- Performance (Effizienz)
- Performance muss messbar gemacht werden, indem wir Szenarien und Messwerte (Duchsatz, Antwortzeit etc.) definieren.
- Verfügbarkeit
- Die Verfügbarkeit von Systemen kann genau berechnet werden.
- Die beiden Hauptmesserte werden MTBF (Mean Time Between Failure) und MTTR (Mean Time To Repair) genannt.
- Idealerweise können wir uns mit dem Kunden auf Betriebszeiten zu einigen. Dadurch mindern wir die Zeit wo das System unbedingt vergübar sein muss.
- Unrealistische Verfügbarkeiten wie 99.999% und höher machen keinen Sinn und sollten dem fantasierenden Stakeholder direkt vorgerechnet werden. Hierzu stehen uns zwei Formel zur verfügung:
- Serielle verkettung von Komponenten: A = A1 * A2 * An; hierbei gilt, dass A immer kleiner ist als das "schächste" glied.
- Parallele verkettung von Komponenten A = 1-((1-A1)*(1-A2)*(1-A3)); daraus folgt, dass A immer grösser ist als das stärkste Glied der "Kette".
- hierzu mehr in einem späteren Kapitel; es werden auch Berechnungsbeispiele folgen, welche aufzeigen was für fantastische Anforderungen zu diesem Thema gestellt werden können.
- Korrektheit
- Bedienbarkeit
- Wartbarkeit
- Änderbarkeit
- Stabilität
- Testbarkeit
- Betriebbarkeit
- weitere Attribute mit "...barkeit" am Wortende
Generell gilt bei den NFA's, dass man sich mit den Stakeholdern auf 4-5 einigen sollte, welche auch messbar gemacht werden. Achtung: jeder Stakeholder hat seine eigenen Anforderungen!
Risiken abschätzen
Hier haben wir oft einen fliessenden Übergang zwischen Sammeln der Anforderungen und abschätzen der Risiken. Unter "Risiken" verstehen wir z. Bsp.
- fehlendes Knowhow
- grosse Datenmengen
- komplizierter Use Case, der nicht mehr vereinfacht werden kann
- begrenzte physikalische Verbindungen
- eingeschränkte Hardware Ausstattung
- schlechte Testbarkeit aufgrund sehr teurer oder komplexer Umsystem, wo keine Testsysteme vorhanden sind
- Organisatorische Mängel oder Restriktionen
- unrealistischer Zeitplan/Budget
- ...
Diese Liste könnte fast endlos weitergeführt werden. Fast jede Zielbranche eines Systems kennt seine eigenen Risiken - die einen mehr, die anderen weniger.
Konzept und Struktur erstellen
Dieser Schritt wird in vielen Lehrbüchern zusammen mit dem Erstellen der Dokumentation beschrieben. Ich bin jedoch der Ansicht, dass die ersten Konzepte und Strukturen im Kopf (bei einem Spaziergang, während einer langweiligen TV-Sendung, beim Autofahren, auf der Toilette, bei einem Glas Wein etc.) entstehen. Daher trenne ich diese beiden Schritte gerne.
Dokumentation/en erstellen
Zur Dokumentation stehen uns diverse Werkzeuge zur Verfügung. Grundsätzlich sind diese bereits mehr oder weniger standardisiert. Doch viele grosse Unternehmen interpretieren Standards individuelle. Dazu rate ich jedoch nicht, da man sich gerade bei Diagrammen noch um Legenden kümmern muss. Da bedient man sich lieber der UML. Diese Modelliersprache deckt bereits vieles ab.
Das zentrale Dokument, welches ein Software Architekt erstellt, ist das sogenannte "Software Architektur Dokument" (SAD). In diesem sind Punkte enthalten wie
- Zweck des Systems
- Art des Systems
- Stakeholder
- Entscheidungsmatrixen
- Use Cases
- Risiken
- NFA's
- Messbarkeit
- FA's
- Sichten
- Die "Baupläne" des Produktes; hierzu später mehr
- ...
Es gibt bereits sehr gute Vorlagen und Beispiele im Netz. Ich persönlich verwende gerne die Vorlagen von Gernot Starke auf arc42.de. Wichtig ist, dass das Dokument leben darf und soll. Es sollten hingegen keine Kapitel oder Seiten entfernt werden. Ist ein Thema nicht relevant oder dazu noch Fragen offen, so soll dies festgehalten werden - es geht in einem SAD um Transparenz und am Ende muss jeder Stakeholder mehr oder weniger hinter dem Dokument stehen. Der Kunde muss seine Idee wiedererkennen und der Entwickler muss wissen wir er das Produkt umzusetzen hat.
Dokumentationen kommunizieren
Je nach Kunde gestaltet sich das Kommunizieren der Dokumentation, sprich des technischen Konzeptes eher formell, familiär, freundschaftlich oder es wird eine regelrechte Show erwartet. Für die gröberen Fällen steht uns die "Übersichtspräsentation" zur Verfügung. Dokumente, die das SAD vereinfacht zusammenfassen und durch eine Präsentation abgerundet werden - so dass auch Nicht-Techniker den Sinn und Vorteil der Arbeit eines Architekten verstehen.
Will man schwer Eindruck schinden, so erarbeitet man hübsche Diagramme, druckt diese gross (A0 oder noch grösser!) aus und "tapeziert" damit das Büro. In diesem Falle reden wir von "Architekturtapeten".
Weitere Dokumente sind "Handbuch zur Architekturdokumentation" - wie lese ich die ganzen Dokumente, was beinhalten sie und wo liegt die jeweilige Abgrenzung.
"Architekturüberblick" - eine Kompakte Version des SAD (maximal 30 Seiten).
"Technische Informationen" zum Entwicklungsprozess - regeln die Prozesse rund um die Entwicklung, Testing, Deplpoyment, Build, Betrieb.
Richtig - jetzt haben wir erfolgreich einiges an Dokumentationen erstellt und niemand hat mehr den Überblick. Da lässt sich doch gleich noch eine "Dokumentationsübersicht" verkaufen! Nein, im Ernst - es sollen nur die nötigen Dokumente erstellt werden. Nicht vergessen darf man, dass Architektur ja "lebt" und sich weiterentwickelt. Mit jedem Dokument, das wir haben, erhöht sich der Wartungsaufwand. Und es gibt ja den Grundsatz: "Architect also implements" - unser Hauptwerkzeug soll eine IDE sein und nicht eine Textverarbeitungssoftware.
Umsetzung überwachen
Bei der Überwachung geht es an sich nur darum, regelmässig das eigene Tun zu überprüfen. Es geht nicht nur darum zu überprüfen ob die Architektur per se korrekt ist, sondern viel mehr darum um zu prüfen ob
- sie zum Ziel führt
- alle beteiligten noch vom Gleichen reden?
- sich die Implementation daran hält?
- die Dokumentation sich deckt mit der Implementierung?
- Dokumentationsanpassungen ausstehende sind?
Die hohe Kunst besteht hier vermutlich darin, den Stakeholdern zu vermitteln, dass nicht sie überwacht werden sondern wirklich nur die Umsetzung.
Architektur Bewerten
Die regelmässige Bewertung führt dazu, dass die Architektur stetig wächst und korrigiert wird - oder zumindest optimiert werden kann. Nicht selten kann man im Laufe eines Projektes Dinge vereinfachen und somit Komplexität "wegoptimieren".
Anpassen / Erweitern
Für Anpassungen darf man sich nie zu schade sein. Gerade zu Beginn eines Pojektet ist es häufig so, das sie das Ziel noch stark bewegt. Das heisst, auch unsere Architektur muss sich bewegen - man nennt dies "auf bewegende Ziele schiessen".
Die Herausforderung liegt hier darin, ein wenig Einfluss auf die Bewegungen des Zieles nehmen zu können.
