Verbesserung des bereichsbezogenen Designs durch kollaboratives Denken in Systemen

Domain-driven Design (DDD) hat sich in der Softwareentwicklung als eine Methode zur Lösung komplexer Domain-Probleme herauskristallisiert, indem die Implementierung mit einem sich entwickelnden Modell verbunden wird. Der Eckpfeiler von DDD liegt in der Betonung der Zusammenarbeit zwischen den Mitgliedern der Domäne.

Die Zusammenarbeit in der DDD geht jedoch über die reine Kommunikation hinaus. Sie ist ein Mittel, um die Komplexität der verschiedenen Organisationsebenen zu verstehen und zu bewältigen.

Während einer der DDD-Grundlagenschulungen, die wir anbieten, wurde von einem der Teilnehmer die Frage gestellt, warum Zusammenarbeit erforderlich ist, wenn DDD mit Softwaremodellierung zu tun hat.

Unsere Antwort war damals, dass, wenn Komplexität entsteht, der Kontext in Teile zerlegt werden muss, die die Komplexität, die eine Person aufnehmen und verarbeiten kann, verringern. Und danach müssen mehrere Elemente zu einem Ganzen zusammengefügt werden. Das Zusammensetzen der Teile erfordert Zusammenarbeit, um ein gemeinsames Verständnis davon zu schaffen, was der Zweck des Bereichs ist.

Nachdem ich mehr darüber nachgedacht hatte, wollte ich eine bessere Antwort als die gegebene Antwort. Deshalb habe ich beschlossen, darüber zu schreiben und es näher zu erläutern. In diesem Artikel geht es darum, das Thema Zusammenarbeit zu vertiefen, indem die kontextbezogenen Systeme und die Notwendigkeit, den Zweck hinter dem Kontext zu finden, herausgestellt werden.

Die Essenz der Zusammenarbeit

Das Ziel von Domain-Driven Design ist es, die Komplexität eines Kontexts auf die Ebene des Softwaredesigns zu übertragen. Bei der Zusammenarbeit im Rahmen von DDD geht es jedoch nicht nur um den Austausch von Informationen, sondern auch um die gemeinsame Schaffung von Wissen, das das komplexe Wesen der Domäne erfasst, die Umwandlung von Annahmen in Fakten und die Aufdeckung impliziter Informationen. Es geht darum, dass Menschen aus einem bestimmten Domänenkontext in einen kontinuierlichen Dialog treten, Annahmen in Frage stellen und das Domänenmodell weiterentwickeln, um sicherzustellen, dass es auf die Kernkomplexität des Unternehmens abgestimmt bleibt.

Aber was sind Systeme?

Obwohl dieser Text mit dem Bereich der Software beginnt, beziehen sich Systeme hier auf den Kontext, mit dem wir als Menschen verbunden sind. Systeme in diesem Kontext sind dazu da, einen bestimmten Bereich zu strukturieren und ihm Kohärenz zu verleihen. Gleichzeitig definieren menschliche Interaktionen die Protokolle und die operative Dynamik, die Prozesse, gegenseitiges Verständnis, kulturelle Normen, Vorschriften und ethische Standards des Geschäftsgebarens umfassen. Die größte Herausforderung besteht darin, dass Menschen die Realität mit Filtern aus ihrem Hintergrund sehen, die ihre Annahmen und Vorurteile prägen (z.B. Kultur, Ethnie, Geschlecht, Gesellschaft).

 

Wie können wir das Problem einer Gesellschaft oder eines organisatorischen Kontextes erklären, wenn wir selbst Teil davon sind?

Nach Barry Oshry ist ein System eine Reihe miteinander verbundener Elemente, die so organisiert sind, dass sie einen bestimmten Zweck oder eine bestimmte Funktion erfüllen. Die Unklarheit der Beziehungen und Abhängigkeiten kann jedoch zu "wicked problems" führen (böse Probleme sind durch viele miteinander verbundene Faktoren verstrickt, so dass sie schwer zu lösen sind. Außerdem können Sie die Auswirkungen der Lösung des Problems weder vorhersehen noch vorhersagen). Diese Elemente sind nicht isoliert, sondern ihre Beziehungen und Interaktionen erzeugen Muster, die das Verhalten und die Ergebnisse des Systems als Ganzes beeinflussen.

Systeme sind dynamisch und entwickeln sich. Sie zeigen oft komplexe Verhaltensweisen, die aus diesen Interaktionen hervorgehen. Die Art und Weise, wie das System funktioniert, und das, was die Menschen in diesem System denken und glauben, kann dazu führen, dass es in gewohnte Muster verfällt, die es entweder behindern oder dazu beitragen, dass es seine Aufgabe gut erfüllt. Auch die Bedingungen innerhalb desselben Systems können das Verhalten der Menschen beeinflussen, was manchmal zu Missverständnissen, Meinungsverschiedenheiten und Kämpfen um die Kontrolle führen kann.

