Seite 2: Kollaborationen: Organisation designen

Inhaltsverzeichnis

Die oben genannten Beziehungen ergeben sich aus der Aufteilung in Bounded Contexts: "Leihe" ist unabdingbar Downstream von "Suche". Das hat jedoch Nachteile, da das Verleihen von Büchern die Kernaufgabe einer Bücherei ist. Wenn andere Bereiche die zentrale Aufgabe negativ beeinflussen können, sind Gegenmaßnahmen angebracht, um die Prioritäten in dem Projekt richtig setzen zu können.

Die Upstream-Downstream-Beziehung lässt sich nicht wegdiskutieren, da sie objektiv vorhanden ist. Dennoch existieren unterschiedliche Wege, auf das Verhältnis Upstream-Downstream in der Organisation zu reagieren:

• Customer-Supplier-Kollaboration
• Conformist-Kollaboration
• Anticorruption Layer
• Open-Host-Service

Bei einer Customer-Supplier-Kollaboration kann das Downstream-Team beim Upstream-Team Features einfordern, die letzteres im Rahmen seiner Möglichkeiten umsetzt. Bei dieser Art der Zusammenarbeit könnte "Leihe" bei der "Suche" neue Features anfordern. Damit hat "Leihe" tatsächlich eine höhere Priorität als "Suche".

Anders bei der Conformist-Kollaboration: In dem Fall übernimmt das Downstream-Team das Datenmodell des Upstream-Teams und hat kein Mitspracherecht. Das erleichtert zwar die Integration, liefert aber das Downstream-Team dem Upstream-Team aus. Die Entscheidung zwischen Customer-Supplier und Conformist ist eine Architekturentscheidung. Sie hängt von der Priorisierung ab: Ist das Downstream-Team politisch mächtig oder bearbeitet ein wichtiges Thema, bekommt es eher eine Customer-Rolle. Sonst findet es sich vielleicht in einer Conformist-Rolle wieder.

Somit lässt sich die Upstream-Downstream-Beziehung mit einer Architekturentscheidung an den Stellen kompensieren, an denen es sinnvoll erscheint. Teams könnten die "Leihe" in eine Conformist-Rolle zwingen, wenn die Priorisierung nicht hoch genug ist.

Eine weitere Option ist der Anticorruption Layer: Ähnlich wie bei Conformist kann das Downstream-Team nicht in die Belange des Upstream-Teams eingreifen, hat jedoch in dem eigenen System eine Schicht eingezogen, durch die es sich von dem Domänenmodell des Upstream-Teams entkoppelt. Auf der Ebene der Zusammenarbeit entspricht das dem Conformist, aber es kommt eine weitere Schicht zur Übersetzung der Modelle beim Downstream Bounded Context hinzu.

Bei einem Open-Host-Service gibt es mehrere Downstream-Teams, die gemeinsam eine Schnittstelle des Upstream-Teams nutzen. Als Vorschrift für die Interaktion gilt: Das Upstream-Team ist dafür zuständig, die Schnittstelle weiterzuentwickeln. Anforderungen der Downstream-Teams können in die Weiterentwicklung einfließen, aber das Upstream-Team kann Anforderungen ablehnen und stattdessen einem Downstream-Team eine eigene Schnittstelle anbieten.

Voneinander abhängig

Analog zu den unterschiedlichen Ansätzen für Upstream-Downstream-Relation lässt sich auf Organisationsebene auf Beziehungen, die Mutually Dependent sind unterschiedlichen reagieren:

• Partnership
• Big Ball of Mud

Bei einer Mutually-Dependent-Beziehung kommt fast ausschließlich eine Partnership für die Integration in Frage. Der Begriff hört sich zunächst positiv an, steht aber für eine äußerst enge Abstimmung, die typischerweise zu erheblichen Reibungsverlusten führt.

Ein anderes Vorgehen für den Mutually-Dependent-Fall ist der sogenannte Big Ball of Mud, der allerdings kein geschickter Umgang mit wechselseitig abhängigen Teams ist. Der Begriff bezeichnet ein System, das mehrere Bounded Contexts umfasst, aber dermaßen schlecht strukturiert ist, dass praktisch überhaupt keine Struktur zu erkennen ist.

Aufgrund der schlechten Struktur existieren viele Abhängigkeiten. Daraus folgt, dass sich Teams, die gemeinsam an einem Big Ball of Mud arbeiten, eng koordinieren müssen und daher Mutually Dependent sind. Kaum ein Team entscheidet sich bewusst für einen Big Ball of Mud, sondern er entsteht, wenn eine sinnvolle Strukturierung des Systems nicht angegangen wird.

Die Free-Beziehung führt zu vollständiger Unabhängigkeit und daher zu keiner Zusammenarbeit. Daher erscheint es kaum sinnvoll, überhaupt eine Beziehung zwischen Free und einer Kollaboration zu diskutieren.

Dennoch gibt es die Separate-Way-Kollaboration: Wenn Teams zwei Bounded Contexts zwar integrieren können, der Aufwand dafür aber in keinem vernünftigen Verhältnis zum Nutzen steht, können sie sich eine Integration sparen. Voraussichtlich kaum genutzte Schnittstellen kosten gegebenenfalls in der Implementierung mehr Geld, als sie später an Ersparnis einbringen. Durch die Auflösung sind die Teams, die an den beiden Bounded Contexts arbeiten, in einer Free-Beziehung.

Weitere Modelle für die Zusammenarbeit

Darüber hinaus existieren Kollaborationen, die nicht unbedingt Beziehungen beeinflussen:

• Bei einem Shared Kernel teilen sich die Bounded Contexts den Code, die Akzeptanztests und die Datenbank. Änderungen am Shared Kernel erfordern eine Koordination. Um eine ausreichende Unabhängigkeit der Teams zu erreichen, sollte der Shared Kernel klein sein, um eine Mutually-Depend-Beziehung zu verhindern. Upstream-Downstream ergibt sich ebenfalls nicht zwingend, da die beiden Teams gemeinsam an dem Shared Kernel arbeiten sollen.
• Eine Published Language ist ein gemeinsames Datenmodell, das nur zur Kommunikation dient. Es kann sich um einen öffentlich publizierten Standard handeln oder um ein in einem Wiki erklärtes Format. Offensichtlich haben die Bounded Contexts dabei eine Beziehung und müssen sich abstimmen, aber ähnlich wie bei Shared Kernel ist die Beziehung nicht eng, weil sie nur ein Datenmodell für die Kommunikation betrifft. Änderungen am Modell lassen sich daher von Anpassungen am internen Modell entkoppeln.