Projekte und Produktentwicklungen sind unterschiedlich. Fest steht jedoch: Nirgendwo findet man ein perfektes Umfeld mit ausreichend Geld, Zeit und fähigen Leuten, ohne störende Legacy-Lasten, fehlerhafte Libraries oder böse Überraschungen. Selbst wenn viele dieser Parameter passen, ist Ihr Kunde oder Fachbereich vielleicht wankelmütig, oder das Management wechselt während des Vorhabens die eigene Linie (falls es eine gibt). Moderne Softwareentwicklung ist komplex und wenig schablonenhaft. Zeitgemäße Arbeit an der Softwarearchitektur muss deshalb Reaktionsfähigkeit stärken, fokussieren und sich davon verabschieden, dass alles vorab plan- und analysierbar ist.

Viele methodische Entwicklungen der letzten fünfzehn Jahre kann man als Reaktion auf die komplexen Herausforderungen der heutigen Softwareentwicklung verstehen. Agile Vorgehensmodelle versuchen mit Unsicherheit zu leben, Flexibilität im Vorgehen zu ermöglichen und Zusammenarbeit zu stärken. Die richtige Reaktion ist wichtiger als der richtige Plan. Lean stellt das Lernen und stetige Verbesserung in den Vordergrund, versucht Verschwendung zu elimieren und unser Vorgehen auf wichtige Aspekte zu fokussieren. Der Trend geht weit über die Softwareentwicklung hinaus, und selbst wenn Sie den Begriff „Agil“ oder den (abflachenden) Hype darum nicht mögen – es hat sich etwas im Projektalltag verändert, und die Disziplin der Softwarearchitektur muss darauf regieren:

• Neue Ideen, Erkenntnisse und gut funktionierende Praktiken aus aktuellen Vorgehensmodellen sollten in den Architekturwerkzeugkasten übertragen werden. Das bedeutet, den Nutzen von Architekturtätigkeiten für Kunden zu offenbaren, entsprechende Anforderungen zu priorisieren, den Aufwand für Architekturtätigkeiten je nach Priorität und Kritikalität zu variieren, oder auch Architektur in Teams zu entwerfen.

• Architekturpraktiken und -tätigkeiten sollten sich in aktuellen Vorgehensmodellen nicht wie ein Fremdkörper anfühlen. Architekturarbeit muss so schlank wie möglich und so fundiert wie nötig sein. Das bedeutet, Architekturarbeit muss gut mit der Entwicklung verzahnt werden, agile Konstrukte zur Projektsteuerung annehmen, iterativ leistbar und möglichst frei von umständlichen Ergänzungen sein.

Ich greife Aspekte dieser Punkte im Folgenden auf und beschreibe sie etwas detaillierter.

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 nicht funktionalen Aspekte der zu erstellenden Lösung, also wie eine Funktionalität bereitgestellt werden soll. 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 aufwändig in der Umsetzung. Wir sind damit mitten in der Architekturdomäne, und es ist wenig überraschend, dass Qualitätsanforderungen als die Architekturanforderungen gesehen werden.

Umgang mit Qualitätsanforderungen

Um mit Qualitätsanforderungen effektiv zu arbeiten, benötigen Sie konkretere Informationen als die bloße Nennung wichtiger Qualitätsmerkmale wie Sicherheit oder Performanz. Sie benötigen detaillierte Aussagen zu qualitativen Anforderungen – etwa Qualitätsszenarien, die konkrete Beispiele für Qualitätsanforderungen liefern [1]. Abbildung 1 zeigt den Aufbau von Qualitätsszenarien und illustriert ihn mit einem Beispiel. Vereinfacht könnte man sagen, dass Qualitätsszenarien User Stories mit nicht funktionalem Hintergrund sind.

Szenarien sind auch konkret genug, um sie gut untereinander und gegen funktionale Anforderungen priorisieren zu können. Damit sind auch agile Backlogs für die Steuerung von Architekturarbeit im Spiel. Sie können die Qualitätsszenarien wie Stories unabhängig in den Backlog legen oder sie einzelnen funktionalen Anforderungen zuordnen. In der Praxis ist beides sinnvoll: Ein Szenariobeispiel wie „Der Algorithmus zur Berechnung der Artikelbeliebtheit soll leicht anpassbar und austauschbar sein“, ist am besten bei der funktionalen Anforderung zur Berechnung der Artikelbeliebtheit aufgehoben und wird gemeinsam mit dieser Anforderung priorisiert. Andere Szenarien, die Sicherheit oder Zuverlässigkeit zum Thema haben, beziehen sich nicht auf einzelne Funktionalitäten, sondern betreffen oft das gesamte System oder weite Teile desselben. Diese Szenarien sind die aus architektonischer Sicht wichtigeren und werden mit der „normalen“ Suche nach Akzeptanzkriterien zu funktionalen Anforderungen schwer gefunden. Eine gezielte Suche nach konkreten Aussagen zu Qualitätsmerkmalen bietet sich deshalb an.

