In unserer schnelllebigen Zeit, wo technische Lösungen in kurzer Zeit entstehen und nach wenigen Jahren durch noch bessere Lösungen ersetzt werden, ist es besonders wichtig, die Gründe für die Wahl einer Technologie zu kennen. Streaming-Technologien wie Storm oder Spark bekommen gerade Konkurrenz durch das aufstrebende Flink. Auch im Bereich der No-Sql-Datenbanken gibt es mit HBase, Cassandra, Redis, PostgreSQL, MongoDB und CouchDB eine Vielzahl von Optionen. Und wer kann heute schon sagen, ob nicht auch die Konzepte des “machine learning” nicht bald zum Standardbaukasten einer modernen cloud-basierten Software-Architektur gehören.

Motivation

Software-Architektur entsteht immer, unabhängig davon, ob wir sie bewusst entwickeln oder ob wir sie einfach “passieren” lassen. Wichtig ist, dass das Vorgehen zum Projekt und zum Team passt und vom Auftraggeber akzeptiert wird. Die natürliche Tendenz der meisten Menschen ist, die Architektur zu planen. Aus dieser Motivation heraus entstehen sehr schnell Schichtenmodelle oder Baupläne für Komponenten, die die Struktur der Software beschreiben. Ich halte es aber viel wichtiger, dass die Entscheidungen dokumentiert werden, die zu solchen Strukturen führen. Ich bin überzeugt, dass wir mit den Mitteln der Entwickler wie git-Repositories, Namensräumen und objekt-orientierter Programmierung sehr viele gute Möglichkeiten haben, die Struktur einer Software “lesbar” zu machen. Entscheidungen können wir jedoch kaum oder nur schwer aus dem Code ablesen. Das Wissen über alternative Lösungen ist aber auf jeden Fall verloren, wenn die sie nicht dokumentiert werden.

Unter dem Titel “Knigge für Software-Architekten” haben Peter Hruschka und Gernot Starke einen lesenswerten Artikel über Entscheider geschrieben.  Obwohl der Artikel bereits im Jahr 2012 geschrieben wurde, hat er meiner Ansicht nach nichts an Aktualität verloren. Ich bin überzeugt, dass gerade in agilen Projekten die Transparenz bei Entscheidungen wichtiger ist als eine umfassende Dokumentation der Struktur einer Software. In Scrum wird die Software-Architektur von Sprint zu Sprint kontinuierlich weiterentwickelt. Software-Experten im Team treffen wichtige Entscheidungen im Idealfall termingerecht, also nicht zu früh, aber auch nicht zu spät (englisch: last responsible moment).

ktip Über diesen Zeitpunkt des “last responsible moment” gibt es ungezählte Blog-Beiträge und Diskussionen, jedes ernstzunehmende Buch über Software-Architektur widmet sich diesen Thema. Die Methode CARDS+ beschäftigt sich nicht mit der Frage, wann der beste Zeitpunkt für eine Entscheidung ist. Auch auf die Frage, wer die Entscheider sind, wird CARDS+ keine Antwort geben.

Mit dem Baustein Decision gibt es eine einfache Möglichkeit, eine Entscheidung genau dann zu dokumentieren, wenn sie getroffen wird. Zu diesem Zeitpunkt hat sich das cross-funktionale Team mit dem Thema beschäftigt, kennt neben der favorisierten Lösung noch weitere Alternativen. Jetzt ist jeder im Team in der Lage, Feedback zur Lösung und zur Begründung der Entscheidung zu geben. Jede Decision ist außerdem eine Sicherung von wertvollem Wissen der Software-Experten. Dadurch wird das Projekt robust gegenüber Fluktuation der Mitarbeiter.

Ein Punkt ist jedoch ganz wichtig. Dokumentierte Entscheidungen müssen von den Teams berücksichtigt werden. Sie sind Vorgaben, die einzuhalten sind. Natürlich heißt das nicht, dass eine einmal getroffene Entscheidung nie mehr korrigiert wird. Ganz im Gegenteil. Gerade wenn die Entwickler feststellen, dass eine Entscheidung Probleme verursacht, sollte das Team über Alternativen nachdenken. Aber hier kommt der Vorteil zum Tragen, dass wir die schon einmal betrachteten Alternativen kennen.

