EAM meets DDD

Wie groß ist das „E“ in EAM und wie klein das „M“ in Micro-Service?

Auf übergeordneter Ebene sieht sich das Enterprise Architecture Management (EAM) in einer strukturierenden und steuernden Funktion. Oft initiiert es Umsetzungsprojekte, grenzt sich jedoch von den Implementierungsdetails einzelner IT-Systeme ab. Umgekehrt aber beschäftigen sich Software-Entwickler vermehrt mit strategischen und fachlichen Themen und fischen damit im Revier von Unternehmensarchitekten. Ein Einflussfaktor ist die Digitalisierung, in der die technischen Möglichkeiten prägend für neue Geschäftsfelder und letztlich sogar für menschliche Denk- und Verhaltensweisen sind. Qua täglicher Erfahrung sind Software-Entwickler die technischen Experten. Ein zweiter Einflussfaktor sind die allgegenwärtigen Microservices und Self-Contained Systems. Statt großer Monolithen bauen Teams heute einzeln deploybare fachliche Module, die sich möglichst autonom und evolutionär entwickeln sollen.

Um in diesen Strömungen nicht nur Oberwasser zu behalten, sondern womöglich als rettende Lotsen agieren zu können, sollten sich Unternehmensarchitekten auch mit implementierungsnahen Ansätzen beschäftigen. Einer davon ist besonders lohnenswert: Das so genannte Domain-Driven Design (DDD) erschließt die Fachlichkeit mit ähnlichen Mitteln wie das EAM, liefert darüber hinaus aber auch Muster für das Design auf Code-Ebene. Konkret nimmt sich der Artikel eine Capability Map aus dem EAM vor und verknüpft diese anhand eines Beispiels mit einer Context Map aus dem DDD. Unternehmensarchitekten erhalten dadurch Anregungen, wie sie den Übergang von und zu Umsetzungsprojekten fließender gestalten können.

Architektur als Kontinuum

Der Artikel gründet auf folgender Idee eines Architekturkontinuums: Die Geschäfts- und IT-Architektur eines Unternehmens bildet ein Kontinuum und sollte nicht strikt unter den Disziplinen „Enterprise Architecture (Management)“, ggf. einer „Solution Architecture“, sowie der „Software Architecture“ aufgeteilt werden:

Prinzipiell macht es aber Sinn, verschiedene Ebenen zu betrachten. Auf höheren Ebenen fassen wir mehr von der gesamten Breite des Geschäfts und der IT in den Blick. Auf tieferen Ebenen fokussieren wir uns auf ausgewählte Ausschnitte und gehen dafür tiefer in die Details einer bestimmten Lösung. Traditionell deckt die Disziplin des EAM eher die höheren Ebenen ab und die Disziplin der Software Architecture eher die tieferen Ebenen. Beide haben ihre eigenen Spezialisierungen und Methoden hervorgebracht, die für sich wertvoll sind und die sich nicht unter dem Aspekt „verschiedene Betrachtungsbenen“ zusammenfassen lassen. Beide Disziplinen operieren aber auf demselben Architekturkontinuum, wodurch sich die Methoden ähneln und auch zusammenspielen können! In dieser Betrachtungsweise ist EAM nicht nur für „die IT-Landschaft“ und Software Architecture nur für einzelne „IT-Systeme“ zuständig, so als ob diese nichts miteinander zu tun hätten.

Ein Ansatz, der als Bindeglied fungieren kann, ist wie erwähnt DDD, kurz für Domain Driven Design. Indem sich der Artikel eine Capability Map aus dem EAM vornimmt und diese anhand eines Beispiels mit einer Context Map aus dem DDD verknüpft, skizziert er einen Weg durch das Kontinuum. Im Vordergrund steht dabei die Fachlichkeit. Nur wenn sich diese durch das gesamte Kontinuum zieht, kann die IT das Geschäft optimal unterstützen oder gar neue Geschäftsfelder prägen!