Gefundene Szenarien, die unabhängig in die Anforderungsliste aufgenommen werden können, müssen priorisiert werden. In neu gestarteten Projekten sollte möglichst schnell ein „Walking Skeleton“ entstehen – ein Gerüst der Anwendung, das alle kritischen Schichten und Technologien berührt, ohne viel „Fleisch“ (im Sinne von Funktionalität) zu bieten. Technologisch herausfordernde oder neue Anforderungen und Szenarien werden folglich höher priorisiert als Anforderungen, die architektonisch mehr vom selben sind. In späteren Projektphasen ist vor allem das architektonische Risiko entscheidend. Folgende Fragen liefern Hinweise auf die Höhe des Risikos:

• Wie teuer oder zeitaufwändig wäre es, eine Fehlentscheidung zu revidieren?

• Wie viele Projektmitglieder sind von der Entscheidung betroffen?

• Sind zentrale Ziele des Projekts mit der Fragestellung verknüpft?

Szenarien mit hohem architektonischen Risiko oder großem Beitrag zum Walking Skeleton (oder beides) wandern weiter oben in die Anforderungsliste.

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 ü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 – die Architekturarbeit wird spannender. Abbildung 2 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 aufwändiger als nötig. Erstellen Sie etwa einen Prototyp 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.

Konkrete Fragestellungen einschätzen

Es ist das Eine, einzuschätzen, wie viel Architekturaufwand Ihr Projekt allgemein verdient. Es ist etwas Anderes, herauszufinden, wo genau diese Aufwände hinfließen sollten. Wie erkennen Sie an konkreten Fragestellungen, ob Architekturarbeit notwendig ist? Eine Lösung: Lassen Sie sich von den folgenden Fragen leiten (angelehnt an [3]):

• Ist die Entscheidung der Fragestellung später nur schwer zu ändern?

• Ist die Umsetzung der Entscheidung eher teuer?

• Werden sehr hohe qualitative Anforderungen gestellt (Hochsicherheit, Hochverfügbarkeit, Hochperformanz etc.)?

• Lassen sich die Anforderungen oder Lösungsalternativen nur schwer in Bestehendes abbilden (Istarchitektur, Rahmenbedingungen)?

• Ist die eigene Erfahrung im Lösungsspektrum schwach?

Die Fragen sind weder überschneidungsfrei noch messerscharf formuliert, sie sind aber für sehr unterschiedliche Rahmenbedingungen und Projektumgebungen funktionsfähig. „Schwer änderbar“ beinhaltet einmal mehr, einmal weniger Fragestellungen. Und was für manche Projekte „teuer“ wäre, ist für andere ein Klacks. Auch die beiden letzten Fragen, die eher Richtung Wissen, Erfahrung und Lösungsidee zielen, setzen keinen bestimmten Rahmen voraus.

Beantworten Sie die Fragen mehrheitlich mit „ja“, haben Sie vermutlich eine architektonisch risikoreiche Fragestellung an der Hand. Gerade die erste Frage ist recht aussagekräftig: Später schwer zu ändernde Entscheidungen betreffen viele Projektmitglieder, haben externe Abhängigkeiten oder beinhalten hohen finanziellen Einsatz. Häufig basieren solche Fragestellungen auf qualitativen Anforderungen, die querschnittlich wirken.

Haben Sie eine Fragestellung oder Entscheidung als architekturrelevant erkannt, lohnt sich der Einsatz architektonischer Mittel, um das Risiko einer Fehlentscheidung zu minimieren. Dazu gehören etwa die genauere Analyse nicht funktionaler Anforderungen, die Konzeption und ggf. Modellierung möglicher Lösungen, die Definition von Prinzipien, die Erstellung von Durchstichen und Prototypen oder die breite Vermittlung und Etablierung von Entscheidungen.

Andere Fragestellungen können während der Implementierung und im Zusammenspiel mit Test und Auslieferung effizienter beantwortet werden. Typische Kandidaten hierfür sind das genaue Klassendesign, interne Schnittstellen oder Implementierungsalternativen. Rückschläge auf dieser Ebene bedrohen Sie bei beschränkten Mitteln jedoch meist weniger als die eben identifizierten architekturrelevanten Fragestellungen.

