Agilität trotz komplexer Architekturen

Kulturelle Wesenszüge agiler Architektur

Die Antwort auf die zuvor gestellten Fragen hat zwei Aspekte. Zum einen geht es um die Angleichung von Prozessen, der wir uns im nächsten Abschnitt zuwenden. Zum anderen geht es um Einstellungen, Prinzipien und Praktiken der Akteure im Architekturumfeld – anders gesagt, um die Kultur, wie Architektur gelebt wird. Betrachten wir also Grundsätze agiler Entwicklung – darunter einige, die eher der verwandten Lean-Philosophie à là Poppendieck entstammen [9] – in ihrer Auslegung für die Architektur.

Ein wesentlicher Schlüssel ist die Einstellung, dass Architektur eine Hilfsdisziplin ist, die in der Wertschöpfungskette nur eine zuliefernde Rolle hat. Ein stimmiges „Architecture Repository“ (so der TOGAF-Terminus für die Gesamtheit der Architekturmodelle und Dokumente) hat keinen Wert in sich. Vielmehr sind die in Abbildung 1 gezeigten Prozesse mit Wissen zu versorgen, insbesondere also die Entwicklung, der eigentliche Wertschöpfer. Die Kunst ist, eine Produktionsgeschwindigkeit zu finden, die gemäß dem Lean-Grundatz „No Waste“ keine Depots anhäuft, in denen Dinge spezifiziert sind, die in absehbarer Zeit nicht von der Entwicklung nachgefragt werden.

Eine weitere Justierschraube ist die Granularität der architektonischen Modellierung. Die Architektur sollte keine detaillierte Programmieranweisung sein, sondern ein Gerüst, entlang dem das System „organisch“ wächst. Das Design im Einzelnen können Entwickler besser erstellen, wenn es an die Umsetzung geht, denn erst dann sind die Anforderungen bis ins Kleinste bekannt und entschieden. Weit gesteckte Leitplanken in den architektonischen Vorgaben erhalten die Flexibilität und vermeiden einen autokratischen Stil.

Ein weiterer Grundsatz von Lean, aufgeschobene Festlegung (Deferred Commitment), stellt Architekten vor eine gestalterische Herausforderung. Erweiterbarkeit und Flexibilität sind ohnehin Qualitätsmerkmale einer Architektur, bekommen aber im agilen Modus eine besondere Bedeutung. Da sich Anforderungen auch spät im Projektverlauf ändern können, ist es entscheidend, sich gestalterisch nur soweit festzulegen, wie es die aktuelle Lage erfordert. Nicht dass Agilität eigene Gestaltungmuster (Design Patterns) ausprägte, aber bekannte Muster der „Nicht-Festlegung“ wie das Abstract Factory Pattern können hilfreich sein, agil zu bleiben. Einfache Rezepte gibt es vermutlich nicht, wohl aber die Grundhaltung, sich nicht zu früh festlegen zu lassen und unsichere, fragwürdige Festlegungen zu isolieren, um sie gegebenenfalls austauschen zu können.

Die beiden zuletzt genannten Wesenszüge, grobe Granularität und aufgeschobene Festlegung, kann man auch unter dem Begriff „Just-in-Time-Modellierung“ zusammenfassen. Hinzu käme noch die Offenheit der Architekturmodelle gegenüber Einsichten, die erst während der Programmierung gewonnen werden. Selbstverständlich muss es prinzipiell möglich sein, Modelle auch in der Implementierungsphase noch zu ändern, und man sollte späte Einsichten auch nicht per se mit aufwendigen „Change Request“-Formalia abstrafen.

Ist agiles Projektvorgehen architekturagnostisch?

