Every App Needs Two Capabilities

Ask most portfolio teams what an application does and you get a list of business capabilities: it supports order management, pricing, customer service. That list is useful, and it is also why so many rationalization efforts stall. Business capabilities answer what an application serves. They do not answer what it is.

While building the AI-maintained knowledge base for my architecture practice, I settled on a rule that every application page now has to satisfy: at least one business capability, and exactly one primary technical capability. Two lenses, different jobs.

Lens one: business capabilities describe outcomes

A business capability model describes what the organization does — manage orders, manage suppliers, develop products — independent of who does it or with which system. Applications legitimately map to many of them. An ERP touches finance, procurement, inventory and manufacturing at once, and that is correct.

Because the mapping is many-to-many, this lens is excellent for impact and coverage questions: which capabilities have no supporting application, which have seven. It is poor at telling you whether two applications are the same kind of thing.

Lens two: technical capabilities describe what it is

The second lens is a reference model of technology classes: things like transactional business platforms, data and analytics, integration, collaboration and content, infrastructure and operations, security and identity. The branches will differ by organization. What matters is the property of the tree, not its labels.

The technical tree is mutually exclusive and collectively exhaustive. Every application classifies to exactly one primary branch.

An application may do things in several branches, and you can note that. But it gets one primary code, the one that answers "if we had to put this on one shelf, which shelf?" That single constraint is what makes the lens useful.

Why you need both

• Rationalization. Two applications that share business capabilities might be duplicates, or might be a system of record and the analytics layer on top of it. Two applications that share business capabilities and the same primary technical code are real consolidation candidates. The overlap on both lenses is the evidence.
• Acquisition reviews. When someone requests a new tool, declare its primary technical code first, then list the incumbents already in that branch. The net-new-versus-overlap question answers itself.
• Reference architecture. Patterns and standards index naturally by technical branch. An application's code points straight at the patterns it should conform to.
• Roadmaps. Business capabilities tell you where to invest. Technical classes tell you what you are actually buying and running.

Traps I hit

• Keywords in the wrong branch. An ERP whose description mentions "data" is still a transactional platform, not a data platform. Classify on what the system is for, not the words in its description.
• Letting new applications in with one lens. If a new application enters the inventory with only business capabilities, it starts life inside the gap you are trying to close. Require both at intake.
• Treating AI proposals as decisions. I let the AI propose technical codes from existing relationship evidence and sort them into high, medium and low confidence. A person ratifies the high-confidence tier in a batch; the rest get reviewed one at a time. The proposal is labeled as a proposal until someone signs it.

Copy this: the classification rule

## Two-lens capability rule
Every application page carries both lenses:

- business_capabilities: [..]   What it serves. Many per app is normal.
- technical_capability: <code>  What it is. Exactly ONE primary code from
                                the technical tree (mutually exclusive,
                                collectively exhaustive).

Rules:
- A new application enters the inventory with both lenses, or with an
  explicit gap flag. Never business-only.
- Classify on what the system is for, not keywords in its description.
- AI-proposed codes carry source: ai-proposed and a confidence (0-1).
  They are not authoritative until a person ratifies them.
- Consolidation candidates share business capabilities AND the same
  primary technical code. Record both as the evidence.

Start with one question

Pick ten applications. For each, write down the business capabilities it supports, then force yourself to choose one technical shelf. The arguments you have over the second step are the most useful architecture conversation you will have all quarter.