Jene Art von Drill Down, wie sie die obige Grafik suggeriert, ist bereits von Capability Maps aus dem EAM bekannt. Die folgende Grafik zeigt als Beispiel die Geschäftsfähigkeiten eines Schwimmvereins auf oberster Ebene. Für ein ausgewachsenes EAM ist ein Schwimmverein zugegebenermaßen kein klassischer Kandidat. Doch warum sollte sich eine Capability Map im Sinne von „Lean“ und „Agile“ nicht darauf anwenden lassen?

Die Mitglieder des Vereins können durch eine Website sowie persönlich oder telefonisch im Büro der Geschäftsstelle Kontakt aufnehmen. Das Kerngeschäft des Vereins ist zunächst das Durchführen von Schwimm-Trainings sowie die Teilnahme an Schwimmwettkämpfen. Die Ausrichtung von Wettkämpfen für Teilnehmer aus beliebigen Vereinen ist explizit eine separate Geschäftsfähigkeit, weil sie sich grundlegend von der reinen Teilnahme unterscheidet. Wesentliche „Ressourcen“, die der Verein benötigt, sind Trainingsstätten, die Mitglieder sowie die Trainer. Unterstützend wirken die Lohn- und Finanzbuchhaltung, bei der gesetzliche Vorgaben einzuhalten sind, sowie die Öffentlichkeitsarbeit. Letztere zählt anders als das Marketing bei vielen kommerziellen Unternehmen nicht zum Kerngeschäft. Daneben gibt es eine übergreifende Organisation, die sich beispielsweise um die Beschaffung von Arbeitsmitteln und um übergreifende Vereinsveranstaltungen kümmert. Übrigens: Das Beispiel dient der Illustration, es erhebt keinen Anspruch auf fachliche Vollständigkeit und Richtigkeit im Detail.

Die Einteilung der Capability Map in die Dimensionen „Kundenzugang“, „Kerngeschäft“, „Ressourcen“ und „Unterstützung“ ist Engels [Eng08] entlehnt, findet jedoch in vielen EAM-Ansätzen und auch im Geschäftsprozess-Management (GPM) in ähnlicher Form Anwendung. Sie organisieren die Geschäftsfähigkeiten anhand der Nähe oder Entfernung zum Kunden. Diese Dimensionen stellen noch keinen Drill Down im Sinne der vorhergehenden Grafik dar, sondern befinden sich alle auf der selben Ebene. Dies ist durch die durchgängige hellblaue Hinterlegung der Kästchen symbolisiert.

Auf der nächsttieferen Ebene ist die Geschäftsfähigkeit „Wettkampfteilnahme“ wie folgt heruntergebrochen:

Sobald sich mehrere Trainer auf die Teilnahme an einem bestimmten Wettkampf verständigt haben, müssen sie von den Schwimmern verbindliche Zusagen einholen. Bei der so genannten Meldung muss der jeweilige Trainer für jeden teilnehmenden Schwimmer die relevanten Schwimmdisziplinen und Bestzeiten erfassen. Diese Daten „meldet“ der Trainer anschließend elektronisch an den jeweiligen Wettkampfveranstalter, welcher meist ein anderer Schwimmverein ist. Am Ende steht die eigentliche Durchführung des Wettkampfs.

Context Map zur Fortführung der Capability Map

Bisher verfolgten wir einen Top-Down-Ansatz, wie er im EAM Usus ist. EAM-Projekte hören typischerweise auf einer bestimmten Ebene im Architekturkontinuum auf und überlassen die tieferen Ebenen den Umsetzungsprojekten, die sie manchmal noch initiieren und anschließend dem operativen Projekt-Portfolio-Management übergeben. Schließlich ist es die Kernleistung des EAM, von der Geschäfts- und IT-Strategie geeignete Handlungsempfehlungen abzuleiten, um die Architektur mittel- bis langfristig zielgerichtet steuern zu können. Nicht Aufgabe des EAM ist es, die resultierenden Maßnahmen bis ins Detail zu operationalisieren. Wie das Domain-Driven Design (DDD) an diesem Übergang helfen kann, zeigt die Fortführung des Schwimmverein-Beispiels anhand einer Context Map, die wiederum so genannte Bounded Contexts beinhaltet.

