Alljährlich im Oktober finden in Essen die internationalen Spieltage, kurz “Spiel” genannt, statt. Auf der weltweit größten Publikumsmesse für Gesellschaftsspiele können Besucher aktuelle Neuerscheinungen auf dem Brettspielmarkt ausprobieren. Letzte Woche war es wieder so weit. Wie  die letzten Jahre auch waren ich mit meiner Frau 2 Tage vor Ort (Donnerstag und Freitag) und wir hatten Riesenspaß.

Kingdom Builder (Queen Games)

Besucher der Spiel werden viel mit Spielanleitungen konfrontiert. Ist Ihnen schon einmal aufgefallen, dass diese immer den gleichen Aufbau haben?

1. Kurze atmosphärische Einführung (optional, entfällt bei abstrakten Spielen)
2. Ziel des Spieles
3. Spielmaterial
4. Spielvorbereitung (Aufbau)
5. Spielablauf (Phasen, Züge, Aktionen)
6. Spielende (End- und Siegbedingungen)
7. Varianten (optional, z.B. für abweichende Spielerzahl, Expertenversion, Solospiel)

Die viel spielenden Messebesucher wären sehr überrascht, wenn eine Anleitung auf feste Bestandteile verzichten würde, oder die Spielvorbereitung mitten drin erklärt würde.

Auch wenn man das Spiel zwar kennt, aber länger nicht mehr gespielt hat, kommt die Anleitung zum Einsatz. Typische Fragen:

• Wie viele X bekommt jeder am Anfang? (X = Karten, Ressourcen, Pöppel, …)
• Wann genau ist das Spiel zu Ende?
• Geben X, die man am Ende über hat, Punkte?

Man darf erwarten, solche Fragen durch die Spielanleitung beantwortet zu bekommen, ohne sie von vorne bis hinten durchlesen zu müssen. Auch dabei hilft die Struktur.

Spielregeln Kingdom Builder

Von Spielanleitungen zu Architekturbeschreibungen

Genau wie bei Spielanleitungen verspricht eine vorgegebene Struktur auch für Architekturbeschreibungen Vorteile. Eine feste Gliederung der Inhalte unterstützt Autoren und Leser gleichermaßen. Als eine frei verfügbare  und betont praxistaugliche Strukturvorlage zur Beschreibung von Softwarearchitektur ist arc42 von Peter Hruschka und Gernot Starke eine naheliegende Wahl. Das Template erfreut sich mittlerweile im Feld großer Akzeptanz und Bekanntheit.

Missverständnisse

Ein von mir sehr oft gehörtes Missverständnis: “Bei arc42 muss man dieses Word-Template ausfüllen.” Die Vorlage ist vorrangig als Struktur zur Verwaltung zu verstehen, wo jedes Arbeitsergebnis, das im Rahmen des Architekturprozesses anfällt, seinen Platz findet. Hier fällt der meist im englischen belassene Begriff Repository; er hat mit “Fundgrube” und “Verwahrungsort” recht aussagekräftige deutsche Entsprechungen. Aus dem Repository lassen sich dann zielgruppengerecht verschiedene Dokumente ableiten. Wie flexibel und mit wie viel Aufwand Sie solche Dokumente aus Ihrer Fundgrube ableiten können, hängt stark von der Wahl der Werkzeuge und Notationen ab. Ein einzelnes Word-Dokument mit dreistelliger Seitenzahl macht Sie unbeweglich.

arc42-Repo in einem Wiki

arc42 ist nicht alternativlos. In der Regel spricht aber wenig gegen die Verwendung. Am ehesten vielleicht organisatorische Randbedingungen, die explizit etwas anderes fordern. Bevor Sie aber mit einem weißen Blatt anfangen, sollten Sie arc42 zumindest als Inspiration und Ausgangspunkt für Ihre eigene Dokumentationsstruktur nehmen.

Da sitzen sie im Stuhlkreis, die 14 Diagrammarten der UML im Workshop “Mehr Empathie in der Modellierung”. Und da bricht es aus ihm heraus: “Keiner hat mich lieb. Ich will gesehen werden.” Kann einem schon Leid tun, das Deployment Diagramm.

Gerade bastle ich bei meinem Buch über Architekturdokumentation am Unterkapitel zur Verteilungssicht. Ich habe 4 UML-Bücher auf dem Schreibtisch, und in wirklich jedem werden Deployment Diagramme absolut stiefmütterlich behandelt (auch in denen von meinen Kollegen übrigens). Sie wissen nicht, was ein Deployment Diagramm (deutsch Verteilungs- oder Einsatzdiagramm) ist? Genau das meine ich!

Sieht ungefähr so aus:

In einem der 4 Bücher vermutete ich einen Fehler. Um es nachzuprüfen habe ich in die Spezifikation geguckt, und siehe da: gleiches Bild. Viel Raum nimmt es auch dort nicht ein. Zwingende Beispiele Fehlanzeige. Armes Teil.

Liegt wohl daran, dass UML doch eher für die Entwickler gedacht war. Früher haben Entwickler ja an den Betrieb immer als letztes gedacht (“OK läuft, und wie kriegen wir das jetzt in Produktion? Wer ruft an? Wir losen!”). Trends wie Cloud Computing und DevOps überwinden alte Vorbehalte und versöhnen die Lager ein wenig.

Was mach ich denn jetzt mit dem verheulten Deployment Diagram? Soll ich es in meinem Buch mal anders machen? Dem Diagramm Raum geben und zeigen, was es tolles kann? Zum Beispiel: Zeigen, wie aus abstrakten Bausteinen Dinge werden, die man verteilen kann. Beschreiben, wie mögliche Zielumgebungen aussehen. Und wie man die Dinge tatsächlich dort zum Laufen bringt.

Haben Sie ein Herz fürs Deployment Diagram? Setzen Sie es ein? Ich freue mich auf Ihre Kommentare! Oder geben Sie diesem Beitrag +1. Dann freut es sich.

Im unserem Stuhlkreis hat das Timing Diagram in der Zwischenzeit all seinen Mut zusammen  genommen …

Der Ausspruch “Ein Bild sagt mehr als tausend Worte” wird allgemein akzeptiert. Nicht immer transportiert ein Bild aber tatsächlich mehr Informationen als Text, oder kommuniziert sie effizienter. Nehmen Sie als Beispiel folgenden Satz:

Das System XY besteht aus den drei Subsystemen A, B, und C.

Alternativ könnte man diesen Sachverhalt auch als Aufzählungsliste darstellen.

Subsysteme von System XY:

• A
• B
• C

Das versteht jeder im XY-Projekt involvierte, vorausgesetzt er kann Deutsch und weiß, was ein Subsystem ist. Vergleichen Sie diese textuellen Darstellungen mit dem folgenden Bild, vielleicht eingebettet als Graphik in einem Wiki, dass Sie zur Dokumentation Ihrer Architektur nutzen.

System XY besteht aus den drei dargestellten Subsystemen

Auf den ersten Blick ist die Abbildung hübsch anzuschauen und beinhaltet die gleichen Informationen wie der Satz oben. Für das Bild muss man die Notation verstehen, sie ist hier noch recht intuitiv. Wer die UML nur ein wenig kennt weiß wie viel Deutungsspielraum in dem Diagramm liegt. So könnte es beispielsweise noch weitaus mehr Subsysteme von XY im Modell geben, das Diagramm zeigt halt nur drei davon. Um das Abzusichern könnte man das Diagramm mit einem beschreibenden Text versehen, etwa wie in der Bildunterschrift bereits geschehen.

Das Diagramm liefert nun gegenüber dem ursprünglich zitierten Satz kaum einen Mehrwert.

Dieses Beispiel soll Sie keineswegs davon abhalten, ihre Architektur zu visualisieren. Es gibt aber durchaus Fälle, wo sie stattdessen eine textuelle Beschreibung zumindest in Erwägung ziehen sollten. So kann ein Ablauf unter Umständen auch in Pseudocode notiert werden, anstatt ein Sequenzdiagramm anzufertigen.

Graphische Darstellungen spielen ihre Stärken in Situationen aus, die über das bloße Aufzählen weniger Elemente wie oben herausgehen:

• Hierarchische Strukturen, Verfeinerungen
• Abläufe, insbesondere Alternativen, Wiederholungen, Parallelität
• Beziehungen zwischen Strukturelementen (z.B. auch Spezialisierung, Verwendung)
• Kategorisierung von Elementen, z.B. durch unterschiedliche Symbole
• Auszeichnen von Elementen und Anreichern mit Informationen
• Anordnen von Elementen in Gruppen, Schichten, …

Im speziellen Fall hier läge der Vorteil von UML weniger im oben gezeigten Diagramm, als in der Tatsache, dass es weitere Diagramme gibt, welche die selben Elemente z.B. in Interaktion oder im Einsatz zeigen. Das einheitliche Modell sorgt dann für Konsistenz, wenn z.B. etwas umbenannt wird.

Zum Abschluss noch eine kleine Aufgabe für Sie zur Anregung! Betrachten Sie die folgende Visualisierung von Klaviermusik (aka Noten, hier konkret aus Schwanensee). Finden Sie Elemente, die oben als Stärken für eine graphische Darstellung genannt sind, in Noten wieder?

Visualisierung von Musik

