Hartmut Schlosser: Softwarearchitekten sind in ihrer Arbeit davon abhängig, wie ein Unternehmen mit den Kunden kommuniziert, wie sich die Abteilungen des Unternehmens untereinander austauschen, wie die IT intern aufgebaut ist und wie die Mitglieder der einzelnen Teams miteinander reden und zusammenarbeiten. Vielleicht kannst du ein Beispiel aus deiner Praxis nennen, bei dem dir Conways Law ganz deutlich vor Augen geführt wurde.
Ralph D. Müller: Die Auswirkungen von Conway‘s Law sehe ich persönlich bei Web-Projekten vor allem direkt in den Projektteams, weniger in der Organisation, in die das Projektteam eingebettet ist. So macht es beispielsweise einen großen Unterschied, ob man in einem Web-Projekt reine „Full-Stack”-Developer einplant oder die Umsetzung auf Backend- und Front-End Entwickler verteilt. Die entstehenden Softwarestrukturen unterscheiden sich nicht im Schnitt, sondern in der Komplexität. Dies macht sich aus meiner Sicht gerade bei modernen Front-End-Frameworks wie Angular oder React stark bemerkbar. Aber auch der Vertikale Schnitt durch die Aufteilung eines Projekts auf mehrere agile Teams hat einen entsprechend großen Einfluss auf das Ergebnis.
Hartmut Schlosser: Stimmt dann auch der Umkehrschluss? Eine gute Software-Architektur kommt dann zustande, wenn die Unternehmensorganisation bzw. – kommunikation darauf abgestimmt ist?
Die Architektur muss auch zu den Skills und der Organisation des Teams passen
Ralph D. Müller: Conway‘s Law funktioniert auf jeden Fall in beide Richtungen und sollte auch entsprechend in einer Softwarearchitektur 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 ideal auf den Architekturentwurf zugeschnitten organisieren.
Software Architecture Summit vom 11. - 13. März in München
Technische und methodische Themen, Kommunikationstrends, Cloudlösungen, MLOps, Design und Psychologie
Hartmut Schlosser: Man kann Conway‘s Law als strukturalistisches Prinzip verstehen – die agierenden Objekte sind abhängig von den sie umgebenden Strukturen, d.h. auch den Beziehungen der Objekte untereinander. Was bedeutet das für den agierenden Softwarearchitekten? Er kommt in ein Unternehmen, in dem bestimmte Strukturen vorherrschen – eine Unternehmenskultur, Abteilungsgrenzen, Teams, etablierte Prozesse und inoffizielle, als selbstverständlich angenommene Gepflogenheiten. Er ist aber auch mit Menschen konfrontiert, die diese Strukturen einerseits tragen und andererseits verändern können. Wo setzt man da als Architekt an, um negative Strukturen ein Stück weit aufzubrechen? Hat sich da in deiner Praxis ein Mittel bewährt?
Ralph D. Müller: Wie bei so vielen Problemen in der Softwareentwicklung gibt es hier wohl nicht die “Silver Bullet”, sodass man Probleme dieser Art je nach Situation angehen muss.
Hartmut Schlosser: 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 Softwarearchitektur Rechnung tragen?
Ralph 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.
Hartmut Schlosser: Welcher andere Aspekt (außer Conway’s Law) ist in der aktuellen Diskussion um Softwarearchitektur für dich besonders anregend für deine Arbeit?
Ralph D. Müller: Der für mich wichtigste Aspekt ist – wie oben schon angedeutet – die richtige Verteilung der Module eines zu implementierenden Systems auf Teams und Personen. Das kann auch bedeuten, dass man aus einem Projekt unter Umständen zwei machen muss um den richtigen Schnitt des Systems zu erreichen.
Hartmut Schlosser: Auf dem Software Architecture Summit hältst du einen Talk zum Thema “Hitchhikers Guide to Architecture Documentation.” Ich nehme an, das Wichtigste dabei ist ein Handtuch. Was ist aber das Zweitwichtigste? Worauf sollte man beim Dokumentieren von Softwarearchitektur achten?
Ralph D. Müller: Das Zweitwichtigste ist natürlich, dass man nicht in Panik verfällt 😉
Spaß beiseite – die Art und Weise, wie eine Softwarearchitektur dokumentiert wird, muss zur Vorgehensweise des Projekts und den dokumentierenden Personen passen.
Gernot Starke und ich stellen einen Ansatz vor, wie die Erstellung der Dokumentation mit den Tools eines Entwicklers effizient erfolgen kann. Die in agilen Projekten dringend notwendige Dynamik der Dokumentation spielt dabei eine genauso große Rolle, wie das kollaborative Erstellen der Doku im Team.
LUST AUF MEHR SOFTWARE ARCHITEKTUR?
Zahlreiche aktuelle Themen wie KI, LLMS und Machine Learning, sowie Frontend-Architektur, für Tools zur Softwarearchitektur, Cloudlösungen und Software beweisen.
Geschrieben von: 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.
