Capability Architecture

I’ve been using the phrase capability architecture for a while now, and I’m increasingly convinced it describes something more useful than another name for consulting.

Most organizations are pretty good at describing what they have.

• Teams.
• Processes.
• Technology.
• Skills.
• Systems.
• Strategies.

What seems harder is recognizing what those things might make possible when they actually work together.

That’s the space I’m interested in.

Capability architecture starts with a different question than “What system do we need?” or even “What’s our strategy?”

It asks:

What are we trying to become capable of doing?

Sometimes the answer is already visible but buried beneath organizational friction. Sometimes technology makes a new capability possible, but the surrounding human system hasn’t caught up. Sometimes the capability is there in a person or team, but the environment doesn’t allow it to become useful.

And sometimes we discover that what looked like a technology problem wasn’t really about technology at all.

I’ve been exploring this through identity, contextual computing, human-centered operations, and some decidedly practical experiments with tools that help people notice, remember, decide, and act.

The tools are interesting.

The capability they enable is more interesting.

That’s why “capability architect” has increasingly felt like a better description of what I do — and what I want to leave behind — than a conventional consulting label.

The work isn’t simply about implementing something new.

It’s about uncovering capability, arranging the conditions around it, and making it usable.

I’m still exploring exactly where this leads.

That seems appropriate.

A capability worth building should change what becomes possible next.