Für den Fall, dass Sie keine Noten lesen können, hier ein paar Beispiele: die Parallelität der Hände (oben rechte Hand, unten linke), die Strukturierung in Takte, Anreichern mit Informationen (mf = Dynamik mezzoforte, Ziffern = beim Spiel zu verwendende Finger). Tatsächlich lassen sich sämtliche Punkte von oben aufzeigen.

Ich platze vor Neid. Scrum-Berater haben eine universelle Antwort auf alle Fragen, etwa die eines Scrum-Masters in Ausbildung (SIP), parat. Insbesondere, wenn es konkret wird, und die Fragen mit “Wie” und “Wann” eingeleitet werden, lautet die Antwort stets “Frag das Team!”. Oft kommt sie prompt als wäre es das klarste von der Welt. Ich stelle ich mir den kleinen Yoda vor, wenn ich sie höre: “Das Team fragen Du musst.”. Und wenn Sie mir nicht glauben: Hier ist ein ein schönes Scrum FAQ online, das viele unterschiedliche Fragen, aber keine unterschiedliche Antworten parat hat. Es ist stattdessen eine Gruppenarbeit: “The questions are intended to be read and answered as a team.” Toll.

Das agile Team (v.l.n.r. Entwickler, Entscheider, Architekt) hat bestimmt eine Antwort ... Einfach fragen.

In einem Kundenworkshop zu Architekturdokumentation habe ich mich letztens dabei ertappt, eine ähnliche Strategie zu verfolgen wie die Scrum-Berater. Ich hatte auch eine universelle Antwort benutzt, die verblüffend oft auf in Diskussionen aufgeworfene Fragen passte. Sie lautete “Wenn es den Leser interessiert.” Mitunter wird so auch gleich die Schwäche in der Frage aufgedeckt, dass gar nicht genau klar ist, wer der Leser eigentlich ist. Eine 42 für Architekturdokumentation? (vgl. 42 bei Wikipedia)

7 Regeln für angemessene Dokumentation

Tatsächlich handelt es sich bei dieser Antwort übrigens um eine einfache Anwendung der 7 Regeln für angemessene Dokumentation. Sie werden im Buch Documenting Software Architectures vorgestellt, sind aber universell für Dokumentation gedacht. Hier sind sie komplett:

1. Schreibe Dokumentation aus Sicht des Lesers
2. Vermeide unnötige Wiederholungen
3. Vermeide Mehrdeutigkeit
4. Verwende eine Standardstrukturierung
5. Halte Begründungen fest
6. Halte Dokumentation aktuell, aber nicht zu aktuell
7. Überprüfe Dokumentation auf Gebrauchstauglichkeit

“Wenn es den Leser interessiert” ist eine Anwendung von Regel 1, und diese ist in der Praxis übrigens gar nicht so leicht zu befolgen, wie es auf den ersten Blick scheint. Das gilt für viele dieser Regeln.

Eine Architekturbeschreibung auf n Seiten, n < 30

Meiner Erfahrung nach wünschen sich viele Vorhaben ihre Architektur beschrieben in einem einzelnen Dokument, das vom Umfang her überschaubar ist. Die Seitenzahl sollte z.B. 30 DIN-A4-Seiten nicht überschreiten. Jeder Projektbeteiligte sollte das Dokument lesen (idealerweise von vorne nach hinten) und auch verstehen können; es manifestiert das gemeinsame Verständnis von der Softwarearchitektur. Dabei handelt es sich um genau so eine Art von Dokument, wie es entstehen soll, wenn Sie eine Vorlage wie z.B. arc42 benutzen (siehe Regel 4). Dass es sich dabei um eine verlockende Sache handelt, ist unstrittig.  Gleichzeitig ist die Erstellung aber schwierig, denn es drohen eine Reihe Fallen. Der Grund sind die besonderen Anforderungen:

• Die Zielgruppe ist heterogen
• Die Arbeitsergebnisse müssen sinnvoll linear angeordnet werden
• Informationen sollen nach Möglichkeit nicht redundant aufgenommen werden, das Dokument aber gleichzeitig leicht lesbar sein.

Und Sie sehen: Der erste Punkt macht die Anwendung von Regel 1 “Schreibe Dokumentation aus Sicht des Lesers” recht schwierig. Den Leser gibt es gar nicht.

Wirkungsvolle Architekturdokumentation

Dass die Regeln zwar sinnvoll klingen, ihre Anwendung in der Praxis aber ihre Tücken hat, habe ich in vielen Vorhaben erlebt. Denn ich beschäftige mich nun schon länger mit dem Thema Architekturdokumentation (zum Beispiel in meiner Kolumne im Java Magazin). Mit verschiedenen Projekten durfte ich gemeinsam Lösungen zu dem Thema erarbeiten.

