JAX Blog

Die Evolution der Softwarearchitektur

Sep 11, 2017

Source: Shutterstock

In diesem Interview spricht Dr. Gernot Starke darüber, dass die Unternehmensführung extrem motiviert sein müsse, um ein Unternehmen auf Softwarearchitektur abzustimmen, weshalb die Software selbst eine grundlegende Bedeutung für das Unternehmen haben muss.
Erörterung zu Conway’s Law

Melvin E. Conway hat 1968 die Beobachtung angestellt, dass das Design von Systemen Kopien der Kommunikationsstrukturen der Unternehmen darstellen, die diese Systeme entwickeln. Was bedeutet das konkret für  Software-Architekten?
Hängen Software-Architekten in ihrer Arbeit davon ab, wie ein Unternehmen mit den Kunden kommuniziert, wie sich die Abteilungen des Unternehmens untereinander austauschen, wie die IT intern aufgebaut ist, wie die Mitglieder der einzelnen Team miteinander reden und zusammenarbeiten?

 

W-JAX:   Ein Beispiel aus deiner Praxis: Wo wurde dir Conway’s Law ganz deutlich vor Augen geführt?

Dr. Gernot Starke: Darf ich voranstellen, dass ich „Conway’s Law“ für eine totale Fehlbenennung halte: Es sollte „Conway’s Observation“ heißen – weil es weder ein Gesetz noch eine eiserne Regel ist, sondern eine (empirische) Beobachtung.

Als Softwarearchitekten arbeiten wir häufig in einem Unternehmenskontext, bei dem wir auf organisatorische Randbedingungen meistens Rücksicht nehmen müssen, und selten einmal „organizational change“ anstoßen können, um diese Randbedingungen für unsere Entwicklung zu lockern. Meistens hingegen liegen organisatorische Änderungen außerhalb der uns zugestandenen Kompetenzen – und wir müssen mit der bestehenden Organisation leben.

Zu der eigentlichen Frage, wo mir Conway bereits begegnet ist: Ich müsste eher überlegen, bei welchen meiner Kunden bzw. Projekte die interne Organisation keine Auswirkungen auf die Softwarestruktur hatte. Conway hat bei mir beispielsweise im Maschinenbau zugeschlagen:

Diverse Komponenten von Großmaschinen wurden von verschiedenen Ingenieurteams entwickelt, mit jeweils ziemlich speziellen Anforderungen. Die Software für die Rüstung dieser Maschinen war in komplett anderer Technologie entwickelt, genauso wie die Software zur Überwachung/Monitoring zur Laufzeit. Das hat Synergien gründlich verhindert 

Ein zweites Beispiel stammt von Versicherungen: Dort habe ich Datenbankteams angetroffen, die losgelöst von den sogenannten Client/Server-Teams gearbeitet haben. Dann brauchte es noch eine dritte Gruppe, die Integrations-Leute, die C/S und DB zu den berüchtigten Deployment-Monolithen zusammengebracht haben.

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.

 

W-JAX:   Welches Mittel hat sich in deiner Praxis bewährt, um den Effekten von Conway’s Law zu begegnen?

Dr. Gernot Starke: Ja, Separation-of-Concern: für organisatorische Änderungen Leute dazuholen, die das professionell und Full-time machen. Als Softwarearchitekten neben der Entwicklungsarbeit noch schnell eine Abteilung oder gar Unternehmen umorganisieren, wäre aus meiner Sicht ein etwas vermessener Anspruch…

Einer meiner Kunden hat das beherzigt und einen Profi für „Change Management“ angeheuert – eine erfahrene, empathische und trotzdem durchsetzungsstarke Dame. Sie hatte sowohl strategisches wie politisches Verständnis, hat die Software-Teams „mitgenommen“, aber auch das Management. Diese Zusammenarbeit war für mich eine positive Erfahrung, weil sich durch ihre Arbeit in diesem Unternehmen wirklich Dinge positiv verändert haben – was viele Software-Teams in den Jahren vorher nicht annähernd geschafft hatten.
 

Der Software Architecture Track auf der W-JAX 2018

 

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

Dr. 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.

 

Ich müsste eher überlegen, bei welchen meiner Projekte die interne Organisation keine Auswirkungen auf die Softwarestruktur hatte.

 

W-JAX:   Welcher Aspekt in der aktuellen Diskussion um Softwarearchitektur ist für dich besonders anregend für deine Arbeit?

Dr. Gernot Starke: Bei vielen Entwicklungsteams, auch in großen Unternehmen, ist mittlerweile angekommen, dass der Wandel unserer Branche immer schneller wird. Das führt dazu, dass verkrustete Strukturen und überkommene Entscheidungen vermehrt in Frage gestellt werden, dass Organisationen und Entwickler die Notwendigkeit für Änderungen, Innovation und Evolution mehr einsehen.
 

Free: Mehr als 40 Seiten Java-Wissen


Lesen Sie 12 Artikel zu Java Enterprise, Software-Architektur und Docker und lernen Sie von W-JAX-Speakern wie Uwe Friedrichsen, Manfred Steyer und Roland Huß.

Dossier herunterladen!

 

W-JAX: Dr. Gernot, du erzählst auf der kommenden W-JAX die „VENOM“-Story. Klingt irgendwie giftig. Worum wird es gehen?

Dr. Gernot StarkeIm Open-Source-Projekt (aim42) engagiere ich mich für mehr Systematik bei der Verbesserung und Evolution bestehender Systeme. VENOM illustriert anhand eines (riesigen) Beispiels, was dabei geschehen könnte, und zeigt praktische Maßnahmen auf, um große Systeme wieder „auf die Spur“ zu bringen. Dabei prallen Meinungen aufeinander, es gibt Streit, Opfer und überraschende Wendungen. Wie der Showdown ausgeht, verrate ich erst im Vortrag.

 

 

Alle News der Java-Welt:

Behind the Tracks

Agile, People & Culture
Teamwork & Methoden

Clouds & Kubernetes
Alles rund um Cloud

Core Java & Languages
Ausblicke & Best Practices

Data & Machine Learning
Speicherung, Processing & mehr

DevOps & CI/CD
Deployment, Docker & mehr

Microservices
Strukturen & Frameworks

Performance & Security
Sichere Webanwendungen

Serverside Java
Spring, JDK & mehr

Software-Architektur
Best Practices

Web & JavaScript
JS & Webtechnologien

Digital Transformation & Innovation
Technologien & Vorgehensweisen

Domain-driven Design
Grundlagen und Ausblick

Spring Ecosystem
Wissen in Spring-Technologien

Web-APIs
API-Technologie, Design und Management