Conways Law Revisited

Wenn man in einer Woche zweimal in unterschiedlichen Kontexten mit einer Sache
konfrontiert wird, ist das ein Zeichen. Wofür auch immer. So ist es mir in der
letzten Wochen mit Conways Law ergangen. Bisher kannte ich Conways Law als
das Gesetz, das besagt, dass sich über kurz oder lang die Strukturen eines
sozialen Systems in einem technischen System wiederfinden werden. Wenn ich ein
Programm schreibe, mit dem später zwei Fachabteilungen arbeiten werden, wird
sich diese Trennung auch im technischen System – dem Programm – ausdrücken.

Die Wikipedia zitiert das Gesetz von Conway so: “Organizations which design
systems [...] are constrained to produce designs which are copies of the
communication structures of these organizations”. Die Strukturen richten sich
demnach vor allem an den Kommunikationsstrukturen aus. (Ich glaube ohne eine
Quelle zur Hand zu haben, dass es im Original vor allem um Compiler ging, die
von Komitees entwickelt wurden. Conway hatte festgestellt, dass die
Modulstruktur der fertigen Compiler den Arbeitsgruppen der Komitees
entsprach.)

Das Gesetz begegnete mir zunächst in einem Artikel von Brandon Byars. Dieser
publiziert gerade auf der Webseite von Martin Fowler einen Artikel über
Enterprise Integration using REST. Im Abschnitt Do not let systems
monopolize resources
 
diskutiert er die Frage, wie man größere Systeme schneiden soll. Soll man bspw. an einer Stelle das Wissen über ein Produkt zentralisieren? Man hätte
dann ein System, das eine Ressource monopolisierte. Und das verstoße gegen das
Gesetz von Conway, das da besage, dass die Architektur des Systems die
Struktur des sozialen Systems spiegeln solle. Im Konkreten würde das heißen,
dass es mehrere Produktbegriffe in mehreren Systeme gäbe und jedes Softwaresystem um ein soziales System, das durch einen einheitlichen semantisches Kontext (Bounded Context) gekennzeichnet ist, zu errichten wäre. Doch das ist eine andere Geschichte.

Für mich war an dieser Lesart des Gesetzes neu, dass es präskriptiv,
vorschreibend, und nicht deskriptiv, beschreiben, gelesen wurde. Bisher fand ich es immer interessant, an den entstandenen Systemen zu rekonstruieren, wie sich hier die
faktischen Kommunikationsstrukturen ausgedrückt haben. Das es praktisch der gleiche
Gedanke ist, vorher nach dem sozialen Systemen und den Kommunikationsstrukturen zu fragen und die Systeme so zu modellieren, dass sie sie abbilden, kam mir dabei
nicht in den Sinn. Bis zu dieser Woche, bis zu Brandon Byars.

Die andere Begegnung war folgende. Ich lass über das Wasserfallmodell, über all die Phasen und all die Artefakte, die jede Phase erzeugte. Das Modell beschreibt auch ein System. Es ist kein strukturelles, es ist ein temporales. Die Phase folgen einander.
Aber das Gesetz von Conway lässt sich ebenfalls anwenden. Das soziale System,
das bei der Softwareerstellung involviert ist, reflektiert sich im Phasenmodell. Jede Abteilung hat ihre Phase und ihre Dokumente. Die grundsätzlichen Anforderungen werden vom oberen Management festgelegt. Die Fachabteilungen erzeugen den Inhalt der Spezifikationen. Die Architekten schaffen den Systementwurf. Die Programmierer den Code. Die Tester den Testplan. Die Betreiber das Betriebskonzept. Die Stabilität des Modells besteht darin, dass jede Gruppe ihre Phase und ihre Artefakte hat. Jede Gruppe kann sich vergegenständlichen. Es gibt kein einheitliches Wasserfallmodell (es
gibt die unterschiedlichsten Ausführungen mit zwischen 6 und 18 Phasen), weil das
zugrundeliegende soziale System immer anders aussieht. Jedes soziale System
schafft sich seine Phase und sein Artefakt. Je stärker die Abteilung um so
ausgeprägter die Phase und wichtiger das Dokument.

Das Problem des Wasserfallmodells lässt sich aus dieser Perspektive folgendermaßen
charakterisieren. Es gibt N Systeme, N Phasen und N Dokumente (Artefakte). Im
Kontext des Systems I ist das Dokument I aussagekräftig. Die Welt des Systems
I verleiht dem Dokument I seine Bedeutung. Für alle anderen Systeme ist das
Dokument marginal, randständig, unscharf, weil alle anderen Systeme anderen
Sprachspielen und Kontexten gehorchen. Im Wasserfallmodell ist dieses
Übersetzungproblem nicht adressiert. Im Gegenteil, man könnte sagen, es ist
zementiert.

Zwei Anwendungen von Conways Law, die für mich neu waren. Im Kern geht es bei
beiden um das Verhältnis von sozialen und technischen Systemen. Einmal in
struktureller Hinsicht (Design von Subsystemen), einmal in temporaler
(Phasen). Ich vermute, das wird nicht das letzte Mal sein, dass ich auf dieses
Gesetz gestoßen bin.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>