Zunächst ist es wichtig zu verstehen, dass DDD aus der Software-Entwicklung kommt. Der Urvater Eric Evans beschreitet in seinem berühmten „Blue Book“ [Eva03] den Weg von einem Domänenmodell auf Software-Ebene bis hin zu einer erweiterten Kontextsicht, die mehr vom angrenzenden Geschäft und der angrenzenden IT in den Blick fasst. Diesbezüglich ist das erklärte Ziel, die Kerndomäne herauszudestillieren, für die sich die Software-Entwicklung tatsächlich lohnt. Zu angrenzenden, weniger lohnenden Subdomänen müssen dennoch die fachlichen, technischen und organisatorischen Beziehungen definiert werden. Dem widmet sich das Strategic Design im DDD, zu dem die erwähnten Muster Context Map und Bounded Context gehören. Aus dieser Bottom-Up-Perspektive kommt man zu Fragen wie: Welche Software-Komponenten müssen wir selbst entwickeln? Welche können wir von der Stange kaufen? Wie kommunizieren die Software-Komponenten miteinander? Und: Wie schneiden wir die Teams, die diese Lösungen umsetzen? Wie kommunizieren die Teams untereinander? Gerade in den letztgenannten Aspekten ist DDD eine konsequente Fortführung von Conway’s Law. Im zugehörigen Artikel [Con68] ist übrigens auch schon von „boundaries“ die Rede!

Somit kommt DDD aus den Untiefen der Software-Entwicklung zu ähnlichen Fragestellungen, wie das EAM in Bezug auf Handlungsempfehlungen. Sowohl EAM als auch DDD beantworten die Leitfragen anhand der Fachlichkeit und setzen ähnliche Methoden ein. Allerdings leistet DDD in diesem Übergangsbereich der Architekturebenen etwas Zusätzliches. Es gibt Entwicklern auch konkrete Muster für das fachliche Software-Design an die Hand. Jene Muster wie Entities, Value Objects und Aggregates waren Software-Entwicklern tendenziell schon bekannt, bevor ihr Interesse mit dem Aufkommen von Microservices und Self-Contained Systems auch auf das Strategic Design überschwappte.

Die folgende Grafik zeigt eine vereinfachte Context Map zur Geschäftsfähigkeit der Wettkampfteilnahme:

Im Vergleich zur Capability Map sind die Kästchen runder geworden. Bei genauerem Hinsehen erkennen wir, dass die Überschriften nicht mehr hundertprozentig zu den bisherigen Geschäftsfähigkeiten auf zweiter Ebene passen. Was steckt dahinter?

Wir nehmen an, aus übergeordneten strategischen Überlegungen entschied sich der Vorstand des Vereins, die Wettkampfteilnahme software-technisch unterstützen zu lassen. Schließlich sei die Teilnahme an Wettkämpfen prägend für das Profil und die Außenwirkung des Vereins. Zudem gebe es kaum passende Standard-Software, die den Mitgliederstamm integriere und den manuellen Aufwand zur Einholung der Zusagen und zur Meldung an den Veranstalter entscheidend reduziere. Der Vorstand beauftragte daher ein kleines Entwickler-Team, eine geeignete Software zu entwickeln. Dieses sollte sich jedoch aus Kostengründen auf die größten Schmerzpunkte fokussieren und keine Lösungen redundant implementieren, für die es bereits Software gibt.

Dem Team diente die Capability Map als Anhaltspunkt. Schnell tauchten die Software-Entwickler und Schwimm-Trainer in die Tiefen der Fachlichkeit ab, um sie so weit zu ergründen, dass sie sich in konkrete Software gießen lässt. Dazu entwarfen sie erste Domänenmodelle, die in der Context Map mit stilisierten Klassendiagrammen angedeutet sind. Die vereinfachte Context Map visualisiert bereits einige Erkenntnisse und Entscheidungen:

