Software-Architektur und Agilität

Dieser Blog Artikel ist „Work in Progress“ und könnte sich bisweilen ändern…

Auslöser

Der Impuls meine Gedanken zum Thema aufzuschreiben, entsprang einer lebhaften Diskussion auf Twitter zwischen Leonid Lezner und Boris Gloger: Thread . Herzlichen Dank dafür! Da meine Gedanken zu umfangreich sind auch zu lange „gegärt“ haben, jetzt als Blogeintrag und nicht als Twitterantwort.

Der Architekturbegriff

„Architektur“ ist ein Begriff, der für die Softwareerstellung eine Metapher ist. Im Ursprünglichen Sinn bezeichnet Architektur „Den Aufbau und die Gestaltung von Bauwerken“. Die Assoziation mit dem Bauwerk ist nach wie vor tief verankert, und so sickern weitere Metaphern aus dem „Bauwerk“-Kontext in unsere Vorstellung von „Softwarearchitektur“ ein, die heute vielleicht eher schädlich als nützlich sind: Fundamente die gelegt werden und auf denen alles aufbaut, die Vorstellung von einer langfristigen Stabilität und Nutzung. Das „Big Picture“, der große Gesamtplan der Überblick und Sinnhaftigkeit deutlich macht.

Allerdings ist die Softwarelandschaft heute schnelllebiger geworden. Statt langlebiger Denkmäler ist schnelle, dynamische Reaktion auf wechselnde Prioritäten und veränderliche Märkte und Kunden gefragt. Das Bild des großen Bauwerkes beschränkt dabei unnötig unsere denkbaren Assoziationen. Der Mensch tendiert dazu, innerhalb einer Metapher weiterzudenken. Ich persönlich halte das Architekturbild daher nicht mehr für hilfreich, sondern für hinderlich.

Die Architektur in großen Organisationen

In Konzernen wird geredet von „Pflege der Softwarelandschaft“ oder „Bebauungsplänen“. Es wird viel Zeit und Geld investiert, um die gewachsenen Strukturen zu erfassen, verstehen, konsolidieren und einem zentral gesteuerten Strategie zu unterwerfen. Ich habe allerdings noch nie erlebt, das es funktioniert und belegbar die herbeipostulierten „Business-Cases“ dieser Zentralisierung auch realisiert werden.

Was ich aber erlebe, ist das aus „Zustand A“ ein neuer „Zustand B“ geplant wird, budgetiert wird und in die Umsetzung geht. Drei Jahre später, ist die Umsetzung so auf halbem weg, 20% der alten Landschaft ist weg, der Rest läuft noch weil er ja noch nicht vollständig umgesetzt wird. Das Budget ist zu Ende, die Umsetzung wird langsamer weil 70% der Leute nicht mehr weitermachen dürfen, als man feststellt das die neueste Gartner-Studie den „Zustand B“ als Legacy-Lösung einstuft und man anfängt, den „Zustand C“ mit der aktuell angesagten Technologie zu planen. Also Zeit für einen neuen Bebauungsplan, neues Budget und neue Initiativen, die das aktuelle „Big Picture“ in die Umsetzung bringen sollen. Die Geschichte wiederholt sich…

Ganze Abteilungen werden dem Thema gewidmet. Aus meiner Wahrnehmung ist der Einfluss auf das Tagesgeschäft der Entwickler minimal und wird selten als hilfreiche Unterstützung wahrgenommen, sonder eher als sinnentleerte Belastung.

Wozu eigentlich Architektur?

Die Aufgabe einer „Softwarearchitektur“ ist es, bestimmte Eigenschaften in der Software sicherzustellen. Das ist, allgemein gesprochen, ein Ausschnitt aus den nichtfunktionalen Anforderungen (NFR), wie z.B. Wartbarkeit, Betreibbarkeit, Interoperabilität, Veränderbarkeit und Modularität, Wiederverwendbarkeit, etc.pp. Für viele dieser NFRs bietet sich der Begriff der Architektur gar nicht mal direkt an, da die Anforderungen eher Richtung eines kleinen, temporären, und vielseitig Verwendbaren „Etwas“ gehen, Eigenschaften die man mit einem Bauwerk nicht unbedingt verbindet.

Was könnte man anders machen?

