Interessantes aus der iSAQB Grundausbildung

Die letzten paar Tage besuchte ich die Grundausbildung (‚Foundation‘) zum iSAQB Certified Professional for Software Architecture. Der Kurs wurde von Stefan Zörner (embarc GmbH) geleitet. Der Kurs ging insgesamt drei Tage. Man beschäftigte sich während diesen drei Tagen intensiv mit Software-Architektur und den Aufgaben der Rolle ‚Software Architekt‘. In diesem Blog-Eintrag möchte ich nicht auf die iSAQB Foundation Zertifizierung eingehen – sondern bestimmte inhaltliche Elemente und auch persönliche ‚Eye-Opener‘ aus dem Kurs festhalten.

Was ist Software-Architektur?
Software-Architektur ist nicht ganz so einfach zu definieren. Am Kurs wurden verschiedene Definitionen diskutiert – am besten hat mir dabei die Definition von Eoin Woods gefallen: „Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.“ Das SEI – Software Engineering Institute hat verschiedene Definitionen zum Begriff ‚Software Architecture‘ gesammelt und bietet die Möglichkeit auch eigene Definitionen zu publizieren.

Start eines Vorhabens
Beim Start eines Vorhabens sollte vorgängig das WAS und anschliessend Teile des WIE erarbeitet werden. Folgende Punkte können das WAS beschreiben:

  • Systemkontext (*)
  • Rahmenbedingungen (*)
  • Qualitätsanforderungen und Qualitätsziele (*)
  • Szenarien
  • Risiken

Wenn die grundlegenden Informationen zum WAS erarbeitet wurden können die WIE-Grundlagen geschaffen werden:

  • Einzusetzende Technologien (*)
  • Architekturstil (-muster) (*)
  • Architekturprinzipien (*)
  • Grobe Gliederung
  • Domänenmodell (Begrifflichkeiten)

Mit einem (*) deklarierten Punkte sind besonders wichtig!

Systemkontext – nicht verhandelbar!
Aus dem Kurs ging hervor, dass das System eingehend mit einem Systemkontext beschrieben werden muss. Der Systemkontext beschreibt das System als Blackbox und zeigt die interagierenden Benutzer in unterschiedlichen Rollen sowie Beziehungen und Schnittstellen zu Umsystemen an. Wichtig ist, dass der Systemkontext anhand des Zielpublikum, das heisst fachlich und/oder technisch, modelliert werden muss.

Qualitätsziele aus Qualitätsanforderungen festlegen
Um Architekturstile, Entwurfsmuster und Strukturen für ein Software-System bzw. dessen Bausteine festlegen und diese implementieren zu können, sind  Qualitätsziele für das Entwicklungsteam essentiell. Ohne ein gemeinsames Verständnis (inkl. wichtige Stakeholder) über Qualitätsziele, läuft man (= der Projektleiter bzw. der Product Owner) in die Gefahr ein Software-System realisieren zu lassen, welches nicht den Erwartungen der Stakeholder bzw. des Auftraggebers entspricht. Daher ist es essentiell, dass man implizite Annahmen zu expliziten (Qualitäts-) Anforderungen macht.
Vor dem Kurs war mir die genaue Abgrenzung zwischen Qualitätsziel und Qualitätsmerkmal nicht klar. Während dem Kurs haben wir intensiv diskutiert – dazu meine Notizen:

  • Qualitätsmerkmale
    • „Mögliche Eigenschaften einer Anwendung“
  • Qualitätsziele
    • „Vorhaben spezifische Ziele, welche sich aus den Qualitätsmerkmalen zusammensetzen.“

Qualitätsziele kann man mittels Qualitätsanforderungen, beschrieben als Szenarien, gemeinsam mit den Stakeholder ermitteln. Dabei priorisiert man ermittelten Qualitätsziele und selektiert die höchst priorsierten 3 – 5 Ziele für das eigene Vorhaben. Die Herausforderung ist dabei, die Qualitätsmerkmale auszubalancieren, z.B. ‚Wartbarkeit‘ vs. ‚Effizienz‘ (Beispiel Modellierung eines Schachfeldes mittels mehrdimensionalen Arrays [8][8] vs. Bitfelder). Die Ermittlung der Qualitätsziele aus den Qualitätsmerkmalen ist dabei immer eine Wechselwirkung: Effizienz vs. Wartbarkeit, Sicherheit vs. Benutzbarkeit (z.B. Two-Factor Authentifizierung, Einsatz von Captchas, etc.), Portierbarkeit vs. Effizienz (Standard SQL vs. T-SQL), Zuverlässigkeit vs. Kosten. Das ganze Entwicklungsteam kennt und verfolgt während der Implementierung die Erreichung der definierten Qualitätsziele. Die definierten Qualitätsziele ermöglichen zu einem späteren Zeitpunkt dem Entwickler-Team Entscheidungen anhand der Ziele zu argumentieren (z.B. wieso eine ‚Schichten-Architektur‘) – siehe auch späteres Kapitel ‚Lösungsstrategie finden‘.