Von aktuellen Erkenntnissen zu Zusammenarbeit und Vorgehen beeinflusst

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

Die Softwareentwicklung hat seit den 90er 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 halten Sie von zeitgemäßen Methoden zur Minimierung von Unsicherheiten und Risiken? Und was wäre, wenn Softwarearchitektur so transparent wird, dass Sie stetig und gewinnbringend mit Stakeholdern zusammenarbeiten können? Konkrete Methodikbausteine wären (näher beschrieben in [2]):

• Leichtgewichtige Ausprägungen von Architekturbewertungsverfahren: Sie bringen Projektmitglieder zusammen, um gezielt über architektonische Herausforderungen zu sprechen, stärken also Kommunikation und Fokussierung.

• Konsensmechanismen zur Unterstützung von Gruppenentscheidungen: Sie ermöglichen etwa die Vorbereitung von Entscheidungen durch einzelne Projektmitglieder und deren Annahme durch alle interessierten Entwickler. Über die Messung von Widerständen werden Risiken effektiv behandelt und Entscheidungsverfahren ufern nicht zu sehr aus.

• Sichtbare Architekturartefakte, etwa auf einer „Architekturwand“, wie in Abbildung 3 gezeigt: Eine Architekturwand kann als Informationsradiator nach agilem Vorbild verwendet werden und stärkt gleichzeitig die Zieltreue, verhindert das Verwässern wichtiger Architekturideen.

Gut mit der Implementierung verzahnt

Abbildung 4 zeigt ein vereinfachtes Bild eines generischen Entwicklungsprozesses. Er zeigt, wie Anforderungen die iterative Entwicklung speisen (Mitte), und der Umsetzungszyklus auslieferbare Software erstellt (rechts). Grundsätzliche, fundamentale Fragestellungen wandern vor der Implementierung durch den Architekturzyklus (links). Ich durchwandere das Bild mithilfe eines vereinfachten Beispiels, um die Verzahnung von Architektur und Implementierung zu illustrieren.

Sie haben immer wieder wichtige Entscheidungen in Ihrem Projekt zu treffen. Nehmen wir zum Beispiel an, ein Teil Ihrer Applikation nimmt komplizierte Berechnungen vor. Sie haben den Applikationsteil bereits in Bausteine zerlegt und sehen sich nun mit Anforderungen konfrontiert, die hohe Flexibilität im Berechnnungsablauf fordern. Da die Fragestellung nicht isoliert betrachtet werden kann und viele Bausteine betrifft, wandern Sie in den Architekturzyklus aus Abbildung 4.

Um möglichst lose Kopplung zu erreichen, entwerfen Sie einen einfachen Eventmechanismus. Sie sehen vor, dass Komponenten einen eigenen Berechnungszustand halten und bei Änderungen an diesem Zustand entsprechende Events feuern. Andere Bausteine können auf diese Events reagieren. Sie erstellen eine kleine Implementierung, die Möglichkeiten Ihrer Plattform nutzt, um diese Idee umzusetzen. Es funktioniert.

An dieser Stelle definieren Sie die Idee als brauchbare Möglichkeit und entscheiden sich für eine breitere Umsetzung. Sie schaffen damit die Grundlage für Implementierungstätigkeiten, Sie stellen eine Vorgabe auf (Abb. 4, oben links). Es handelt sich um den ersten wichtigen Berührungspunkt zwischen Architektur- und Umsetzungsarbeit.

In der Umsetzung wenden Sie das Konzept auf Ihre Bausteine an (vielleicht nicht sofort auf alle). Sie versuchen, Zustandsübergänge zu definieren, eine produktivtaugliche Implementierung für den Zustand selbst zu kreieren und entwerfen fachliche Events. Erst hier haben Sie das Problem annähernd vollständig vor Augen: Sie erkennen, wie kompliziert sich Zustände teilweise zusammensetzen, welche Daten mit den Events übertragen werden müssen und wie diese Lösung mit anderen Konzepten Ihrer Bausteine zusammenwirkt. Haben Sie wichtige Teile umgesetzt, können Sie mit Tests eine Idee vom Laufzeitverhalten bekommen.

Hier ist der zweite wichtige Berührungspunkt zwischen Architektur und Implementierung: die Rückmeldung aus der Implementierung, samt den Erkenntnissen aus Integration und Test (Abb. 4, oben rechts). Sie sollten diese Rückmeldung häufig und zeitnah suchen. So prüfen Sie Architekturentscheidungen und minimieren den Raum für Annahmen und Spekulationen. Technische oder konzeptionelle Probleme, die auf Implementierungsebene auftreten, stellen einen sekundären Architekturtreiber dar (neben den weiter oben besprochenen Anforderungen). Insgesamt entsteht eine gelebte Softwarearchitektur, die durch die Implementierung nicht verwässert, sondern bereichert wird.

