I’m Called a Business Architect. But My Outputs Serve the CIO, Not the Enterprise.
- Sunil Dutt Jha
- 2 days ago
- 5 min read
The Work Looks Enterprise-Facing
I’m called a Business Architect. My work looks enterprise-facing.
I create business capability maps. I create value streams. I create process views. I create customer journey maps. I create operating model diagrams. I create transformation roadmaps. I create business requirement views.
I support enterprise programs. This sounds like Business Architecture.
But who actually uses my outputs?
Very often, the primary consumer is the CIO organization.
The CIO uses my work to understand business needs. The technology team uses my work to plan systems. The portfolio team uses my work to prioritize programs. The IT team uses my work to map applications. The delivery team uses my work to shape implementation.
This is useful.
But if my outputs mainly serve the CIO, then I may not be defining the enterprise.
I may be translating the business for IT and not for CEO or business heads.
Where the Distortion Begins
The distortion begins when CIO-facing business views are called Business Architecture.
Because the diagrams contain business language, they appear enterprise-owned.
Because they describe customer journeys, they appear customer-facing.
Because they show capabilities, they appear strategic.
Because they support transformation, they appear architectural.
But if the main use of these outputs is to help IT plan, fund, rationalize, modernize, or implement systems, then the work is still largely serving the CIO agenda.
That does not make it wrong. But it makes it incomplete.
Business Architecture should not only help the CIO understand the business. It should help the enterprise define how it behaves.
The Airline Context
Take an airline.
A real airline does not behave through one CIO program.
It behaves through multiple departments and functions:
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 ICMG Enterprise Anatomy™.
If my outputs do not define this anatomy, then they may support the CIO. But they do not define how the airline behaves.
Passenger Disruption Example
Take a passenger disruption program.
The Business Architect creates a disruption view:
flight delayed, passenger notified, passenger rebooked, baggage updated, crew informed, airport desk alerted, compensation offered, support activated.
The CIO organization uses this view to plan system changes:
notification platform, mobile app updates, rebooking engine, baggage system integration, refund workflow, support case routing, data dashboard.
The output is useful to IT. But the real airline questions are broader.
How does Schedule Planning decide recovery priority?
How does Revenue Management protect fare class and inventory?
How does Airport Operations adjust gates, counters, queues, and passenger handling?How does Crew Planning apply duty-time constraints?
How does Maintenance confirm aircraft readiness?
How does Customer Experience define passenger promise?
How does Finance calculate compensation exposure?
How does Support receive complete passenger context?
How does IT/Data enforce the logic across systems?
If these are not defined across D1–D15 × P1–P6, the output serves IT implementation.
It does not define disruption anatomy.
What the CIO Gets
The CIO gets value.
The CIO can see which systems must change. The CIO can see which applications are involved. The CIO can see where integrations are needed. The CIO can plan budgets, vendors, timelines, and delivery teams. The CIO can align the portfolio.
That is helpful. But it is not enough.
Because the CIO does not only need system visibility. The CIO needs anatomical clarity.
Why does the notification not match airport reality?
Why does rebooking logic conflict with revenue protection?
Why does baggage information lag behind passenger recovery?
Why do refund rules differ across channels?
Why does customer support receive incomplete context?
Why does every disruption change require multiple systems and teams?
These questions cannot be answered by CIO-facing views alone. They require D1–D15 × P1–P6 anatomy.
What the Enterprise Does Not Get
The enterprise does not get one shared operating definition.
Revenue Management continues using its own inventory logic. Airport Operations continues using manual recovery methods.
Crew Planning continues applying duty rules separately. Finance continues seeing compensation after the fact.
Customer Experience continues defining promises that operations may not fulfil. Support continues handling escalations with incomplete context.
IT continues modifying workflows after issues appear. So the Business Architect’s output helps the CIO plan the program.
But the airline still behaves department by department. That is the problem.
The output serves IT transformation. It does not become the enterprise’s operating anatomy.
How the Role Gets Misread
Because my output supports the CIO, the organization assumes Business Architecture is working.
The CIO sees business language. The program sees alignment. The portfolio sees structure. The delivery team sees requirements. The vendor sees scope.
But the enterprise does not necessarily see behavior change.
The Business Architect becomes a bridge between business and IT. That sounds valuable. But a bridge is not anatomy. A bridge transfers information. Anatomy defines how the organism behaves.
Financial Impact
This becomes expensive.
The CIO funds systems, integrations, dashboards, workflows, and platforms. But disruption costs continue.
Rebooking errors continue. Compensation leakage continues. Passenger support volume continues. Manual airport handling continues.
Crew recovery delays continue.Refund and voucher exceptions continue. Revenue leakage continues through poor seat reuse and inconsistent recovery logic.
The airline spends more on technology. But the margin does not improve proportionately.
The reason is simple. The CIO-facing output helped IT move. It did not define how the enterprise should behave across D1–D15 × P1–P6.
So technology investment increases. But anatomical control does not.
Why the Title Becomes Dangerous
The problem is not that my outputs serve the CIO. The CIO is important.
The problem is that the organization believes Business Architecture is complete because the CIO can use my outputs.
So no one asks:
Do Revenue Management teams use this anatomy?
Do Airport Operations teams use this anatomy?
Do Crew Planning teams use this anatomy?
Does Finance use this anatomy?
Does Customer Experience use this anatomy?
Does Support use this anatomy?
Does IT enforce this anatomy?
Does the CEO see how the airline behaves across departments?
If the answer is no, then Business Architecture has not defined the enterprise. It has supported the CIO.
That is useful. But it is not enough.
The Real Correction
The correction is not to stop serving the CIO. The correction is to stop making the CIO the primary boundary of Business Architecture.
Business Architecture must serve the enterprise.
It must define how business outcomes, process sequences, system logic, component specifications, implementation tasks, and operations connect across D1–D15.
It must be used by departments.
It must guide systems.
It must inform operations.
It must expose financial impact.
It must help leadership understand how the enterprise behaves as one organism.
Only then does Business Architecture become ICMG Enterprise Anatomy™.
Diagnostic note
I’m called a Business Architect. But if my outputs mainly serve the CIO, I am not necessarily defining the enterprise.
I may be helping IT understand the business.
I may be helping CIO teams plan transformation.
I may be helping delivery teams interpret requirements.
But unless my work defines D1–D15 × P1–P6 anatomy, I am not architecting the business. I am creating CIO-facing business views.
And CIO-facing business views are not the same as enterprise anatomy.
One Enterprise. One Anatomy.
Comments