Vielleicht ist eine andere Metapher hilfreicher als das Architekturbild. Ein Garten, in dem man Bäume und Büsche pflanzt? Oder ein Baukasten, in dem man die Steine immer wieder neu zusammensetzen kann? Oder ein Orchester, in dem viele Musiker und Komponisten gemeinsam großartige Musik machen? Oder ein Vogelschwarm, der Schwarmverhalten und Individualverhalten unter einen Hut bringt? Ich habe da noch nicht DIE EINE kraftvolle Metapher gefunden, die für viele Menschen gleichermaßen funktionieren würde, aber andere Begrifflichkeiten auszuprobieren könnte helfen, an das Thema heranzugehen.

Man sollte sich von der Vorstellung verabschieden, ein „Big Picture“ wäre hilfreich. Es braucht immer wieder Anpassungen und Korrekturen, bevor auch nur Teile des Big Picture umgesetzt sind, warum sollte man also so viel Energie in die Erschaffung dieses Bildes investieren? Was man braucht, sind die Rahmenbedingungen innerhalb derer Entscheidungen getroffen werden können, und die Ziele, an denen die Entscheidungen ausgerichtet und bewertet werden können.

Teams und Architektur — Architektur und Teams

Häufig wird Architektur als eine sehr technische Angelegenheit verstanden. Systeme und Technologie stehen im Fordergrund. Dabei ist dieser Aspekt gar nicht mehr der spannendste, da es für viele Aufgabenstellungen gute und bewährte Musterlösungen gibt. Mit Microservice-Konzepten rückt ein anderer Aspekt mehr ins Blickfeld: Die Aufteilung der Teams entlang von fachlichen Abgrenzungen. Da eine Stabilität der Teams eine nicht unerhebliche Rolle bei der „Performance“ von Teams spielt, ist es sinnvoll bei größeren Vorhaben die mehrere oder viele Teams umfassen die fachliche Aufteilung in den Vordergrund zu stellen gegenüber technischen Faktoren. Domain Driven Design kann helfen, das große Vorhaben in „self contained“-Einzelteile zu zerlegen, und entlang dieser Einzelteile können sich die Teams formieren.

Und die Architekten?

Das ist im Moment ein Problem, da Software-Architekt ein „natürlicher“ Karriereschritt für einen Software-Ingenieur zu sein scheint. Raus aus dem Tagesgeschäft von Coding und dem Leidensdruck schlechter Projektentscheidungen, endlich selber am großen Rad drehen und dafür sorgen das es endlich einmal richtig gemacht wird. Leider erfüllt sich dieser Wunsch selten. Die Projekte machen doch was sie wollen, da die Architekten nur lose zugeordnet sind. Die Entwickler empfinden die Architektur als untauglich, als veraltet oder als zu umständlich. Die Architekten ziehen sich in ihren Elfenbeinturm zurück und reden erst gar nicht mehr mit den Entwicklern, sondern produzieren Schaubilder ohne Relevanz. In verschiedenen Konzernen habe ich solche Entwicklungen beobachtet oder das Ergebnis beobachten können.

Was wir statt Menschen in der Rolle „Architekt“ brauchen, sind Menschen in den Teams (also vorwiegend Entwickler) die das Wissen und die Erfahrung und den Gestaltungswillen mitbringen, die Lösungen ihrer Teams mit einem Blick über die Grenzen des Teams hinaus zu Gestalten, für Interoperabilität, der Ausrichtung an strategischen Zielen, und anderen nichtfunktionalen Anforderungen.

Und wenn sich die Rolle des Architekten in der Organisation noch wiederfindet, muss sich das Selbstverständnis deutlich verändern: Vom „Senior Oberchecker“ der den ganzen Junior-Devs die Regeln vorgibt, hin zu einem Mentor der die Entwickler dabei begleitet selber sinnvolle Entscheidungen zu treffen.

Fazit

Aus meiner Sicht ist die Vorstellung einer Softwarearchitektur überholt und in weiten Teilen nicht mehr hilfreich, da er unser Denken ein eine nicht hilfreiche Richtung lenkt. Es ist an der Zeit, eine neue Metapher zu suchen, unter der wir eine Reihe von NFRs zusammenfassen und beschreiben wollen. Insbesonders agile Methoden in der Softwareentwicklung könnten von einer neuen Metapher profitieren.

Der große Bauplan hat sich erübrigt, da auch moderne Lösungsarchitekturen andere und viel dynamischere Möglichkeiten bietet, als es vor 35 oder 40 Jahren der Fall war, als der Begriff der „großen Planung“ in das Software-Engineering Einzug gehalten hat.

Heute ist die Aufteilung eines großen Systems auf handlungsfähige Teams wesentlich bedeutsamer geworden gegenüber der lange vorherrschenden technologischen Betrachtung von System-Design.