Qualitätsmerkmale konkretisieren
Qualitätsmerkmale sind meistens nicht konkret genug, um entsprechende Qualitätsanforderungen zu evaluieren, Lösungsstrategien abzuwägen und/oder Entscheidungen zu bewerten. Vielfach sind diese auch schwer messbar.
Mit Szenarien können Qualitätsmerkmale konkretisiert werden. Ein Szenario besteht aus einem kurzen Text, welcher beispielhaft die Verwendung des Systems beschreibt. Das Qualitätsmerkmal spielt dabei die Hauptrolle. Das Ziel soll sein, mittels Szenarion über die entsprechenden Qualitätsmerkmale diskutieren zu können. Zusätzlich sollte man sie dadurch auch überprüfen können. Man unterscheidet zwischen den folgenden drei Kategorien von Szenarien. Die Kategorien zielen dabei auf unterschiedliche Qualitätsmerkmale.

  • Verwendungsszenarien: Verwendung des Systems durch einen entsprechenden Akteur.
    • z.B. Qualitätsmerkmal Benutzbarkeit
  • Änderungszenarien: Es wird etwas am System verändert.
    • z.B. Skalierbarkeit oder Wartbarkeit
  • Fehlerszenarien: Es kommt zu unerwarteten Ereignissen.
    • z.B. Robustheit

Szenarien bestehen typischerweise immer aus einer Quelle, einem Auslöser, einem Artefakt / Umgebung, einer Antwort sowie ein entsprechendem Antwort-Mass. Logischerweise kann man nicht erwarten, dass die entsprechenden Attribute immer in dieser Form kommen. Jedoch ist es möglich die Szenarien immer anhand dieser Form herzuleiten. Wichtig ist, dass es kein Szenario gibt ohne Quelle und Auslöser – darauf sollte man achten.

Im Kurs wurde ein weiteres Mittel für die Konkretisierung von Qualitätsmerkmale vorgestellt.  Dabei geht es darum verschiedene Werte für die Erfüllung bzw. nicht-Erfüllung einer Qualitätsanforderung zu definieren. Das Modell stammt ursprünglich von einem Herr Gilb. Um eine Qualitätsanforderung zu konkretisieren werden Werte zu folgenden Eigenschaften definiert. Die folgende Grafik zeigt die Einordnungsmöglichkeiten von entsprechenden Qualitätswerten.

Qualitätsanforderungen konkretisieren

Es geht dabei mit den Stakeholder (Qualitäts-) Werte einordnen zu können, um ein Gefühl zu bekommen, was der erwartete Wert ‚Zielwert‘ ist. So werden die Erwartungen bereits zu Beginn des Vorhabens geglättet.

Mit Prinzipien das Team befähigen.
Das vorherige Kapitel beschreibt ‚Architekturprinzipien‘ als besonders wichtig für den Start eines Vorhabens. Prinzipien befähigen das Entwicklungsteam Entscheide zu treffen. Dabei schaffen Architekturprinzipien ein gemeinsames Verständnis wie wiederkehrende Probleme gelöst werden können (!) oder ermöglichen die Förderung eines ganz bestimmten Architekturstils. Prinzipien sind langlebiger als konkrete Lösungen.  Aus meiner Sicht können Prinzipien ein wertvolles Mittel sein, wenn es nicht DEN Software-Architekt im Team gibt. Wichtig ist, dass diese Prinzipien projektspezifisch formuliert werden.

Architektur Vision als Team-Gedanke
Wie oben beschrieben sind Prinzipien ein Mittel um das Entwicklungsteam zu befähigen Architektur-Entscheidungen herleiten zu können. Neben den Prinzipien gibt es auch noch Elemente wie Randbedingungen, Einflussfaktoren sowie ein zu verfolgendes Architekturmuster, welche Entscheidungen massgäblich beeinflussen. Die Informationen zu diesen Elementen sollte in einer Architektur-Vision (teilweise) gemeinsam mit dem Entwickler-Team erarbeitet und entsprechend dokumentiert werden. So haben auch neue Entwickler die Chance schnell vergangene Entscheidungen zu verstehen, aber auch zukünftige Konzepte danach ausrichten zu können. Persönlich finde ich die Bezeichnung ‚Architektur Vision‘ sehr passend.

