Prevent Million-Dollar Disasters and Lost Years by taking a Domain-First Approach
Over the past five years, we’ve explored the relationship between Domain-Driven Design (DDD) at a strategic level and tactical design patterns like Clean or Hexagonal Architecture designing future state architectures for our clients.
We’ve accumulated many valuable anecdotes that we plan to publish in due time, but it is essential to start this entire narrative by highlighting one of the biggest mistakes we see organizations make as they begin their architecture modernization journeys and how you can avoid this costly pitfall.
Replacing Old Tech with New Tech: A Risky Assumption
When most organizations start architecture modernization projects, the conventional approach prioritizes replacing old tech with new tech — replacing outdated architectures with modern architectures. The primary focus from Day 1 of these ‘tech-first modernizations’ is selecting the right new tech and re-architecting the business domains around this new tech.
This means a big and expensive IT modernization project, but unfortunately things don’t always go according to plan. A study published in Harvard Business Review highlights the True IT Pitfall:
"When we broke down the projects’ cost overruns, what we found surprised us. The average overrun was 27%—but that figure masks a far more alarming one. Graphing the projects’ budget overruns reveals a “fat tail”—a large number of gigantic overages. Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%. This highlights the true pitfall of IT change initiatives: It’s not that they’re particularly prone to high cost overruns on average, as management consultants and academic studies have previously suggested. It’s that an unusually large proportion of them incur massive overages—that is, there are a disproportionate number of black swans."
Leaders in organizations that run these tech-first modernizations, in our experience, often treat understanding the business domains as a secondary concern. They are more focused on the technology selection and exciting new capabilities, falsely believing business nuances and edge cases can be dealt with in implementation. When these nuances come to light much later during implementation, cost and schedule overruns like HBR highlights follow suit.
Figure 1 illustrates this disconnect:
In our experience, this is one of the most critical mistakes organizations make right from the start and a big contributor to tech-first modernization failures. Instead of framing the modernization project by what they are trying to achieve with the new tech (e.g., desired outcomes for customers and employees), they instead focus on the selection and adoption of the new tech as the desired outcome itself.
When we work with clients, we try to help them learn that at the start of modernization projects, it’s not about AWS or Azure or on-premise. It’s not about Kubernetes or Docker or Serverless. It’s not about Java, C# or Python. It’s not about Hexagonal or Event-Driven architectures.
Do these things matter as part of future state architecture? Absolutely!
Should they be the primary focus of your architecture modernization effort from the outset? Absolutely not!
Tech-First Modernizations: A Vicious Cycle
We often see a pattern with modernization that repeats itself every decade or so, as seen in Figure 2.
Perhaps you’ve seen it too:
- Legacy System Limitations
Tech debt has built up over decades for the core systems that run an organization. What once was a competitive advantage is now holding the organization back. The Business and IT Leaders agree something needs to be done about the architecture. It needs to be modernized. - The Allure of Modern Solutions
The Leaders think that “NewTech” (Cloud, Low Code, CRM Platform, AI, Microservices, etc.) is the answer. From the outset, modernizing the architecture is framed around adopting NewTech. - The Rush to Modern Solutions
A modernization team is created and jumps right into thinking about NewTech’s capabilities and how the organization can re-architect its services and processes to bring NewTech’s capabilities to life. People get excited about what’s possible with NewTech. - The Risk of Early Commitment to Technology Choices
The organization locks in early on key technology selections to drive the architecture forward. With NewTech chosen, roadshows are organized and licenses are purchased. Everyone’s committed to NewTech and modernization. - Implementation Challenges and Compromises
Many months (or years) later, during implementation, surprises are discovered in the domain logic that are expensive and time-consuming to fix in NewTech. It turns out business model nuances and real-world edge cases did not come to light earlier and now they are impacting NewTech’s architecture in unexpected ways. More tech debt is created. Delivery schedules slip, teams work overtime, and compromises are made to make it work. “New Tech” is shoved into production. - The Cycle Continues
Teams eventually adapt to the compromises made to implement NewTech and Leaders move onto other roles. As the business’s needs and competitive landscape changes over time in ways NewTech’s architecture did not anticipate, more cracks are created requiring more patches to make NewTech work for the real-world. More tech debt is created and after a decade NewTech becomes OldTech and the cycle repeats itself again.
Sound familiar?
This is not to say that business domains are not considered along this journey, but in our experience, they are almost always a secondary consideration to the primary focus of new technology selection and adoption.
What if there was a way to avoid this expensive cycle? What if there was a way to create an architecture that wasn’t dependent on tech selection and locking in early?
It turns out there is a way to do this differently, but it requires a different mindset when starting your architecture modernization projects.
Domain-Driven Design: The Strategic Alternative
While a tech-first approach sounds logical on the surface, it actually sets up teams and organizations to learn expensive lessons during implementation that could have been avoided in the first place.
When we work with clients, the one of the most vital lessons we try to teach them is summarized by my colleague, Jordan:
”Domain logic first, everything else second”
Meaning, when you start designing a modern architecture, if you understand the fundamentals of your organization’s domains — things like their people and processes, their bounded contexts, how information flows, and how their domains model unique business concepts — there will be numerous new tech options to meet your needs. Some you may buy, others you may build, but multiple options exist if you begin with this step.
On the other hand, if you get the domain logic part wrong, then it may not matter what new tech you’ve chosen. You may forever encounter challenges when trying to adapt new tech or a new architecture to the unique needs, edge cases, and nuances of those domains. Even worse, by the time you find out, you’re knee-deep into implementation and turning the ship is really expensive, leading to schedule and cost overruns and your own black swam.
This is why we advocate for a Strategic DDD approach to architecture that first focuses on understanding your business domains before evaluating technology platforms, solutions and architectures.
Figure 3 illustrates this concept. This approach uncovers the bounded contexts in your organizations that are then used as the basis for new tech selection and solution architectures.
Domain Allergy: When Trendy Tech Overshadows Domain Learning
We’re not alone in our observations. Stephen Tilkov has an excellent GOTO conference presentation in which he coins a new term for what we often see in practice:
💡 Domain Allergy: preferring to explore cool technology to being bothered by learning domain concepts; a disease common among technology developers
Do your IT teams have domain allergies? I’m sure they do; it’s rampant in the IT industry. Tech-driven architecture modernization projects suffer from it, too. Starting with a Strategic DDD approach is one way to help your IT teams cure their domain allergies and embrace the domains as first-class citizens in the architecture.
How to Start with Strategic Domain-Driven Design
Based on our experience helping organizations take a strategic approach to architecture modernization, we’ve developed a recipe that is summarized in Figure 4.
- Start with Problem Framing - Start your modernization journey by aligning everyone on the real problem(s) you’re solving for, the people impacted by these problems, the desired outcomes, and any relevant constraints. Avoid solution talk about using new tech. We like a brief workshop using our Problem Framing Miro template so everyone’s grounded on problems first and what success looks like (hint: not adopting new tech).
- Understand How Value Flows - Next, talk with the people who understand how the business works and build a rapport with them. We combine small group interviews and big-picture Event Storming workshops for the key processes related to architecture we’re modernizing. Dig into the terms, logic, and nuances of the business domains. Look for frictions in the process and user experience that should be addressed during modernization. Use simple models to estimate the ROI benefits of modernization.
- Understand Systems and Dependencies - At the same time you’re learning about domains, understand the systems and how they integrate today. We use our C4 Model Miro template to create Context and Container diagrams for an accurate picture of in-scope systems. These don’t have to be dry documentation exercises! We organize collaborative workshops where everyone contributes their pieces of knowledge to build an accurate picture of how things work today. Then we share this picture so everyone’s grounded on the current state complexities.
- Dive into the Domains - As you learn about the domains, start building a common language and understanding between domain experts and IT about how the domain works. Identify the key entities and how they’re related to one another. We typically review existing data models and schema definitions to understand both how it works today and also frictions to be addressed in the future. Engage your entire team in this - not just analysts and architects! When our UX designers and engineers understand the domains and how work flows - they are better prepared to implement new tech in alignment with the people’s needs.
- Identify the Bounded Contexts - This is a critical first step in creating your future state architecture. Using the event storm and the knowledge you’ve acquired about domains and systems, identify a draft set of bounded contexts. We do this with our Bounded Context template in a workshop. Afterwards, we summarize how messages flow between contexts and what dependencies they have on one another. We often do five or more revisions in close consultation with the domain experts to explore different ways to draw the boundary lines. With the bounded contexts, we next strategically classify them to help drive future investment decisions that maximize ROI using our Core Domain Chart Miro template. This happens quickly — in a week or two — and exploring multiple options is part of the design process.
Why Technology Comes Next
Once you have a draft future state architecture aligned with your business domains, then focus on making sound design decisions and choosing smart technology options for implementation. This is the time to explore:
- Whether a Clean or Hexagonal Architecture best fits your needs
- Whether containers or Serverless is a better solution
- Whether to deploy in AWS or Azure, on-premise or a hybrid of both
- The merits of Data-Driven versus Event-Driven Architectures
- What programming languages and runtimes best support your needs (hint: you don’t have to pick the same language for all contexts!).
This is where the architecture moves from strategic to tactical, as summarized in Figure 5.
As you make this move, new focus areas come into view, as seen in Figure 6. You make design decisions and implement technology, learning and adjusting along the way. Engineering kicks in and the design decisions are made to achieve the desired levels of quality necessary.
By taking a domain-first approach to architecture modernization and working from strategic to tactical, we make technology selections after we have a solid understanding of the business domains. This puts us in a better position to make good design choices closer to implementation, while preserving a cohesive overall architecture. We can select a different messaging platform or choose a new database technology three months into implementation and it’s fine because our overall architecture is domain-driven.
In addition to de-risking the architecture, this approach also provides autonomy so that bounded contexts (and teams aligned to them) can make independent technology selections that are best needed to solve the challenges of their contexts. Teams can use API’s, Events and Messages to orchestrate business processes and user journeys, with a focus on high cohesion and low coupling. This only works when you take a Strategic DDD approach to architecture that starts with business domains and not technology selection.
De-Risk Your Modernization with Domain-First Strategy
It may sound counter-intuitive that technology selection and solution architecture should be a secondary concern when starting your architecture modernization project. But take it from us, focusing first on understanding the business domains - especially the nuances and edge cases - is a winning strategy to creating an integrated architecture that minimizes future tech debt and can avoid costly re-writes. It also gives you options for technology implementation and de-risks your project by not over-indexing on a specific technology (that may or may not work out in practice).
Ready to Avoid the Risks?
We help organizations start their architecture modernization projects with our Architecture Modernization Accelerator, designed to expedite the time it takes to achieve a domain-first approach. These accelerators, combined with our Domain-Driven Discovery process, ensure that “domain logic first; everything else second” is embedded into everything we do. Let’s chat about how we can help your organization.
About the Author
As the Chief Technology Officer at SingleStone, Ryan Shriver specializes in Architecture Modernization for Finance, Insurance, and Government clients, with a focus on Domain-Driven Design (DDD). He also teaches Human-Centered Design at VCU School of Arts, where he guide students in using Design Thinking and Agile methods to solve community problems. Additionally, Ryan co-created the Mobius Loop, an open-source decision-making tool that accelerates outcomes globally.