Vom Domain Driven Design zum Domain Driven Enterprise

EDV wird omnipräsent

In den 1990er Jahren begann die Informationstechnologie die Büros endgültig zu erobern. Das Internet warf seinen Schatten voraus – auch wenn es anfangs fast nur GET und wenig POST war. Die PC Standardarchitektur hat nicht nur die Schreibtische erobert, auch in die Rechenzentren zog Intels commodity technology ein. Skriptsprachen und Anfänge breit eingesetzte Softwarevirtualisierung wie Java machten die Entwicklung neuer Software unabhängig von ihrer Laufzeitumgebung.
Was folgte war ein Produktivitätsschub, der es allen Teilen der Unternehmen erlaubte, mit IT zu automatisieren und Geschäftsprozesse hochzuskalieren, bis in die letzten Winkel der Fachbereiche.
Gleichzeitig blieb die Digitale Datenverarbeitung, egal in welcher Organisationsform, ein Fachbereich für sich. Das technische know-how für die Erstellung von IT Applikationen überwog. In dieser Phase kochte das Jahr-2000-Problem die „alte EDV“ hoch, die Dotcom-Blase überhitzte die „neue IT“ – Software is eating the world.
In der Softwareentwicklung regierte noch der Wasserfall: Fachabteilungen versuchen zusammen mit IT-Abteilungen ein Anforderungsdokument zu verfassen, das den Programmierern ohne weiteres Fachwissen des Auftraggebers ermöglicht, die gewünschte Funktionalität in Software zu gießen. Das hat auch vielfach funktioniert, eine Vielzahl von Programmen beweist das. Nach und nach wurde nach dem stabilen fachlichen Funktionskern auch Funktionalität drumherum in Software abgebildet, und die Systeme wurden mehr und mehr vernetzt. Jetzt wird den Unternehmen der langwierige Zyklus, Spezifikation – Implementierung – Test – Einführung, zu unflexibel. Auch bei kleineren, aber vielleicht dennoch wichtigen Änderungswünschen, hemmt ein Releasezyklus von mehreren Monaten oder gar einem Jahr zu sehr.
Versuche, den bestehenden Prozess zu verbessern, zum Beispiel durch den Rationale Unified Process RUP, konnte in der Praxis das Problem nicht beheben.

Sprinten wird modern

2001 trafen sich in einem Skiressort in Utah knapp 20 Koryphäen der Softwareentwicklung um 12 Grundsätze flexibler und erfolgreicher Softwareentwicklung im Agile Manifest niederzuschreiben. Hier wird (unter vielen anderen Prinzipien) das Problem der mangelnden Flexibilität angegangen, zeitige Auslieferung funktionierender Software bekommt Priorität. Scrum als vielleicht bekanntester Vertreter agiler Entwicklungsvorgehensmethoden hat mit seinen raschen Zyklen, sogenannten „Sprints“ und dem Konzept des „Potentially Shippable Product“ viel dazu beigetragen, Bedürfnisse der anderen Fachbereiche flexibel und ausreichend zeitnah umzusetzen.

In den IT-Organisationen musste sich dabei oftmals Grundlegendes ändern: In Zeiten langfristiger, projektzentrierter Entwicklung von Software war in vielen Unternehmen, beziehungsweise deren IT-Bereichen, der „Poolgedanke“ beliebt. Das bedeutet, dass die Entwicklungsteams sich vorwiegend um das technische know-how kümmern, und für Projekte den fachlichen Projekten zugeteilt werden. Bei langer Projektdauer mag das noch funktionieren, da sich das Team dann doch das fachliche know-how mit der Zeit aneignet; beim agilen Vorgehen, wo nach wenigen Wochen bereits ein Ergebnis vorzeigbar sein muss, führt das zu Schwierigkeiten, Produktivität stellt sich nur langsam ein. Für diesen Ansatz benötigt man ein „stehendes Team“, das in kurzer Zeit die neuen Anforderungen versteht, weil es mit den alten vertraut ist.

Domain Driven Design bringt den Fachbereich in die IT

DDD war die logische Reaktion auf diese Herausforderung. Stabile Implementierungsteams ordnen sich in fachliche Domänen, für die sie schnell und flexibel Anforderungen umsetzen. Ein Team kann dabei für mehrere domains verantwortlich sein, aber jede domain (oder auf unterer Ebene auch „Bounded Context“) sollte von nur einem Team überblickt und verstanden werden können. Mit dieser Methodik ist es tatsächlich möglich, in kurzer Zeit der Software neue Fähigkeiten hinzuzufügen.

