I’m Called a Business Architect. But I Create Business Views, Not D1–D15 × P1–P6 Anatomy.

The Title Sounds Strong

I’m called a Business Architect.

That sounds like I define how the business works.

It sounds like I understand how strategy becomes process, how process becomes logic, how logic becomes components, how components become implementation, and how implementation becomes operations.

But what do I actually create?

Capability maps. Value streams. Process views. Journey maps. Operating model diagrams. Stakeholder maps. Business requirement views. Transformation roadmaps.

This is useful work. But useful work is not automatically architecture.

The Real Gap

Most Business Architecture work creates business views. It shows how work appears to move. It shows business capabilities. It shows value streams. It shows customer journeys. It shows department handoffs. It shows business terms in a cleaner language.

But it often does not define the actual anatomy of the business. It does not define how the business works across D1–D15 × P1–P6.

That is the real gap. A business view may explain the business. But anatomy defines how the business behaves.

What D1–D15 × P1–P6 Means

A real enterprise does not run through one diagram.

It runs through many departments (D1-D15), functions, systems, decisions, rules, people, and operations.

In an airline, for example, the enterprise may involve:

D1 Strategy, D2 Network Planning, D3 Schedule Planning, D4 Revenue Management, D5 Sales and Distribution, D6 Customer Experience, D7 Airport Operations, D8 Flight Operations, D9 Crew Planning, D10 Maintenance and Engineering, D11 Safety and Compliance, D12 Finance, D13 HR and Training, D14 IT and Data, D15 Partners and Support

Across each department, P1–P6 must be explicit.

P1: Strategy — direction and value outcomes to achieve.

P2: Process — sequence of activities required to realize the strategy.

P3: Systems / Logic — systems and sub-system logic that execute or enforce business flow across data, rules, functions, access, UI, timing, and interactions.

P4: Component Specifications — the parts that make those systems real: data, functions, rules, events, interfaces, UI, network, and other component specifications.

P5: Implementation Tasks — people and IT tasks that build, modify, configure, or deploy components.P6: Operations — business, service, and IT operations that run, monitor, maintain, and stabilize the service.

That is D1–D15 × P1–P6. That is 90 anatomical cells and thousands of relationships. If those 90 cells are not explicit, the enterprise may have business views. But it does not have explicit ICMG Enterprise Anatomy™.

Why Business Views Are Not Enough

A value stream may show:

book ticket, check in, board passenger, fly passenger, deliver baggage, resolve complaint.

A capability map may show:

customer management, flight operations, airport operations ,crew management, maintenance, revenue management, finance, IT.

A customer journey may show:

search, book, pay, check in, board, fly, arrive, claim baggage, seek support.

These diagrams are helpful. But they do not automatically define architecture.

They do not show how each department’s strategy, process, logic, components, implementation, and operations connect. They show business movement. They do not define anatomy.

Airline Example — Passenger Disruption

Take a passenger disruption. A flight is delayed.

The Business Architect may create a value stream:

notify passenger, rebook passenger, handle baggage, offer compensation, update crew, inform airport desk, manage customer support.

The diagram looks complete.

But the real airline anatomy is much deeper.

In D3 Schedule Planning, what is the recovery strategy when the delay affects aircraft rotation?

In D4 Revenue Management, how does rebooking affect fare class, seat inventory, upgrade logic, and revenue protection?

In D6 Customer Experience, what promise is made to the passenger?

In D7 Airport Operations, how are gates, counters, boarding queues, and ground staff adjusted?

In D8 Flight Operations, what aircraft movement decision is triggered?

In D9 Crew Planning, what duty-time constraint applies?

In D10 Maintenance and Engineering, what aircraft readiness condition must be checked?

In D11 Safety and Compliance, what regulatory condition applies?

In D12 Finance, how is compensation cost calculated, approved, and absorbed?

In D14 IT and Data, what systems enforce notification, rebooking, baggage update, refund, and service recovery logic?

If these are not defined across P1–P6, the value stream is not enough.

It may show disruption handling. But it does not define disruption anatomy.

Where the Business Architect Falls Short

The Business Architect often stops at representation.

The work shows:

what departments are involved,

what activities happen,

what capabilities exist,

what value stream is affected,

what journey is broken.

But it does not define:

which department owns which outcome, which decision sequence must occur, which system and sub-system logic governs the decision, which data - rules - events - UI actions -interfaces must exist, which implementation tasks are required, how operations will run the flow every day.

That is where the gap becomes visible. The diagram explains the business.

But it does not define how the business will behave.

What Happens in Execution

The value stream is approved. The journey map is published. The capability map is accepted. The business stakeholders agree.

Then execution begins.

Schedule Planning interprets recovery one way. Revenue Management protects inventory another way. Airport Operations manages passengers manually. Crew Planning applies duty rules separately. Finance sees compensation costs late. IT implements notification and rebooking based on partial assumptions. Customer Support receives angry passengers without full context.

Every department works. But the airline does not behave as one organism. That is the failure.

Financial Impact

This becomes expensive.

Passenger disruption creates manual rework. Rebooking costs increase. Compensation is applied inconsistently.

Airport teams spend more time resolving exceptions. Customer support volume increases. Crew and aircraft recovery decisions create additional delays.

Revenue leakage appears through poor seat inventory handling, missed upsell, incorrect refunds, and avoidable compensation.

The enterprise spends more on coordination. But the customer experience does not improve proportionately. The value stream looked aligned. The anatomy was not defined.

Why the Title Becomes Dangerous

The problem is not that I create business views. The problem is that the organization believes Business Architecture is covered because these views exist.

So no one asks:

Has D1–D15 been defined?

Has P1–P6 been defined across each department?

Do we know how strategy, process, logic, components, implementation, and operations connect?

Do we know how the airline behaves when disruption occurs?

If the answer is no, then Business Architecture has not been done. Only business representation has been done.

The Real Correction

The correction is not to stop creating capability maps, value streams, or journey maps. The correction is to stop treating them as architecture by default.

A Business Architect must move beyond business views.

The role must define how each department’s strategy, process, systems logic, component specifications, implementation tasks, and operations connect into one explicit anatomy.

That is where Business Architecture becomes real. That is where ICMG Enterprise Anatomy™ begins.

Diagnostic note

I’m called a Business Architect. But if I only create business views, I am not defining business anatomy.

If my work does not make D1–D15 × P1–P6 explicit, I am not architecting the business.

I am representing it. And representation is not architecture.

One Enterprise. One Anatomy.