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.

Coach Reflection Day

Dieser Beitrag ist „Work in Progress“ und wird sich gelegentlich ändern!

Was ist ein CoRe-Day?

Warum CoRe Day?

Menschen die mit Menschen arbeiten brauchen einen sicheren Raum zur Reflektion und zum Austausch. In vielen „sozialpflegerischen Umfeldern“ wie Pflegeberufe oder Sozialarbeit ist seit Jahrzehnten eine entsprechen berufsbegleitende Arbeit unter dem Begriff „Supervision“ etabliert, die unter ausgebildeter Begleitung einen solchen Rahmen bietet.

In der eher technischen Umfeldern (wie kommerzielle Produkt oder Softwareentwicklung) ist solcher Austausch bislang unüblich. Mit der Veränderung hin zu agilen Arbeitsweisen haben sich auch neue Rollen etabliert, die Menschen in Veränderungen begleiten und Veränderungen in Organisationen gestalten, aber in der Regel keinen geschützten Raum haben um ihre eigenen Themen dabei zu bearbeiten und zu reflektieren. Nachdem dieser Mangel erkannt wurde, haben sich Menschen aus der agilen Community Gedanken gemacht und das Format „Coach Reflection Day“ entwickelt, um diesen Rahmen anzubieten.

Zeitaufwand und Kosten sollten dabei so gestaltet werden, das es den Teilnehmern auch ohne Unterstützung des Arbeitgebers ermöglicht wird, einen solchen Termin wahrzunehmen. Die Kosten liegen daher deutlich unter den üblichen Kosten für einen ganztägigen Workshop in IT-Umfeldern.

Wie läuft ein CoRe Day ab?

Das Intro

Eine kurze Einstimmung ins Thema, oft begleitet von einem kurzen Impulsvortrag mit Coachingbezug

Kollegiale Fallberatung

Ein stark strukturiertes Format zur Gewinnung von neuen Perspektiven zu einem gegebenen Fall. Das Format gewinnt neue Hypothesen und Lösungsoptionen aus der Aussensicht unbeteiligter Kollegen, die häufig sehr konkret helfen Handlungsblockaden aufzulösen.

Coaching Dojo

Das Coaching Dojo ist ein Übungsformat aus verschiedenen Coaching-Ausbildungen. Mit einem echten Fall können Menschen üben, Coaching-Gespräche zu führen.

Walk and Talk

Eine Übung um die Fähigkeiten als Zuhörer zu verbessen.

Open Space / Lean Coffee

Zum Tagesabschluss eine offene Runde, die zur Reflektion oder zur weiteren Bearbeitung von Coaching-Verwandten Themen in kleineren Gruppen genutzt werden kann.

Was kann ich von einem CoRe Day mitnehmen?

Die „Fallgeber“ bekommen in aller Regel hilfreiche und wertvolle Anstöße für den weiteren Umgang mit ihrem „Fall“ aus dem beruflichen Umfeld.

Die Coaches können ihre Fähigkeiten trainieren Coaching-Gespräche zu führen, bekommen dazu wertvolle Rückmeldungen mit denen sie lernen können. Sie können sich trauen, neue Dinge auszuprobieren oder erstmalig gezielt in die Rolle als Coach zu schlüpfen und erfahren wie sie sich darin fühlen.

Die Beobachter lernen auch aus der Beobachtung, und helfen dem Coach sich weiter zu entwickeln. Viele Teilnehmer äußern sich im Anschluss so, das sie aus der Rolle als Beobachter am meisten für ihre eigene Arbeit als Coach mitnehmen.

Links und Verweise

Coach Reflection Day

3. CoRe Day Ruhr am 18. Oktober 2019