In vielen Szenarien hat dieses Umfeld gut funktioniert. So etwa bei der Entwicklung stabiler, strategischer und relativ autarker Software. Oder wenn die Domäne eine Software für den Markt entwickelt, somit der Product Owner (PO) auch tatsächlich die Entscheidungshoheit über ihr oder sein Stück Software hat.

Der Product Owner ist die vielleicht wichtigste Rolle bei Scrum: Wenn der PO Teil der IT-Organisation ist, nicht selbst entscheiden kann, wann was umgesetzt wird, kommt es zu Spannungen und Verzögerungen im Prozess. Dies umso mehr, wenn die Domäne ein Teil eines stark vernetzten Ganzen ist.
Grundlage des Prozesses ist, dass sich der Eigentümer der Software direkt engagiert, und das gesamte Team fachlich führt.

Business Capabilities bringen Systematik in die Organisation

Die Business Capability Map ist ebenso eine Methodik, um die Fähigkeiten eines Unternehmens systematisch zu erfassen. Die Open Group definiert im TOGAF Standard Business Capabilities als „an ability to do something“ definiert. Das macht deutlich, dass es um pure Funktionalität geht, unabhängig wie oder warum diese vorhanden ist, oder von wem oder was diese ausgeführt wird. Eine spezielle Fähigkeiten kann im System der Business Capabilities auch von verschiedenen Organisationseinheiten implementiert werden.

Vom Domain Driven Design zum Domain Driven Enterprise

Organisationen erkannten das Problem fehlender klarer Verantwortung und zu langer Entscheidungswege, speziell in der IT, und versuchten das Problem zu begrenzen, durch enge Abstimmung zwischen IT und Fachbereich, durch Einsatz von Proxy Product Ownern oder ähnlichem.
Wenn aber durch Einführung von DDD die IT näher an die anderen Unternehmensbereiche geführt wurde, könnte man Prinzipien daraus auch auf die gesamte Organisation anwenden, und damit das ganze Unternehmen profitieren?

Was unterscheidet die Domains von den Business Capabilities?
Gar nicht viel.
Beides sind Hierarchien, die Fähigkeiten des Unternehmens beschreiben. Fachdomänen sollen Funktionalität zusätzlich bündeln, die Definition von Evans aus dem Domain Driven Design lautet:q:

Domain-driven design is an approach to IT Architecture, driven by business as well as IT organisations, that is first informed by business requirements.

Das gleiche gilt auch für die Business Capability Map. Ein Unterschied besteht vor allem in den Relationen zu anderen Enitäten der Enterprise Archiketur: Während die Capabilities den Fokus auf die Frage Wer-benutzt-Was? legen, beantwortet die Domänen die Frage Wer-ist-für-Was-verantwortlich?
Beide Sichten haben ihren Wert, Business Capabilities haben ihre Stärke bei Fragen der Unternehmenssteuerung, Strategie, Regulatorik u.s.w., während die Domänen auch im operativen Geschäft hilfreich sind.

Ausweitung des Domänenbegriffs

Dieser IT-zentrierte Ansatz lässt sich erweitern: Die Domänenverantwortlichen haben Autorität über ihren Bereich der Organisation, über die Prozesse, die Applikationen, die Daten und die Weiterentwicklung ihrer Domäne, so beispielsweise auch in personeller Hinsicht.

Der Eigentümer einer Domäne hat somit per Dekret (Verantwortung der übergeordneten Domäne) die Kompetenz zur Gestaltung der Domäne. Mit dieser Kompetenz geht die Verantwortung einher, über Teams, Budgets für Betrieb und Weiterenwicklung, Priorisierung des Backlog.

Durch die Taxonomie der Domänen ergeben sich viele Möglichkeiten zur Gestaltung und Steuerung der Organisation:
Domänen können (vielleicht sogar: sollten) große Überlappungen mit der Organisationsstruktur haben, sind aber davon losgelöst. Dadurch lassen sich zwei wichtige Ziele der Unternehmenssteuerung verfolgen:

• Transparenz, wo die Organisation Ressourcen für ihren Betrieb verbraucht (z.B. OPEX)
• Gezielte Weiterentwicklung in strategisch zu stärkende Domänen (z.B. CAPEX)

Abhängigkeiten zwischen Domänen lassen sich darstellen – durch Schnittstellen, Services, Prozessdiagramme u.s.w.
Der Weg der Leistungserfüllung ist verfolgbar von den Domänen des Kerngeschäfts zu den support-domains und Domänen zur Unternehmenssteuerung. Jeder Bereich stellt seinen Mehrwert über Services und Zusammenarbeit mit anderen Domänen dar.

Domänen Modell

