Executable Business Capabilities

I spent several years earlier in my career practicing business architecture and capability-based planning. I still believe the basic abstraction is one of the most useful ways to think about an enterprise: start with what the business must be able to do, not with the applications that happen to implement it today.

But I also lived with the weakness of the artifact. Capability maps were mostly static. They might be reviewed quarterly. A capability could be colored red, yellow or green, assigned a maturity score, connected to a transformation program and discussed at CIO level. Then engineering would ask the obvious question: what actually implements this capability?

Too often, the map did not really know.

The architecture-versus-engineering tension

The discipline intentionally defines a capability as what a business can do rather than how it does it. That separation is valuable because systems, organizations and processes change while the underlying business ability can remain stable. The Business Architecture Guild makes the same distinction and also recognizes capability instances: the places where a capability is realized in the real world by a business unit or other context.

The problem in practice was that our planning artifacts rarely stayed close enough to those realizations.

I could use a capability map to structure a transformation conversation. We could identify strategic capabilities, assess gaps, align programs and prioritize investment. Capability-based planning brought more discipline to CIO-level transformation than a portfolio of unrelated projects. But when the map was several steps removed from the systems, teams, metrics and dependencies that actually manifested a capability, the criticism from engineering was predictable: architecture is documenting; engineering is doing.

I never thought the answer was to abandon the capability abstraction. The answer was to move it closer to reality.

From maturity assertion to evidence

One of my earlier ideas behind MeridianCommand was modest: if someone says a capability is at maturity level four, they should have to attach evidence.

That evidence could be a KPI dashboard, operational metric, adoption report, service-level result, program deliverable or another artifact that supported the claim. I was not trying to invent an automated maturity engine. I wanted to make it harder for an enterprise view to become a collection of unsupported opinions.

The same view could show which programs were maturing a capability and which other capabilities those programs depended on. The goal was enterprise situational awareness for the CIO: not another application inventory, but a view of what the enterprise was becoming and what evidence supported that view.

At the time, this was still primarily a transformation-management problem. Agentic execution changes the requirement.

The capability map becomes part of the runtime

If an enterprise is going to contain Autonomous Business Units, specialist agents and dynamically discoverable tools, it needs a business-level way to describe what those actors can actually do.

A2A can solve an important technical problem. An agent can advertise its skills and another system can discover that agent. But an enterprise should not have to navigate itself as a flat registry of technical actors.

A Renewals ABU should be able to say, "I need Contract Analysis," rather than, "Find me agent contract-reader-v7." The business request is for a capability. Which system, agent, human service or other ABU currently realizes that capability is an implementation detail that may change.

A2A solves technical discovery. A living capability map solves enterprise discovery.

This is where my older business-architecture work and the agentic architecture began to merge.

The capability remains the stable abstraction. Underneath it, the enterprise maintains a current view of its realizations: applications, APIs, tools, ABUs, specialist agents and, where appropriate, human services. It also knows enough about the operating conditions around those realizations to use them responsibly.

That does not mean every capability becomes an API. It means the map starts carrying operational meaning.

What makes a capability living

A traditional capability entry might contain a name, definition, owner and maturity rating. A living capability needs to know more about its present state.

At minimum, it should be able to point to the systems and organizational units that currently manifest it. In an agentic enterprise, that expands to the ABUs, agents, tools and human services that can perform parts of the capability. It should know relevant dependencies, ownership, policies, permissions and authority constraints. It should be able to carry evidence about health or maturity rather than only a periodically assigned score.

The important word is current. A capability map that is accurate once a quarter is still a planning artifact. A capability model that changes as implementations, programs, policies and operating evidence change begins to become part of the enterprise's runtime representation.

I would not make every update automatically authoritative. Machines can discover that a new system or agent exists, that an API changed, or that a KPI moved. Those are useful signals. Business meaning, ownership and authority-sensitive changes still need governance. The goal is not to let agents rewrite the enterprise map without control. The goal is to stop pretending a manually refreshed diagram is sufficient for machine execution.

Cross-ABU execution should resolve through capabilities

Inside an ABU, the unit should normally use its own workers first. A Renewals ABU may have its own contract specialist, usage analyst and communication worker. Those actors share the office context and are already inside the unit's harness and authority boundary.

When the unit needs something it does not own, the enterprise boundary changes.

A small business may choose to put procurement, renewals and legal-adjacent work into one broad ABU. A Fortune 10 enterprise may deliberately separate those responsibilities into several ABUs because authority, regulation, ownership and scale demand it. In the second case, the Renewals ABU may need a capability such as Legal Review, Supplier Risk Assessment or Procurement Approval that belongs elsewhere.

My preference is that this cross-ABU request resolve through the capability map.

The requesting unit asks for the capability. The living map identifies which approved enterprise realization can currently provide it. That realization might be another ABU, a specialist agent, an existing application service or a human-led function. The requesting ABU should not need to know the topology underneath the capability.

This creates a useful separation of concerns:

The implementation can change without forcing every consumer to change. A human legal-review team today might become a Legal ABU tomorrow. A frontier model might be replaced by a smaller private model for a narrow task. A system may be retired. The business capability remains the stable contract.

Capability-based planning becomes closer to operations

This also changes the CIO transformation use case that originally drew me to capability-based planning.

A CIO should be able to look at a capability and see more than a maturity color. What currently realizes it? Which programs are changing it? Which other capabilities does it depend on? What evidence supports its maturity? Where is execution still heavily human? Which implementations are fragmented, duplicated, costly or constrained?

That does not eliminate architecture. It makes the architectural abstraction more useful to engineering and operations because there is a traceable path from the capability to the things that make it real.

MeridianCommand, in this model, is not the execution engine. It is the command view over the living enterprise: evidence of capability maturity, programs that are changing capabilities, dependencies between them, and eventually the machine and human realizations that are carrying the work.

Vyuham and its ABUs execute. MeridianCommand observes the shape and evolution of the enterprise. The living capability layer can serve both.

From descriptive capability to executable interface

I use the phrase executable capability carefully. A box on a capability map does not suddenly execute software. The capability becomes executable when it is represented richly enough that a runtime can resolve a legitimate business need to an approved current realization and carry the relevant operating constraints with that invocation.

That is a much higher bar than adding an agent URL to a capability repository.

It requires the capability model to stay connected to enterprise reality. It requires evidence and provenance. It requires implementations to be discoverable. It requires permissions and authority to matter. And it requires the requesting business unit to remain accountable for why it invoked the capability in the first place.

If we get that right, the capability map finally becomes what I wanted it to be years ago: not merely a picture used to discuss transformation, but a living model through which the enterprise can understand, change and increasingly operate itself.

The next question is what kind of organizational unit consumes those capabilities and owns an outcome end to end. That is the role of the Autonomous Business Unit.