Ich habe viele Definitionen von Softwarearchitektur gesehen und mich gefragt, „wer Recht hat“. Die Frage konnte ich letztlich nicht beantworten, doch den Vergleich fand ich interessant. So interessant, dass ich ihn mit Ihnen teilen möchte.

Grady Booch

width=

Er ist einer der Väter der UML und definierte Architektur so:

„Eine Architektur ist die Menge der signifikanten Entscheidungen über die Organisation eines Systems:

  • Auswahl der Strukturelemente und ihrer Schnittstellen, aus denen sich ein System zusammensetzt
  • Verhalten, wie es in der Zusammenarbeit dieser Elemente spezifiziert ist
  • Zusammenfassung dieser Struktur- und Verhaltenselemente zu immer größeren Subsystemen
  • Architekturstil, der diese ganze Organisation beschreibt“

Strukturelemente und Schnittstellen stehen im Vordergrund, wie bei den meisten Definitionen von Softwarearchitektur. Verhalten, Komponierbarkeit und Stil kommen bei Booch hinzu und runden das Bild von Architektur ab. Außerdem legt Booch Wert auf den Aspekt, dass es sich um signifikante Entscheidungen zu den Themen handelt. (Das Dumme ist, dass man oft erst im Nachhinein weiß, ob eine Entscheidung signifikant war).

ISO 42010

width=

In der ISO-Norm 42010 geht es um Architekturdokumentation. Das Gute an der Norm ist, dass sie jeden Begriff, den sie einführt, kurz und knackig definiert. Die Definition von Architektur bringt eine interessante Variante hinein:

„Architektur: Die fundamentalen Konzepte oder Eigenschaften eines Systems in seiner Umgebung, verkörpert in seinen Elementen, Beziehungen und den Prinzipien für sein Design und seine Evolution“

Hier taucht zusätzlich der Begriff Umgebung auf. Die Norm versteht darunter ganz generell entwicklungsbezogene, technologische, geschäftliche, betriebliche, organisatorische, politische, ökonomische, rechtliche, regulatorische, ökologische und soziale Einflüsse auf das System und seine Entstehung. Das ist für mich eine wichtige Sache, denn ich bin sicher, wenn man dieselben Anforderungen nähme und zwei sehr unterschiedliche Umgebungen vorgäbe, bekäme man zwei sehr verschiedene Architekturen heraus.

Auch den Begriff Evolution finde ich angebracht, denn Architektur bleibt ja nicht stehen, sondern entwickelt sich mit dem System weiter. Da ist es wichtig, dass man in den Teams Regeln dafür vereinbart hat, damit die Architektur nicht verwässert.

Eoin Woods

width=

Eoin Woods war früher Lead Architect für die Clearing-, Settlement- und Asset-Servicing-Systeme der UBS Investmentbank, bevor er Anfang 2015 zum CTO beim IT-Dienstleister Endava wurde.

Eoin sagte: „Architektur ist die Menge der Entwurfsentscheidungen, die, wenn falsch getroffen, Ihr Projekt scheitern lassen können.“

Hier also derselbe Gedanke wie bei Grady Booch: Es gibt manche Entscheidungen, von denen man wünschte, man hätte sie gleich am Anfang richtig getroffen. Zum Beispiel:

  • eine angemessene Programmiersprache gewählt
  • Frameworks ausgewählt, mit denen sich die Entwickler auskennen
  • eine performante, angemessene Datenbank ausgesucht
  • die Teams richtig aufgeteilt, so dass sie tatsächlich die Architektur hervorbringen können, die angedacht war
  • usw.

Leider hat man bei Architekturentscheidungen auch nicht mehr Treffsicherheit als bei allen anderen Entscheidungen im Leben.

Ralph Johnson

width=

„Das wichtige Zeugs, was immer das ist“ – davon sagt Martin Fowler, es sei seine bevorzugte Definition von Softwarearchitektur. Sie stammt nicht von Martin, sondern von Ralph Johnson, in seinem Post auf der Extreme Programming Mailingliste im April 2002.

Ralph argumentierte damals, dass manche Entscheidungen oder Elemente (z.B. die Datenbank) in einem Projekt wichtig sind und deshalb zur Architektur gehören und in einem anderen Projekt nicht. Architektur ist für ihn ein soziales Konstrukt, denn sie hängt nicht nur vom System, sondern von der Wahrnehmung der Leute ab, die an dem System arbeiten.

Paul Preiss

width=

Paul traf ich im März 2013, wir tauschten uns über das Thema Architekten-Ausbildung aus und verglichen das Ausbildungsprogramm der IASA und des iSAQB.

Dabei kamen wir auch auf die Frage: Wie definiert man eigentlich Softwarearchitektur? Paul sagte damals, für ihn seien die gängigen Definitionen („Elemente, Beziehungen, usw.“) zu abstrakt und er ziehe es vor, von Architektur als Kunst und Wissenschaft von der Lieferung wertvoller Software zu sprechen.

Was ich daran interessant finde: Es kommt eine betriebswirtschaftliche Denkweise hinein, die mir sonst in vielen anderen Definitionen fehlt. Man könnte zwar argumentieren: Das ist nicht der Job des Architekten, sondern des Produktmanagers. Doch wir Architekten, so glaube ich, tragen dabei eine Mitverantwortung: Die Effizienz der Entwickler und des Entwicklungsprozesses ist für mich genauso ein Qualitäts-Szenario, das wir anstreben müssen, wie z.B. Änderbarkeit, Performance oder Sicherheit. Wir müssen es den Entwicklern möglichst leicht machen, um kostengünstig zu entwickeln. Oder: Als Architekten müssen wir entscheiden, ob wir eine kostengünstige Fertigkomponente einkaufen, so dass vielleicht gar nichts entwickelt werden muss.

Bass, Clements, Kazman (SEI)

width=

Die drei Gurus von der SEI kritisieren in ihrem Buch Software Architecture in Practice diejenigen Definitionen, die von Architekturentscheidungen als den „frühen“ oder „großen“ Entscheidungen sprechen. Ob eine Entscheidung „groß“ war, wird meist erst die Zeit zeigen, also kann man das nicht als Kriterium nehmen, um zu beurteilen, ob eine Entscheidung eine Architekturentscheidung ist. Auch gibt es viele „frühe“ Entscheidungen, die nicht architekturrelevant sind.

Die Autoren argumentieren: Es geht um Strukturen, die uns dabei unterstützen, über das System und seine Eigenschaften nachzudenken. Eine Struktur ist dabei eine Menge von Elementen des Systems, die durch eine Relation zusammengehalten werden. Natürlich sind nicht alle solchen Strukturen architekturrelevant, z.B. die Menge aller Sourcecode-Zeilen, die den Buchstaben „z“ enthalten, ist zwar eine Struktur, aber keine relevante.

Wann ist also eine Struktur wirklich architekturrelevant? Praktisch und gut verständlich fand ich diese Definition, die die Autoren gleich noch mitliefern: Architekturrelevant ist eine Struktur dann, wenn sie das Nachdenken über das System und seine Eigenschaften ermöglicht, und wenn es dabei um ein Attribut des Systems geht, das für irgendeinen Stakeholder wichtig ist.

Und was heißt das in der Praxis?

Die letzte Definition (die des SEI) wird uns hier noch weiter beschäftigen. Denn wenn Architektur aus Strukturen besteht, stellt sich doch die Frage: Welche Strukturen sollten Sie genau in Ihrem Projekt erarbeiten? Das sehen Sie in diesem Video!

, Softwarearchitektur