Als Definition einer Domäne für die Modellierung des gesamten Unternehmens wäre diese hier eine Möglichkeit:

Ein Verantwortungsbereich mit spezifischen Zielen, Anforderungen und Fähigkeiten, die von Menschen und IT-Systemen erfüllt werden. Die Domäne bietet Dienstleistungen entweder für Stakeholder außerhalb des Unternehmens (Kunden, Lieferanten, Regulierungsbehörden usw.) oder innerhalb (andere Domänen) an. Es spielt keine Rolle, ob diese Dienste als „geschäftlich“ oder „technisch“ gekennzeichnet sind. Verantwortungs- und Kontextgrenzen sind für eine Domäne klar definiert.

An die Domänen sind Ressourcen gebunden, mit denen die Organisation ihre Aufgaben erfüllt:

• Menschen: Die wichtigste Person für die Domäne ist die Eigentümerin. Sie bestimmt alle Aspekte des Betriebs und der Weiterentwicklung der Domäne (z.B. das domain backlog), sowie die Budgets dafür. Für alle Entscheidungen bezüglich Resourcen der Domäne ist die die Eigentümerin erste Eskalationsstufe. Natürlich ist auch der domain owner in die Organisationseinheiten des Unternehmens eingebettet und insofern weisungsgebunden.
  Die Mitarbeiter der Domäne sind Experten der einen oder anderen Form und können natürlich auch Teile davon verantworten (z.B. Applikationen). Alle gemeinsam sind verantwortlich für Weiterentwicklung und effizienten Betrieb ihrer Domäne.
• Know-How: Das wichtigstes Gut der Menschen ist ihre Fachwissen in ihrer Spezialisierung: Wissen über Prozesse, Assets, IT, Verknüpfungen zu anderen Domänen oder Interessenten außerhalb der Organisation.
• Geschäftsziele: Jede Domäne hat als Teil des Ganzen eine Aufgabe zu erfüllen. Diese Ziele werden beschrieben und wenn möglich durch Kennzahlen auch gemessen. Für die Weiterentwicklung wird die Strategie des Unternehmens von oben nach unten auf die Domänen heruntergebrochen.
• Assets: Die Güter der Organisation sind Domänen zugeordnet. Das können IT Applikationen, aber auch Immobilien, Fahrzeuge, Maschinen oder sonstige Betriebsmittel sein.
• Finanzen: Das Unternehmen steuert seine Domänen durch das Zuteilen von Budgets für Betrieb und Weiterentwicklung so wie die Bewertung seines Einkommens – entweder direkt von Kunden oder von anderen Domänen.
• Daten: Daten als spezielle Güter haben in den letzten Jahren stark an Bedeutung zugenommen. Die Verarbeitung und Speicherung von Daten gewinnt immer mehr Einfluss auf die Ertragssituation, bedeutet aber auch immer mehr Verantwortung für deren Besitzer, der Aufwand für Compliance stieg in den letzten Jahren und wird wohl weiter steigen.
  Die Qualität der Daten und deren Management ist eine wichtige Aufgabe der Domäne. Es muss der Domäne als Eigentümer der Enitäten der Strom und Persistierung ihrer Daten vollumfänglich bekannt sein.
• Services: Die Domänen erbringen Leistungen intern und extern. Diese Leistungen sollten gut dokumentiert sein. Wo es sinnvoll ist, werden diese mit SLO/SLA qualitativ und quantitativ erfasst.
• Projekte: Während kleinere, domänenlokale Anforderungen im Ermessen des domain owners geplant und im domain backlog abgearbeitet werden können, werden auch projektübergreifende Initiativen in einer Domäne beheimatet. Dies kann die Domäne mit dem größten Nutzen, oder die mit dem größten Änderungsbedarf für die Anforderung sein.
• Fähigkeiten: Die Business Capabilities können auch explizit im Domänenmodell verankert werden, wenn man domänenübergreifende Fähigkeiten, meist auf feingranularer Ebene, in verschiedenen Domänen (und IT Applikationen) dargestellt haben will. Beispielsweise, wo werden Rechnungen erstellt, oder wo werden Kundendaten erfasst.

Wann ist eine Domäne eine Domäne

Die Frage nach der Granularität der Domänen ist nicht systematisch zu beantworten. Der richtige Schnitt ist betriebswirtschaftliches Kunsthandwerk und damit bis zu einem gewissen Grade auch Geschmacksfrage. Nichtsdestotrotz gibt es Indizien, wann eine Domäne fruchtbare Wirksamkeit entfalten kann:

