Legacy Architecture Modernisation With Strategic Domain-Driven Design
Most organisations go through an architecture modernisation effort at some point as their systems drift into a state of intolerable maintenance costs and they diverge too far from modern technological advances.
I’ve seen some organisations deliver hugely impressive modernisation programmes. A lot of modernisation efforts, though, are shallow and buzz-word driven or carried out by expensive consultancies with flashy Powerpoint decks.
Before jumping into either of those scenarios, have a look at what Strategic Domain-Driven Design can offer you. It’s got a selection of free tools you can use for defining your technology strategy, shaping your architectural boundaries, and organising your teams.
High-level Process Sections
Conceptually, there are three major sections to a modernisation process. What’s the business vision? What architecture will be optimal for enabling that business vision? How are we going to deliver the new architecture?
Within each section there are major deliverables that should be produced.
The diagram above presents the sections and deliverables as a sequential journey because this makes it easy to learn and follow. In reality, you might go through this process once in a sequential order, but you’ll be iterating on each step and jumping back-and-forth between steps after that.
The following caveats should always be kept in mind. I recommend that you don’t view your architecture modernisation as a waterfall project rather as a guideline for the direction you want to travel in with the expectation that your path will change multiple times on the way.
Tools and Techniques
There are plentiful tools and techniques available to you in your modernisation initiative. Below I have shown techniques largely from the Strategic DDD community.
Business Strategy Alignment
Software architecture is the significant technical decisions that have business consequences. This means a software architecture should be purposely designed for the most favourable business consequences. It also means that understanding the business model is a pre-requisite for designing a software architecture.
As a minimum you will need the current state and target state business model. The Business Model Canvas is a great starting point for having these conversations and capturing the key information.
You can use colour coding on the Business Model Canvas to represent current and future states.
For a multi-year architecture modernisation programme, it’s necessary to dig much deeper than the Business Model Canvas. I also recommend the Value Proposition Canvas for going deep into user needs and the Product Strategy Canvas for moving towards measurable business outcomes.
Breaking your business down into a series of components and understanding how they will evolve over time due to market pressures is also a must. Wardley Mapping is the goto tool here and it provides a direct foundation for mapping your IT portfolio (the components on a Wardley Map do not automatically imply boundaries in your software architecture).
Target Architecture Design
With a foundational understanding of the business strategy the target architecture design process can begin.
IT Portfolio Strategy
After Wardley Mapping your business ecosystem, I recommend mapping out your existing portfolio of IT services followed by how you will need to develop them to support the business strategy.
For this purpose, you can use Core Domain Charts. Start by adding all of your IT services (microservices, monoliths, frontends, etc) and classifying them according to their strategic priority. Show your investment in each service (e.g. the number of people working on it or full-time equivalent).
All of the visualisations in this article were created with Miro. Most of them were created with the Strategic DDD template.
Then create another chart showing your future state. On this one, accentuate key strategic choices:
- Outsourced services
- New services
- Experiments / Bets
- Your core platform services
- Services to be discontinued
You can also create a visualisation using arrows to show the movement from current to target, and on the arrows you can show how long you expect the transition to take.
Domain Architecture
There is no escaping the fact that if you want to design a modern software architecture optimised for your business vision, then it’s necessary to explore the business domain in detail. Big-picture EventStorming has proven to be a worthy de-facto standard for this purpose.
After collaboratively modelling your domain with EventStorming you can start grouping the domain events into possible boundaries. DDD calls the boundaries Bounded Contexts but you can think of them as microservices if you prefer.
Once you have identified possible boundaries it’s important to challenge those boundaries by applying real use cases from your domain. This is especially important for uncovering hidden coupling while it is easiest to remove the coupling. Domain Message Flow Modelling is one of the tools you can use here.
You can then use the Bounded Context Canvas to define the roles and responsibilities of each service with just enough up-front design.
Does it make sense to do IT Portfolio Strategy before domain modelling? You can do either first. IT portfolio follows closely from Wardley Mapping so can fit nicely into the same session. But then after domain modelling, your domain boundaries may change and you will need to revisit your IT portfolio. Basically, any order is fine because you’ll return to both activities for additional iterations anyway.
Platform Architecture
Your new architecture will need to be executed on infrastructure. And you need to decide what that platform will be — both the infrastructure technology (e.g. AWS Lambda) along with your technology choices (e.g. Java) and conventions (e.g. no shared databases).
DDD doesn’t have opinions about your platform architecture other than the generic “focus on your core domains and outsource the rest”. So I recommend you start with Thoughtworks’ Digital Platform Strategy Blueprint. Use it as a checkbox activity. For each component of the platform, describe your solution.
I recommend that you automate as much of your platform as realistically-possible and have excellent document for the rest. Treat your platform as a product and your developers as the users. I highly recommend using a developer portal like Spotify’s Backstage for this.
Technical Architecture
With your domain boundaries and digital platform established, the technical aspects of each bounded context can be specified and documented (e.g. integrating via HTTP, developed using C#).
The de-facto standard here is to use Simon Brown’s C4 architecture modelling toolkit. I always use System Context and Containers diagrams, but less so the components and almost never the classes view.
Michael Plöd’s quality storming is also a good option here for uncovering operational/non-functional requirements that can have an influence on your architectural decisions.
Organisational Architecture
How teams are organised around an architecture is fundamental to how rapidly you will be able to improve your products. Team organisation also impacts the types of innovation that can occur and the morale of your engineering organisation. You should consider organisational architecture equally as important as domain and technical concerns.
I recommend a combination of Strategic DDD and Team Topologies for designing your organisational architecture using Core Domain Charts as the base.
DDD Context Maps can also be used to visualise the relationship between teams and architecture, and also the relationships between teams themselves.
I would also highly recommend modelling your end-to-end value stream. This will help to clarify which decisions are made by a team and how handovers between teams will work. I use Team Flow EventStorming to do this collaboratively.
Architecture Roadmap Planning
At some point you’ll start thinking about how to deliver the architecture modernisation over a multi-year period.
There are a couple of aspects of planning which I think are essential to think about up-front: priorities and process. Priorities is about understanding the value of each part of the modernisation and focusing energy where the payback is greatest. Process is about creating an agreement about how people will work together to deliver the modernisation in the most effective way.
Starting planning doesn’t mean design is finished. Design is never actually finished and neither is planning. Once you have enough design to think about planning, then both activities can continue in parallel indefinitely.
Prioritisation
For prioritisation, you can use a modified Core Domain Chart which plots value of modernisation with cost of modernisation.
Typically you’ll modernise something simple first as a low risk starting point. Then you’ll go for the low hanging fruit. The last toothpaste in the tube will be left until the end. So then you have to decide on a mindset: do you want to be risk seeking and go for high value high effort items first, or lower value and lower effort?
In order to determine the effort you’ll need to visualise existing and target architectures. Context Maps, Message Flows, and C4 diagrams are good tools to start with. You can also Strategic DDD patterns like Bubble Contexts for migrating from current to target architecture.
Process
When delivering a modernisation programme, you need to constantly evaluate that what you are doing is having the expected impact. You also need to be scanning the environment for changes which require you to revise your target architecture. It is, therefore, necessary to decide on roles, responsibilities, ceremonies, and rituals.
Team Flow EventStorming is the process I would recommend here to design your architecture modernisation process. Think about activities that should occur on a daily, weekly, monthly, quarterly, and yearly basis. And explore negative scenarios — what’s the worst thing that could possibly happen during your modernisation? How would your process catch it and minimise the costs?
Conclusion
There is a huge checklist to consider when your organisation is commencing an architecture modernisation programme. The risk is substantial, but the rewards are also mighty. It is not uncommon for organisations to deliver software orders of magnitude more rapidly after architecture modernisation.
If you don’t want to risk your architecture modernisation with a naive, shallow approach, and you don’t want to hire expensive consultants either, build your own process using the Strategic DDD toolbox and some other tools to fill in the gaps.
