Suche
Hängt gute Architektur von den Organisationssrukturen eines Unternehmens ab?

Praxis-Check Software-Architektur: Was macht gute Architektur aus?

Hartmut Schlosser

© Shutterstock / Thomas Reichhart

 

Conways Gesetz beschreibt die Beobachtung, dass die Organisationsstrukturen eines Unternehmens das Design bzw. die Architektur einer Software beeinflussen. Stimmt dann auch der Umkehrschluss? Kommt eine gute Software-Architektur dann zustande, wenn die Unternehmensorganisation bzw. – kommunikation darauf abgestimmt ist?

Wir haben mit sieben Software-Architekten über die Auswirkungen von Conways Gesetz und aktuelle Architektur-Trends in der Software-Entwicklung gesprochen.

Im ersten Teil dieser Reihe ging es um die Erscheinungsformen von Conway’s Law und darum, wie man festgefahrene Unternehmensstrukturen, die sich negativ auf Software-Architekturen auswirken, aufbrechen kann. In Teil II wollen wir uns den Zusammenhang zwischen guter Software und Unternehmensstrukturen genauer anschauen und die Frage beantworten, wie viel Flexibilität einer Architektur gut tut.

Gute Software-Architektur und Unternehmensstrukturen

Die Experten

Dr. Carola Lilienthal ist CEO bei der WPS – Workplace Solutions GmbH. Seit 2003 analysiert sie die Zukunftsfähigkeit von Softwarearchitekturen und wendet in ihren eigenen Projekten DDD an.

Ralf D. Müller arbeitet als Architekt und Entwickler und erlebt täglich die Notwendigkeit effektiver Dokumentation. Er ist erklärter AsciiDoc-Fan und Committer bei arc42 sowie Gründer des docToolchain Projektes.

Stefan Tilkov ist Geschäftsführer und Principal Consultant bei der innoQ Deutschland GmbH, wo er sich vorwiegend mit der strategischen Beratung von Kunden im Umfeld von Softwarearchitekturen beschäftigt.

Dr. Gernot Starke (innoQ Fellow), ist Gründer und Maintainer der Open-Source-Architekturprojekte arc42 und aim42, (Mit-)Gründer und aktives Mitglied des iSAQB sowie Autor mehrerer Fachbücher.

Lars Röwekamp, Gründer des IT-Unternehmens OPEN KNOWLEDGE GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends.

Eberhard Wolff ist Fellow bei innoQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie.

Matthias Bohlen ist Softwarearchitekt und Mitglied des iSAQB. Mit seinen Coaching-Programmen hilft er Führungskräften und Teams dabei, profitable Produkte zur Tür hinaus zu bekommen, ohne dabei den Verstand zu verlieren.

Ist Conway’s Law umkehrbar? Hängt gute Architektur also von den Organisationsstrukturen eines Unternehmens ab?

Carola Lilienthal: Nein, eine gute Softwarearchitektur braucht Softwareentwickler und Softwarearchitekten, die wissen, wie eine gute Softwarearchitektur aufgebaut werden soll, was für Qualitätsanforderungen an eine gute Softwarearchitektur gestellt werden müssen und an welchen Stellen Flexibilität in der Softwarearchitektur vorgesehen werden müssen, damit die Softwarearchitektur langlebig ist. Diese Punkte haben nichts mit der Organisation oder den Kommunikationsstrukturen zu tun.

Die Architektur muss zu den Skills und der Organisation des implementierenden Teams passen.

Ralf D. Müller: Conway’s Law funktioniert auf jeden Fall in beide Richtungen und sollte auch entsprechend in einer Software-Architektur berücksichtigt werden. Die Architektur muss auch zu den Skills und der Organisation des implementierenden Teams passen. Im Idealfall lässt sich das Umsetzungsteam entsprechend auf den Architekturentwurf zugeschnitten organisieren.

Stefan Tilkov: Ich würde es anders formulieren: Organisation, Architektur und auch Prozesse müssen aufeinander abgestimmt sein, sonst ist jede einzelne Facette – wie toll sie auch immer gestaltet sein mag – zum Scheitern verurteilt. Im Idealfall werden sie gemeinsam entwickelt. Ist das nicht möglich, z.B. weil eine Organisation schon da ist und nicht einfach geändert werden kann, müssen sich Zielarchitektur und -Prozesse daran orientieren, sonst werden sie nie Realität. Das Gleiche gilt auch andersherum.

Gernot Starke: Ein Unternehmen auf Softwarearchitektur abzustimmen benötigt extrem hohe Motivation seitens der Unternehmensführung, und diese Software muss grundlegende Bedeutung für das Unternehmen haben.

