- Obtaining Domain Knowledge Through Collaboration
- Domain-Driven Design Patterns and Practices
- Discovering Subdomains and Mapping Their Evolution Stages
- Build-or-Buy Decisions with Subdomain Types and Evolution Stages
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Build-or-Buy Decisions with Subdomain Types and Evolution Stages
Wardley Mapping emphasizes that each evolution stage has different characteristics. Different characteristics require using different methods for a given evolution stage. Wardley suggests building components in the genesis and custom-built stages in-house using agile methods, buying off-the-shelf products or using open-source solutions for components in the product + rental stage using lean methods, or outsourcing components in the commodity stage to utility suppliers.1 This doctrinal principle can be enriched with subdomain types from DDD.
DDD highlights that not all subdomains of a problem domain have equal strategic value—some contribute more significantly to the business’s differentiation than others. To reiterate, the differentiating core domains require high strategic investments and represent strong candidates for being built in-house, while the non-differentiating subdomains are well suited for utilizing existing solutions unless they demand a high level of specialization. Over time, the core domains can evolve from custom-built to the product stage and potentially become commodities.
Basing a “buy-versus-build” decision for a value-chain component solely on its location on the evolution axis risks overlooking its potential business-critical importance. For example, a cloud provider would not outsource its cloud services (or underlying data center) to another cloud provider simply because cloud services are generally commodities and should be outsourced. Instead, the cloud provider would rather build its cloud services in-house because they are core and business-critical to its business—even though the level of differentiation might have decreased as a utility service (see Figure 2.4). Outsourcing its core domain would limit the cloud provider’s differentiation opportunities and weaken its competitive advantage2. Conversely, when the organization is custom-building commodities that are not core to its business, it often leads to suboptimal investments of strategic efforts.
Off-the-shelf products and open-source software solutions may not necessarily meet all of the organization’s requirements out of the box, but they generally offer configuration and customization options. However, over-customizing off-the-shelf products beyond their core purpose can be costly and bears the risk of loss of standardization, reduced flexibility, upgrade limitations, performance issues, accidental complexity, and so on. Their original benefit of efficiency could decrease with over-customization. One alternative to excessive customization of an off-the-shelf product is to restrict its usage to the intended, designed-for use cases and to develop a custom solution for any functionality that is not provided by the off-the-shelf product. Thus, build-or-buy decisions are sometimes not either build or buy (i.e., binary), but rather build and buy.
BUILDING IN-HOUSE VERSUS CUSTOM-BUILT EVOLUTION STAGE
Sometimes, where to map components that an organization builds in-house can be a confusing choice. An intuitive approach is to map them to the custom-built evolution stage. This makes sense that if their market is still forming, users perceive them as emerging, they require exploration due to their novelty and lack of standardization, or they need continuous innovation to maintain differentiation.
However, if an organization’s core domain is perceived as well-defined, stable, and widespread, its components are typically mapped to the product or commodity evolution stage rather than being considered in the custom-built evolution stage, even though the organization chooses to build them in-house. In other words, just because a component is being built in-house, that does not mean it is automatically placed in the custom-built evolution stage. The evolution stages are about market maturity and user perception, rather than internal development decisions.
In addition to the mapped evolution stage and subdomain types, it can be helpful to highlight the currently applied method (build, buy, outsource) for each component in a Wardley Map using color-coding or patterns, as Figure 2.6 illustrates.
)
Figure 2.6 Visualizing build–buy–outsource decisions combined with evolution stages and subdomain types
Visualizing build–buy–outsource decisions in combination with the evolution stages and subdomain types helps teams critically assess whether their current investments in custom development are well spent. Key questions to ask are: Are we custom-building components that do not belong to our core domain? Does the level of specialization justify a custom solution for non-differentiating supporting subdomains?
){kind=link}