At GCC, Architecture Became Coding. At HQ, Architecture Became IT Inventory. Neither Is Architecture.

The Split We Created

In many large organizations, architecture has split into two incomplete roles.

At the GCC or offshore center, architects are called Solution Architects, Technical Architects, Cloud Architects, or Platform Architects. But much of their work is coding, service design, API design, deployment design, and platform implementation.

At headquarters, architects are called Enterprise Architects. But much of their work is IT governance, portfolio tracking, architecture review boards, technology standards, application inventory, and compliance checkpoints.

One side is deep inside construction. The other side is managing the construction register. Both are useful. But both are incomplete. Neither side is defining the actual architecture of the project.

What GCC Architects Are Actually Doing

At the GCC, the architect designs microservices, defines APIs, reviews code patterns, guides Kubernetes deployment, defines integration models, and supports delivery teams.

This sits largely in

P5: Implementation Tasks — the people and IT tasks that build, modify, configure, or deploy components. Some of it also touches

P6: Operations, where systems are run, monitored, scaled, and maintained.

This work is essential. But it does not automatically define the project. It defines how the system will be built.

What HQ Architects Are Actually Doing

At headquarters, the person called Enterprise Architect is not defining the enterprise.

He is operating inside IT.

He reviews JIRA boards. He attends governance meetings. He tracks delivery progress. He maintains IT inventory. He rationalizes applications He lists applications, classifies them, groups them, tracks usage, identifies overlaps, and recommends consolidation.

This is real work.

But structurally, this is inventory and classification inside IT. It does not define how the enterprise works.

The Illusion of Scope

Because the HQ architect sees applications, tools, IT project delivery pipelines, technology teams, vendors, cloud platforms, and project status, he begins to believe this is the enterprise.

1. But sales does not come to him for answers.

2. Customer experience does not depend on his models.

3. HR does not align workforce decisions based on his work.

4. Engineering does not use his outputs to define product behavior.

5. Project delivery teams do not change execution based on his views.

6. Finance does not use his structure to understand cost or value.

7. Operations does not depend on his work to improve reliability.

8. Marketing, legal, procurement, risk, and support operate independently of what he produces.

So the real assumption becomes:

Enterprise = IT

Everything else becomes secondary. That is where the distortion begins.

Why This Is Not Architecture

The issue is not that IT inventory is useless. The issue is that IT inventory is being called Enterprise Architecture.

The HQ architect produces lists, labels, classifications, inventories, rationalization views, governance reports, and application maps.

But the enterprise needs something else. It needs defined outcomes. It needs cross-functional flows. It needs system interaction logic. It needs decision traceability. It needs timing logic. It needs structural component clarity.

The gap is not effort. The gap is scope.

What the CIO Actually Needs

Even the CIO does not get the value expected from this role.

The CIO is not only asking:

1. What tools do we have?

2. Which systems can be removed?

3. Which applications overlap?

The CIO is asking:

1. Why do systems behave inconsistently?

2. Why do small changes take weeks?

3. Where will dependencies break?

4. Why do costs continue to rise despite governance?

5. Why do delivery outcomes vary across teams?

These are structural questions. Inventory does not answer them.

What the CEO Actually Needs

The CEO does not need another IT view. The CEO is asking why sales commitments do not translate into delivery. Why customer journeys break across channels. Why operations rely on workarounds.

Why finance sees cost growth without matching value. Why HR capability plans do not match execution needs. Why transformation programs take longer than expected. These are enterprise questions. An IT-only view cannot answer them.

The Missing Middle

The real gap is between these two roles. GCC architects are doing P5. HQ architects are doing IT governance around P6.

But P1–P4 of the project are still not explicit.

P1: Strategy means the direction and value outcomes the project must achieve.

P2: Process means the sequence of activities and decisions required to realize that strategy.

P3: Systems / Logic means the systems and sub-system logic that execute or enforce the business flow — data logic, rule logic, function logic, network logic, access/channel logic, UI logic, and timing logic.

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

Without P1–P4, the project has no explicit anatomy.

It only has delivery activity at one end and governance activity at the other.

Bank Lending Example

Take a bank lending project.

At the GCC, architects split the lending system into microservices.

Eligibility service. Risk scoring service. Pricing service. Document verification service. Approval service. Disbursement service. Collections service.

At HQ, Enterprise Architects review the solution deck, check compliance with technology standards, update application inventory, review integration dependencies, and approve the design through governance.

Both sides appear active. But the real lending decision is still not defined.

1. What outcome must the lending project achieve?

2. What sequence should the lending decision follow from application intake to eligibility, risk scoring, pricing, approval, documentation, disbursement, servicing, and collections?

3. How should eligibility logic interact with risk scoring?

4. How should risk scoring influence pricing?

5. How should policy exceptions affect approval?

6. How should documentation status control disbursement?

7. How should regulatory traceability be enforced?

If these are not explicitly defined, the GCC builds services with partial assumptions, and HQ governs the project without seeing the missing anatomy.

How Both Sides Become Wrong

1. The GCC side becomes wrong when it says:

We designed the services, so we designed the architecture.

No. That is implementation details.

2. The HQ side becomes wrong when it says: we reviewed the system, mapped it to standards, updated the inventory, and approved the governance checkpoint, so architecture is covered.

No. That is IT governance.

One side mistakes construction for architecture. The other side mistakes IT inventory for architecture. Both miss the same thing. The actual project anatomy.

What Happens in the Project

The project moves forward. Code gets written. APIs are built. Systems are deployed. Governance reviews are completed. Inventory is updated. Dashboards are green.

1. But the lending logic remains fragmented. Eligibility behaves one way in one channel and differently in another.

2. Risk scoring qualifies a borrower, but pricing gives the wrong offer.

3. Approval logic does not properly account for policy exceptions.

4. Disbursement starts waiting on documentation conditions that were never explicitly connected.

Every service works. But the lending decision does not work cleanly.

Financial Impact

This becomes expensive. Every change requires rediscovery. Impact analysis depends on senior people. Testing expands across services. Rework increases. Manual exceptions continue.

Business teams lose time reconciling system behavior. The bank spends more on coordination, more on change, more on defect correction, more on governance meetings, and more on delivery capacity.

At the same time, revenue leakage appears through missed offers, incorrect pricing, delayed approvals, and lost lending opportunities.

Margins reduce because exceptions, discounts, manual handling, and rework absorb value. The project becomes more expensive without becoming more precise.

What Headquarters Eventually Sees

Headquarters sees both sides working. The GCC is busy building. The HQ architecture team is busy governing.

But the same issues keep appearing. Costs rise. Change slows. Business complains. Decision behavior remains inconsistent.

So headquarters adjusts. They use GCC for delivery. They use HQ architecture for IT governance.

But real decision conversations move elsewhere. The architecture titles remain. But the roles are no longer central to defining how the project must behave.

How This Completes the GCC–HQ Distortion

So the distortion now exists on both sides. At the GCC, Solution Architects and Technical Architects are inside coding, microservices, APIs, cloud, and deployment. They are doing P5 and calling it architecture.

At HQ, Enterprise Architects are inside IT inventory, JIRA boards, application rationalization, governance meetings, and delivery tracking.

They are managing IT visibility and calling it Enterprise Architecture.

One side mistakes construction for architecture. The other side mistakes IT inventory for architecture.

Both are incomplete. Both are skewed.

And both avoid the same missing work: defining the actual anatomy before implementation and governance begin.

The Real Correction

The correction is not to remove GCC architects. The correction is not to remove HQ architects. The correction is to stop calling incomplete work architecture.

GCC architects must not stop at P5. HQ architects must not stop at governance.

For every major project, both sides must be anchored in P1–P4 before implementation and governance become meaningful.

1. What outcome must this project achieve?

2. What decision sequence must it follow?

3. What system and sub-system logic must govern the decision?

4. What components must exist before coding begins?

Only then does P5 implementation have meaning. Only then does P6 governance have substance.

Diagnostic Note

At GCC, architecture became coding. At HQ, architecture became IT inventory. Both looked useful.

Both looked mature. Both created activity. But neither defined the anatomy. That is why the title remains, but the role is bypassed. The missing work is not more coding. The missing work is not more governance.

The missing work is explicit project anatomy. One Enterprise. One Anatomy.