Weitere Quellen

Es gibt eine Reihe von Ansätzen, die Software-Architektur quasi als wissenschaftliche Disziplin betrachten, Kernaufgaben definieren und Vorlagen zur Verfügung stellen.

Die ganz wichtigen Entscheidungen werden als “Architecture Principles” beschrieben. Mit einem “Statement” beschreibt man die Essenz der Entscheidung, in einem “Rational” erklärt man die Auswirkungen der Entscheidung und die “Implications” definieren die Anforderungen an Projekt und Produkt bei der Umsetzung der Entscheidung. Zusätzlich gibt es das “Decision Log” als Teil des “Governance Log” zur Sicherung von Entscheidungen im Verlauf des Projektes.

Quelle: TOGAF9 online documentation

Hier ist es wünschenswert, alle wichtigen Entwurfsentscheidungen geschlossen nachlesen zu können. Wir werden aber aufgefordert abzuwägen, inwiefern Entwurfsentscheidungen zentral dokumentiert werden sollen oder wo eine lokale Beschreibung (z.B in der Beschreibung von Bausteinen) sinnvoller ist.

Quelle: ARC42 online documentation

Definition

Beschreibung

Der Baustein Decision hilft, Entscheidungen zu dokumentieren. Problem und Lösung als Überschriften kommen daher, dass wir uns zuerst mit dem Problemraum beschäftigen. Die Lösungen sollen die Vor- und Nachteile, Chancen, Risiken und Herausforderungen beschreiben. Die Entscheidung selbst soll nur zeigen, dass es zu einem bestimmten Zeitpunkt ein Team oder das Projekt auf Basis von bestimmten Gründen für eine der Lösung entschieden hat.

Eine Decision kann verändert werden. In diesem Fall können neue Lösungen ergänzt werden. Die existierenden Lösungen werden nicht geändert. Damit bleibt eine Historie  erhalten.

Struktur

Abschnitt Ausgangslage

Der Abschnitt beschreibt die Ausgangslage, also eine Anforderung, eine Herausforderung bezüglich Qualität, ein nicht-funktionaler Aspekt oder ganz allgemein ein fachliches oder technisches Problem. Folgende Fragen stellen wir uns:

  • Was genau ist das Problem?
  • Warum ist es für die Software-Architektur relevant?
  • Welche festen Randbedingungen müssen wir einhalten?
  • Welche Einflussfaktoren müssen wir beachten?
  • Welche Annahmen haben wir getroffen?
  • Welche Annahmen können wir vorab überprüfen?
Abschnitt Lösungen

In diesem Abschnitt präsentieren wir mindestens zwei Lösungen. Es ist jedoch nicht notwendig, jede Lösung in der gleichen Tiefe zu betrachten. Häufig gibt es eine favorisierte Lösung, die sehr genau beschrieben wird. Alternative Lösungen schreiben wir auf, um die unser Meinung nach relevanten Gründe gegen diese Lösungen festzuhalten.

Bei der Beurteilung der Lösung bietet sich eine SWOT-Analyse an. Dort stellen wir uns in vier Quadranten folgende Fragen:

  • Welche Stärken hat die Lösung?
  • Welche Schwächen hat die Lösung?
  • Welche Chancen eröffnet uns die Lösung?
  • Welche Risiken beinhaltet die Lösung?
Abschnitt Entscheidung

In diesem Abschnitt wählen wir die Lösung, die ab einem bestimmten Zeitpunkt (meist ab sofort) gültig ist. Dabei muss die Wahl der Lösung begründet werden.

  • Wer hat die Entscheidung getroffen?
  • Wann wurde entschieden?
  • Wie ist sie begründet?

In Ausnahmefällen können wir entschieden, dass wir keine oder keine akzeptable Lösung haben. In diesem Fall ist die Begründung besonders wichtig.