Die Harvard Business Review lehnte damals seine ursprüngliche Arbeit mit der Begründung ab, dass er seine Hypothese nicht bewiesen habe. Nichtsdestotrotz ist diese Beobachtung als Conway’s Law bekannt geworden, und die kollektiven Erfahrungen meiner Kollegen und von mir selbst haben den Wahrheitsgehalt dieser Aussage immer wieder bestätigt. Aber Sie müssen uns nicht beim Wort nehmen!
In einer Studie der Harvard Business School mit dem Titel „Exploring the Duality between Product and Organizational Architectures“ (Erforschung der Dualität zwischen Produkt- und Organisationsarchitekturen) wurden verschiedene Codebasen analysiert, um zu prüfen, ob sich Conways ursprüngliche Hypothese auf Softwaresysteme übertragen lässt. In der Studie wurden mehrere Beispiele für Software, die für denselben Zweck entwickelt wurde (z. B. Textverarbeitung, Finanzmanagement und Datenbanksoftware), mit den Codebasen von Open-Source-Teams verglichen, die nur lose miteinander verbunden waren, und mit denen von Teams, die eng miteinander verbunden waren. Ihre Studie ergab, dass die häufig an einem gemeinsamen Standort arbeitenden, fokussierten Produktteams Software erstellten, die eher zu eng gekoppelten, monolithischen Codebasen tendierte. Die Open-Source-Projekte hingegen führten zu modulareren, dekomponierten Codebasen.
Organisationen haben diesen Zusammenhang zwischen der Organisationsstruktur und der von ihnen geschaffenen Software seit einigen Jahren verstanden und sind dazu übergegangen, neue Strukturen einzuführen, um das gewünschte Ergebnis zu erzielen. Netflix und Amazon zum Beispiel strukturieren sich um mehrere kleine Teams herum, von denen jedes für einen kleinen Teil des Gesamtsystems verantwortlich ist. Diese unabhängigen Teams können den gesamten Lebenszyklus der von ihnen erstellten Dienste selbst bestimmen, was ihnen ein höheres Maß an Autonomie ermöglicht, als dies bei größeren Teams mit monolithischen Codebasen möglich ist. Diese Dienste mit ihren unabhängigen Belangen können unabhängig voneinander geändert und weiterentwickelt werden, was dazu führt, dass Änderungen schneller in die Produktion einfließen können. Hätten diese Unternehmen größere Teams eingesetzt, hätten die daraus entstandenen größeren monolithischen Systeme ihnen nicht die gleichen Möglichkeiten gegeben, zu experimentieren, sich anzupassen und letztlich ihre Kunden zufrieden zu stellen.
Sie sehen vielleicht in Ihren eigenen Unternehmen Spannungen, wenn Ihre Struktur und Ihre Software nicht aufeinander abgestimmt sind. Vielleicht kennen Sie zum Beispiel die Herausforderungen, die entstehen, wenn verteilte Teams versuchen, an derselben monolithischen Codebasis zu arbeiten. In diesem Fall stehen die Kommunikationswege, auf die sich Conway bezieht, im Gegensatz zum Code selbst, wo eine einzelne Codebasis eine feinkörnige Kommunikation erfordert, ein verteiltes Team aber nur zu einer grobkörnigen Kommunikation fähig ist. Wo solche Spannungen auftreten, bringt die Suche nach Möglichkeiten zur Aufteilung monolithischer Systeme entlang organisatorischer Grenzen oft erhebliche Vorteile.
In früheren Technologie-Radaren haben wir die wachsende Popularität von Microservices hervorgehoben, die zunehmend von Organisationen übernommen werden, die die Autonomie ihrer Teams verbessern und die Geschwindigkeit von Veränderungen erhöhen wollen. Der Artikel von Martin Fowler und James Lewis geht näher auf das Thema ein und hebt hervor, dass diese Architekturen den Unternehmen viel mehr Flexibilität bei der Anpassung der Architektur ihrer Systeme an die Struktur ihrer Teams bieten, um sicherzustellen, dass das Conway’sche Gesetz für Sie funktioniert. In der nächsten Ausgabe des Tech Radar werden wir uns mit dem wachsenden Einfluss von Microservices befassen, von Infrastrukturtechnologien wie Packer oder Docker bis hin zum Service Discovery Tool Consul oder Micro-Containern wie dem beliebten DropWizard oder dem relativ neuen SpringBoot. Wir werden auch den umgekehrten Weg diskutieren – Unternehmen, die ihre Teamstruktur ändern, um sie an ihre IT-Systeme anzupassen.
Wir erwarten, dass weitere Techniken und unterstützende Technologien auftauchen werden, um Microservice-Architekturen zu ermöglichen, und wir werden diese in den kommenden Monaten im Auge behalten. Wenn Sie in der Zwischenzeit mehr wissen wollen, melden Sie sich für den neuesten Tech Radar an, lesen Sie den Artikel von Martin und James über Microservices oder mein Buch von O’Reilly, Building Microservices.