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.
So how do we map business domains, technology services, engineering teams, communication patterns, dependencies as enterprise architects and integration domain architects?
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.
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
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
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
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
Alok Mishra 