In my last article, Why Most App Modernizations Fail, I made the case that organizations know they need to modernize but are lacking a framework that removes the ambiguity from the decision making. This article moves us from strategy to practice, walking through how organizations use business capability heatmaps and domain alignment to make deliberate, data-driven, and defensible modernization decisions that delivery business value at every step of the journey.
Breaking Down Silos Through Domain Alignment
Application modernization cannot happen in a silo. Legacy applications in many instances can be considered a bowl of spaghetti when pulling one noodle somehow breaks four in the process. By understanding domains and aligning technical teams to those domains, organizations create a cross-functional structure that ensures modernization efforts consider the impact on various departments and promote an integrated approach. This alignment also follows Conway’s Law [1] where organizations design systems that mirror their internal communication structures, turning an organizational reality into a deliberate design advantage.
Delivering the Value
To begin delivering value during application modernization, organizations must have an established business capability model with corresponding heatmap. In this article, I will not be describing how to establish the model, nor will I be describing how to create the needed heatmap. It is also assumed that a definition of business capability is not needed though one can reference the article Organizing Around Business Capabilities. This article will describe how using capabilities focuses strategic refactoring decision making on changes that increase value rather than simply rebuilding every application.
Precursors to a capabilities-driven application modernization
The first step is to recognize that not all business capabilities have the same significance. Business capabilities are stratified into three layers [2]
- Strategic – direction setting or typical executive focal points
- Core – customer facing or what an organization does to thrive in the marketplace
- Supporting – what the organization must have to function as a business
For those not as familiar with business architecture, a similar concept can be found with Martin Fowler [3]. He describes how to determine if IT is strategic or utility. Technology is strategic where it contributes or supports capabilities that differentiate the organization. As with Strategic and Core business capabilities, if the business value for the technology is determined strategic then that is the area one wants to be as good as possible.
The stratification of capabilities and Martin’s concept of IT being strategic or utility are keys to unlocking sound investments. An additional key is to establish a capability-driven organization that contains both technical and business operations into the capabilities. These keys will unlock the next steps in determining how to make sound economic application modernization investments. These steps include:
- Assess the value, performance, and risk of your capabilities using a capability heatmap
- Align domains to your capabilities
Asses the value, performance, and risk of your capabilities using a capability heatmap
Since many organizations fail with their application modernization efforts, using data to determine what areas of the organization they should focus on should be standard practice. Those who engage in a business capability assessment will have a clear advantage by having data that shows what the organization should focus on for improvements. In Strategy to Reality: Making the Impossible Possible for Business Architects, Change Makers and Strategy Execution Leaders, Whynde Kuehn [4] identifies the business capability assessment as offering ‘a data-based view of business performance, at an aggregate level.’
Assessing the value (strategic importance), performance (people, process, and technology), and risk (flexibility/suitability) of business capabilities is the basis of a capability heatmap. Creation of the heatmap should occur before any decisions around application modernization efforts are made.
Figure 1: Example Business Capability Heatmap
Align domains to your capabilities
A domain is the activity or business of the end user [3]. A simple explanation is a domain is equal to a business object which includes its behavior, state transitions, and data associated with an element of a business. It is a specific problem space that a software solution is meant to address. Examples of domains are Product, Market, Work Order, and Customer.
There are a few important distinctions between business capabilities and domains. Business capabilities are described at a higher, more abstract level, and they are non-redundant across the organization. Domains can be redundant across the organization. They participate in one or more bounded contexts that facilitate encapsulation of teams and systems from each other that distinguish the distinct meaning and rules inside and outside the area. For a domain the smaller the boundary the smaller the teams and the more modular the service architecture. Larger boundaries will result in larger teams and more complex or monolithic architecture. In other words, alignment of business capabilities and domains follows Conway’s Law [5] where organizations will design systems that mirror their own internal communication systems.
What happens when domains are redundant across the organization? Does it matter? The short answer is it depends. Redundancy in domains does not mean there should and will be redundancy in data models. Attempting to unify the redundancies breaks the core principle bounded context and will in effect drive accidental complexity and monolithic coupling. For example, ‘Customer’ can appear in both ‘billing’ and ‘shipping’, but has different attributes in each context (e.g. billing address does not always equal shipping address, etc.).
Eric Evans, in Domain-Driven Design: Tackling Complexity in the Heart of Software (2003) [3], explicitly warns against forcing a single unified model across contexts. Each bounded context owns its own ubiquitous language, meaning “Customer” in billing may carry attributes like payment history and credit status, while “Customer” in shipping cares only about address and delivery preferences. The behavior and attributes should differ because they serve different capabilities. The key is to ensure that the domain has a consistent meaning across all contexts in which it participates, and that when needed attributes from multiple contexts can be combined to fulfill a particular business need.
Sam Newman, in Building Microservices (2nd ed., 2021) [5], reinforces this by describing how shared models across service boundaries create tight coupling — the very problem that bounded contexts are designed to prevent. He recommends tolerating some data duplication across services rather than introducing shared libraries or databases that erode autonomy.
With that said, there are instances where a domain should have the same behavior and attributes across capabilities. Take for example ‘Product’ domain. It is undesirable for calculation of pricing within the Inventory domain to be different than the calculation of pricing in the e-commerce domain. This would lead not only to teams solving the same problem, perhaps leading to different outcomes but also to increased operational costs when resolving any issues and/or updating the calculations. This is the organizational mirror that Conway’s Law predicts: siloed teams produce siloed, inconsistent implementations of logically shared concepts.
In short, if the behavioral difference has no business justification and exists purely because two teams built the same thing independently; refactoring is warranted, but the target is not necessarily a shared service. Often the right move is to designate one context as authoritative (a published language or open host servicein Evans’ terminology) and have the other consume it through a clearly defined application programming interface (API), rather than collapsing both into one monolith.
When aligning business capabilities and domains, ensure the smallest possible bounded context per domain while also taking into consideration if the redundancy within the domains has a business justification or not is critical. Otherwise, a system that continues to perpetuate dependencies across the organization is created. If the language of the consumer varies significantly from the authoritative context, one can establish an anti-corruption layer to translate an external model into terms that are more meaningful within the consumer’s bounded context.
Pulling it Together
Nicholas Tune and Jean-Georges Perrin point out ‘To get buy-in from stakeholders and maximize return on investment, you must have a solid understanding of the business outcomes you aim to achieve and clearly articulate how investing in architecture modernization will move the business toward its strategic priorities’. [6]
To do this, leverage business capability and domain heatmap. At the most basic level, the tool visually identifies which capabilities are most critical to improve from a strategic level. The heatmap also indicates the impacts that the strategic decisions will have on the organization. Is the strategy to increase speed of innovation, operation costs, or scalability? Will the strategy impact multiple highly strategic capabilities that all have highly inflexible and are performing below average? What is the current technical debt? The executive will know that a higher level of investment will be needed to improve the capabilities and domains.
Conversely, the heatmap will also show areas that are already performing within the needed objectives and goals. The executive will know that investment in these areas is not wise as it is unnecessary to continually improve on a capability that is already performing at a high level.
Companies who may have a good understanding of their distinctive business capabilities fail to associate them with their domains. Ensuring the alignment between capabilities and domains and their associated technologies improves an organization’s awareness of where they are wasting money on non-strategic, overperforming or adequately performing capabilities. Ultimately this prevents the company from hemorrhaging money on unnecessary application modernization efforts.
This article was originally published in Architecture & Governance Magazine in May 2026.
References
[1] Conway, Melvin E., “How Do Committees Invent?” Datamation, 1968, https://www.melconway.com/Home/Committees_Paper.html. [2] Business Architecture Guild®, A Guide to the Business Architecture Body of Knowledge®, v 13.0 (BIZBOK® Guide), 2024. Part 2, Section 2.2 & Page 79 [3] Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2003. [4] Kuehn, Whynde. Strategy to Reality: Making the Impossible Possible for Business Architects, Change Makers and Strategy Execution Leaders. Morgan Jame Publishing, 2022 [5] Newman, Sam. Building Microservices: Designing Fine-Grained Systems. 2nd ed. Sebastopol, CA: O’Reilly Media, 2021. [6] Tune, Nick, and Jean-Georges Perrin. Architecture Modernization: Socio-Technical Alignment of Software, Strategy, and Structure. Manning Publications, 2024.