Mittlerweile habe ich angefangen, meine Erfahrungen in einem Buch zusammenzuschreiben. Es soll den Lesern konkret anwendbare Hilfestellung bei ihrer Architekturdokumentation geben. Einfache Universalantworten habe ich aber nicht parat. Aber das Buch macht die sieben Regeln für gute Dokumentation durch praxiserprobte Werkzeuge und durchgängige, konkrete Beispiele erlebbar.

In diesem Blog möchte ich ab und über meine Fortschritte berichten. Bleiben Sie dran, über Feedback freue ich mich.

Ein Kollege erklärte mir gestern, dass er für eine spezielle Transformation “Cloud-Funktionalität” benutzt hätte. Konkret ging es um die Umwandlung von MS Visio in BPMN 2.0; die Seite http://www.businessprocessincubator.com bietet dies als Service, oder wie sie es nennen, ganz modern als “Cloud App” an:

Cloud gehört noch immer zu den aktuellen Aufregern in unserer IT-Welt. Mit “Cloud Apps” hat der Anbieter hier sogar gleich zweimal in die Trend-Zentrifuge gegriffen — Das Menu ist jedenfalls Buzzword compliant. Schön.

Mon Chéri wirbt mit der Piemont-Kirsche. Vermutlich bin ich nicht der einzige, der keine Ahnung hat, was das ist. Ist mir auch egal, Hauptsache lecker. Wen sollte nun interessieren, dass ein Service ein “Cloud Service”, bzw. hier eine App eine “Cloud App” ist?  Mein erster Gedanke also: Marketing-Schnick-Schnack — Das ist ein netter Service, aber kein Cloud-Computing! Wirklich nicht?

Er hat überhaupt nicht gebohrt
Cloud Computing ermöglicht einen Betrieb von Anwendungen, der von Infrastrukturdetails abstrahiert, und der es erlaubt,  bei sich änderndem Bedarf weitere Resourcen hinzu oder auch wieder weg zu nehmen. Verschiedene Anbieter haben unterschiedliche Modelle entwicklelt, die sich vor allem im Grad der Abstraktion unterscheiden.
Nun will ich diesen Service aber gar nicht betreiben. Ich will ihn nur nutzen. Netterweise ist dieser hier sogar umsonst (“Geiz ist geil”). Für mich als Nutzer ist relevant, dass der Service ausreichend verfügbar ist, und ein akzeptables Antwortverhalten zeigt. Möglichweise hat der Betreiber auf Cloud-Lösungen gesetzt, um diese Qualitätsziele zu erreichen. Aber im Grunde ist es mir egal. Vor allem würde ich als Anwender aus der bloßen Tatsache, dass Cloud im Spiel ist, kaum auf Qualität schließen können.

Sie waschen gerade Ihre Hände drin
Ziehen wir die Definition von Cloud Computing bei Wikipedia zu Rate: “Cloud computing describes computation, software, data access, and storage services that do not require end-user knowledge of the physical location and configuration of the system that delivers the services.” Das ist so weich, dass so ziemlich jeder im Netz angebotene Service sich Cloud Service nennen könnte.
Und tatsächlich geht obiger Service als SaaS (Service als SaaS) und damit als eine der klassischen Spielarten von Cloud durch. Vermutlich hätte ich mich weniger dran gestoßen, wenn der Service nicht kostenlos gewesen wäre. Services, die über das Netz zu nutzen sind, anstelle der Installation einer lokalen Applikation, gibt es natürlich reichlich.
Zwei konkrete Beispiele dieser Art, dich ich in letzter Zeit genutzt habe: yUML zur Erzeugung von UML-Diagrammen und 3D-box maker zur Erzeugung von Produktkarton-Bildern …

Wer wird denn gleich in die Luft gehen?
Es ist müßig ist zu diskutieren, ob nicht jede Web-Seite die weiche Definition zu Cloud Computing bei Wikipedia erfüllt. Ein Aspekt jedoch, der Cloud Computing eigen ist, ist beim konkreten Beispiel wie auch bei den beiden anderen Services, die ich genannt habe, extrem relevant: Die Frage nach der Sicherheit. Immerhin lade ich Modelle hoch, die dann von dem Service verarbeitet werden. Was geschieht mit meinen Daten — auf dem Weg von und zum Anbieter, und vor allem in dessen wolkiger Infrastruktur? Bei unternehmenskritischen Inhalten sicherlich bedenkenswert.

