Conway’s Law nutzen

Conway’s Law nutzen

Wie könnte der Wandel von monolithischen Applikationen hin zu Microservices in der Praxis funktionieren?

Melvin Conway stellte in den 1960ern die folgende Theorie auf:

Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.

„Organisationen, die Systeme modellieren, […] sind auf Modelle festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“

— Melvin E. Conway

Die Theorie besagt also, dass technische Systeme in Organisationen Abbilder der Kommunikationsstrukturen sind. Im Großen bedeutet dies, dass einzelne Organisationseinheiten verantwortlich für einzelne Systeme sind. Beispiele sind das BI-System, das Stammdatensystem und das Bezahlsystem. Jedes für sich wird von einer Organisationseinheit verantwortet. Im Kleinen bedeutet es, dass für die jeweiligen Funktionsblöcke der Systeme abgegrenzte Teams verantwortlich sind. Beispiele hierfür sind das Frontend-Team, das Datenbank-Team und das Business-Logik-Team. Im Kleinen wie im Großen entstehen an den Schnittstellen Reibungsverluste. Dies ist erstmal unabhängig von der Vorgehensweise in der Produktentwicklung.

In dem genannten Beispielen verantwortet jedes Team eine monolithische Applikation, die alle Funktionalitäten vereint. Funktionale Änderungen und die Aufrechterhaltung einer modularen Struktur werden mit der Zeit und steigender Komplexität komplizierter. Nach wie vor sind monolithische Applikationen die viele Features und Business-Fähigkeiten vereinen aber die Regel.

Microservices

Seit einigen Jahren wird der Einsatz von Microservices als Architektur-Alternative zu monolithischen Applikationen präsenter. Vor allem auch im Zuge von neuen  Cloud-Betriebsmodellen, die durch viele Entwicklungstools unterstützt werden. Ein System werden in fachlich und technisch in sich geschlossene Services zerteilt – jeder Service repräsentiert eine Business-Fähigkeit. Beispiele für Microservices sind VISA-Kreditkartenzahlung, Preisberechnung und Lieferauskunft. Ein System besteht im Sinne der Microservices-Architektur also aus einer Zahl von einzelnen Services, die leicht zu ersetzen und schnell zu deployen sind. Im Gegensatz zu SOA-Architekturen gehören Microservices aber immer nur zu einer Applikation – es gibt hier keinen Anspruch auf Wiederverwendbarkeit. Die eine Applikation wird so in beherrschbare Teile zerschnitten, wobei jedes Teil grundsätzlich unabhängig ist. Das Potential für “Wegwerfen und Neuschreiben” statt ” Diese gewachsene Applikation wird nicht angerührt” wird somit erhöht. Üblich ist eine einfach Makro-Architektur, die für alle Services gilt: Zumeist die Nutzung von REST und HTTP zur Kommunikation.

Zur Entwicklung, Test, Deployment, Betrieb und Monitoring gibt es inzwischen eine umfassende Tool-Landschaft und Cloud-Angebote (Docker, Dropwizard, Digital Ocean, Chaos Monkey etc.). Allerdings steigt natürlich auch die Komplexität, eine Applikation die aus vielen Services in der Cloud besteht zu überblicken und im Auge zu behalten. Zudem ist die Latenz von Netzwerken bei vielen Services ein größeres Thema als bei einer Applikation. Trotzdem wird die Mean-Time-To-Recovery – also die Zeit die eine Applikation benötigt, um wieder lauffähig zu sein – verkürzt. Schließlich bedeutet der Wegfall eines Services nicht den Wegfall der gesamten Applikation. Das erfordert aber natürlich auch ein komplexes Exception-Handling innerhalb des Services, sobald er von anderen Services abhängt.

Inverses Conway-Manöver

Der Wandel von monolithischen Applikationen zu Microservices birgt das Potential die Nachteile zu beseitigen. Und wenn die Struktur der technischen Systeme der Struktur der Organisation entspricht, müssen sich Technik und Organisation synchron zueinander anpassen. Thoughtworks führte im Technology Radar von Juli 2014 daher als Trial Technique das “Inverse Conway Maneuver” auf.  Einen zentralen Artikel dazu haben Martin Fowler und James Lewis im März 2014 veröffentlicht.

