Wie Ihr vielleicht schon gelesen habt, trommeln wir immer wieder für mehr Konzeptarbeit in Softwareprojekten (beispielsweise hier, hier oder hier). Dass das notwendig ist, sehen wir immer wieder in unseren Projekten, in denen ganz häufig einfach mal losgelegt wird und dann zentrale Qualitätsanfoderungen nicht erfüllt werden können und das System grundlegend umgebaut werden muss. Gut reflektiert das auch die Architekturdokumentation. Wenn es gut läuft, sind Kontextabgrenzung, Bausteinsicht und Deployment gefüllt, zentrale Architekturkonzepte darüber hinaus sind aber nur selten zu sehen und wenn, dann nur rudimentär beschrieben. Wir finden das immer bemerkenswert und schade, weil doch hier die ganze Musik im Design des Systems spielt.

Initialzerlegung, dann konzeptzentriertes Design

Wir unterscheiden typischerweise zwischen einer Initialzerlegung des Systems und dem konzeptzentrierten Design: Wenn man anfängt, ein System zu entwerfen, macht man zunächst eine Initialzerlegung, in der man sich um fundamentale Systemstruktur, Daten und Deployment kümmert. Hat man hier einen ausreichend detaillierten Stand erreicht, wird Architektur als kontinuierliche Aktivität im Entwicklungsprozess zunehmend mehr konzeptzentriert: Man nimmt sich sukzessive Themen vor und entwickelt dafür einen geeigneten Lösungsansatz. Und davon sollte es selbst in einem System mittlerer Größe bereits ein paar Dutzend geben.

Wenn wir dieses Vorgehen in Bezug zur arc42-Vorlage setzen, dann gehören Kapitel 5, 6 und 7 zur Initialzerlegung, Kapitel 8 enthält die Ergebnisse des konzeptgetriebenen Designs. Ich finde, alleine dadurch entsteht schon bei Vielen der Eindruck einer niedrigen Priorität des Konzepte-Bereiches: Es ist nur ein Kapitel neben vielen anderen und kommt dann auch noch relativ weit hinten; nicht so wichtig, kümmern wir uns später drum, wenn wir Zeit haben. Nicht zuträglich ist hier auch die Beschreibung von arc42: „Pick only the most-needed topics for your system…“ suggeriert: eher klein halten. Und interessanterweise sind auch die Beispiele im Buch „arc42 by Example“ eher dünn aufgestellt. Im Schnitt werden nur sieben Seiten für Architekturkonzepte verwendet, mal nur zwei, mal auch elf. Da ist die von uns immer wieder festgestellte Dürre im Kapitel 8 nicht verwunderlich.

Konzeptarten

Ich habe ja oben gesagt, bei Konzepten spielt die Musik. Damit man ein Gefühl bekommt, was das alles sein kann, will ich folgend ein paar Beispiele geben. Wir unterscheiden typischerweise die folgenden Arten von Architekturkonzepten: technische Konzepte, Qualitätskonzepte und fachliche Konzepte (oder auch Domänenkonzepte). Diese Unterscheidung ist, wie immer, nicht 100%-ig trennscharf; als Richtlinie um an alles Wichtige zu denken, kann sie aber ganz hilfreich sein.

Technische Konzepte sind Konzepte für typische, häufig wiederkehrende und für die meisten Systeme zutreffende Herausforderungen technischen Ursprungs. Obwohl man sie streng genommen auch als Lösungsansätze für Qualitätsattribute sehen kann, werden für technische Konzepte nur selten explizite Qualitätsszenarien definiert. Die Notwendigkeit ist technischen Stakeholdern meist intuitiv klar (explizite Anforderungen zu definieren ist aber natürlich immer eine gute Idee). Beispiele für technische Konzepte sind:

• Logging-Konzept
• Error Handling-Konzept
• Input Validation-Konzept

Qualitätskonzepte sind Lösungsansätze, die als Grundlage zur Erfüllung von Qualitätsanforderungen dienen. Dafür werden typischerweise Qualitätsszenarien formuliert, die die konkrete Ausprägung der Anforderung für das zu entwickelnde System erfassen. Qualitätskonzepte schaffen Lösungen für ein oder eine Menge von zusammengehörigen Qualitätsanforderungen, die häufig Auswirkungen auf unterschiedliche Systemteile haben, das heißt sie sind meist „cross cutting“. Beispiele für Qualitätskonzepte sind:

