Kulturelle Bedürfnisse bei der Gestaltung begrenzter Kontexte

Das Bounded Context Pattern aus Eric Evans Buch Domain-driven Design ist zweifellos eines der wichtigsten Patterns für den Entwurf und die Entwicklung moderner Software. Vor allem im Land der Microservices-Architekturen, wo die Festlegung eines geeigneten Bounded Context, der eng mit den Geschäftszielen der Domäne verknüpft ist, unerlässlich ist, um nicht in das Anti-Muster des verteilten Monolithen zu geraten. Der begrenzte Kontext ist im Kern eine Sprachgrenze, eine Grenze, an der die Sprache konsistent bleiben kann und die die Grenze des für einen bestimmten Zweck entwickelten Modells darstellt. Grenzen für Menschen sind aus kultureller Sicht von entscheidender Bedeutung. Menschen können nicht ohne Grenzen leben; sie sind eine Möglichkeit, uns selbst zu definieren und uns von anderen abzugrenzen. Die Definition unseres Selbst schafft eine Identität, ein Gefühl der Zugehörigkeit, das mit der Zeit zu Eigentum führen kann. Um uns selbst definieren zu können, müssen wir jedoch auch die anderen definieren, um unsere eigene Identität zu bewahren. Wenn wir uns die Kulturanthropologie ansehen, haben wir dies traditionell an der Grenze durch Zusammenkünfte wie auf Marktplätzen getan, wo wir Waren austauschen. Wenn wir nun die kulturellen Vorteile des begrenzten Kontexts in unserem Unternehmen erhalten wollen, müssen wir uns auch um die kulturellen Bedürfnisse kümmern, die begrenzte Kontexte gestalten. In diesem Beitrag beschreibe ich diese kulturellen Anforderungen bei der Verwendung des Musters für gebundene Kontexte.

Das gebundene Kontextmuster

Der begrenzte Kontext ist ein Muster aus Eric Evans Buch Domain-driven Design. Das Muster ist vom Design her unscharf, also lassen Sie mich zunächst erklären, was ich mit dem Muster des begrenzten Kontexts meine. Der begrenzte Kontext ist eine bewusste Designentscheidung, die eine Gruppe von Menschen, vorzugsweise ein Team, trifft. Wenn wir einen begrenzten Kontext entwerfen, konzentrieren wir uns auf eine Sprache, in der wir die Situation in der Domäne wirklich knackig und präzise beschreiben. Wir erstellen ein Modell für einen Zweck, bei dem die Sprache in diesem Rahmen im Laufe der Zeit konsistent bleibt. Konsistent im Laufe der Zeit bedeutet, dass die Sprache des Modells niemals zweideutig sein wird, sondern sich im Laufe der Zeit ändern kann. Wir verwenden eine gemeinsame Sprache, die durch Gespräche zwischen Geschäftsleuten (Fachleuten) und Softwareexperten entstanden ist und die zur allgegenwärtigen Sprache wird. Die Konzentration auf die Sprache bedeutet, dass der begrenzte Kontext eine Sprachgrenze ist und keine Systemgrenze, wie Sie sie bei Microservices sehen. Der begrenzte Kontext bedeutet daher nicht, dass Sie auch eine Systemgrenze haben.

Der kulturelle Nutzen bei der Gestaltung begrenzter Kontexte

