Die Frage ist heute: Wie viel Architektur darf’s denn sein, für ein funktionsübergreifendes, agiles Team, das im Dienste der Entwicklungsteams unterwegs ist? Wieviel Architektur ist überhaupt notwendig?
Dazu noch einmal die Definition von Ralph Johnson, die ich im Anschluss ergänzen möchte:
Architektur ist die Menge von Entscheidungen, von denen Sie wünschten, Sie könnten sie früh im Projekt richtig treffen (aber bei denen die Wahrscheinlichkeit, sie richtig zu treffen, nicht notwendigerweise größer ist als bei jeder anderen Entscheidung).
Bei der Achitektur geht es um die wichtigen Dinge, die man am liebsten gern von Anfang an richtig machen würde. Was wirklich wichtig ist, hängt natürlich vom Kontext ab: Für ein Büro-Informationssystem kann die Tatsache, dass man sich für eine Oracle-Datenbank entschieden hat, Bestandteil der Architektur sein. Für ein Bildverarbeitungssystem im medizinischen Bereich kann es dagegen völlig unwichtig sein, in welcher Datenbank das System die Bilder speichert. Hier geht es eher um die Algorithmen, mit denen aus den Bildern die relevanten Informationen herausgeholt werden. Für das erste System gehört die Datenbank also zur Architektur, für das zweite System eben nicht.
Die Elemente der Architektur
Für mich besteht Softwarearchitektur aus Form, Struktur und Stil. All das wird erstellt mit dem Ziel, das gewünschte Verhalten des Systems zu ermöglichen, eben den Service, den es für seine Benutzer erbringen soll und für den die Kunden bezahlen werden.
Die Form ist dabei die Essenz der Struktur – also das, was den Stakeholdern entgegentritt (Christopher Alexander lässt grüßen). Mit Stakeholder meine ich hier nicht nur die Benutzer, sondern auch die Domänenexperten und die Entwickler. Die Form ist das „außenrum“, das von der Struktur getragen wird. Dabei ist Form nicht nur etwas Statisches. Form gibt es auch im dynamischen Bereich, im Bereich der Abläufe, des Verhaltens, der Algorithmen.
Stellen wir einmal Form und Struktur einander gegenüber, sowohl statische als auch dynamische Form und Struktur:
Was das System istWas das System tutFormSubsysteme Interfaces, APIs, DomänenobjekteUse Cases, Kontext, Methodenfreie RollenStrukturModule, Pakete, KlassenMethodenreiche Rollen, Algorithmen
Ich finde, Architektur sollte sowohl Lean als auch agil sein. Lean vermeidet Verschwendung, z.B. durch Umräumen und Aufräumen des Codes über Klassen- und Paketgrenzen hinweg. (Refactoring innerhalb eines Pakets zähle ich eher zu den notwendigen Übeln, die mit Dazulernen zu tun haben. Aufräumen und Ändern der Form im großen Stil würde ich gern durch Architekturarbeit vermeiden.)
Änderungen der Form ziehen möglicherweise Strukturänderungen in großer Zahl nach sich. Beispiel aus dem Bauwesen: Wenn man im Nachhinein eine Wand (Struktur) durchbricht, um zwei Räume zu verbinden (die Form zu ändern), muss man auch den Teppichboden und die elektrischen Leitungen (Struktur) neu verlegen. Beispiel aus der Software: Legt man zwei Subsysteme (Form) zusammen, so muss man auch Pakete, Klassen und Konfigurationen (Struktur) in möglicherweise großer Zahl ändern.
Demgegenüber steht im Bereich des Verhaltens die Forderung nach Agilität: Den Benutzern und den Kunden fällt ständig etwas Neues ein, deshalb muss es einfach sein, neues Verhalten zu schaffen oder bestehendes Verhalten zu ändern. Eine User Story oder Use Case zu ergänzen sollte kein Problem sein. Einen Algorithmus zu ändern ebenfalls nicht. Zwei Stories zusammenzuwerfen ist schon etwas Größeres, eine Änderung der Verhaltens-Form. Das ist mit einfachem Refactoring nicht getan.
Architektur steht also im Spannungsfeld zwischen Lean und Agilität: Sie soll größere Änderungen vermeidbar machen, indem sie Formentscheidungen möglichst früh richtig fällt (Lean). Sie soll andererseits späte, lokale Änderungen möglichst einfach machen, indem sie die Auswirkungen von Strukturänderungen begrenzt (agil).
In Lean gibt es den Begriff des verantwortlichen Moments. Genau darum geht es auch bei der Architektur: Strukturen zu schaffen ohne das richtige Verständnis der Form zu haben, ist Verschwendung, denn sie müssen nachher alle wieder geändert und an die richtige Form angepasst werden. Deshalb ruhig etwas länger über Form nachdenken, bis man den verantwortlichen Moment erreicht hat – dann geht mit den gewonnenen Informationen das Schaffen von Strukturen sehr einfach und schnell.
Form und Struktur arbeitsteilig finden
Die Aufteilung der Arbeit zwischen dem Architekturteam und den Entwicklungsteams wird dann ebenfalls einfach:
- Im Architekturteam denkt man gemeinsam über Form nach.
- In den Entwicklungsteams schafft man Struktur, die die Form stützt und das Verhalten ermöglicht.
Das Architekturteam kann seine Sitzungen kurz halten, weil die Leute dort nicht über jedes Paket und jede Klasse entscheiden müssen, das tun die Entwickler in ihren Teams.
Die Entwickler können Designaufwand minimieren, weil sie eh schon wissen, wie die Form ist und wo demnach die Struktur (Klassen und Algorithmen) hingehört. Es ist ein bisschen wie bei einem Haus, bei dem der Platz für den Ofen schon feststeht. Der Küchenbauer bringt den Herd, der Elektriker hat schon die Steckdose gemacht, der Küchenbauer kann den Ofen sofort anschließen.
Plädiert der Bohlen jetzt etwa für BDUF?
Manche mögen jetzt sagen: Ich weiß genau, der Bohlen ist für Agilität und für Lean. Kommt er jetzt etwa doch mit BDUF (big design up front), dem berühmten großen Entwurf im Vorhinein, dem im Nachhinein alle Entwickler zu folgen haben?
Nein, wenn schon diese vier Buchstaben, dann komme ich lediglich mit DBUF (design the big things up front)! Ich will damit sagen:
- Entwerfen Sie die wichtigen Dinge (eben die Form des Systems) ruhig vorher.
- Hören Sie aber bereits da auf, wo die Struktur beginnt.
Das ist eben genau kein big design, weil es nur wenige Elemente enthält. Es legt nicht viel im Vorhinein fest, sondern nur die paar großen Dinge, die zur Form gehören. Es ist auch nicht weiter schwierig und muss nicht lange dauern.
Das ist der Unterschied zwischen dem Entwurf großer Dinge und einem großen Entwurf. Ein großer Entwurf würde einen regelrechten Masterplan machen, mit vielen Strukturelementen, die von den Entwickler nur noch „runterprogrammiert“ werden. Das meine ich nicht. Ich meine die paar großen Dinge, die man als Form braucht, um die vielen kleinen Dinge der Struktur einzufügen. Alles andere würde die Entwickler zu reinen Erfüllungsgehilfen machen – das ist nicht gemeint.
Wie geht das denn nun genau?
OK, nun habe ich viel über Philosophisches geredet – das muss auch mal sein. Doch ich verspreche, ich komme noch zum konkreten Tun, insbesondere zu den Einträgen in der obigen Tabelle. (Vielleicht werden Sie sich schon über die methodenfreien und methodenreichen Rollen gewundert haben?) Das muss leider bis zu einem späteren Blog-Eintrag warten.
Die Vordenker
Ich will hier schon einmal verraten, dass diese Gedanken von Christopher Alexander (A Timeless Way of Building), Trygve Reenskaug (DCI-Architekturstil) und James Coplien (Lean Architecture) beeinflusst sind. Schließlich muss ich nicht jedes Rad neu erfinden, sondern kann auch eins anwendbar machen, das es bereits gibt.