• Authentifizierungskonzept
• Konzept für horizontale Skalierung
• Internationalisierungskonzept

Fachliche Konzepte (oder auch Domänenkonzepte) sind Konzepte, die Lösungsansätze für die Problemstellungen aus der Fachlichkeit bereitstellen, in der das System verortet ist. Damit sind diese Konzepte hochgradig spezifisch für das zu entwickelnde System. Beispiele aus unseren Projekten, in denen wir unterwegs waren sind:

• Konzept zur Rundung von Beträgen bei Abrechnungen
• Konzept zur Identifikation von Produkten bei unterschiedlichen Händlern im E-Commerce
• Konzept zur Modellierung von Geschäftsregeln durch Fachanwender und deren Qualitätssicherung und Ausführung

Von häufig anzutreffen bis projektspezifisch

Die genannten Konzeptarten werden von oben nach unten zunehmend projektspezifischer. Während in vielen Projekten technische Konzepte für ähnliche Themen anzutreffen sind, ist die Auswahl der relevanten Qualitätsattribute und zugehöriger Anforderungen und Konzepte über Projekte hinweg differenzierter, und am spezifischsten bei den fachlichen Konzepten, wo die Themenstellungen bei unterschiedlichen Systemen meist völlig andere sind. (Um präzise zu sein: ich spreche hier von wiederkehrenden Themen, die konkrete Ausgestaltung der Konzepte unterscheidet sich potentiell zwischen Projekten deutlicher.)

Interessanterweise ist es auch hier so, dass obwohl die höchste Priorität auf den Konzepten liegen sollte, sich die Häufigkeit mit der wir entsprechende Konzepte in Architekturdokumentationen ausgearbeitet sehen, quasi genau entgegengesetzt verhält. Technische Konzepte sieht man schon gelegentlich, detailliert ausgearbeitete Qualitätskonzepte seltener und nur sehr selten fachliche Konzepte.

In der Erläuterung zu Kapitel 8 findet sich in arc42 das folgende Diagramm, in der unterschiedliche Arten von Konzepten mit Beispielen gegeben sind (in etwas anderer Kategorisierung).

Der kleinste Bereich ist auch hier der der Domänenkonzepte. Das ist irgendwie auch nachvollziehbar, arc42 soll ja eine, für viele Systeme anwendbare Vorlage sein. Da ist es schwierig, für diesen Bereich spezifische Beispiele aufzuführen, die auch verständlich und übertragbar sind. Dennoch entsteht auch dadurch der Eindruck einer untergeordneten Priorität, in einem ohnehin schon wenig beachteten Kapitel.

Fazit

In den Architekturdokumentationen, die wir in unseren Projekten sehen, nehmen wir eine absolute Überbetonung der Kapitel zur Initialzerlegung des Systems wahr und gleichzeitig sind Architekturkonzepte häufig total unterrepräsentiert. Und wenn Konzepte ausgearbeitet sind, sind es meist die immer wiederkehrenden Klassiker und nicht die, die das System von anderen unterscheidet.

Das sollte so nicht sein. Zwar ist die Initialzerlegung ein wichtiger erster Schritt, aber dann müssen Lösungen für alle wichtigen Problemstellungen des Systems erarbeitet werden. Darin steckt so viel Tiefe und Detail über die Funktionsweise des Systems, dass mir ehrlich gesagt schleierhaft ist, wie man denken kann, überhaupt klarzukommen, ohne diese Dinge aufzuschreiben.

Diese Dinge erarbeitet und dokumentiert man geschickterweise als Architekturkonzepte, die dann auch in der Architekturdokumentation an der entsprechenden Stelle niedergelegt sein sollten. So wird die Architekturdokumentation zu einem lebenden Artefakt, das immer mehr und besser die Funktionsweise des Systems beschreibt. Das passt auch gut zu Softwarearchitektur ingesamt, die ja nicht nur am Anfang stattfindet, sondern als kontinuierliche Aktivität im Entwicklungsprozess die Umsetzung des Systems begleitet.

Also, arbeitet an Euren Konzeptkapiteln! Die Entscheidungen müsst ihr ohnehin treffen, wenn ihr das explizit macht und das Konzept auch aufschreibt, profitiert Euer gesamtes Projekt davon. Also, los geht’s.