Abhängigkeiten, egal ob technischer oder organisatorischer Art, sind in der Softwareentwicklung problematisch. Größere, klassisch vorgehende Softwareentwicklungsorganisationen schaffen nach unserer Erfahrung bspw. regelmäßig nur 2-4 Releases pro Jahr, da die Organisation zu komplex und die Abhängigkeiten zu hoch sind. Durch die Harmonisierung von Aufbauorganisation und Systemarchitektur in Anlehnung an Conways Law lassen sich die Abhängigkeiten in der Softwareentwicklung um bis zu 80 % reduzieren, wie wir nachfolgend aufzeigen.

Conways Law, welches bereits seit 1967 (!) intensiv diskutiert und viel zitiert worden ist, besagt, dass Systeme die Organisationsstrukturen der Einheiten reflektieren, in denen sie entstehen:

»Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.«

Oder anders formuliert, man bekommt nicht zwangsläufig die Systeme, die am Whiteboard, Flipchart oder in UML designed wurden, sondern Systeme, die aussehen, wie das Organigram der sie umgebenden Organisation. Da Systeme und Organisationen i.d.R. anderen Änderungszyklen unterliegen und die jeweiligen Änderungen anders motiviert sind, laufen System- und Organisationsgrenzen irgendwann zwangsläufig auseinander:

Dies führt zu erheblichen Schwierigkeiten in Entwicklung und Betrieb entsprechender Software-Systeme, da sich die Verantwortung für ein System dann schnell über mehrere Organisationseinheiten hinweg erstreckt, was zu Abhängigkeiten, unklaren Verantwortlichkeiten, erhöhtem Abstimmungsbedarf, usw. führt.

Interessant ist zu sehen, was passiert, wenn man auseinander gelaufene System- und Organisationsgrenzen wieder in Einklang bringt, wie wir im folgenden Artikel an einem unserer Projekte in anonymisierter Form aufzeigen.

Hintergrund

Im konkreten Fall sollte der IT-Bereich eines Online-Unternehmens reorganisiert werden, da aufgrund des starken Wachstums der Firma, dieser den anstehenden Aufgaben nicht mehr gewachsen war. Das Unternehmen war einer klassisch-funktionalen Aufbauorganisation folgend strukturiert. Das nachfolgend vereinfacht dargestellte Organigram erschien auf den ersten Blick unauffällig:

Unsere der sog. Theorie Z folgende Analyse ergab u.a., dass die Mitarbeiter in der dortigen IT in einer eher technologischen Aufbauorganisation, welche nicht im Einklang mit der fachlichen, projektseitigen oder auch betrieblichen Realität stand, eine historisch gewachsene, komplexe und komplizierte, monolitische Architektur mit einer Vielzahl an Technologien / Systemen und hohen technischen Schulden entwickelten und betrieben.

Selbst kleine Anpassungen führten zu hohen Aufwänden und regelmäßigem Überschreiten der vereinbarten Termin- und Budgetzusagen, da alles mit allem zusammenhing und eine Änderung an einer Stelle immer auch Anpassungen an einer Vielzahl von anderen Stellen bedeutete. Das Gesamtsystem war kaum noch beherrschbar.

Eine erste, qualitative Untersuchung der Makro-Architektur, insb. im Hinblick auf die wesentlichen Architektursichten brachte die in folgender schematischer Darstellung zusammengefassten Erkenntnisse:

Wie häufig war über die Architektursichten hinweg kein einheitlicher Systemschnitt zu finden. Die fachliche Anforderungssicht war bisher nur wenig ausgeprägt und folgte bspw. nicht der User bzw. Customer Journey eines Kunden im Portal. Die einzelnen Softwaresysteme waren »historisch gewachsen«, dabei aber zunehmend ihrem initialen, technologischen Ordnungsmuster der 3-Schichten-Architektur entflohen (»Architekturerosion«). Wenig verwunderlich, da die Gliederung in Frontend, Backend, und Datenhaltung (Persistenz) von Systemen i.d.R. wenig mit der Sicht des Anwenders gemein hat. Die Infrastruktur wiederum folgte einem ganz anderen Muster und war auch organisatorisch stark vernachlässigt, wie weiter unten zu sehen ist. In Folge kaskadierte sich eine einzelne fachliche Änderung auf zahlreiche Anpassungen diverser Systeme, welche wiederum weitere Änderungen anderer Systeme nach sich zogen.

Wobei an dieser Stelle auch eine Lanze für die Software-Architekten gebrochen werden muss: die einheitliche Durchsetzung einer Architekturidee über mehrere Architektursichten hinweg ist nach wie vor eine erhebliche Herausforderung. Bis dato kann der Architekt überwiegend retrospektiv und eher Dokumenten-basiert, also über Konzept-, Spezifikations- und Code-Reviews/-Analysen feststellen, ob (s)eine Architekturidee eingehalten und entsprechend umgesetzt wurde. Architektur-DSLs (Domain-Specific Languages) stellen hier einen interessanten Ansatz dar, die Wahrheit steckt aber schlußendlich im Code. Der Architekt ist in der Rücklage gegenüber der Software-Entwicklung, insb. im agilen Umfeld; nachträgliche Umbauarbeiten an den Systemen, um selbige wieder ins architekturelle Modell zu bekommen, sind nur selten gegen den üblichen Marktdruck durchsetzbar. Das Label »historisch gewachsen« haben wir schon an vielen anderen von uns untersuchten Architekturen gefunden. Die geschickte Kombination moderner Ansätze (Microservices-Architekturstil, Domain-driven Design, …) und das Verlassen etablierter Software-Engineering-Paradigmen, wie z.B. der zentralen Datenhaltung, aber bspw. auch das bewusste Akzeptieren von Redundanz, etc. verspricht hier Besserung, wie wir auch in folgenden Artikeln noch aufzeigen werden.