• Der fachliche Kontext der Domäne ist ad-hoc jedem klar und kann einfach formuliert und dokumentiert werden.
• Die Eigentümerschaft (business, IT) kann benannt werden und es formiert sich sofort Verantwortungsbewusstsein.
• Ein sich selbst bewusstes Team ist für die Domäne zuständig, in der fachlichen Sachbearbeitung oder in der IT Organisation.
• Es gibt Applikationen oder andere Assets, die eindeutig zur Domäne gehören.
• Es gibt Datenentitäten, die eindeutig zur Domäne gehören und deren Stammdaten der betreffende Kontext verantwortet.
• Es kann ein sinnvoller Arbeitsbestand (backlog) für Betrieb & Weiterentwicklung für die Domäne gebildet werden, der möglicherweise mehrere Applikationen überspannt.
• Es ist sinnvoll und positiv wirksam, ein Budget dediziert zu Betrieb & Weiterentwicklung der Domäne bereitzustellen. Durch die Transparanz kann eine strategische Steuerung des Bündels an betriebswirtschaftlichen Fähigkeiten der Domäne erfolgen.

Domains müssen nicht mit der Organisationsstruktur übereinstimmen, eine Überlappung macht allerdings vieles einfacher. Der Domänenschnitt berücksichtigt dabei den Kontext des Unternehmens als ganzes, seine Historie, die langfristige Marktentwicklung, erwartete Möglichkeiten der Technologie und so weiter.

Namensgebung

Dingen bedeutungsvolle, und auch haltbare, Namen zu geben ist immer eine große Herausforderung. Hier ist es besonders wichtig, da die Begriffe die Basis sind für eine effiziente Kommunikation, auch über Grenzen von Organisationseinheiten.
Einen Königsweg für „richtige“ Namen gibt es nicht, und – manchmal sogar emotional geführte – Diskussionen wenn es um die Namensgebung von Domänen geht, sind normal. Jedenfalls sollten die Namen aus der normalen Geschäftssprache stammen und für alle Teilnehmer der Domäne aussagekräftig sein. Wieselwörter sollte man vermeiden (-Management, -Services, -Daten, -Prozess), wobei dies auch keine feste Regel ist, sondern diese im Einzelfall durchaus Sinn stiften können¹.

Ansonsten sollte man den Verantwortlichen der Domäne nicht zu viele Vorschriften machen, wie sie ihren Bereich nennen mögen: Es kann die wichtigste Entität der Domäne sein („Rechnung“), oder ein Prozessname („Rechnungslegung“) oder auch zum Beispiel eine ganze Formulierung sein („Kundenprodukte in Rechnung stellen“). Wichtig ist, dass sich das domain team mit dem Namen und der dazugehörigen Beschreibung identifizieren kann.

Ziele des Domain Driven Enterprise

Das Bauen, Ausrollen und Aufrechterhalten eines Domänenmodells bedingt nennenswerten Aufwand. Deswegen muss diese Maßnahme auch effektive und effiziente Wirkung im Unternehmen entfalten. Nicht alle möglichen Ziele werden für alle Unternehmen gleich wichtig oder überhaupt relevant sein, entweder weil sie als nicht wirksam gesehen werden, oder ohnehin schon erreicht sind.

• Gemeinsame Sprache: Es ist eine unterschätzte Wirkung von DDD, Begriffe in IT und Fachbereichen gemeinsam zu definieren und ein gemeinsames Glossar aufzubauen. Viele Missverständnisse und Fehler in Software stammen aus ungenauen, nicht abgestimmten Begriffen.
  Im DDD Konzept gilt ein Glossar immer nur für eine Domäne. Durch die Systematik, die Business Capabilities in das Konzept bringen, sollte ein organisationsweites Glossar aufgestellt werden können. Begriffe können aber weiterhin domänenspezifisch sein (Klassiker: verschiedene Interpretationen von „Kunde“ in verschiedenen Fachdomänen); durch das Nebeneinanderstellen steigt aber die Transparenz, und Missverständnisse lassen sich nicht nur bei der Kommunikation zwischen Fachbereich und IT-Abteilungen vermeiden, sondern jeweils auch zwischen Domänen.