Bei eCommerce-Unternehmen habe ich solche Motivation kennengelernt – ja, und davon haben einige auch hervorragende Systeme zustande gebracht. Als Softwarearchitekten bzw. Entwicklungsteams fallen viele Entscheidungen dann leichter, weil das Unternehmen viel mehr unterstützt.

Die eher klassischen Unternehmen aus Finance, TelCo, Handel und Maschinenbau sind aber anders organisiert, und meiner Beobachtung nach auch ziemlich träge damit, ihre IT- beziehungsweise Entwicklungsorganisation zu flexibilisieren, also mehr in Richtung cross-funktionale Teams aufzustellen.

Lars Röwekamp: Ich würde es eher so formulieren: Eine schlanke Unternehmensorganisation bzw. -kommunikation erhöht die Chancen, dass am Ende ein System herauskommt, bei dem die konkrete Fachlichkeit – also die jeweils umzusetzende Domäne (DDD lässt grüßen) – im Fokus steht und nicht eine unternehmensweite Architektur bzw. ein Rahmenwerk, in welches die Fachlichkeit irgendwie hineingepresst werden muss.

Wir haben in unseren Projekten häufig feststellen dürfen, dass fachlich organisierte Teams, im Vergleich zu rein technisch organisierten Teams, qualitativ bessere Software in kürzerer Zeit produzieren. Dies liegt nicht selten daran, dass ein Großteil der für die Implementierung der Software notwendigen Kommunikation direkt innerhalb des Teams stattfinden kann.

Eberhard Wolff: Conway’s Paper diskutiert, dass Projekte zu großen Teams neigen. Das ist gut für das Prestige, und bei einem Fehlschlag kann man argumentieren, dass selbst ein sehr großes Team die Aufgabe nicht lösen konnte. Dann kommt das Gesetz von Parkinson: Eine Aufgabe hält alle verfügbaren Mitarbeiter beschäftigt. Das Gesetz erklärt die Beobachtung, dass eine Verwaltung beliebig mehr Mitarbeiter einstellen kann – die Aufgaben dauern gleich lange.

Gute Architektur ist nur mit guter Kommunikation möglich.

Ein großes Projekt hat aber entsprechende Kommunikationsschwierigkeit und dann auch Herausforderungen in der Architektur. Also hat Conway schon in seinem Paper erläutert, dass gute Architektur nur mit guter Kommunikation möglich ist.

Matthias Bohlen: Definitiv. Wenn eine bestimmte Zielarchitektur gewünscht ist, doch die Teamstrukturen gar nicht dazu passen, wird unter der Haube eine andere Architektur entstehen, die eben zu den Teams passt. Es wird nicht die gewünschte Zielarchitektur sein!

Wenn Teams sich z.B. einigen, dass es eine scharfe Schnittstelle zwischen zwei Subsystemen geben soll, die nicht verwässert, dann ist es zu empfehlen, die beiden Subsysteme in getrennte Teams zu legen. Umgekehrt: Wenn man im Projekt erkennt, dass zwei Subsysteme so stark gekoppelt sind, dass ständig intensive Kommunikation über beide erforderlich ist, dann ist es einfach sinnvoll, wenn beide Subsysteme im selben Team erstellt werden.

Also: Zuerst das Business mit seinen Bounded Contexts sauber erkennen, dann die Zielarchitektur daran ausrichten, danach die Teamorganisation der Zielarchitektur folgen lassen. Teams folgen der Architektur, die Architektur folgt den Bounded Contexts aus dem Business, nicht andersherum.
X

Flexibilität in der Software-Architektur – wie viel ist gesund?

Jeff Sussna hat einmal in einer Keynote darauf hingewiesen, dass Conway aus seiner Ursprungsthese etwas seiner Meinung nach viel Wichtigeres folgert: Dass es für jedes gegebene Design nämlich immer ein noch besseres geben könnte. Wichtiger als gutes System-Design wird damit die Fähigkeit zum Redesign. Würdest du dem zustimmen? Und wenn ja, wie kann man dem in der Software-Architektur Rechnung tragen?

