A core subdomain—usually called a core domain—is a business area with both high potential for differentiation and a complex software model. It is a candidate for strategic IT: the organization has reason to invest in capabilities that competitors cannot easily match. Complexity here means the effort to discover, design, build, and maintain the model, not simply the difficulty of running the software. section 10.2 section 10.5
A Core Domain Chart places subdomains by business differentiation and model complexity; core domains sit in its upper-right area. Supporting subdomains can help a core domain differentiate without offering much differentiation alone. Generic subdomains have little differentiation potential. These are investment judgments, not permanent labels: a core domain may become supporting as circumstances change. section 10.2 section 10.5
Finding the consequential bet
For a shared electric-scooter company, better scooter placement was judged a potential source of substantial differentiation: analysis suggested that improved locations could increase rides by 25–50%. Achieving it would require new data sources and a richer calculation engine. A compelling idea alone is not enough, however; the proposed robot tour guides had little supporting evidence despite their possible novelty. section 10.2.1
To make the classification useful:
- Bring domain, business, product, and technical experts together to place team-sized subdomains on a Core Domain Chart. Discuss both the evidence for differentiation and the work needed to evolve each model. section 10.2
- Mark possible investment directions, then compare opportunities across the portfolio. In an events-company modernization, this exposed two core domains with potential new differentiating features alongside a supporting subdomain needing design improvements. section 10.2.4
- Check whether priorities and staffing match the picture. Many simultaneous core domains may spread investment thinly; team size can reveal when supporting areas receive more investment than core ones. section 10.3.10
Use the classification to guide, not replace, decisions. Core domains should nearly always be built in-house, but their boundaries and priority deserve continuing scrutiny. Teams can identify them through bottom-up modeling as well as strategic discussion: one e-commerce organization identified discovery and ordering as core domains, then checked that their boundary kept coupling low. section 10.5 section 17.4