1. Zusagen: Schwimmer sollen künftig über die Website des Vereins verbindlich für einen Wettkampf zusagen können. Es gibt bereits ein kleines Website-Team im Verein.
2. Wettkampfausrichtung: Der Verein richtet den Wettkampf nicht selbst aus, sondern nimmt lediglich daran teil. Der Veranstalter wiederum setzt eine eigene Software ein, die nicht im Einfuss des teilnehmenden Vereins liegt. Deshalb ist die Wettkampfausrichtung in der Context Map mit einer gestrichelten Linie abgegenzt. Eine andere Sichtweise nimmt die Capability Map auf oberster Ebene ein: Hier steht die Wettkampfausrichtung für die Fähigkeit des Vereins, auch selbst einen Wettkampf auszurichten.
3. Meldung: Der Hauptaufwand liegt darin, jeden Schwimmer individuell mit seinen Schwimmdisziplinen und seinen Bestzeiten für den jeweiligen Wettkampf zu erfassen und anschließend elektronisch an den Veranstalter zu melden. Für letzteres spezifiziert der Schwimmverband ein Datenaustauschformat, das implizit ein Domänenmodell beinhaltet. Darin ist ein Wettkampf unter anderem in so genannte Abschnitte und Läufe unterteilt. Dieses Domänenmodell ist bei der Meldung, d.h. auf Seiten des teilnehmenden Schwimmvereins, mit dem selben stilisierten Klassendiagramm symbolisiert wie bei der Wettkampfausrichtung, d.h. auf Seiten des Veranstalters.
4. Mitgliederverwaltung: Für die Mitgliederverwaltung setzt der Verein bereits eine Standard-Software ein. Es macht Sinn, sie mitzubetrachten, weil sie die Stammdaten der Vereinsmitglieder führt, wie bspw. Name, Geburtsdatum, Adresse und Kontaktmöglichkeiten. Diese werden auch für die Meldung benötigt.
5. Durchführung: Die eigentliche Teilnahme am jeweiligen Wettkampf lässt sich nicht elektronisch unterstützen. Schließlich müssen die Schwimmer ihre Leistung körperlich unter Beweis stellen. Daher ist sie in der Context Map nicht repräsentiert.

Die Kringel in der Context Map sind Beispiele für Bounded Contexts. Sie definieren jeweils eine Grenze, innerhalb derer ein bestimmtes Domänenmodell gültig ist. Gleichzeitig definieren sie eine Sprachgrenze, da es ein Kernanliegen von DDD ist, innerhalb eines Teams eine gemeinsame Sprache von den fachlichen Diskussionen bis in den Code zu schaffen. Wovon in den dargestellten Bounded Contexts die Rede ist, illustrieren die folgenden Sprechblasen:

Wer sich über die Website für Wettkämpfe anmeldet, sieht sich selbst als „Schwimmer“ und wird in der Web-Oberfläche auch so genannt. Im Kontext der Meldung und Wettkampfausrichtung handelt es sich um „Teilnehmer“ an einem bestimmten Wettkampf mit bestimmten Schwimmdisziplinen und Bestzeiten. Die Mitgliederverwaltung hingegen sieht in ihnen nur „Vereinsmitglieder“. Diese zeichnen sich noch nicht einmal besonders als Schwimmer aus. Jenes unterschiedliches Begriffsverständnis steckt bereits in den Domänenmodellen. Die abgegrenzten Bounded Contexts zeigen deutlich, dass das Entwickler-Team gar kein globales Begriffsverständnis über alle Kontexte hinweg anstrebt. Innerhalb eines Kontexts aber herrscht ein einheitliches Begriffsverständnis von der Fachlichkeit bis in den Code – die so genannte Ubiquitous Language.

Apropos Team: Es gibt ja nicht nur eines! Auf Grund der geschilderten Erkenntnisse wird sich das beauftragte Entwickler-Team auf die Meldung fokussieren. Des Weiteren wird sich das bestehende Website-Team um die Einholung der Zusagen kümmern. Der Veranstalter, der den Wettkampf ausrichtet, ist eine externe Organisation, genauso wie der Produkthersteller für die Mitgliederverwaltung.

