Business Architecture and Organizational Design: Aligning the What and the Who

You don't transform an organization by looking only at processes, or only at the org chart. The two are inseparable. Business architecture describes what the organization does and why — its capabilities, its value streams; organizational design describes who does it and how teams are structured. When the two diverge, you create invisible friction that sabotages performance.

Yet in most companies these two disciplines live in separate worlds: business architecture with the architects, organizational design with HR and the executive team. Bringing them together is one of the most powerful — and most neglected — transformation levers. Here's how I do it.

Two disciplines, one reality

Business architecture and organizational design describe the same company from two complementary angles. The capability ('Manage Claims') says what we know how to do; the organizational unit ('Claims Division') says who is in charge of it. The problem arises when the correspondence between the two is implicit — which is to say, almost always.

Aligning the two means making that correspondence explicit. It's the condition for transformation to act on the right object: you don't reorganize to shuffle org-chart boxes, you reorganize to better carry the capabilities that create value.

The capability × organization matrix

In the field, my central tool is the capability × organization matrix. Rows are level-2 business capabilities; columns are divisions and departments. At each intersection, you indicate who carries the capability and in what role (owner, contributor).

• Filled cells show who owns what.
• Empty cells reveal orphan capabilities that nobody truly owns.
• Cells with multiple owners reveal latent responsibility conflicts.

It's a simple but devastatingly effective tool: in a single view, it makes visible dysfunctions that months of meetings had failed to formalize.

Gray zones and overlaps revealed

I've seen companies where capabilities were perfectly mapped, but nobody could say which team was responsible for which capability. Result: gray zones where decisions fall through the cracks, and overlaps where two divisions claim the same responsibility.

The capability × organization matrix turns these diffuse discomforts into precise findings. A critical capability with no clear owner becomes a named risk; a capability claimed by three divisions becomes a conflict to arbitrate. You move from feeling ('things stall between our departments') to fact ('this capability has no owner').

Analyzing the impact of reorganizations

The other decisive dimension is the impact of reorganizations on architecture. When a company merges two divisions, you need to understand which capabilities are affected, which processes need redesigning, which applications become redundant. The org chart alone says nothing about any of this.

Business architecture provides this impact analysis. Using the capability × organization matrix, you simulate the reorganization on the capability side before decreeing it on the org-chart side: which capabilities change hands, which end up orphaned, which get duplicated. That's what distinguishes a steered reorganization from a mere game of musical chairs.

Involving HR: linking capabilities and skills

My most consistent advice: involve HR in the business architecture effort from the start. It's not natural — architects talk about capabilities, HR talks about competencies, roles, and job descriptions. The two vocabularies rarely meet.

Yet when you connect capability and competency, you get a complete, forward-looking picture: which skills to develop, recruit, or train to strengthen tomorrow's strategic capabilities? The capability becomes the common language between strategy, organization, and talent management — a bridge few companies know how to build.

What I take from the field

Business architecture and organizational design are two sides of the same coin: the what and the who. Aligning them via the capability × organization matrix turns invisible friction into explicit decisions, and gives reorganization the compass it almost always lacks.

The reflex to adopt is simple: before any reorganization, ask which capabilities it serves better. If the answer isn't clear, it's not a transformation, it's an office move.