In der Domain-driven Design-Community haben bereits mehrere Personen über die kulturellen Vorteile eines begrenzten Kontexts gesprochen. In fast allen diesen Vorträgen wird auf das Buch von Daniel Pink "Drive: Die überraschende Wahrheit darüber, was uns motiviert". In seinem Buch erklärt Daniel Pink, dass MIT-Studien zeigen, dass Mitarbeiter, die über ihre Grundaufgaben hinaus arbeiten, ab einer bestimmten Schwelle nicht mehr durch mehr Geld motiviert werden. Diese Schwelle ist die Befriedigung der Grundbedürfnisse und das Gefühl, dass sie fair bezahlt werden. Nach dieser Schwelle werden Menschen nur noch durch Autonomie, Zielsetzung und Beherrschung motiviert. Der kulturelle Nutzen eines begrenzten Rahmens, wenn er richtig gestaltet ist, besteht darin, dass er uns Autonomie und Sinn verleiht. Er gibt uns ein Ziel, weil wir ein Modell für ein Ziel definieren, und er gibt uns Autonomie, weil er eine Sprachgrenze darstellt. Manche nennen den begrenzten Kontext auch eine autonome Grenze. Das erhöht die Autonomie, und das gibt uns auch die Möglichkeit, unsere Beherrschung zu verbessern, was natürlich von der Kultur des Unternehmens abhängt! Ein weiterer kultureller Vorteil des begrenzten Kontexts liegt in seinem Namen: begrenzt. Begrenzt bedeutet, dass wir eine Grenze um einen Kontext ziehen und ein Team sich diese Grenze zu eigen machen kann. Als Menschen brauchen wir Grenzen, um uns in einer Gruppe miteinander zu identifizieren. Diese Gruppe kann zu einem Team mit eigener Identität und Individualität werden. In ihrem Buch Jam culture (das später in diesem Jahr ins Englische übersetzt wird) sagt Jitske Kramer jedoch:

"Wir können diese Identität und Individualität nur durch andere schaffen. Wir haben unser Selbst nie ohne andere definiert. Durch die Art und Weise, wie andere Menschen sind, können wir so sein, wie wir sind. Durch die Grenzen zu anderen sind wir wir selbst."

In der gleichen Argumentationslinie sehen wir das auch für das Architekturdesign, wo der folgende Tweet von Ruth Malan meiner Meinung nach alles erklärt: https://twitter.com/ruthmalan/status/1081578760271523840?s=20

Die kulturellen Bedürfnisse bei der Gestaltung begrenzter Kontexte

In ihrem Buch Jam culture erwähnt Jitske Kramer auch Folgendes:

"Ein Stamm, eine Gemeinschaft oder eine Organisation existiert aufgrund der Grenze zwischen innen und außen, wer dazugehört und wer nicht. Wir bilden unsere eigene Subkultur, indem wir uns mit anderen vergleichen, indem wir den Kontrast zu einem anderen finden. Wir brauchen uns gegenseitig, um uns selbst zu finden. Wir verlieren uns aber auch durch andere."

Eine Auswirkung, die Grenzen haben können, ist, dass wir uns immer mehr isolieren, wenn wir nicht vorsichtig sind. Wir konzentrieren uns auf unsere eigenen Ziele und verlieren den Kontakt zu anderen Teams. Dies kann auch aus dem Bedürfnis heraus geschehen, uns selbst zu schützen, wenn die Unternehmenskultur eine Kultur der Schuldzuweisung ist. Wir konzentrieren uns auf KPIs und Ziele. Wenn etwas schief geht und wir das Gefühl haben, dass andere Teams daran schuld sind, können diese Grenzen zu Betonmauern werden. Wir versuchen, uns noch mehr zu isolieren; wir glauben, dass wir andere Menschen nicht brauchen, um unsere Ziele zu erreichen. Damit begrenzte Kontexte wirklich funktionieren, brauchen wir also eine generative Kultur, in der wir uns darauf konzentrieren, transparent zu sein und Informationen an den Grenzen unserer Grenzen zu teilen. In ihrem Buch erklärt Jitske Kramer das Folgende:

"Traditionell kommen wir über Marktplätze und Handelsrouten miteinander in Kontakt, wo verschiedene Gruppen Waren, Geschichten und Götter tauschen, sich verlieben und Konflikte austragen."