Einen Überblick über die Beziehungen zwischen den Teams und deren Bounded Contexts gibt die nun vollständige Context Map:

Die Kanten stehen beispielhaft für Beziehungstypen, die das Strategic Design des DDD definiert. Die Pfeilrichtung deutet dabei an, wer wem in der Beziehung das Domänenmodell vorgibt. Beispielsweise richtet sich das Website-Team für die Zusagen nach dem Modell der Meldung. Das dafür zuständige Entwickler-Team und das Website-Team kooperieren im Sinne einer Customer-/Supplier-Beziehung. Zum Produkthersteller für die Mitgliederverwaltung ist die Beziehung hingegen einseitig, da die Software „as is“ im Verein eingesetzt wird. Das Entwickler-Team bindet sie mittels eines so genannten Anti-Corruption Layer an die Meldung an. Auf diese Weise kann es die Mitgliederstammdaten in die Meldung übernehmen und in das eigene Modell übersetzen, ohne es ungünstig zu beeinflussen. Zu guter Letzt verwendet das Entwickler-Team das Datenaustauschformat des Schwimmverbands als Published Language, um Daten an den Veranstalter übermitteln zu können. Da diese Published Language nur indirekt vom Veranstalter stammt, ist diese Beziehung in der Grafik gestrichelt dargestellt.

Es bleibt anzumerken, dass die Notation für die Context Map frei gewählt und so nicht von Evans [Eva03] vorgegeben ist. Weiterhin kennt die DDD- und Microservice-Community eine Vielzahl von Kriterien, um fachliche Domänenmodelle zu erheben und Bounded Contexts sinnvoll zu schneiden. Eric Evans selbst stützt sich in seinem Buch weitgehend auf Klassendiagramme mit Geschäftsobjekten.

Fazit

Die beispielhafte Capability Map eines Schwimmvereins befindet sich auf höherer Ebene im Architekturkontinuum als die Context Map, die spezifischer auf die Geschäftsfähigkeit der Wettkampfteilnahme eingeht. Letztere bezieht neben fachlichen auch technisch-organisatorische Gegebenheiten der Implementierung ein. In diesem Übergangsbereich der Ebenen berühren sich die Darstellungsformen und Methoden.

Unbenommen bleibt, dass reine EAM-Methodik zu ähnlichen Erkenntnissen und Darstellungsformen führen kann. So dienen Capability Maps oft als „Kartengrund“ für weitere Darstellungen der IT-Landschaft, die – in Verbindung mit der Informations- und Kopplungsarchitektur – ähnliche Aspekte wie eine Context Map abdecken. Unterschiedlich aber ist die Richtung im Architekturkontinuum: Während eine Capability Map typischerweise in einem Top-Down-Ansatz erhoben wird, entsteht eine Context Map nach der Lesart von Evans [Eva03] durch ein „Hocharbeiten“ aus implementierungsnahen Domänenmodellen. Insofern eignen sich EAM und DDD für einen gemischten Top-Down- und Bottom-Up-Ansatz. Dieser birgt die Chance, übergeordnete strategische Überlegungen mit Domänenmodellen und technisch-organisatorischen Gegebenheiten der Implementierung entlang der Fachlichkeit zu integrieren:

Wichtig ist dabei: Auch wenn die fachlichen Cluster in Capability Maps und Context Maps ähnlich aussehen, macht ein bewusster Übergang der Darstellungsformen und Methoden Sinn, wie im Beispiel gezeigt. Der Grund ist, dass Capability Maps die grundlegenden Geschäftsfähigkeiten eines Unternehmens zeigen. Der Treiber für Bounded Contexts hingegen ist die Implementierung und damit vor allem Use Cases. Diese wiederum unterstützen die Geschäftsfähigkeiten, sind mit ihnen aber nicht identisch.

