Core vs Context

Invest in what differentiates you; standardise or outsource everything else.

Spend custom engineering on the core that differentiates you, and expect today's core to become tomorrow's context.

To an executive

Customers choose you for your core work. Put your best people and money there, and standardise or outsource the rest, because excelling at routine work wins no extra customers.

To an engineer

Classify each system as core or context. Invest engineering effort in core, and run context with standard products and minimal customisation. Reclassify as markets mature.

The idea

Geoffrey Moore distinguished core activities, which create competitive advantage and customer preference, from context, which is everything else: necessary, sometimes critical, but not what customers choose you for. Doing context brilliantly wins no extra customers; doing it badly can still lose them.

Moore's prescription is to concentrate your best people and money on the core, and to standardise, simplify or outsource the context, freeing resources to fund innovation. In Dealing with Darwin he adds a second axis, mission criticality, so context work can still be mission-critical and must be run well.

Over time, today's core becomes tomorrow's context as competitors catch up and the market commoditises it.

Why it works

Resources are finite and context grows. Left alone, context work absorbs more and more of an organisation's people, because it never stops needing attention.

Differentiation is where returns are. Investment in core work changes customers' choices; investment in context mostly keeps the lights on.

It gives a reason to let go. Naming something as context makes it legitimate to stop customising it and adopt a standard product.

Where it applies

Sourcing strategy, deciding where to build custom software and where to adopt SaaS or standards.
Capability maps and investment planning, marking which capabilities are core and should get the most funding.
Operating model choices, deciding what to keep in-house and what to outsource or share.
Domain-driven design, where the core domain gets the best people and the generic subdomains get off-the-shelf solutions.

How to apply

List the capabilities in scope, ideally from a capability map.
Ask whether customers choose you because of each one. If not, it is context.
Mark mission-critical context, which must be reliable but not custom.
Move context to standard products and partners, and redirect the freed people and budget to the core.
Review regularly, because core drifts into context as markets mature.

Example scenario

An insurer had more engineers maintaining its in-house document management system than building underwriting and pricing models. Document management was mission-critical, but no customer chose the insurer because of it.

The enterprise architect classed it as mission-critical context. The insurer moved documents to a SaaS product with strong service levels and reassigned most of the team to pricing, its actual differentiator.

Questions to ask

Does this capability differentiate us in customers' eyes?
Would doing it better than competitors actually win us business?
Has this quietly moved from core to context since we last looked?

When not to use it

When context is your product, as for a company that sells the very capability others treat as context.
When no adequate standard exists yet, so the "context" still has to be built or heavily tailored.

How it misleads you

Outsourcing so much context that integration and vendor management become the dominant cost. The label is a judgement, not a fact: parts of a context system can still differentiate, so revisit the split as the business changes.