Читать книгу Vom Monolithen zu Microservices - Sam Newman - Страница 17

Sind Microservices rund um eine Businessdomäne modelliert, sehen wir Übereinstimmungen zwischen unseren IT-Artefakten (den unabhängig deploybaren Microservices) und unserer Businessdomäne. Diese Idee hallt bei Technologiefirmen wider, die die Grenzen zwischen »Business« und »IT« niederreißen. In klassischen IT-Organisationen geschieht die Softwareentwicklung oft völlig getrennt vom Business, das die Anforderungen definiert und eine Verbindung zum Kunden hat (siehe Abbildung 1-4). Die Dysfunktionen dieser Art von Organisationen sind zahlreich und vielfältig, und wir müssen hier vermutlich nicht weiter darauf eingehen.

Abbildung 1-4: Eine Organisationssicht auf die klassische IT-Business-Aufteilung

Stattdessen sehen wir echte Technologieorganisationen, die diese zuvor getrennten organisatorischen Silos vereinen (siehe Abbildung 1-5). Product Owner arbeiten jetzt direkt als Teil der Delivery-Teams mit, die wiederum nicht mehr technischen Gruppen, sondern entsprechenden kundenzentrierten Produktlinien zugeordnet sind. Statt dass zentralisierte IT-Funktionen die Norm sind, ist das Ziel jeder zentralen IT-Funktion, diese kundenzentrierten Delivery-Teams zu unterstützen.

Auch wenn nicht alle Organisationen diesen Wechsel vollzogen haben, sorgen Microservices-Architekturen dafür, dass er leichter umzusetzen ist. Wollen Sie mit den Produktlinien abgestimmte Delivery-Teams und mit der Businessdomäne abgestimmte Services haben, wird es einfacher, die Ownership ganz klar diesen produktorientierten Delivery-Teams zuzuweisen. Es ist wichtig, immer weniger von mehreren Teams betreute Services zu haben, um Ärger bei der Auslieferung zu vermeiden – Microservices-Architekturen, die an Businessdomänen orientiert sind, erleichtern diesen Wechsel der Organisationsstrukturen.

Abbildung 1-5: Ein Beispiel dafür, wie echte Technologiefirmen Software-Delivery integrieren