Lösungsstrategie finden
Während dem Kurs wurde ein einfaches Instrument für die Erarbeitung einer Lösungsstrategie präsentiert. Die Lösungsstrategie ermöglicht die Evaluierung, Entscheidung und Kommunikation bestimmter Architekturansätze. Das Instrument ist eine einfache Tabelle mit zwei Spalten – Qualitätsziele und die dafür definierten Architekturansätze. Die folgende Tabelle zeigt den möglichen Aufbau einer solchen Tabelle.

Lösungsstrategie erarbeiten

In der linken Spalte führt man die bereits vorgängig definierten Qualitätsziele und rechts die dafür gedachten Architekturansätze. Die Architekturansätze können unterschiedlicher Art sein:

  • Architekturstile – und Muster, wie z.B. Schichten-Architektur, MVC, CQRS, REST, Microservices, etc.
  • Technologieentscheidungen, wie z.B. Programmiersprachen (z.B. Java oder .NET), Einsatz von Frameworks, etc.
  • Prinzipien, wie z.B. ‚Wenn möglich Open-Source einsetzen‘
  • Spezifisch zu verfolgende Konzepte

Durch diese Tabelle können verfolgte Lösungsstrategien argumentiert und verfolgt werden. Zusätzlich dient es einem Software-Architekt als gutes Kommunikationsmittel gegenüber unterschiedlichen Stakeholdern (und auch Kritikern ;-)) – sämtliche Entscheide können über die vorgängig definierten bzw. übergeordneten Qualitätsziele argumentiert werden.

Dokumentation unterstützt Kommunikation
Die Dokumentation ist essentiell – wichtig ist nicht, dass sie vollständig ist, sondern aktuell und angemessen. „Zu viel“ Dokumentation wie auch „Der Source-Code dokumentiert die Architektur.“ passt nicht. Die Schwierigkeit liegt grundsätzlich darin, genau so viel wie nötig zu dokumentieren. Eine Möglichkeit für die Strukturierung von Dokumentation von Architektur-Konzepten bietet die arc42 Vorlage. Im Kurs wurden die sieben Regeln für Dokumentation vorgestellt:

  1. Schreibe aus Sicht des Lesers
  2. Vermeide unnötige Wiederholungen
  3. Vermeide Mehrdeutigkeit und erkläre deine Notation
  4. Verwende eine Standardstrukturierung
  5. Halte Begründungen für Entscheidungen fest
  6. Halte Dokumentation aktuell (aber auch nicht zu aktuell)
  7. Überprüfe Dokumentation auf Gebrauchstauglichkeit

Software-Architektur bewerten
Neben dem Entwurf von Architekturen ist eine Disziplin des Software-Architekten auch das Bewerten von Software-Architekturen. Hier wurde während dem Kurs auf die verbreitete Bewertungsmethodik ‚ATAM‘ – Architecture Tradeoff analysis method eingegangen. ATAM kann früh angewendet werden und ist szenarienbasiert. ATAM ermöglicht, dass Entscheidungen transparent aufgedeckt werden, Feedback gegeben werden kann und Klarheit herrscht.

Wichtig: Es ist nie zu spät eine Architektur zu bewerten. Bewertungen können jederzeit durchgeführt werden und sollten auch vorgesehen und eingeplant werden.

Aufgabe und Rolle des Software-Architekten
Die Rolle des Software-Architekt ist anspruchsvoll. Zu seinen Aufgaben zählen (aus dem Buch ‚Effektive Software-Architekturen von Gernot Starke‘):

  • Anforderungen und Randbedingungen klären
  • Strukturen entwerfen
  • Technische Konzepte entwerfen
    • Architektur kommunizieren
    • Umsetzung begleiten
    • Architektur bewerten

Die Rolle des Software-Architekten ist aktiv, d.h. er geht Aufgaben pro-aktiv an, holt alle notwendigen Stakeholder zusammen, hält Randbedingungen ein, hat immer das sogn. ‚ Big-Picture‘ im Hinterkopf und strebt zugleich nach Einfachheit. Software-Architektur berührt alle Disziplinen der IT: Anforderungsmgmt, Betrieb, Projektmanagement, Implementierung und Design sowie die Berücksichtigung von technischen und organisatorischen Einflussfaktoren.

Ein wichtiger Aspekt in Projekten ist zugleich: Projektziele sind kurzfristig, Architekturziele aber langfristig!

Dies und das.
Folgende interessante Dinge wurden während dem Kurs genannt:

Discovery-Review„: Möglichst früh Architektur-Vision in den Review geben.
Architecture-Speeddating„: Unter Zeitdruck unterschiedliche Sichten der Software-Architektur des eigenen Systems zeichnen und einem Kollegen präsentieren.
Starschnitt“ – siehe http://update.hanser-fachbuch.de/tag/arc42-starschnitt/

Buch
Folgendes Buch dient als Vorbereitung für den Kurs:
Effektive Software-Architekturen von Gernot Starke