2Einstieg samt Wegweiser

Auf den nächsten Seiten tauchen Sie in die inhaltliche Vision des Buchs ein. Die übergreifende Idee hinter den 29 Vorgehensmustern für Softwarearchitektur ist in Abschnitt 2.1 detailliert dargestellt und mit den Konzepten der übrigen Kapitel verbunden. Nach diesem vielleicht wichtigsten Abschnitt des gesamten Buchs biete ich Ihnen verschiedene Zugänge zu den enthaltenen Vorgehensmustern:

? ? Für Pragmatiker gibt Abschnitt 2.2 – „Muster im Überblick“ einen sachlichen Überblick: Einer Kapitelzusammenfassung folgt jeweils ein Verzeichnis der enthaltenen Vorgehensmuster, inklusive Problem und Kurzbeschreibung.

? ? Für Methodiker kommt Abschnitt 2.3 – „Muster im Vorgehen einsortiert“ gerade recht: Ich stelle hier ein generisches Entwicklungsvorgehen vor, das beschreibt, wie und wann Softwarearchitekturarbeit sinnvoll ist. In dieses Vorgehen integriere ich anschließend die Vorgehensmuster dieses Buchs.

? ? Für Rollenfreunde bietet Abschnitt 2.4 – „Muster und die Architektenfrage“ eine musterübergreifende Antwort auf die Frage, ob und wenn ja, welche Arten von Architekten, in zeitgemäßen Entwicklungsprojekten gefragt sind.

Zum Abschluss stelle ich kurz das Fallbeispiel vor, das Sie durch alle Vorgehensmuster begleiten wird (Abschnitt 2.5).

? ?2.1 Die inhaltliche Vision

Hinter den Vorgehensmustern dieses Buchs steht eine konsistente Vision zeitgemäßer Softwarearchitekturarbeit. Bereits die in Abschnitt 1.3 genannten Definitionen von Softwarearchitektur scheren nicht alle Softwareentwicklungsprojekte über einen Kamm. Menge und Ausprägung von grundlegenden, risikoreichen Fragestellungen sind von Projekt zu Projekt unterschiedlich. Zeitgemäße Softwarearchitektur erkennt diese Individualität auf vielen Ebenen an und greift aktuelle Strömungen der Softwareentwicklung auf. Zeitgemäße Softwarearchitektur ist:

1.Durch Anforderungen getrieben

2.Vom Aufwand her dem Problem angemessen

? ? In dynamischen Umfeldern nicht behindernd

? ? In architektonisch risikoreichen Projekten ausreichend fundiert

3.Von aktuellen Erkenntnissen zu Zusammenarbeit und Vorgehen beeinflusst

4.Gut mit der Entwicklung verzahnt

5.Einfach in aktuelle Vorgehensmodelle integrierbar

? ? Iterativ leistbar

? ? In aktuellen Konzepten des Vorgehens verankert

? ? Frei von behindernden oder umständlichen Ergänzungen

Ich greife diese Punkte im Folgenden auf, beschreibe sie etwas detaillierter und referenziere auf wichtige Vorgehensmuster.

2.1.1?Durch Anforderungen getrieben

Wenn Sie eine fachliche Methode ausimplementieren oder ein neues Feld im UI vorsehen, orientieren Sie sich an Wünschen und Anforderungen des Kunden. Dasselbe sollten Sie tun, wenn Sie Technologien auswählen oder Fremdsysteme anbinden. Was auch immer die grundlegenden Fragestellungen in Ihrem Projekt sind: Lassen Sie sich von Anforderungen leiten.

Qualitätsanforderungen kommt dabei eine besondere Bedeutung zu. Sie beschreiben die nichtfunktionalen Aspekte der zu erstellenden Lösung, also wie eine Funktionalität bereitgestellt werden soll.1 Soll die Funktionalität ohne Unterbrechung zur Verfügung stehen, sind Zuverlässigkeit und Verfügbarkeit wichtig. Wollen wir in Zukunft mehr Benutzer mit unserer Funktionalität beglücken, ist Skalierbarkeit spannend. Wollen wir verhindern, dass Unbefugte heikle Funktionalität nutzen, ist Sicherheit ein Thema. Diese Qualitätsmerkmale beziehen sich oft auf weite Systemteile oder sogar das Gesamtsystem. Zuverlässigkeit lässt sich nicht durch eine neue Klasse oder Komponente sicherstellen, die gesamte Anwendung und deren Basis müssen entsprechenden Prinzipien gehorchen.