Man nimmt gewöhnlich an, dass die Auswahl des Projektvorgehens orthogonal zu dem gewählten Architekturstil ist. Unsere Überlegungen zum Thema „Deferred Commitment“ legen allerdings nahe, dass es Designmuster gibt, die Agilität ermöglichen, und sicher auch solche, die Agilität erschweren. Von besonderer Bedeutung sind natürlich die Architektureigenschaften der Modularität und losen Kopplung. Folgt man nämlich [4] oder [5], so sollte eine gute User Story die INVEST-Eigenschaften besitzen:

  • Independent: Unabhängig von anderen User Stories
  • Negotiable: Verhandelbar, soweit noch nicht in einem Sprint „committed“
  • Valuable: Wertvoll für den Nutzer oder den, der die Entwicklung beauftragt
  • Estimatable: Im Umfang abschätzbar
  • Small: In absehbarer Zeit, idealerweise in einem Sprint realisierbar
  • Testable: Mit einem wohldefinierten Kontrakt zur Überprüfung versehen

Modularisiert man nun ein System kaum oder entkoppelt die Bausteine unzureichend, so leiden alle Charakteristika von INVEST. Eine unabhängige User Story zum Beispiel wird wegen der vielen technischen Abhängigkeiten schwer zu isolieren sein, und der Verhandelbarkeit sind durch die Notwendigkeiten der Implementierungsreihenfolge ebenfalls Grenzen gesetzt. Wertvoll ist an einer User Story dann nur ein Teil – der Rest geht in die Bearbeitung von Seiteneffekten. Ein älteres, monolithisches System mit agilem Projektvorgehen warten zu wollen, ist daher nur bedingt sinnvoll.

Die Öffnung gegenüber spätem Feedback von Seiten der Entwickler ist nur ein Beispiel für offene Kommunikation, die ebenfalls zu den sozialen Grundsätzen von Agilität gehört. Traditionelle Ansätze der Unternehmensarchitektur setzen bei der Datenbeschaffung und Bewertung von Ist- und Soll-Architektur eher auf Gremien und gesteuerte Expertenbefragung [2]. Demgegenüber empfiehlt Agilität, auch unberufene Informationen und Meinungen einzubeziehen, etwa aus dem Kreis der Nutzer, Betreiber oder Entwickler von Geschäftsprozessen und anderer Architekturbausteine. Bei entsprechender Diversität der Befragten hat man gute Aussichten, von der „Wisdom of Crowds“ zu profitieren [7], [8]. Bewerten etwa alle Anwender oder IT-Praktiker einen Geschäftsprozess mit nur zwei Sternen auf der üblichen Skala mit bis zu fünf, so darf man berechtige Zweifel haben, dass der zuvor befragte Experte mit seiner Einschätzung, der Prozess sei effizient und von hohem Wertbeitrag, richtig liegt.

Zu guter Letzt sei auch dem agilen Grundsatz individuals and interactions over processes and tools Tribut gezollt. Architektur ist kein produzierendes Gewerbe, sondern ein aufklärendes. Es ist daher kein Primärziel, Architekturartefakte auf eine Art zu erstellen, die diesem oder jenem Standard konform ist oder mit einem bestimmten EAM-Werkzeug erstellt wurde. Wichtiger ist vielmehr, den Auftraggebern der Architektur erhellende Sichten auf das Ist- und Soll-System zu bieten. Unter dieser Zielsetzung kann ein urwüchsiges Tafeldiagramm, das jeder intuitiv versteht, einem kunstvoll mit allen Möglichkeiten von UML 2.0 spielenden Diagramm, das man allenfalls im Prinzip verstehen könnte, vorzuziehen sein. Als Ausnahme mögen Projekte gelten, die Model-driven Software Development anwenden und auf Konformität der Modelle angewiesen sind. Aber auch dort tun Architekten gut daran, ihre Auftraggeber nicht mit denselben Modellen zu „füttern“ wie die MDSD-Generierungsmaschine. Der Grundsatz empfiehlt, bei der Auswahl aus präzisen Modellen, Sichten und bildlichen Darstellungen die Kommunikation und Verständlichkeit in den Vordergrund zu stellen.

Die Ausrichtung der Modelle an den Fragestellungen der Auftraggeber ist nun auch ein ausdrückliches Anliegen von TOGAF, das hier mit Agilität konform geht. Womit wir wieder bei den Architekturframeworks sind und uns im nächsten Abschnitt dem Prozessaspekt zuwenden. Dem interessierten Leser sei Kapitel 8 des lesenswerten Buches [1] zu weiteren Prinzipien und Praktiken agiler Architekturkultur empfohlen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.