Demnach ist ein Team kross-funktional aufgebaut und für mindestens einen Service verantwortlich. Das heißt, ein Team  verantwortet den gesamten Service, von der Aufstellung fachlicher Anforderungen, über Entwicklung bis hin zum Betrieb. Das Gesetz von Conway lässt sich nicht umgehen, wird hier aber produktiv genutzt. Die Organisation ändert sich also und synchronisiert sich mit der technologischen Architektur. Somit greift wieder Conway – die Organisation ist jetzt aber die Kopie der Kommunikationsstrukturen der Applikation. In einem Team sitzen Vertreter aus Fachbereich, Produktmanagement, Entwicklung, Test und DevOps. Ein Team kann mehrere Services verantworten.

Projektion auf die Praxis

Technisch erfordert der Paradigmenwechsel hin zu Microservices sicherlich einiges an Umdenken und spürbare Aufwendungen. Organisatorisch ist der Wechsel aber sicherlich noch dramatischer. Soll die Architektur der Organisation mit der technischen Architektur gleichziehen, so bedeutet das für viele Unternehmen Aufbrechen von Abteilungsstrukturen und Umverteilung von Verantwortungen. Das kann zügig Ängste wie Macht- und Kontrollverlust schüren. Zunächst schwer vorstellbar ist, dass Konzerne Organisationsstrukturen alle paar Jahre mit einem großen Software-Release umfassend umbauen. Für kleine junge Firmen ist es durchaus vorstellbar. Auch für einzelne abgeschlossene Unternehmensbereiche (Beispiel: E-Commerce bei OTTO), die ihre Applikationen auf Microservices umstellen.

Martin Fowler und James Lewis sehen ebenso den Wechsel von Projekt- zu Produktentwicklung. Applikationen werden nicht mehr länger nach Projektende von Entwicklung in den Betrieb übergeben, vielmehr soll ein kross-funktionales Team den Microservice dauerhaft weiterentwickeln und betreiben. Der Mehrwert dieser Veränderung sollte für jeden schnell ersichtlich sein.

Fazit

Der technische und organisatorische Paradigmenwechsel zu Microservices klingt vielversprechend und spannend. Technisch als auch organisatorisch erfordert so ein Vorhaben aber umfassendes Umdenken: Klassische Abteilungsstrukturen würden hiermit der Vergangenheit angehören und es entstehen ganz neue Herausforderungen an Deployment und Betrieb. Daher ist es in der Praxis eher unwahrscheinlich, dass große etablierte Unternehmen schnell auf das Paradigma der Microservices schwenken. Kleinere Unternehmen oder Organisationseinheiten können aber mit dem Einsatz von kross-funktionalen Teams und Microservices schnell effizient arbeiten. Dass Fachabteilung, Produktmanagement, Entwicklung, QS und Betrieb dauerhaft zusammen in einem Team arbeiten und zusammen verantwortlich für eine Applikation sind, ist aber eine Entwicklung mit der sich jeder mal auseinandersetzen sollte. Schließlich entstehen durch eine Teilung der Verantwortlichkeiten immer wieder Ineffizienzen und ein Aufbrechen wäre nicht anderes als die sinnvolle Umsetzung einer großen Erfahrung.

So we write this with cautious optimism. So far, we’ve seen enough about the microservice style to feel that it can be a worthwhile road to tread. We can’t say for sure where we’ll end up, but one of the challenges of software development is that you can only make decisions based on the imperfect information that you currently have to hand.

— Martin Fowler, James Lewis

 Links

Microservices – von Martin Fowler und James Lewis

How Do Committees Invent? – der Orginalartikel von Melvin E. Conway

Diesen Artikel teilen:

Einen Kommentar hinterlassen

*

Projektpfad – Der Blog für agile Produktentwicklung - Background

Suche eingeben

Alle Ergebnisse anzeigen