Bei DDD ist das Erfassen der komplizierten Ebenen der Komplexität entscheidend für die Schaffung technisch robuster Systeme, die mit den strategischen Zielen des Unternehmens übereinstimmen. Sie müssen sich darüber im Klaren sein, dass diese Art der Forschung und des Verständnisses eine erhebliche geistige Anstrengung erfordert, die als kognitive Belastung bezeichnet wird. Unser Gehirn neigt von Natur aus dazu, Annahmen zu treffen und weiterzugehen, denn das Eintauchen in komplexe Sachverhalte verbraucht geistige Energie. Die eigentliche Herausforderung besteht darin, diese natürliche Tendenz zu überwinden und die kognitive Kluft zwischen den verschiedenen Ebenen der Komplexität zu überbrücken. Dies erfordert einen Rahmen, der zu einem gründlichen Verständnis anregt und die Zusammenarbeit fördert, um diese Komplexität effektiv zu navigieren und zu integrieren.

Wie kann die kognitive Kluft innerhalb des Teams verringert werden, um die Zusammenarbeit und das gemeinsame Verständnis zu verbessern?

Dazu möchte ich die Arbeit von Otto Scharmer untersuchen. Der Theory U-Prozess bietet einen Rahmen für das Verständnis und die Förderung von Veränderungen bei Einzelpersonen, Organisationen und sozialen Systemen. Er basiert auf der Prämisse, dass die Qualität der Ergebnisse eines jeden Systems von dem Bewusstsein abhängt, mit dem die Menschen in diesem System arbeiten.

Im Kontext von DDD kann Theory U Teams bei der gemeinsamen Erstellung von Domänenmodellen anleiten, die tief in der Realität des Unternehmens und seiner Komplexität verwurzelt sind, und einen Wechsel von der isolierten Entwicklung von Software hin zu einem kontinuierlichen, einfühlsamen Dialog mit den Mitgliedern der Domäne fördern, um ein gemeinsames Verständnis für eine effektive Domänenmodellierung zu schaffen.

Die Anwendung der U-Theorie von Otto Scharmer kann einen abstrakten Ansatz für die Zusammenarbeit bieten, indem sie einen Prozess des kollektiven Lernens und der Ko-Kreation skizziert, der Folgendes beinhaltet:

1. Mit-Initiieren: Einbindung von Interessengruppen, um die Komplexität des Bereichs zu verstehen.
2. Co-Sensing: Beobachten und Erleben der Domäne, um tiefe Einsichten zu gewinnen.
3. Gegenwärtig sein: Reflektieren und zulassen, dass ein tieferes Gefühl für den Zweck auftaucht.
4. Mitgestalten: Entwerfen und Prototyping von Lösungen, die die Herausforderungen des Bereichs angehen.
5. Ko-evolvierend: Implementieren Sie Lösungen und passen Sie sich gleichzeitig dem Feedback und den Veränderungen in der Domäne an.

Integration von Theorien in die Praxis

Die Integration der Erkenntnisse aus Theory U und Seeing Systems in das Domain-Driven Design erfordert eine Änderung der Denkweise: Software-Design wird nicht mehr als rein technisches Unterfangen betrachtet, sondern als ein zutiefst kollaborativer, systemischer Prozess. Change Agents übernehmen diese Frameworks in ihre DDD-Praktiken in organisatorischen Umgebungen. Sie verbessern die Abstimmung zwischen Softwaresystemen und Geschäftsstrategien, verbessern die Anpassungsfähigkeit an sich ändernde Marktbedingungen und schaffen eine engagiertere und innovativere Belegschaft.

Herausforderungen und Überlegungen

Während die theoretische Integration einen vielversprechenden Ausblick bietet, ist ihre praktische Umsetzung eine Herausforderung. Widerstände gegen Veränderungen, festgefahrene Organisationskulturen und die Komplexität der Theorien können erhebliche Hindernisse darstellen. Die Bewältigung dieser Herausforderungen erfordert einen durchdachten Ansatz, der maßgeschneiderte Schulungen, das Engagement der Führungskräfte und die Förderung einer Kultur des kontinuierlichen Lernens und der Anpassung umfasst.

Fazit

Die Zusammenarbeit bei Domain-Driven Design ist nicht nur ein Mittel zum Zweck, sondern ein wesentlicher Prozess, der es Teams ermöglicht, die Komplexität ihrer Domänen zu bewältigen und zu verstehen. Durch die Integration von Erkenntnissen aus der Theorie U, den fünf Disziplinen einer lernenden Organisation und dem Verständnis von Macht und Systemen können DDD-Praktiker ihre kollaborativen Praktiken verbessern, was zu aufschlussreicheren, anpassungsfähigeren und besser abgestimmten Domänenmodellen führt. Die Einbeziehung dieser Rahmenwerke verbessert die technischen Aspekte der DDD und fördert eine dynamischere, reaktionsfähigere und innovativere Organisationskultur.