Strategic DDD and Context Mapping for Architects

<div class="cs-rating pd-rating" id="pd_rating_holder_1819065_post_1917"></div> <p class="wp-block-paragraph">Conway’s law says the structure of our organisation guides how we build software and this holds specially true today as we build distributed software services rapidly and at scale. </p> <p class="wp-block-paragraph">So how do we map business domains, technology services, engineering teams, communication patterns, dependencies as enterprise architects and integration domain architects? </p> <figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/06/thegrowingchasm.jpg"><img src="https://alok-mishra.com/wp-content/uploads/2021/06/thegrowingchasm.jpg?w=1024&quot; alt="" class="wp-image-1944" /></a><figcaption>High tower architecture can sometimes be misaligned to project architecture. Project architecture can be silo’d due to time/budget needs. Engineering software as an organization therefore can become incoherent</figcaption></figure> <h2 class="wp-block-heading">The problem</h2> <p class="wp-block-paragraph"><strong>1. Growing disconnect between solution and enterprise architecture teams and models</strong></p> <p class="wp-block-paragraph">My main gripe has been around the work produced by the EA processes, the traceability they provide around business capabilities and digital services is a bit of a concern. There seems to be a disconnect between the “Solution Architecture” and “Enterprise Architecture” – while they may belong to an single team (e.g. architectural practice) they lack a common language and mapping techniques to pull together the tactical and strategic views</p> <p class="wp-block-paragraph"><strong>2. Too much focus on project centric thinking</strong></p> <p class="wp-block-paragraph">This lack of alignment between the strategic vision and tactical architecture could be because of tactical, <span style="text-decoration:underline;">project-centric thinking which</span> emphasise Minimal Viable Products (MVPs), short-term team and a general rush to deliver functionality vs long lived products.</p> <p class="wp-block-paragraph"><strong>3. Silo’d Product teams / Product teams not aligned to Capabilities</strong></p> <p class="wp-block-paragraph">Now, there have also been cases, in my experience, where product teams and architects <span style="text-decoration:underline;">have operated in their own silos leading</span> to a fragmented or non-existent view of the enterprise software model etc</p> <p class="wp-block-paragraph"><strong>4. The missing big-picture to steer the leadership team</strong></p> <p class="wp-block-paragraph">Regardless of the means, the lack of a common view of the enterprise, its contexts, its social constructs, services, dependencies etc leads to fog at the leadership level such that the overall technology starts to feel complex and alien from the top</p> <h2 class="wp-block-heading">Shaking it up with DDD</h2> <p class="wp-block-paragraph">One of the key emerging techniques to refresh architectural practices and produce top-level models with bottom-up and top-down techniques is Domain Driven Design (DDD) </p> <p class="wp-block-paragraph">Domain Driven Design (DDD) as pioneered by Eric Evans and Vernon Vaughn describes <strong>two key techniques – Tactical DDD and Strategic DDD</strong>. Tactical DDD is useful when building a solution and considering what services to build, what events and information to model. Strategic DDD is great at describing the bounded contexts and relationships between them using a technique called Context Mapping</p> <figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/06/ddd-at-a-high-level.jpg"><img src="https://alok-mishra.com/wp-content/uploads/2021/06/ddd-at-a-high-level.jpg?w=1024&quot; alt="" class="wp-image-1923" /></a></figure> <p class="wp-block-paragraph">DDD can help modernise Enterprise Architecture through better mapping of socio-technical relationships across various contexts in the enterprise, better top-down view of domains, bounded contexts, services, events and models through an application of both strategic and tactical DDD</p> <p class="wp-block-paragraph"><strong>Hypothesis 1</strong>: <em>Business architecture practice must apply strategic Domain Driven Design to continuously map the socio-technical landscape of the enterpri</em>se</p> <h2 class="wp-block-heading">How? </h2> <h2 class="wp-block-heading">Strategic DDD first …</h2> <p class="wp-block-paragraph">The Business Architecture process within EA in 2021 (modern world 🌎 ) should start with business SMEs doing domain storytelling or event storming sessions. For example, whether starting in a greenfield or brownfield enterprise – the EA should seek business endorsement and request them to invest time to come to Domain Storytelling sessions. In these sessions, they can describe the rich business interactions the actors are expected to have with the software systems (we would be building) in their context</p> <p class="wp-block-paragraph">The domain stories from business SMEs should capture key attributes such as the business context, actors, behaviours, model, transaction boundaries etc. The architecture team should document these stories (see https://www.wps.de/modeler/), version control them and run sessions across architecture practice to analyse and do domain decomposition seeking to understand the business domain, bounded contexts, interactions with other hidden contexts etc. </p> <figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/06/screen-shot-2021-06-22-at-7.48.12-pm.png"><img src="https://alok-mishra.com/wp-content/uploads/2021/06/screen-shot-2021-06-22-at-7.48.12-pm.png?w=1024&quot; alt="" class="wp-image-1929" /></a><figcaption>Domain Storytelling from https://domainstorytelling.org/</figcaption></figure&gt; <p class="wp-block-paragraph"><strong>Hypothesis 2</strong>:<em> Business Architecture practice can benefit from techniques such as Domain Storytelling to document business contexts</em>. <em>The business repository should contain domain stories</em></p> <p class="wp-block-paragraph">This process should lead to a repository of domain stories and context maps. The context map from the stories can then be laid out in a common and visible area of the enterprise in physical or virtual space (Miro works best) leading to highly collaborative discussion</p> <figure class="wp-block-image size-large"><img src="https://alok-mishra.com/wp-content/uploads/2021/06/screen-shot-2021-06-29-at-4.31.55-pm.png?w=1024&quot; alt="" class="wp-image-2027" /><figcaption>A context map from domain story analysis</figcaption></figure> <figure class="wp-block-image size-large is-resized"><a href="https://alok-mishra.com/wp-content/uploads/2021/06/screen-shot-2021-06-22-at-7.50.17-pm.png"><img src="https://alok-mishra.com/wp-content/uploads/2021/06/screen-shot-2021-06-22-at-7.50.17-pm.png?w=764&quot; alt="" class="wp-image-1931" width="783" height="453" /></a><figcaption>Context Mapping with Strategic DDD – my sample</figcaption></figure> <p class="wp-block-paragraph"><strong>Hypothesis 3</strong>: <em>Enterprise and Solution architecture teams must collaborate on context mapping exercise in common forums leading to a common picture of socio-technical relationship across the enterprise and its business contexts </em></p> <figure class="wp-block-image size-large"><img src="https://alok-mishra.com/wp-content/uploads/2022/03/distributed.jpeg?w=1024&quot; alt="" class="wp-image-2292" /><figcaption>Wall of context maps for entire organisation produces a view of business capabilities traceable to APIs</figcaption></figure> <p class="wp-block-paragraph"><strong><strong>Hypothesis </strong>4: </strong><em>The common socio-technical picture should be transparent and visible to the entire enterprise including business, architecture and engineering teams to see the same view of the software and relationship between the teams that build it</em><em style="font-weight:bold;"> </em></p> <h2 class="wp-block-heading">… then tactical DDD</h2> <p class="wp-block-paragraph">Following the strategic DDD work, the architecture practice can work to define the services and models. This can be done for current state or future state – that is, we can start defining what information model is managed by our domain services and how that relates to the overall picture </p> <p class="wp-block-paragraph">The tactical design aspect of DDD can be performed in a solution context while informing and aligning to the strategic architectural view. For example, if one of the core principles is to build business oriented, encapsulated domain services then the top-level view should capture this and the tactical DDD should update the picture throughout its journey</p> <figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/06/tactical-and-strategic-ddd.jpg"><img src="https://alok-mishra.com/wp-content/uploads/2021/06/tactical-and-strategic-ddd.jpg?w=1024&quot; alt="" class="wp-image-1937" /></a><figcaption>Tactical and Strategic DDD combined – A common picture of the enterprise services, events and encapsulated contexts</figcaption></figure> <p class="wp-block-paragraph"><strong><strong>Hypothesis </strong>5: </strong><em>The top-level view of the business domain services their interactions should also be mapped with a view that explicitly calls out the domain aggregates relevant to the contexts, domain events produced and consumed. This leads to a greater alignment between architecture and engineering </em></p> <h2 class="wp-block-heading">Recap</h2> <p class="wp-block-paragraph">In summary, I believe modern enterprise architecture can benefit from techniques such a Domain Driven Design (DDD). I believe these 5 things need to happen to achieve this outcome (unless I learn more and expand this post)</p> <p class="wp-block-paragraph"><strong>Hypothesis 1</strong>: <em>Business architecture practice must apply strategic Domain Driven Design to continuously map the socio-technical landscape of the enterpri</em>se</p> <p class="wp-block-paragraph"><strong>Hypothesis 2</strong>:<em> Business Architecture practice can benefit from techniques such as Domain Storytelling to document business contexts</em>.<em>The business repository must contain context maps and 1 high level enterprise-wide context map</em></p> <p class="wp-block-paragraph"><strong>Hypothesis 3</strong>: <em>Enterprise and Solution architecture teams must collaborate on context mapping exercise in common forums leading to a common picture of socio-technical relationship across the enterprise and its business contexts</em>. <em>The business repository must contain context maps and 1 high level enterprise-wide context map</em></p> <p class="wp-block-paragraph"><strong><strong>Hypothesis </strong>4: </strong><em>The common socio-technical picture should be transparent and visible to the entire enterprise including business, architecture and engineering teams to see the same view of the software and relationship between the teams that build it</em><em style="font-weight:bold;"> </em></p> <p class="wp-block-paragraph"><strong><strong>Hypothesis </strong>5: </strong><em>The top-level view of the business domain services their interactions should also be mapped with a view that explicitly calls out the domain aggregates relevant to the contexts, domain events produced and consumed. This leads to a greater alignment between architecture and engineering </em></p>