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.