Carola Lilienthal: Ich bin mit Jeff Sussna einer Meinung, dass eine Architektur immer so designt werden muss, dass sie änderbar bleibt. Allerdings ist es schwierig, alle möglichen Änderungen vorauszuahnen. Welche Oberflächen-Devices die Zukunft für uns bereithält, ist schwierig im Voraus zu wissen. Grundsätzlich bin ich überzeugt davon, dass die erste Lösung, die man entwickelt, nie die beste ist, weil es nur der erste Versuch ist. Softwareentwicklung ist ein Lernprozess, bei dem das Entwicklungsteam immer neue Erkenntnisse in die Software überführen muss. In Acht nehmen muss sich ein Entwicklungsteam allerdings vor der Versuchung, allein ob der Schönheit des Designs immer weitere Überarbeitungen vorzunehmen. Das wird dann der typische Tot in Schönheit. Redesigns sollten nur aufgrund von falsch verstandener Fachlichkeit und schlecht umgesetzter Qualitätsanforderungen an die Architektur vorgenommen werden.

Ralf D. Müller: Diese Aussage hat meines Erachtens auch losgelöst von Conway’s Law Gültigkeit: Die Fähigkeit zum Redesign und somit Anpassung an sich verändernde Bedingungen ist heute essentiell und auch durch agile Vorgehensweisen eingefordert.

Stefan Tilkov: Das ist aus meiner Sicht die ganz zentrale Erkenntnis in der Diskussion über die „richtige“ Architektur: Es gibt sie nicht. Man kann nur darauf hinarbeiten, einen Architekturrahmen zu definieren, der Evolution und Weiterentwicklung unterstützt. Das ist nach meinem Verständnis die zentrale Idee hinter Microservices, Self-contained Systems und ähnlichen Ansätzen.

Lars Röwekamp: Da gebe ich Jeff Sussna zu 100% recht! Diese These deckt sich im Übrigen auch in etwa mit dem, was ich in meiner vorherigen Antwort (siehe Teil 1 der Serie) zum Ausdruck bringen wollte. Leider wird in der Praxis die „Fähigkeit zum Redesign“ immer wieder gerne mit „generischen“ und somit scheinbar hoch flexiblen Systemen verwechselt, in denen am Ende mehr deklariert als programmiert wird.

Aber zurück zu der Aussage von Jeff Sussna: Nehmen wir einmal als Beispiel die wunderschöne Welt der Microservices. Ein gut durchdachtes Design sieht von Anfang an vor, dass die Schnittstellen der Services – egal ob synchrones REST API oder Messaging – sich im Laufe der Zeit verändern dürfen und dass einzelne Services oder ganze Service-Gruppen durch andere ersetzt werden können. Gut und richtig gemacht, ergibt sich am Ende eine Gesamtarchitektur als Choreographie des Zusammenspiels der einzelnen Services und nicht als Orchestration durch eine zentralen Instanz. Die Fähigkeit zum Redesign ist somit per Definition Bestandteil der Architektur.

Matthias Bohlen: Hmmm… darüber müsste ich länger nachdenken. Meine Intuition sagt zum ersten Punkt „Nein“: Es ist nicht wichtig, dass es zu jedem Design immer ein noch besseres geben könnte. Wir brauchen nicht nach dem „allerbesten“ Design zu streben, es reicht, ein „gutes“ Design zu haben, das das Problem korrekt, performant, sicher, user-attraktiv und auf wartbare Weise löst. Wenn ich das habe, reicht mir das.

Die Fähigkeit zum Redesign halte ich allerdings auch für sehr wichtig, denn das Business mancher unserer Kunden ändert sich möglicherweise sehr schnell. Beispiel: Die Fintechs greifen gerade die traditionellen Modelle der Finanzdienstleister an, und die EU möchte das sogar fördern. Die PSD2-Direktive nimmt den Banken das Monopol über die Kontoinformationen und Zahlungsdienste weg! Das ist eine starke Kraft, da muss man halt auch traditionelle Software einmal etwas heftiger anfassen als bisher!

Architekten müssen die Architektur ständig kritisch hinterfragen und weiterentwickeln.

Eberhard Wolf: Problematische Architekturen entstehen, weil der richtige Zeitpunkt zur Änderung verpasst worden ist. Nicht nur die Anforderungen ändern sich. Es gibt auch neue Technologien und Techniken, die neue Verbesserungen ermöglichen. So ist es unausweichlich, dass eine Architektur sich immer weiter vom Optimum entfernt.

Also müssen Architekten die Architektur ständig kritisch hinterfragen und weiterentwickeln. Vorsorglich Flexibilität in Architekturen einzubauen führt hingegen zu erhöhten Aufwänden, und am Ende ist die Flexibilität leider meistens an den falschen Stellen.

Im dritten Teil dieser Reihe gehen die Experten auf aktuelle Architektur-Trends ein, die momentan besondere Beachtung verdient haben. Bleiben Sie dran!

Lesen Sie auch:

Praxis-Check Software-Architektur: Conway’s Law auf der Spur

 

 

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

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