Der Schlüssel hierzu sind die häufige Integration (und Auslieferung) von Software und die Verankerung von Architekturinformationen in Tests oder im Monitoring des Systems. So können konkrete Rückschlüsse auf die Erreichung wichtiger Qualitätsmerkmale gezogen werden. Unpassende, nicht performante oder unsichere Architekturkonzepte werden schneller entlarvt und treiben den Architekturzyklus. Die meisten Projekte beschreiben die erkannten Schwächen in Form von technischen Schulden und priorisieren sie wiederum mit Qualitätsszenarien und funktionalen Anforderungen im Backlog.

Einfach in aktuelle Vorgehensmodelle integrierbar

Immer mehr Projekte adaptieren ein Vorgehen, das mit so wenig Verzögerung wie möglich Richtung Auslieferung von Software drängt. Das Stichwort „agil“ ist so omnipräsent, dass sich viele bereits genervt abwenden, wenn das Thema zur Sprache kommt. Ich verweigere mich jedem religiösen Fanatismus an dieser Ecke und möchte hier auch nicht dogmatisch werden. Nüchtern betrachtet setzen immer mehr Projekte auf agile Praktiken – und es funktioniert. Viele Studien und Umfragen zeigen Erfolge von agilen Projekten [4], [5]. Eine von VersionOne durchgeführte Umfrage [6] befragte 2013 4 048 IT-Mitarbeiter aus Europa und den USA zum „State of Agile Development“. 84 Prozent der Organisationen setzen demnach agile Methoden ein, nur 3 Prozent der Unternehmen planen, das in Zukunft nicht zu tun. Scrum ist, wenig überraschend, am weitesten verbreitet und kommt auf 72 Prozent Marktanteil unter den agilen Methoden (Varianten mit eingerechnet).

Was bedeutet das für die Disziplin der Softwarearchitektur? Zeitgemäße Softwarearchitektur muss auch in agile Softwareprojekte passen und sollte die Konzepte, Praktiken und Rollen dieser Projekte nutzen und annehmen. Sie muss zumindest iterativ zu leisten sein und sollte eher erklären, wie Architekturpraktiken in moderne Vorgehensmodelle passen, als diese Vorgehensmodelle mit behindernden oder umständlichen Ergänzungen zu versehen. Wenn 75 Prozent der Projekte Iterationsplanungstreffen abhalten, 56 Prozent kontinuierlich integrieren und immerhin 23 Prozent Kanban nutzen [6], sollte Softwarearchitektur zumindest seinen Platz in diesen Praktiken kennen.

Die beschriebene Adoption des Backlogs zur Steuerung von Architekturarbeit ist bereits ein wichtiger Baustein, um diesem Zielbild näher zu kommen. Neben der Rückmeldung aus Systemtest und -integration muss man auch die Rollenfrage stellen. Was passiert mit „dem Architekten“ in agilen Vorgehen? In der Praxis etablieren sich neben dem Architekten als Person auch Modelle, in denen die Rolle auf mehrere Schultern verteilt wird (Abb. 5).

Ich habe jede der gezeigten Formen bereits in Projekten funktionieren sehen. Je nach Umfeld und Rahmenbedingungen funktionieren bestimmte Interpretationen der Architektenrolle besser oder schlechter – wichtig jedoch auch hier: Die Welt wird offener und flexibler. Die Architekturdisziplin wandelt sich zu einem Betätigungsfeld voller Möglichkeiten.

Fazit

Das gezeichnete Bild einer zeitgemäßen Architekturdisziplin, die auch in agilen Vorhaben ihren Platz findet und sich an modernen Praktiken orientiert, ist (dem Rahmen geschuldet) nicht vollständig. Es soll aktuelle Möglichkeiten zeigen und Sie dazu animieren, Ihr Denken zu öffnen und einige Facetten davon in Ihrem Kontext auszuprobieren. Wollen Sie tiefer in das Thema einsteigen, werden sie in [2] fündig – sehr praxisnah und intensiv können Sie auch im neuen iSAQB Advanc­ed-Level-Modul „AGILA – Agile Softwarearchitektur“ [7] lernen und diskutieren. Dort werden auch noch weiterführende Themen, wie der Zusammenhang der gewählten technischen Architektur und agilen Vorgehensmodellen, thematisiert.