© Liashko/Shutterstock.com
Entwickler Magazin
Software schnell und nachhaltig entwickeln

Microservices: Architektur agil skalieren

Softwarearchitektur beschreibt die Aufteilung von Softwareprojekten in Module - aber die Architektur hat nicht nur Auswirkungen auf die Struktur der Software, sondern auch auf die Organisation der Projekte. Microservices machen sich das zunutze und sind so eine neue Hoffnung für produktive und nachhaltige Softwareentwicklung - gerade auch bei großen Teams.

Eberhard Wolff


Kleinere Teams können bekanntermaßen sehr effizient und effektiv agil arbeiten. Bei großen Teams ist das oftmals nicht mehr so einfach. Größere Projekte haben allerdings auch einen viel größeren Kommunikationsbedarf und eine komplexere Organisation. Das scheint unvermeidlich, denn mit der Größe des Projekts muss auch die Organisation wachsen, und damit steigt auch der Kommunikationsbedarf.

Conways Gesetz

Aber es gibt Möglichkeiten, diese Herausforderungen anders anzugehen. Basis ist das Gesetz von Conway [1] von 1968. Es stellt einen interessanten Zusammenhang zwischen der Organisation und der Softwarearchitektur her und besagt, dass Organisationen, die Systeme modellieren, auf solche Modelle festgelegt sind, die der Kommunikationsstruktur dieser Organisationen entsprechen. Software besteht letztendlich aus Modellen, und daher gilt das Gesetz gerade auch für die Softwareentwicklung. Es konnte bereits in verschiedenen Kontexten empirisch nachgewiesen werden.

Ein Beispiel für das Gesetz von Conway: Nehmen wir an, dass ein Softwareprojekt in ein Team für das GUI-Design, ein Team für die Geschäftslogik und ein Team für die Datenbank aufgeteilt wird (Abb. 1). Conways Gesetz besagt nun, dass dieses System der Organisationsform dieser drei Teams entsprechen wird – also wird es eine GUI-Komponente, eine Komponente für die Geschäftslogik und eine Komponente für die Datenbank geben. Natürlich kann es in diesen Komponenten noch weitere, feinere Aufteilungen geben. Aber eine Aufteilung ohne diese drei fundamentalen Komponenten ist nicht möglich.

Abb. 1: Technische Aufteilung von Teams und Komponenten

In letzter Zeit rückt ein anderes Verständnis von Conways Gesetz in den Mittelpunkt: Die Organisation wird so gewählt, dass sie der Softwarearchitektur entspricht. Die Organisation des Projekts ist also ein Ergebnis der Softwarearchitektur. So wird die Umsetzung der Architektur erleichtert. Statt also Conways Gesetz als eine Begrenzung zu begreifen, wird es innerhalb dieses Ansatzes konstruktiv zur Umsetzung der Architektur genutzt.

Letztendlich ergibt sich ein Dualismus: Die Architektur und die Teamstruktur sind nur zwei Seiten derselben Medaille. Beide Komponenten beeinflussen sich so stark, dass sie eigentlich untrennbar sind.

Das wirft folgende Frage auf: Wenn die Organisation und Kommunikation großer Projekte so komplex ist, kann die Softwarearchitektur dieses Problem gegebenenfalls lösen?

Typisch ist eine Aufteilung von Organisation und Architektur in technische Schicht...

Entwickler Magazin
Software schnell und nachhaltig entwickeln

Microservices: Architektur agil skalieren

Softwarearchitektur beschreibt die Aufteilung von Softwareprojekten in Module - aber die Architektur hat nicht nur Auswirkungen auf die Struktur der Software, sondern auch auf die Organisation der Projekte. Microservices machen sich das zunutze und sind so eine neue Hoffnung für produktive und nachhaltige Softwareentwicklung - gerade auch bei großen Teams.

Eberhard Wolff


Kleinere Teams können bekanntermaßen sehr effizient und effektiv agil arbeiten. Bei großen Teams ist das oftmals nicht mehr so einfach. Größere Projekte haben allerdings auch einen viel größeren Kommunikationsbedarf und eine komplexere Organisation. Das scheint unvermeidlich, denn mit der Größe des Projekts muss auch die Organisation wachsen, und damit steigt auch der Kommunikationsbedarf.

Conways Gesetz

Aber es gibt Möglichkeiten, diese Herausforderungen anders anzugehen. Basis ist das Gesetz von Conway [1] von 1968. Es stellt einen interessanten Zusammenhang zwischen der Organisation und der Softwarearchitektur her und besagt, dass Organisationen, die Systeme modellieren, auf solche Modelle festgelegt sind, die der Kommunikationsstruktur dieser Organisationen entsprechen. Software besteht letztendlich aus Modellen, und daher gilt das Gesetz gerade auch für die Softwareentwicklung. Es konnte bereits in verschiedenen Kontexten empirisch nachgewiesen werden.

Ein Beispiel für das Gesetz von Conway: Nehmen wir an, dass ein Softwareprojekt in ein Team für das GUI-Design, ein Team für die Geschäftslogik und ein Team für die Datenbank aufgeteilt wird (Abb. 1). Conways Gesetz besagt nun, dass dieses System der Organisationsform dieser drei Teams entsprechen wird – also wird es eine GUI-Komponente, eine Komponente für die Geschäftslogik und eine Komponente für die Datenbank geben. Natürlich kann es in diesen Komponenten noch weitere, feinere Aufteilungen geben. Aber eine Aufteilung ohne diese drei fundamentalen Komponenten ist nicht möglich.

Abb. 1: Technische Aufteilung von Teams und Komponenten

In letzter Zeit rückt ein anderes Verständnis von Conways Gesetz in den Mittelpunkt: Die Organisation wird so gewählt, dass sie der Softwarearchitektur entspricht. Die Organisation des Projekts ist also ein Ergebnis der Softwarearchitektur. So wird die Umsetzung der Architektur erleichtert. Statt also Conways Gesetz als eine Begrenzung zu begreifen, wird es innerhalb dieses Ansatzes konstruktiv zur Umsetzung der Architektur genutzt.

Letztendlich ergibt sich ein Dualismus: Die Architektur und die Teamstruktur sind nur zwei Seiten derselben Medaille. Beide Komponenten beeinflussen sich so stark, dass sie eigentlich untrennbar sind.

Das wirft folgende Frage auf: Wenn die Organisation und Kommunikation großer Projekte so komplex ist, kann die Softwarearchitektur dieses Problem gegebenenfalls lösen?

Typisch ist eine Aufteilung von Organisation und Architektur in technische Schicht...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang