I’m Called a Business Architect. But My Work Still Sits Inside IT.
- Sunil Dutt Jha
- 3 hours ago
- 5 min read
The Title Sounds Business-Facing
I’m called a Business Architect.
That sounds like my work should define how the business operates.
It sounds like I should help sales, finance, operations, HR, customer experience, product, legal, procurement, risk, support, partners, and technology understand how their work connects.
It sounds like I should define how business strategy becomes process, how process becomes system logic, how system logic becomes components, how components become implementation, and how implementation becomes daily operations.
But in practice, where does my work sit?
Inside IT.
I attend IT transformation meetings. I support technology programs. I create capability maps for system modernization. I create value streams for CIO-led initiatives. I translate business requirements for delivery teams. I help technology teams understand business language.
This is useful work.
But useful work inside IT is not automatically business architecture.
Where the Distortion Begins
The distortion begins when business language is used inside IT and then called Business Architecture.
Because I use terms like capability, value stream, customer journey, operating model, process, and outcome, the work appears business-led.
But the funding comes from IT. The program governance sits with IT.
The audience is mostly CIO, CTO, program directors, product owners, solution architects, enterprise architects, delivery managers, vendors, and platform teams.
The business participates in workshops. But IT owns the motion. That is where the role starts shifting.
The title says Business Architect. The operating context says IT translator.
The Airline Context
Take an airline.
A real airline does not operate through one business view.
It operates through multiple departments and functions, such as:
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, we must understand P1–P6.
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 the minimum anatomy needed to understand how the airline behaves.
What I Actually Produce
In a customer disruption program, I may create a business view.
Flight delayed. Passenger notified. Passenger rebooked. Baggage updated. Compensation offered. Crew updated. Airport desk informed. Customer support activated.
This looks useful.
But if my work still sits inside IT, the view is usually created to help technology teams configure systems.
Notification system. Rebooking system. Baggage system. Refund system. Customer support system. Mobile app. Data integration. Reporting dashboard.
The work helps IT execute. But it may not define how the airline should behave across D1–D15. That is the gap.
What Is Not Being Defined
If this is truly business architecture, then the disruption anatomy must be defined across the airline.
In D3 Schedule Planning, what is the strategy when 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, then the work is not defining airline anatomy. It is creating a business-facing view for an IT program.
The CIO Still Gets Limited Value
Even the CIO does not get the full value expected from this role.
The CIO does not only need to know which systems must change. The CIO needs to know why systems behave inconsistently.
Why a passenger notification does not match airport desk reality.
Why rebooking logic conflicts with revenue protection.
Why refund rules differ across channels.
Why mobile app information does not match airport operations.
Why customer support receives incomplete context.
Why a small disruption change requires multiple teams, multiple systems, and multiple rounds of testing.
These are not only IT questions. They are anatomy questions.
An IT-contained Business Architect cannot fully answer them unless the D1–D15 × P1–P6 anatomy is explicit.
The CEO Gets Even Less
The CEO does not need another IT-supported business view. The CEO needs to know why the airline cannot behave as one organism during disruption.
Why passengers receive inconsistent information.
Why airport teams rely on workarounds.
Why compensation cost rises.
Why crew recovery and customer recovery are not synchronized.
Why digital channels make promises that operations cannot fulfill.
Why customer experience declines even after investment in systems.
These are enterprise questions. An IT-contained Business Architect may help explain them.
But explanation is not architecture. The work must define the anatomy that makes consistent behavior possible.
What Happens in Execution
The IT program moves forward.
Systems are configured. Interfaces are built. Dashboards are created. Notifications are automated. Workflows are tested. Reports are published.
But the airline still fragments during disruption.
Schedule Planning interprets recovery one way. Revenue Management protects inventory another way. Airport Operations handles passengers manually. Crew Planning applies duty rules separately. Finance sees compensation costs late. Customer Support receives angry passengers without complete context. IT keeps adjusting workflows after issues appear.
Every team works. But the airline does not behave as one anatomy.
Financial Impact
This becomes expensive. Disruption handling remains manual.
Passenger rebooking creates revenue leakage. Compensation is applied inconsistently. Airport teams spend more time resolving exceptions. Customer support volume increases. Crew and aircraft recovery decisions create additional delays. Refund and voucher logic require repeated correction. IT keeps funding change requests after deployment.
The airline spends more on systems, integrations, dashboards, workflow changes, testing, and support.
But disruption cost does not reduce proportionately. Customer experience does not improve consistently.
Margin is absorbed by rework, compensation, lost revenue, operational delay, and support escalation.
The IT program looks active. The airline anatomy remains undefined.
Why the Title Becomes Dangerous
The problem is not that my work sits inside IT. IT is essential.
The problem is that the organization believes Business Architecture is being done because I create business views inside IT programs.
So no one asks the harder questions:
Has D1–D15 been defined?
Has P1–P6 been defined across each department?
Do we know how strategy, process, systems 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 IT-facing business translation has been done.
The Real Correction
The correction is not to remove Business Architects from IT programs. The correction is to stop limiting their work to IT programs.
If I am called a Business Architect, my work must define how the business behaves across departments.
Not only how IT should implement business requirements.
The role must move from business representation for IT delivery to explicit ICMG Enterprise Anatomy™ across D1–D15 × P1–P6.
Only then does the work become architecture.
Diagnostic Note
I’m called a Business Architect. But if my work is scoped by IT, funded by IT, consumed by IT, and mainly used to support IT execution, then my work still sits inside IT.
I may be creating useful business views.
I may be helping technology teams understand the business.
I may be supporting CIO-led transformation.
But unless I define D1–D15 × P1–P6 anatomy, I am not architecting the business.
I am translating it for IT.
One Enterprise. One Anatomy.