Am Übergang der Darstellungsformen geben die Dimensionen der Capability Map eine Hilfestellung: Mit der Wettkampfteilnahme verwendet das Beispiel bewusst eine Geschäftsfähigkeit aus der Dimension „Kerngeschäft“ als Basis für Bounded Contexts. Dies funktioniert generell gut, da die Dimension auf Geschäftsprozesse verweist, aus denen gut Use Cases abgeleitet werden können. Dies gilt ferner auch für die Dimension „Unterstützung“, wo aber für Software-Entwicklung in der Regel ein schlechteres Kosten-/Nutzen-Verhältnis gegeben ist.

Keine gute Basis für Bounded Contexts dagegen sind Geschäftsfähigkeiten der Dimension „Ressourcen“. Es handelt sich eigentlich um keine Geschäftsfähigkeiten, sondern um ein Geschäftsobjekte. Diese schon auf hoher Ebene vorzugeben, schränkt die Freiheit ein, innerhalb dedizierter Bounded Contexts use-case-orientierte Domänenmodelle und Begriffe zu entwickeln. Das Beispiel zeigt dies anhand der Mitglieder, die in einem anderen Kontext auch Schwimmer oder Teilnehmer heißen und nicht genau dasselbe sind. Ein unternehmensweites kanonisches Datenmodell, wie man es zu Hochzeiten der service-orientierten Architektur (SOA) propagiert hat, passt nicht zu den Schnitt-Ideen für Bounded Contexts. Auch in der Implementierung können rein ressourcen-orientierte (Micro-)Services für das Erstellen, Lesen, Ändern und Löschen von Geschäftsobjekten (CRUD) zu einer Vielzahl von unerwünschten Abhängigkeiten führen und zu einem Engpass werden. Schließlich müssen die eher use-case-orientierten Services laufend Geschäftsobjekte lesen und bearbeiten.

Zu guter Letzt eignet sich die Dimension „Kundenzugang“ dort als Basis für Bounded Contexts, wo sie sich an Geschäftsprozessen orientiert. Auf das Beispiel bezogen wäre es denkbar, die Prozesse und Use Cases hinter der Website oder der Geschäftsstelle des Schwimmvereins mit Bounded Contexts zu strukturieren. Dort, wo es beim Kundenzugang primär um Technologien geht, funktioniert dies nicht ohne Weiteres.

DDD hat im Übergangsbereich der Architekturebenen mehr zu bieten als nur Context Maps. Beispielsweise beschreiben Large Scale Structures Muster, die im Architekturkontinuum noch höher gehen. Zudem entstand im Fahrwasser von DDD ein Workshop-Format namens Event Storming, welches Ergebnisorientierung und Spaß in sonst dröge Termine zu bringen vermag. Dabei erschließen fachliche und technische Stakeholder einen Geschäftsprozess anhand der Ereignisse, die in ihm aufgetreten sind [Bran]. Ebenfalls im Fahrwasser von DDD entstand das Domain Storytelling, eine leichtgewichtige visuelle Methode des Requirements Engineering.

All dies zeigt, wie sehr es Sinn macht, dass sich Unternehmensarchitekten mit DDD befassen. Einen guten Einstieg hierzu bietet Vaughn Vernon [Ver16]. Nicht zuletzt vermag DDD eine gemeinsame Meta-Sprache zwischen Unternehmensarchitekten und Software-Entwicklern zu schaffen, in der sie sich über die Fachlichkeit unterhalten können!

---

Literatur

[Bran] Brandolini, Alberto, Introducing Event Storming, Leanpub, https://leanpub.com/introducing_eventstorming

[Con68] Conway, Melvin E., How do Committees Invent, Datamation 14.4, 1968

[Eng08] Engels, Gregor et al., Quasar Enterprise: Anwendungslandschaften service-orientiert gestalten, d.punkt, 2008

[Eva03] Evans, Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003

[Ver16] Vernon, Vaughn, Domain-Driven Design Distilled, Addison-Wesley, 2016

---

Über den Autor