Im Zuge der Umstrukturierung unserer Architekturseminare sind mir in letzter Zeit viele Bücher und Artikel in die Hände gefallen. Insgesamt muss ich leider feststellen, dass die meisten veröffentlichten Werke zum Thema Software-Architektur eher sparsam mit brauchbaren Aussagen umgehen. Ich eröffnete eine Liste mit persönlich neuen Anregungen und gut zusammengefassten Sachverhalten, die ich in meiner Praxis immer wieder finde. Als die Liste nach 5 Büchern und einigen Whitepapers noch auf eine einzelne A4-Seite passte, stolperte ich über „Software Systems Architecture“ von Nick Rozanski und Eoin Woods. Endlich ein Buch das sich nicht auf zwei Aussagen reduzieren lässt…

Grob in zwei Abschnitte unterteilt, geht „Software Systems Architecture – Working With Stakeholders Using Viewpoints and Perspectives“ zunächst auf Architekturgrundlagen und Vorgehensfragen ein. Dabei wird viel von dem ausgesprochen und kondensiert, was ich auch über die Jahre gelernt habe. So häufig habe ich noch selten beim Lesen genickt. Der zweite Teil des Buches stellt „Viewpoints“ und „Perspektiven“ vor. Die entsprechenden Kapitel geben einen guten Überblick zu architektonischen Belangen (wie funktionale Strukturierung oder die Behandlung von Nebenläufigkeit, Sicherheit, Performanz, …) und zeigen wie man sie sinnvoll darstellt und behandelt. Gerade der qualitative Aspekt von Perspektiven und dessen Verbindung zu bekannten Viewpoints, wie Verteilungs- oder Kontextsichten, ist sicher wertvoll.

Insgesamt entsteht hier ein richtig rundes Bild von dem, was auch ich unter guter Architekturarbeit verstehe. Trotz 500+ Seiten wirkt der Inhalt sehr kompakt und gut strukturiert. Auch wenn das Buch schon älter ist (2005), kann ich es jedem noch wachsenden Softwarearchitekten oder interessiertem Entwickler empfehlen. Ich hätte mir gewünscht dieses Werk schon vor einigen Jahren gelesen zu haben…

Mehr Informationen: http://www.viewpoints-and-perspectives.info/

Verfügbar (leider) nur auf Englisch

Ich habe gerade einen Vortrag für die JAX eingereicht in dem ich über Architekturarbeit mit mehreren Teams sprechen möchte. Nach einer User-Group Teilnahme in Leipzig habe ich gesehen, dass das Thema durchaus von breitem Interesse ist. Architekturbewertung (im nicht akademischen Sinn) ist hier, meiner Meinung nach, ein sehr hilfreiches Werkzeug.

Größere Projekte stellen sich oft die Frage wie viel Steuerung und welche zentralen Rollen benötigt werden wenn man „agil“ arbeiten möchte. Die Architekturarbeit berühren vor allem zwei Fragestellungen immer wieder: Wie geht man mit Abhängigkeiten zwischen Teams um und wie sorgt man für Transparenz, Kommunikation und Zielrichtung (Teamübergreifend)?

Abhängigkeiten zwischen Teams
Grob gesprochen gibt es zwei Arten von Abhängigkeiten die hier interessant sind:

• Terminliche Abhängigkeiten, bei denen Team A etwas umgesetzt haben muss bevor Team B damit arbeiten kann. Diese Abhängigkeiten sind oft fachlicher Natur. Team A arbeitet beispielsweise an einer zentralen Komponente oder an einem Systemteil der im Geschäftsprozess weiter vorne steht.
• Abhängigkeiten aufgrund querschnittlicher Aspekte. Diese Abhängigkeiten entstehen bei mehreren „Cross-funktionalen“ Teams, da sich alle Teams Gedanken zu Sicherheit, Persistenz, UI-Frameworks, etc. machen müssen. Der Auslöser sind hier meist nicht-funktionale, qualitative Anforderungen.

Terminliche Abhängigkeiten können meist ganz gut „geplant“ werden. In Scrum-Projekten würde etwa der Product Owner (bzw. sein Team) für eine geeignete Zuteilung von Stories zu Teams und Releases sorgen. Die meisten Abhängigkeiten können so lokal gehalten werden, ohne zu große Kommunikationshürden aufzubauen. Um diese Aufgabe zu bewältigen, ist in größeren Projekten ein gewisses Maß an fachlicher Analyse und Abhängigkeitsmanagement notwendig. Die Architekturaufgabe der fachlichen Strukturierung muss teilweise früh im Projekt angegangen werden, die genaue Ausgestaltung der Schnittstellen kann aber durchaus später erfolgen.

