Strategic DDD and Context Mapping for Microservice and Integration Enterprise Architects


Enterprise Architecture (EA) is starting to feel a bit stale

While I love the structure TOGAF ADM provides and the associated standard industry reference models for Capabilities models etc. but recent (3-4 years) experience with this practice has been disappointing

The Growing Chasm: EA and SA, Products vs Projects

The problem

1. Growing disconnect between solution and enterprise architecture teams and models

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

2. Too much focus on project centric thinking

This lack of alignment between the strategic vision and tactical architecture could be because of tactical, project-centric thinking which emphasise Minimal Viable Products (MVPs), short-term team and a general rush to deliver functionality vs long lived products.

3. Silo’d Product teams / Product teams not aligned to Capabilities

Now, there have also been cases, in my experience, where product teams and architects have operated in their own silos leading to a fragmented or non-existent view of the enterprise software model etc

4. The missing big-picture to steer the leadership team

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

Shaking it up with DDD

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)

Domain Driven Design (DDD) as pioneered by Eric Evans and Vernon Vaughn describes two key techniques – Tactical DDD and Strategic DDD. 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

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

Hypothesis 1: Business architecture practice must apply strategic Domain Driven Design to continuously map the socio-technical landscape of the enterprise

How?

Strategic DDD first …

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

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.

Domain Storytelling from https://domainstorytelling.org/

Hypothesis 2: Business Architecture practice can benefit from techniques such as Domain Storytelling to document business contexts. The business repository should contain domain stories

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

Context Mapping with Strategic DDD – See https://contextmapper.org/docs/examples/
Context Mapping with Strategic DDD – my sample

Hypothesis 3: 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

Big wall of context maps – Physical or Virtual

Hypothesis 4: 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

… then tactical DDD

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

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

Tactical and Strategic DDD combined – A common picture of the enterprise services, events and encapsulated contexts

Hypothesis 5: 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

Recap

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)

Hypothesis 1: Business architecture practice must apply strategic Domain Driven Design to continuously map the socio-technical landscape of the enterprise

Hypothesis 2: Business Architecture practice can benefit from techniques such as Domain Storytelling to document business contexts.The business repository must contain context maps and 1 high level enterprise-wide context map

Hypothesis 3: 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. The business repository must contain context maps and 1 high level enterprise-wide context map

Hypothesis 4: 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

Hypothesis 5: 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

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s