Case study
Mapping a life insurer's new business journey before rebuilding it
Guardian, a life insurer, wanted to get products to market faster, but tightly coupled software on a LISS-based system made that slower and more expensive. Across two discovery engagements in 2020–21 we used domain-driven design to map its new business journey, and delivered a project plan and a strawman architecture.
2020–21
What we built
- Architecture documentation the whole business can read
- Domain context map of bounded contexts
- Event-storming model of the new business journey
- Impact map linking work to goals
- User-story map and project plan
- Strawman architecture for a more flexible platform
The challenge
Guardian wanted technology to win it business and get life insurance products to market faster. Instead, technology was the constraint. The platform was built on a LISS-based system, many parts were tightly coupled in both process and technology, and so many changes had been made that the vendor's upgrade path no longer fitted, while a long-term vendor contract narrowed the options. The domain was complex, with many business rules and external services, and the software no longer matched how the business worked. The priority was a multi-benefit product, and an architecture flexible enough for what came after it.
What we did
- December 2020 — scoped a remote discovery of the business domain, drawing on event storming, value-stream mapping, Wardley mapping, domain context mapping and user-story mapping
- January 2021 — initial discovery sessions on the new business journey produced a project plan and the proposal for a second phase
- February 2021 — the New Business Journey discovery opened by rewriting Guardian's architecture documentation so the whole business could read it
- Domain context mapping, two days of event storming and input/output mapping built a shared model of the journey; impact mapping and user-story mapping then tied the work to business goals
- March 2021 — a technology investigation, then the project plan and a strawman architecture
What we built
Domain-driven design starts with the business rather than the database. Domain context mapping divides an organisation into areas that each have their own language, rules and data, which DDD calls bounded contexts, and shows how they depend on each other: who provides the wording, who approves the layout, who is only told after a change. Where one tightly coupled system has blurred those boundaries, the map shows where they should be.
Event storming puts business and technical stakeholders in one session to lay out everything that happens in a journey as events, in time order, so hand-offs, hidden rules and disagreements surface on the timeline rather than in production. Input/output mapping then tied Guardian's screens and data to those events, giving a conceptual model of the whole new business journey.
Impact mapping, which we taught Guardian's team before facilitating it, linked each piece of work to the business goal it served, and user-story mapping set out the journey as work in delivery order. A technology investigation looked at where off-the-shelf products could fit.
The result
Guardian came out of discovery with one shared picture of its new business journey, architecture documents that business and technical teams could both read, a project plan and a strawman architecture to build towards. It kept us on for consultancy afterwards, including an architecture review in January 2022.