Die Menschen sind aufeinander angewiesen, daher ist es wichtig, dass wir eine Kultur schaffen, in der wir uns häufig über die Grenzen hinweg begegnen. Bei Xebia machen wir das, indem wir alle zwei Wochen eine interne Konferenz abhalten. Wir als Berater bestimmen die Tagesordnung. Es ist wichtig, dass das Unternehmen diese Konferenzen ermöglicht. Lassen Sie Ihre Mitarbeiter dies nicht ganz allein und in ihrer eigenen Zeit tun; die Menschen haben Familien und ein Privatleben, die wichtiger sind als Ihr Unternehmen. Diese Konferenzen sind sowohl für das Unternehmen als auch für die Mitarbeiter von Nutzen, also sollten Sie sie ernst nehmen. Vor kurzem haben Victoria Morgan-Smith und Matthew Skelton ein Buch über interne Tech-Konferenzen geschrieben, in dem sie praktische Ratschläge für die Vorbereitung, Durchführung und Nachbereitung einer internen Tech-Konferenz geben. Diese internen Tech-Konferenzen geben Ihren Teams das Rüstzeug, um ihre Arbeit besser zu erledigen.

Sozio-technische Architektur

Interne Tech-Konferenzen vermitteln uns zwar bessere Kenntnisse über den technischen Teil unserer Identität, aber wir müssen auch den Zweck unserer begrenzten Kontexte mit anderen teilen. Bleiben Sie mit der Vision und den Zielen des Unternehmens und anderer Teams verbunden. Hier sehe ich eine wesentliche Aufgabe für Architekten. Meiner ehrlichen Meinung nach sollte ein Architekt sozio-technisch und nicht nur technisch sein. Ein Architekt sollte sich darauf konzentrieren, Wissen zwischen Teams und Kontexten auszutauschen, anstatt die perfekte Architektur zu entwerfen. Er sollte den Teams die Möglichkeit geben, sich an den Unternehmenszielen zu orientieren, anstatt ihnen vorzuschreiben, wie sie arbeiten sollen. Sie sollten als neutrale Partei agieren, um sicherzustellen, dass sich die Teams mit anderen Teams identifizieren können. Sie sollten aber auch führen, wenn es nötig ist, und Entscheidungen auf der Grundlage der Bedürfnisse der Teams treffen. Sie müssen eine 'Spinne im Netz' sein, die alle Kontexte aus der Vogelperspektive betrachtet und gemeinsam mit den Teams strategische soziotechnische Muster entwickelt. Die wichtigste Aufgabe eines soziotechnischen Architekten ist es, eine wohlwollende Führungskraft für die Teams zu sein!

Zusammenarbeit bei der Modellierung

Wie können wir also diese Marktplätze fördern? Die Art und Weise, wie ich das seit einigen Jahren mache, ist, dass ich regelmäßig gemeinsame Modellierungssitzungen durchführe. Für ein Unternehmen können wir jedes Quartal ein Eventstorming zum großen Ganzen veranstalten. Das Ergebnis ist der Austausch von Fachwissen, die Abstimmung zwischen den Teams und dem Unternehmen und die Ermittlung unserer Theorie der Zwänge. Bei einem neuen Vorschlag oder einer Änderung in unserem Bereich können wir die Auswirkungen mit Hilfe von Impact Mapping prüfen und die Auswirkungen auf die Teams visualisieren. Auf einer detaillierteren Ebene können wir mehrere Teams an einem Produkt arbeiten lassen und ein User Story Mapping durchführen. Zwischen den Teams können wir verschiedene Arten der kollaborativen Modellierung durchführen, von EventStorming und Example Mapping bis hin zu Domain Storytelling und Feature Mapping. Das Wichtigste bei der Veränderung der Arbeitsweise ist, dass die Teams sich regelmäßig treffen, z.B. bei einem Stand-up. Wenn wir beginnen wollen, die Kultur zu verändern, müssen wir dieses neue Verhalten so oft wie möglich verbreiten, um den Leuten den Nutzen zu zeigen und es in ihr System zu bringen.Wenn Sie sich also auf die Entwicklung von Bounded Context oder sogar auf eine Microservices-Architektur zubewegen, stellen Sie sicher, dass Sie auch Ihre Arbeitsweise und Ihre Kultur verändern! Ich bin sehr daran interessiert, wie Ihr Unternehmen oder wie Sie diese Marktplätze zwischen Teams schaffen. Dieser Beitrag ist auch auf meiner persönlichen  Blog-Seite.