• Systematische Verantwortung: So gut wie alle Ressourcen im Unternehmen können in die Fachdomänen einsortiert werden. Dadurch ergibt sich eine „default-Verantwortung“, die der jeweilige domain owner innehält.
• Agileres Verhalten der gesamten Organisation. Durch einen von allen im Unternehmen verstandenen Raster lassen sich nicht-lokale Anforderungen schneller einordnen, Verantwortliche sind schneller gefunden, die Analysephase in domänenübergreifenden Projekten wird kürzer. Dabei hilft ein Enterprise Repository, wobei das keine komplexe Software sein muss, wichtig ist nur das für jeden im Unternehmen einfache Finden von Domänen und allen Ressourcen, Beschreibungen, Verantwortlichkeiten etc.
• Transparenter Einsatz von Budget: Jede Domäne bekommt, top-down, Finanzmittel zum Betrieb und zur inkrementellen Weiterentwicklung. Dabei ist ersichtlich, für welche Unternehmensfunktionen welche Mittel vorgesehen sind; Projektbudgets für strategische Weiterentwicklung können zielgerichtet auf den Bedarf und die zu entwickelten Geschäftsfelder abgestellt werden. Aber auch Einsparungen und Verkleinern von Fähigkeiten und das Verschieben in andere Bereiche ist transparenter möglich, wenn die Ressourcen in den Domänen eingeordnet sind.
• Kontrollierte Redundanzen beim Ressourceneinsatz. Wenn verschiedene Fachabteilungen Software mit sehr ähnlichen Fähigkeiten einsetzen, kann das zu ineffizientem Ressourceneinsatz führen. Wenn man die Fähigkeit in eine eigene Deomäne faktorisiert, werden diesbezügliche Redundanzen sichtbar – und können akzeptiert und verwaltet, oder ausgeräumt werden. Dies kann auch für andere Ressourcen außerhalb der IT funktionieren.
• Gegenseitiges Profitieren von Mitarbeitern in Fachbereichen und IT. Die Kolleginnen und Kollegen in den fachlichen und technischen Abteilungen genießen hohen Respekt für ihr jeweilige Fachwissen. Auch in der Literatur (siehe z.B. Evans²) wird als Idealfall dokumentiert, dass die IT Spezialisten endlich (z.B. durch das Prinzip ubiquitous language) das Fachpersonal „verstehen“. In der Praxis ist dennoch kein Mensch vor einer gewissen „Betriebsblindheit“ gefeit. Prozesse, Datenstrukturen, Möglichkeiten und Grenzen der Automatisierung – all das kann lang eingeschliffen in einem lokalen Maximum gefangen sein. Eine häufige Reaktion auf diese Sorge ist das Engagieren externer Berater. Aber warum nicht auch die Außensicht der IT Kollegen nutzen?
  Bei der Analyse und die damit verbundene speziellen Sicht auf die Fähigkeiten des Fachbereichs können durchaus neue Erkenntnisse gewonnen werden. Somit kann es fruchtbar sein, wenn der Fachbereich auch fachliches feedback der IT Mitarbeiter annimmt, und man nicht von absolutem Wissen, der Fachbereich weiss schon was er tut, starr ausgeht. Dabei ist natürlich klar, wer die Verantwortung und damit auch den Letztentscheid über die Fachlichkeit besitzt.
  Für den anderen Weg, aus dem Fachbereich in die IT, gilt natürlich das gleiche. Als IT Mitarbeiter soll man sich gerne überraschen lassen, wieviel know-how dazu auch in den Mitarbeitern des Fachbereichs vorhanden ist.
  Gemeinsame Sprache – bessere Kommunikation – besseres Verstehen – Möglichkeit zur gegenseitigen konstruktiven Kritik.
• Und nicht zuletzt Entrepreneurship: Intrinsische Motivation ist nicht nur ein Erfolgsfaktor für hippe start-ups. Wenn das dafür nötige „Enablement“ nicht nur eine Worthülse sein soll, müssen die Mitarbeiter mit der nötigen organisatorischen Kompetenz und einer gewissen Autarkie von oben ausgestattet werden, um sich ihre fachliche Kompetenz in der Domäne aufzubauen. Auch wenn das betriebswirtschaftlich nicht so gestaltet ist (kein Profit Center), so kann eine Domain als „kleine Firma in der Firma“ als Teil des Ganzen wesentlich zum Erfolg beitragen.

Abspann

Unternehmensführung ist eine Kunst, und mehr Werkzeuge machen es nicht unbedingt einfacher. Organisation, die einen klaren Fokus haben, und die ihre Organisationsstruktur ohnehin flexibel an ihre fachlichen Anforderungen anpassen, werden keine Probleme mit dem Abgleich ihrer IT Assets und mit unklaren Verantwortungen haben.
Derartige Ziele erreichen sie direkt – in so einem Fall wären Organisationseinheiten und Domänen deckungsgleich.

Organisationen mit interessanter Historie, deren IT Organisation in den letzten 20 Jahren stark gewachsen ist, nicht parallel mit dem Geschäft – dann kann ein solches Modell trotzdem die gewünschte Flexibilität ermöglichen.