Abhängigkeiten aufgrund querschnittlicher Aspekte sind schwerer zu antizipieren. Arbeitet man alle übergreifenden Fragestellungen vorrausschauend aus, landet man schnell beim Wasserfall. Auf der anderen Seite führt völlige Ignoranz auf Anforderungsebene zu Insellösungen, Redundanzen, wenig Integrität und mehrfacher Arbeit. Ein Lösungsansatz muss hier Verantwortung an die Teams abgeben, gleichzeitig aber Kommunikation zwischen den Teams fördern, den Austausch zielrichten und entsprechende Entscheidungen möglich machen, ohne in „Design by Comitee“ abzudriften.
Eine Hälfte der Lösung kann das Verankern von qualitativen Anforderungen in den Backlogs sein (wie hier beschrieben: http://bit.ly/ehcVux). So sind sich die Teams dieser Abhängigkeiten bewusst und können entsprechend kommunizieren. Allgemeine Merker werden dabei meist gemeinsam ausgearbeitet (Stichwort Scrum of Scrums), Qualitätsgeschichten müssen in den meisten Fällen abgestimmt werden und Akzeptanzkriterien können in Einzelfällen zu breiteren Lösungen (wie Frameworks) führen, die dann ebenfalls abgestimmt werden müssen.

Transparenz, Kommunikation und Zielrichtung
Das Erkennen von Abhängigkeiten ist ein guter Schritt, aber wie funktioniert nun die genannte „Abstimmung“? Die zweite Hälfte einer möglichen Lösung heißt für mich Architekturbewertung. Der Kern dieser Methodik liegt abseits der akademischen Methoden und „Expertenreviews“ in der zielgerichteten Zusammenarbeit. In Workshops mit möglichst breiter Stakeholder-Beteiligung werden Lösungsoptionen gegen Anforderungen gehalten. (Architekturbewertung stelle ich im Detail hier vor: http://bit.ly/hKkZ7r)
In obigem Beispiel, wären die wichtigsten Stakeholder auf jeden Fall Mitglieder aus den betroffenen Teams und der (ein) Product Owner. Lösungsoptionen werden vom bearbeitenden Team in die Runde getragen und dort auf breite Anwendbarkeit und Risiken geprüft. Im Prinzip handelt es sich um ein Scrum of Scrums mit einigen unterstützenden Werkzeugen. Durch die lokale Erarbeitung, die getrennte Bewertung und die explizite Benennung dieses Vorgangs richtet man Kommunikation klar auf ein Ziel aus. Dabei schrumpft der Kommunikationsbedarf auch in größeren Projekten auf ein handhabbares Ausmaß. Um breite Transparenz zu erzeugen, kann man die Workshops in wechselnder Zusammensetzung durchführen oder stille Beobachter erlauben.

Und der Architekt?
Auch wenn die Rollengestaltung immer eine sehr individuelle Sache ist, ist der Architekt als Rolle in der Architekturbewertung nicht zentral. Es geht um Architekturentscheidungen, die durch die Arbeit mit Qualitätsanforderungen im Backlog getroffen werden. Die Teamübergreifende Abstimmung kann auf dieser Basis gut ohne eine entsprechende Rolle auskommen. Die Abhängigkeiten aufgrund querschnittlicher Aspekte erfordern also nicht zwangsläufig einen Architekten. Für die angesprochene fachliche Strukturierung und die Verankerung von Qualitätsanforderungen könnte der Product Owner allerdings Unterstützung brauchen…

Mehr dazu hoffentlich auf der JAX.

Anfang der Woche zwitscherte der Link auf einen Blogeintrag mit dem schönen Titel: “Goodbye Google App Engine (GAE)” herum. Da klickt natürlich jeder erstmal reflexartig drauf (“Wie, Google macht die App Engine dicht?”).

Beim Lesen stellte sich dann aber schnell heraus, dass Google die App Engine mit nichten dicht macht. Ich blieb trotzdem dran, leitete der Autor Carlos Ble den Text doch immerhin ein mit: “Choosing GAE as the platform for our project is a mistake which cost I estimate in about 15000€. Considering it’s been my money, it is a “bit” painful.” Böse, böse Cloud?

Liest man weiter, lernt man, dass die Entscheidung in Carlos Projekt für die GAE vor allem in der Hoffnung getroffen wurde, Skalierbarkeit, Verfügbarkeit etc. zu erreichen. Im weiteren Verlauf der Entwicklung tauchten aber viele Stolpersteine auf.  Letztlich Limitationen der GAE, um eben diese Skalierbarkeit, Verfügbarkeit etc. zu erreichen. Für Carlos aber im Nachhinein (!) mit ausschlaggebend, um die GAE als Deployment-Plattform für die Produktion zu verwerfen (“Goodbye”).

Softwarearchitektur ist die Summe wichtiger Entscheidungen. Diese Architekturentscheidungen sind dadurch gekennzeichnet, dass sie im weiteren Verlauf nur sehr schwer zurückzunehmen sind. Sie grenzen den Lösungsraum für den Entwurf massiv ein. Wenn sie falsch getroffen werden, kostet das nicht selten viel Aufwand, Geld, Zeit, und unter Umständen scheitert das Projekt.

Ich habe selten ein so prägnantes Beispiel für eine (im nachhinein) falsch getroffene Architekturentscheidung gesehen. Technische Risiken sollte man beim Architekturentwurf schon auf dem Schirm haben. Im vorliegenden Fall hätte allein schon das Lesen der Dokumentation viel Unsicherheit rausnehmen können.

Carlos Ble hat den Text mittlerweile neu geschrieben, und zahlreiche Kommentare (u.a. von Google) verarbeitet. Ich habe großen Respekt vor ihm.  Er gibt von Anfang an (auch in seinem ersten Beitrag) nicht anderen die Schuld für seine zu euphorische Entscheidung für GAE. Und es ist eine schöne, einführende Darstellung der Limitationen für Interessierte, die sich nicht durch die ganze Doku kämpfen wollen. Allerdings mit etwas Vorsicht zu genießen; teilweise hat Google sie bereits aufgehoben.

Was lernen wir nun daraus? Dass methodischer Architekturentwurf auch beim Deployment in der Cloud eine sinnvolle Aktion ist. Und vor allem:  Dass ein cooler Titel bei einem Blog-Eintrag für viel Aufmerksamkeit sorgen kann.

In meinem vorigen Blogeintrag (http://bit.ly/cWU0fn) habe ich beschrieben, wie ein moderner, skalierender Architekturprozess aussehen kann. Als Entscheidungsgrundlage, ob und wenn ja wie viel Architektur man braucht, wurden dabei Anforderungen identifiziert: Besonders Risikoreiche oder qualitative Anforderungen machen den Architekturzyklus sinnvoller. Nun möchte ich einen Blick auf agile Projekte werfen: Wie dockt das beschriebene Entwicklungsmodell hier an?

Was es braucht…
Gerade in agilen Projekten ist es wichtig zu entscheiden wann Architektur wichtig ist und wann man besser direkt in die Umsetzung geht. Ein Problem das ich hierbei schon öfter beobachtet habe ist, dass qualitative Anforderungen und teilweise auch Risiken zu wenig sichtbar sind, um die richtige Entscheidung zu treffen. Funktionale Anforderungen in einem Backlog zu sammeln ist hier nicht genug. Konkrete, explizite Qualitätsanforderungen zu Wartbarkeit, Sicherheit, Verfügbarkeit, etc. sind nicht nur für die Architekturarbeit essentiell, sondern auch für die Entscheidung ob Architekturarbeit nötig ist.

Qualitätsanforderungen verankern
Mir sind drei Möglichkeiten bekannt, qualitative Anforderungen in agilen Projekten zu „verankern“:

• Als Qualitätsgeschichte: Qualitative Anforderungen (etwa zu Skalierbarkeit) kommen, wie funktionale Anforderungen auch, als Story in den Backlog.
• Als Akzeptanzkriterium: Qualitative Anforderungen werden als Akzeptanzkriterium funktionalen Anforderungen zugeschlagen.
• Als allgemeiner Merker: Qualitative Anforderungen werden als omnipräsent kommuniziert. Jedes Teammitglied denkt immer an Qualität xy und wird eventuell durch einen Eintrag in der Definition of Done daran erinnert.

In bestimmten Situationen haben sicher alle genannten Optionen so ihre Probleme. Definiert man Qualitäten allerdings konkret genug, kann man ein sinnvolles Zusammenspiel der Techniken erreichen. So kommen Qualitätsgeschichten zum Einsatz wenn entsprechende Anforderungen relativ unabhängig bearbeitbar sind, Akzeptanzkriterien kommen bei direkten Erweiterungen funktionaler Anforderungen zum Einsatz und allgemeine Merker bei sehr breit wirkenden Anforderungen.

Agile Architektur
Durch die explizite Erhebung und Verankerung von qualitativen Anforderungen, kann die Entscheidung zur Architekturarbeit leichter erfolgen. Der Architekturzyklus wird z.B. durchlaufen wenn Qualitätsgeschichten hochprior im Backlog liegen, wenn Akzeptanzkriterien große Bedenken auslösen oder ein allgemeiner Merker erarbeitet werden soll (etwa eine breite Entwicklungsvorgabe zur Verwendung von Interfaces). Die Arbeit erfolgt in den Iterationen, parallel zur Umsetzung und natürlich vom Kundenvertreter priorisiert. Letzteres schafft eine potentielle „Streitschnittstelle“, die implizit angenommene Risiken aufdeckt und für Transparenz sorgt.

Fazit
Auch wenn ich sie hier nicht in aller Ausführlichkeit besprechen kann, sind die vorgestellten Ansätze, in der ein oder anderen Form, in vielen Projekten zu finden. Der gemeinsame Einsatz führt dabei zur Umschiffung vieler Nachteile, sorgt für bessere Entscheidungen was Architekturarbeit betrifft und erlaubt die sinnvolle Bewertung von Architekturlösungen. Dabei sollte der schlanke, kundenorientierte Prozess agiler Projekte nicht an Schwung verlieren.

Wie funktioniert Softwarearchitektur heutzutage eigentlich? Seit den 80ern hat sich eine Menge getan und die agile Bewegung brachte noch einmal Schwung in die Entwicklung hin zu… ja hin zu was? Gibt es Architektur als Disziplin noch?

Anforderungen an eine Architekturmethodik
Wir arbeiten gerade an einem neuen Architektur-Curriculum für 2011 und versuchen unsere Praxis auf ein vermittelbares Fundament zu stellen. Aber Architektur fühlt sich nicht mehr an wie noch vor einigen Jahren. Viele Projekte mit denen ich zu tun habe verabschieden sich von groß angelegten Architekturphasen zu Projektbeginn, arbeiten stetig, iterativ, kundengetrieben und oft auch ohne die Rolle „Architekt“ im ursprünglichen Sinn. Das ist erfolgreich und eine äußerst positive Entwicklung, verändert die Disziplin der Softwarearchitektur aber auch nachhaltig. Die Disziplin gibt es zwar noch, wir müssen sie aber offener beschreiben und einige Paradigmen ersetzen.

Nun hilft es meiner Ansicht nach wenig, Architektur einfach nur agil zu machen. Zumindest die Projekte unserer Kunden sind sehr unterschiedlich was ihre Agilität angeht. „Emergentes Design“ und Agilität in Reinkultur funktionieren nicht unter allen Voraussetzungen. Eine Architektur-Methodik muss also skalieren und braucht eine Entscheidungsgrundlage. Wann arbeitet man mehr, wann weniger an der Architektur? Wann implementiert man einfach, wann lohnt sich Design?

Architekturarbeit im Kontext
Ein erster Versuch darzustellen wie ein einfacher Architekturprozess aussehen kann, der diese Abwägungen lokalisiert, ist in folgender Abbildung zu sehen.

Architekturarbeit im Kontext

Die Abbildung zeigt 2 Zyklen: links den Architekturzyklus, rechts den Implementierungszyklus. Tätigkeitsbereiche sind in grauen Kästen dargestellt und werden durch eine Auflistung typischer Artefakte ergänzt. Basis für Architektur und Umsetzung sind in jedem Fall priorisierte Anforderungen von Kundenseite. Anforderungen können direkt in Code gegossen werden, Funktionalität wird stetig ausgeliefert, bildet aber auch iterativ Feedback für noch nicht umgesetzte Anforderungen.

Architekturzyklus: Wann und wie oft?
Wie man sieht, ist der Architekturzyklus optional. Zu Beginn wird den Zyklus aber fast jedes Projekt durchlaufen. Zumindest um eine gemeinsame Vision zu entwickeln, spätere Entscheidungen zu vereinfachen und den groben Rahmen für die Entwicklung festzulegen. Üblicher Weise versucht man sich vorab auf ein Minimum zu beschränken. Anforderungen sind hier, genau wie später im Prozess, der entscheidende Faktor: Architekturarbeit wird interessanter wenn:

• Anforderungen beträchtliche Risiken bergen
• höhere qualitative Anforderungen (Sicherheit, Verfügbarkeit, Skalierbarkeit, etc.) ins Spiel kommen.

Um Risiken zu mindern wird man vor der tatsächlichen Umsetzung eventuell Prototypen oder Durchstiche bauen und versucht neue Technologien auszuprobieren bevor man sie breit einsetzt.

Hohe qualitative Anforderungen, wie im zweiten Punkt genannt, kommen fast immer mit der Notwendigkeit von Kompromissen einher. Diese Kompromisse willentlich abzuwägen, zum Kunden zu tragen und entsprechende Entscheidungen konsistent und transparent zu treffen ist ebenfalls Architektur- und vor allem Architekturbewertungsaufgabe.

Dinge die man später noch einfach ändern kann, fallen nicht in dieses Schema. Sie werden am besten auf einfache Weise direkt umgesetzt.

Anmerkung: Die bloße Präsenz von Architekturaufgaben hat, aus meiner Sicht, nichts mit der Notwendigkeit eines Architekten zu tun.

Ausblick
Wie man qualitative Anforderungen und Risiken nun entsprechend festhält und auch in agilen Projekten verankert (ohne diese schwergewichtiger oder weniger kundenorientiert zu machen), wird Thema eines folgenden Blogeintrags. Danach werde ich auch darauf eingehen wie Architekturbewertung effektives Feedback ermöglicht und dabei Gedanken des „Lean Development“ aufgreift.