Convey’s Law: Warum Menschen stärkeren Einfluss auf die Architektur eines Systems haben als die Technik

Bestimmt haben Sie schon einmal vom Pareto-Prinzip gehört: 80 Prozent des Aufwands werden für die letzten 20 Prozent des Weges benötigt. Aber kennen Sie auch Convey’s Law? Der US-Informatiker Melvin Edward Convey hat es 1968 formuliert:

Organisationen, die Systeme entwerfen, sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.

Als mir der Satz vor vielen Jahren das erste Mal begegnet ist, dachte ich: „So ein Quatsch. Als Architekt bin ich Gestalter des Systems und kriege das schon in den Griff.“ Doch wie so oft im Leben macht einen Erfahrung klüger. Und so bin ich heute davon überzeigt: Convey hat recht.

Schauen wir in ein typisches Entwicklungsprojekt hinein: ein modernes Frontend im Browser, die Gestaltung stylish. Im Hintergrund werkelt ein Mikroservice, der das Frontend mit Daten versorgt. Eigentlich eine einfache Struktur mit klarer Aufgabenverteilung, oder? Weit gefehlt! Hören wir doch einmal unserem Projektteam bei der Gestaltung des Systems zu ...

Tom, der Architekt: „Wir sollten uns heute mit der Fehlerbehandlung beschäftigen.“

Bille, die Frontend-Entwicklerin: „Muss das sein? Ich hab’ eigentlich keine Zeit. Die Animation beim Aufklappen der Kundendaten ruckelt immer noch. Das muss noch richtig gut werden. Und morgen ist Code-Freeze.“

Jonas, der Backend-Entwickler: „Also mein System zur Fehlerbehandlung ist fast fertig, soll ich euch das vorstellen?“

Tom entscheidet, dass das Thema wichtig ist, und Jonas legt los. Stolz zeigt er den anderen Teammitgliedern seinen Mikroservice. Sein Code ist sauber und ganz auf Sicherheit ausgelegt. Es ist gegen jeden denkbaren Fehler abgesichert. Schlägt die Sicherung an, wird die Ausführung abgebrochen und das Problem dem Aufrufer gemeldet. Eigentlich scheint alles gut, oder?

Bille (völlig entsetzt): „Was bekomme ich denn da für Zeugs? Da kann ich doch gar nichts mit anfangen!“

Jonas: „Wieso? Mein Webservice meldet doch im Fehlerfall ganz exakt, was los ist.“

Tom: „Gut. Dann kannst du doch die Fehlermeldung nehmen, wie sie ist, und zeigst sie den Kunden an.“

Bille: „Aha. Und dann bekommt meine Kundin ‚Customer doesn’t exist in Database‘ angezeigt. Und das soll sie verstehen?“

Tom: „Na, dann musst du eben die technische Meldung in eine kundenfreundliche Meldung übersetzen!“

Bille: „Wie soll das gehen? Soll ich denn aus den vielen Texten, die Jonas mir liefert, erraten, was ich dem Kunden erzählen soll? Nein, Jonas. Du musst mir Texte liefern, die meine Kunden verstehen.“

Jonas: „Wie … Meine Texte sind unverständlich? Da steht genau drin, was das Problem ist. Besser geht es doch gar nicht!“

Und so geht das noch eine Weile hin und her. Die drei diskutieren intensiv, und wenn sie Glück haben, finden sie sogar eine Lösung, die alle zufriedenstellt. Ob diese dann aber die bestmögliche Lösung ist, das hängt in nicht geringem Maße von den Beteiligten ab. Wenn Bille nur für das Frontend zuständig ist und Jonas kein Interesse am Frontend hat, werden sie wahrscheinlich eine Lösung finden, welche die Grenzen zwischen den Zuständigkeiten von Jonas und Bille erkennbar werden lässt.

In der Diskussion wird jeder versuchen, seine Interessen durchzusetzen. Und so kann am Schluss auch das System aussehen: ein Mix aus allem Möglichen, eben eine Kompromissarchitektur. Jonas darf seine Fehlermeldungen behalten, und damit Bille es leichter hat, gesteht er ihr zähneknirschend zu, jeden Fehler mit einer Nummer zu versehen. Bille ist zufrieden, dass sie im Frontend weiter nach Lust und Laune schalten und walten und die Meldungstexte nach ihren Vorstellungen gestalten kann. Die ursprünglichen Meldungen aus dem Webservice wird bald niemand mehr beachten – außer den Testern, die wie immer alles sehr genau nehmen.

Ein paar Wochen später wird dann im Sprint Review auffallen, das das Team inzwischen begonnen hat, einen eigenen Service zur Abbildung der Fehlermeldungen aufzubauen: Weil sich niemand für das Vorhalten der Texte in zehn Sprachen verantwortlich fühlte, bekam ein neu hinzugekommenes Teammitglied die Aufgabe, einen passenden Mikroservice zu bauen. Das System bläht sich auf. Nicht weil es technisch notwendig ist, sondern weil es in der gegebenen Organisation des Teams unmöglich war, eine einfachere Lösung durchzusetzen.

Neulich habe ich darüber mit einem Kollegen diskutiert. Er schlug vor, einfach Systeme zu bauen, bei denen alles von einem Team gebaut wird, was gebraucht wird – Frontend, Business-Logik, Objektmodell und Datenbank. Dann liegt alles in der Verantwortung dieses einen Teams, und die Entwicklung kommt schneller voran.

Eigentlich eine gute Idee, wenn alles aus einer Hand kommt. Die Mischung aus Mikroservices und Domain-driven Design kann die Entwicklung deutlich beschleunigen – aber eine gute Architektur wird es trotzdem nur dann, wenn das Team harmoniert und sich die Teammitglieder nicht durch Abgrenzung profilieren. Und selbst wenn das gegeben ist, bleibt die Herausforderung, die Integration mit anderen Systemen gut zu lösen. Das gilt besonders, wenn die Organisation eine Zusammenarbeit über Strukturgrenzen hinweg nicht fördert, weil Partikularinteressen höher bewertet werden als die der Gemeinschaft.

Sicher kennen Sie das aus der eigenen Praxis: ein Team, das vor allem darauf achtet, dass sein Produkt nicht verwässert wird – das lieber eine Idee seiner Nutzer ohne zu Zögern ablehnt, als sich die Idee zu eigen zu machen und so sein eigenes Produkt noch besser zu machen. Zwischen zwei Teams kann es noch viel schwieriger sein, zu guten Lösungen zu kommen. Erst recht gilt das, wenn neben der Aufteilung der Arbeit auch noch Budget- und Machtfragen zuschlagen: „Ich würde ja gerne, wenn mein Chef das Geld dafür bereitstellte.“

Als Architekt ist man gewohnt, vor allem in technischen Dimensionen zu denken. Tatsächlich sind aber die Beziehungen der Mitwirkenden untereinander einer der stärksten Architekturtreiber. Melvin Convey hat mit seiner Beobachtung Recht: Zeig’ mir deine Architektur, und ich sage dir, wie in deiner Organisation kommuniziert wird.

Vielen Dank an meinen Kollegen Abdelkader Mazan für die interessante Diskussion, welche die Idee zu diesem Beitrag lieferte. Auch das ist CGI.