Kommunikationsstruktur sticht Architektur

Wer definiert die Architektur?
 M.C.Escher: "Relativiteit", Juli 1953

Quizfrage: Wer hat den größten Einfluss auf die Architektur einer Software?

• Die Enterprisearchitekten, die organisationsweite und softwaresystemübergreifende Entscheidungen treffen (wie z.B. die Einführung von SOA im gesamten Unternehmen)?
• Die Solutionsarchitekten, die die Architekturentscheidungen für applikationsübergreifende Softwaresysteme treffen (wie z.B. die Verwendung von Domain-Driven Design)?
• Die Applikationsarchitekten, die die Architektur der einzelnen Applikationen definieren (wie z.B. die Verwendung von Hibernate für den Zugriff auf die DB)?
• Die Entwickler, die die Architektur schlussendlich umsetzen - potentiell anders, als durch alle vorangegangenen Architekten definiert?

Falsch geraten. Gemäß des Gesetzes von Conway hat die Kommunikationsstruktur der die Software umsetzenden Organisation den größten Einfluss auf die Architektur der Software.

Wie kann das sein? Versuchen wir es anhand zweier Beispiele nachzustellen:

• Projekt A: Die meisten Projektmitarbeiter (Entwickler und Tester) sitzen in einem großen Raum. Projektleiter, Business Analytiker sind oft gesehene Gäste und bei allen Meetings anwesend. Es gibt tägliche Standup Meetings, wöchentliche Technik Meetings und 2-3-wöchige Scrum Meetings. In Summe ca. 3h pro Woche.
  Die Kommunikationsstruktur ist eine Vollstruktur - d.h. jeder redet mit jedem.
• Projekt B: Die Projektmitarbeiter sind auf 3 Räume aufgeteilt, weitere Komponenten werden anderswo im Hause entwickelt. Zwei Ansprechpartner für die weiteren Komponenten arbeiten im Team, sitzen allerdings anderswo. Es gibt tägliche Standup Meetings, wöchentliche Technik Meetings und 2-3-wöchige Scrum Meetings. In Summe ca. 3h pro Woche.
  Die Kommunikationsstruktur ist eine Rad- oder Sternstruktur - d.h. die Mitarbeiter eines Raumes reden mit den Mitarbeitern eines anderen Raumes nur selten wie z.B. bei Meetings und vor allem über die definierten Ansprechpartner

Wie wird wohl die Architektur dieser beiden Projekte aussehen? Da in Projekt A alle Mitarbeiter schrankenlos mit allen anderen kommunizieren können, kristallisieren sich keine Programmteile heraus, die nur wenigen Mitarbeitern bekannt sind. Es müssen auch keine schwergewichtigen Schnittstellen eingeführt werden, ebenso ist eine zentrale Kommunikationsdrehscheibe wie ein ESB unnötig.
In Projekt B wiederum werden sich auf Grund der Raumsituation unterschiedliche Teile entwickeln, die nur die Entwicklern in den sie umsetzenden Räumen genau kennen. Diese Teile werden durch schwergewichtige Schnittstellen voneinander getrennt werden, um z.B. unterschiedliche Entwicklungsgeschwindigkeiten der Teams abzufangen.

• Projekt A: Gemäß Gesetz von Conway wird die Architektur tendentiell monolithisch werden - potentiell viele Module, die aber alle gemeinsam entwickelt und gebaut werden. Es wird keine schwergewichtigen Schnittstellen innerhalb der Software geben - alles wird über direkte Methodenaufraufe miteinander verbunden sein.
• Projekt B: Gemäß Gesetz von Conway wird die Architektur mindestens 4 Module bekommen, potentiell werden es mehr Module, aber niemals wird ein Modul von Entwicklern in 2 verschiedenen Räumen umgesetzt. Die Kommunikation zwischen den Modulen wird über schwergewichtige Schnittstellen (Web-Services) laufen, potentiell sogar über einen Mittelsmann (ESB)

Welche der beiden Architekturen ist nun die bessere? Es gibt keine "richtige" Architektur. Eine Architektur muss den an sie jetzt und in Zukunft gestellten Anforderungen entsprechen - dann ist sie richtig. Üblicherweise kann aber davon ausgegangen werden, dass innerhalb eines Projektes/Programmes nur eine Anwendung innerhalb einer Anwendungsdomäne entwickelt wird. Eine willkürliche Einführung von harten Schnittstellen innerhalb eines Softwaresystems (und nur damit die Projektmitarbeiter nicht miteinander reden müssen) ist ein Anti-Pattern.

Beide Projekte existieren in der Realität - und beide müssen mit den Problemen der Architektur kämpfen:

• In Projekt A entschied das Management zu späteren Zeitpunkten und gegen den Willen der Architekten, dass weitere Programmteile in anderen Teams, teils offshore entwickelt werden müssen. Diese wurden (gemäß Gesetz von Conway) in getrennten Modulen entwickelt, die man krampfhaft versuchte möglichst von den restlichen Modulen abzukoppeln. Insgesamt führte diese Managemententscheidung zu großen Einbrüchen in der Produktivität, da die Architektur nicht auf eine derartige Änderung ausgerichtet war. Inzwischen wurden diese Entscheidungen wieder zurückgenommen.
  à In Projekt A war die Architektur ursprünglich den Anforderungen angepasst. Erst durch die Änderung der Kommunikationsstruktur passte die Architektur nicht mehr, was zu enormen Mehrkosten führte.
• In Projekt B werden (die Entwicklung hat gerade erst begonnen) die schwergewichtigen Schnittstellen zwischen den Modulen potentiell zu Performanceschwierigkeiten führen. Vorsorglich wurden bereits im Vorfeld der Entwicklung viele zimmerübergreifende [sic] Anforderungen zum Leidwesen des Auftraggebers gestrichen und extrem überdimensionierte, teure Hardware angeschafft.
  à In Projekt B passt die Architektur von vornherein nicht zu den Anforderungen. Eine Software innerhalb einer Anwendungsdomäne willkürlich mit harten Schnittstellen zu versehen ist eine Fehlentscheidung. Der Kunde bekommt (wie er selbst so schön sagte) "Einen 2CV zum Preis eines Porsches".

Fazit: Wie schon in Raumaufteilung und Projekterfolg festgestellt, wird jedem Projekt dringend angeraten vor Definition der Architektur die Raumaufteilung und somit Kommunikationsstruktur des Projektes festzulegen. Die Architektur spiegelt immer die Raumaufteilung wieder, eine schlechte Raumaufteilung führt unweigerlich zu einer schlechten Architektur. Lässt sich eine Software fachlich in Teile zerlegen, die nichts miteinander zu tun haben (auch keine Daten austauschen), dann - und nur dann - ist eine Aufteilung des Projektteams in unterschiedliche Räume sinnvoll.