Artikel

Microservices für Manager

Beitrag von Christian Setzwein
23. Februar 2017

Viele ManagerInnen haben sich bisher nicht oder nur wenig um technische Architektur-Muster gekümmert. Viele sehen ihre Aufgabe vielmehr darin, Organisationsstrukturen zu verändern oder Prozesse anzupassen. Da fehlt vielfach die Zeit und das Wissen, sich mit Softwarearchitekturen und Deploymentprozessen (Bereitstellung von Anwendungen in Produktion) zu beschäftigen. Dafür hat man ja seine Techniker.

Doch schon 1968 beschreibt Conways Law, dass Technik und Organisation durchaus etwas miteinander zu tun haben. „Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“ Das bedeutet, dass sich Teamstrukturen direkt in der Struktur Software wiederfinden lassen (und damit gut oder schlecht strukturierte Software möglich machen) – und dass in der Umkehrung die Struktur der Software bestimmt, wie sich Menschen in der Organisation in Teams strukturieren können.

Damit wird das Wissen um die Struktur der Software zu einer Voraussetzung, um Organisationen strukturieren zu können. Conways Law schien lange Zeit unbeachtet. Auffällig für Manager in ihrer Arbeit war immer wieder nur, dass Teams ihren Teil der Arbeit nicht fertigstellen konnten, weil sie noch auf irgendein anderes Team warten mussten. Langwierige Lieferprozesse waren die Folge, niemand schien so recht verantwortlich dafür, der Fehler schien im System zu stecken und zudem unabänderlich zu sein. Trotz noch so sauberer Organisationstrukturen oder überdachter Prozesse wurden immer wieder Konflikte wegen überschneidender Abhängigkeiten und Zuständigkeiten sichtbar, denn die Kommunikationen waren durch die Strukturen der Software bestimmt.

Auch die Manager, die dann die Zerlegung der Software in Komponenten/ Domains beförderten und Teams nach Produkten/Dienstleistungen entsprechend der Komponenten/Domains gliederten und den Software-Artefakten zuordneten, waren nur zum Teil erfolgreich. Immer noch musste auf abschließende Tests eines großen Releases und das Bereitstellen (Deployment) des Releases gewartet werden. Ausufernde Kommunikationen und Abhängigkeiten von anderen Teams waren die Folge.

In den letzten drei Jahren hat sich mit dem Aufkommen von Microservices als Architekturpattern meiner Ansicht nach ein fundamentaler Knoten auch im Bereich der Organisationsstrukturierung gelöst.

Microservices:

sind klar abgegrenzte Softwareeinheiten mit Schnittstellen, die wiederum von anderen Microservices genutzt werden können.
können vollständig in einem Team entwickelt werden, Überschneidungen der Kommunikationen bei der Entwicklung und des Testens eines Service werden unnötig.
machen es möglich, ein Produkt oder eine Dienstleistung für den Kunden im Rahmen der Software-Architektur so zu gliedern, dass Teams immer kundenorientiert arbeiten, z.B. den Paymentservice entwickeln.
lassen sich unabhängig von anderen Microservices in Testsystemen oder Produktivumgebungen bereitstellen, also einzeln deployen. Damit ist es einem Team möglich, wann immer es will oder muss, seine Microservices ohne Kommunikation mit anderen Teams in Produktion zu bringen.
lassen damit auch eine eindeutige Verantwortlichkeit entstehen. Die Teams sind für ihre Microservices und das Zusammenspiel der eigenen Microservices mit anderen verantwortlich.

Microservices sind aus mener Sicht eine technische Möglichkeit, damit Organisationen und Teams schneller und flexibler liefern können. Eine gut strukturierte Microservice-Architektur vermeidet unnötige Kommunikationen und legt Verantwortlichkeit eindeutig fest. Es macht also auch für ManagerInnen Sinn, sich mit den Mechanismen hinter Microservices zu befassen.

Auch interessant:

| Keine Kommentare