Qualität ist somit meist querschnittlich und betrifft viele Projektmitarbeiter. Wir erreichen Qualitätsmerkmale durch den Einsatz der richtigen Technologien, Plattformen, Frameworks, Muster oder die breite Adaptierung von Arbeitsweisen. Das ist grundlegende Arbeit am Fundament. Entsprechende Entscheidungen sind weitreichend und oft aufwendig in der Umsetzung. Wir sind damit mitten in der Architekturdomäne und es ist wenig überraschend, dass Qualitätsanforderungen als die Architekturanforderungen gesehen werden.

2.1.2?Vom Aufwand her dem Problem angemessen

Stellen Sie sich ein Produktentwicklungsprojekt vor, das auf einem bekannten Technologiestack aufsetzt. Es gibt ein passendes, unternehmensspezifisches Applikationsframework, das einzige Umsetzungsteam hat bereits ähnliche Projekte durchgeführt und kennt die Domäne. Der Projektplan ist realistisch und der Aufwand ist überschaubar. Dieses Projekt kommt wohl mit weniger Architekturaufwänden aus als ein großes Projekt für die Umsetzung einer neuartigen Flugsicherungssoftware. Im ersten Projekt ergeben sich wahrscheinlich weniger risikoreiche Fragestellungen. Das Umfeld ist weniger komplex, das zu lösende Problem und der Lösungsweg sind recht gut verstanden. In Projekt zwei sind einige Komplexitätstreiber zu finden – Architekturarbeit wird spannender. Bild?2.1 zeigt, wie sich Architekturaufwände und Komplexitätstreiber die Waage halten sollten.

Arbeit an der Softwarearchitektur hat das Ziel, gute Entscheidungen zum richtigen Zeitpunkt zu treffen und das Risiko einer falschen Entscheidung zu minimieren. Zu hohe Aufwände machen Projekte schwerfällig, langsam und aufwendiger als nötig. Erstellen Sie etwa einen Prototypen für eine einfach umzusetzende Anforderung, verzögern Sie die Umsetzung und die damit verbundene Rückmeldung. Ihr Aufwand hat zudem wenig bis keinen Nutzen. Solche „Irrwege“ behindern vor allem in weniger komplexen, dynamischen Projekten und machen sie starrer als nötig.

Auf der anderen Seite führt zu wenig Arbeit an der Softwarearchitektur zu zufälliger Architektur und potenziell zur Verfehlung wichtiger Projektziele. In architektonisch risikoreichen Projekten muss folglich ausreichend fundierte Architekturarbeit geleistet werden.

Wichtig ist die richtige Balance, die sich für jedes Projekt anders gestaltet.

Bild?2.1?Das richtige Maß für Softwarearchitekturarbeit

2.1.3?Von aktuellen Erkenntnissen zu Zusammenarbeit und Vorgehen beeinflusst

Auch wenn die Wurzeln der Disziplin noch weiter zurückreichen, Softwarearchitektur ist ein Kind der 1990er-Jahre. Im universitären Umfeld und mit großer finanzieller Unterstützung des amerikanischen Verteidigungsministeriums wurden Muster, Sprachen und Methoden erarbeitet2. Weil Rollen- und Prozessmodelle ihre Blütezeit erlebten, konnte man die Disziplin relativ leicht einem „Architekten“ zuschlagen.

Die Softwareentwicklung hat seit den 1990er-Jahren viel gelernt. Agile Softwareentwicklung, Lean Development oder auch die Organisationstheorie beinhalten viele Erkenntnisse zu Zusammenarbeit, Komplexität und Dynamik. Auch Softwarearchitektur kann als Disziplin von diesen Erkenntnissen profitieren.

Wie wäre es mit Praktiken, die es ermöglichen, Architekturaufgaben effektiv auf mehrere Schultern zu verteilen? Praktiken, die dynamische Projekte nicht bremsen? Was...