Im konkreten Fall war die gesamtheitliche Betrachtung von Architektur und Organisation, Conways Law aber auch unserem Ansatz von IT-Management-Beratung folgend, der nächste Schritt:

Weder die Aufbauorganisation der Fachbereiche noch der IT ließen sich in der Architektur verorten. Darüber hinaus standen aber auch die Strukturen der Fachbereiche, also der internen Kunden der IT, in keiner Beziehung zur Organisation des IT-Bereichs. In Folge setzte sich die schon auf Architekturebene gezeigte Abhängigkeitskaskade in der Organisation fort und verstärkte sich entsprechend. Eine einzelne Änderung führte nicht nur zur notwendigen Anpassung einer Vielzahl von betroffenen, abhängigen Systemen, sondern involvierte auch eine Vielzahl von Ansprechpartnern und Teams. Die Organisation war im permanenten Eskalationsmodus.

Die quantitative Auswertung der historischen Änderungsaufträge eines Jahres bestätigte die qualitative Betrachtung: in 50% der Fälle kam es zum sog. »Übersprechen«. Jeder zweite Änderungsauftrag führte im vorliegenden System- und Teamzuschnitt also zu Abstimmungen mit anderen Teams und entsprechenden Anpassungen weiterer Systeme.

Lösungsansatz

Welches Ordnungskriterium sollte nun aber angesetzt werden, um die erodierende Architektur wieder mit der divergierenden Organisation in Einklang zu bringen? Da Softwareentwicklung zumindest in den meisten Fällen kein Selbstzweck ist, sondern dem Kunden/Anwender dienen sollte, fängt auch unser Lösungsansatz mit der Fachlichkeit, also der Anforderung, dem Use Case oder der User Story an. Da Anforderungen häufig »organisationspolitisch« gefärbt sind, also von Interessen der Einheiten, die sie gestellt haben, geleitet werden, gingen wir im konkreten Fall zunächst noch einen Schritt weiter »zurück« in der Anforderungskette zum Anwender im Portal.

Insbesondere im kundennahen Online-Umfeld mit geringer Standardisierung und Wiederverwendbarkeit bei hoher Individualsierung durch die notwendige Differenzierung sollte der Fokus auch entsprechend extern, also auf den Kunden gelegt werden. Im Umfeld von ERP-Standardsoftware-Entwicklung bspw. mag der Fokus auch entsprechend eher intern auf Kostenoptimierung (Stichwort: Kostenführerschaft) gelegt werden.

In einem ersten Schritt analysierten wir dementsprechend innerhalb der fachlichen Architektursicht die User bzw. Customer Journey und leiteten daraus unter Hinzuziehung weiterer, unternehmensinterner Aspekte ein fachliches Domänenmodell ab. Eric Evans Domain-Driven Design, auf welches wir in einem separaten Beitrag eingehen werden, war hierbei natürlich mit in unserem Handwerkskoffer.

Dem Domänenmodell ordneten wir in einem nächsten Schritt die entsprechenden Softwaresysteme zu und es entstand eine fachlich getriebene Zielarchitektur, welche den Bebauungsplan für die notwendigen Umbaumaßnahmen der Systemarchitektur darstellte:

Anschließend richteten wir die Teams ebenfalls gemäß dem Domänenmodell neu aus. Das Produktmanagement stellte je Domänenteam einen Product Owner, der im agilen Sinne die Verantwortung dafür übernahm, was umgesetzt wird. Das Entwicklungsteam der IT verantwortete die technische Umsetzung, also das »Wie« und übernahm in seiner Domäne gemäß Werner Vogels (CTO Amazon.com) Ansatz »You build it, you run it« auch die Betriebsverantwortung.

Somit waren alle drei Architektursichten organisatorisch und technisch autark in jeweils einem Domänen-Team vereint, das Produktmanagement kapselte die Fachlichkeit, IT-Organisation und Fachbereichsorganisation sowie Architektur waren wieder im Einklang:

Die resultierende Matrixorganisation war dem Umstand der zwei beteiligten Linien-Organisationseinheiten geschuldet und in der konkreten Projektsituation das organisatorisch maximal Mögliche. Produktentwicklung hat ebenso wie Softwareentwicklung unserer Einschätzung nach einen langfristigen Charakter und sollte dementsprechend idealerweise auch in einer entsprechend langfristig ausgerichteten Linien-Produktentwicklungsorganisation erfolgen; dies werden wir in einem separaten Beitrag noch näher beleuchten.

Die anschließende quantitative Analyse der historischen Änderungsaufträge gegen die neue Architektur und Organisation ergab, dass das »Übersprechen« nur noch in 5-10 % der Fälle auftrat; gegenüber der Ausgangssituation mit 50 % also eine Verbesserung um ~80 %!

Neben unserer Erfahrung aus zahlreichen weiteren IT-Management-Beratungsprojekten, insb. auch ähnlich gelagerten Vorhaben wie bspw. hier, fußte das Vorgehen und der Erfolg in diesem Projekt im Wesentlichen auf den genannten, etablierten (Conways Law; 1967) und neueren (Domain-Driven Design; 2003) Ansätzen; ganz nach dem Motto »Standing on the shoulders of giants«.