At the GCC, We Called Coding as Architecture. That Is Where the Misrepresentation Began.

What Happened Inside the GCC

At the GCC, we built serious engineering capability. We designed microservices. We defined APIs. We created data models. We reviewed code structure. We deployed on cloud. We managed Kubernetes, pipelines, environments, monitoring, and release flows.

This work was important. But it was implementation.

Inside the project, P5 was getting done. The problem started when this P5 work was presented as architecture.

The Bank Lending Example

Take a bank lending project. The GCC team split the lending system into services. There was an eligibility service. A risk scoring service.

A pricing service. A document verification service. An approval service. A disbursement service. A collections service.

On paper, the system looked modern. The code was modular. The services were clean. The APIs were defined. The deployment model was scalable. So the GCC called it architecture. But the real lending decision was still not clearly defined.

What Was Missing

Before coding began, P1–P4 of the project were not explicit.

1. P1 was not clearly defined: what lending outcomes must this project achieve?

2. P2 was not clearly defined: what exact sequence of decisions must occur from application intake to eligibility, risk scoring, pricing, approval, disbursement, servicing, and collections?

3. P3 was not clearly defined: how do rules, functions, data, UI, and timing interact across eligibility, risk, pricing, exceptions, compliance, and disbursement?

4. P4 was not clearly defined: what components must exist before implementation begins—rules, decision tables, customer data structures, exception components, approval components, pricing components, audit components?

So the services were built. But the lending anatomy was not explicit.

How Misrepresentation Happened

The GCC presented service decomposition as architecture. Eligibility service became architecture. Risk scoring service became architecture. API design became architecture. Deployment topology became architecture.

But these did not define how lending decisions should work. They only defined how parts of the system were built.

1. If eligibility logic is not explicitly defined, the eligibility service only automates partial understanding.

2. If risk scoring is not aligned with pricing, the borrower may qualify but receive the wrong offer.

3. If approval logic is not connected to policy exceptions, manual overrides continue.

4. If disbursement logic is not aligned with documentation status, operational rework continues.

Changing code granularity does not create lending clarity. It only distributes undefined logic into smaller technical units.

Financial Impact

This is where the cost begins.

1. A policy change that should take days starts taking weeks.

2. Impact analysis depends on senior engineers because the logic is not explicit.

3. Testing expands because each service carries partial assumptions.

4. Rework increases because downstream behavior is discovered late.

The bank spends more on change, more on coordination, more on regression testing, more on release management.

But the lending decision still behaves inconsistently. The project gets more expensive without becoming more controlled. This is how architecture misrepresentation becomes financial leakage.

What Headquarters Sees

Headquarters sees more architects. More services. More platforms. More engineering spend. More delivery dashboards. But they also see slower change, higher cost, and inconsistent behavior.

So they adjust. They use the GCC for delivery. They handle decision logic elsewhere. They do not depend on architecture roles to define how the lending decision should behave.

The title remains. But the role is no longer trusted for architecture.

Correction

The correction is not to stop microservices. The correction is to stop calling microservices architecture.

Before coding begins, the project must define P1–P4.

1. What outcome must the lending project achieve?

2. What decision sequence must lending follow?

3. What system and sub-system logic governs lending decisions?

4. What components must exist before services are built?

Only then should P5 begin. Until then, GCC architecture will remain implementation presented as architecture.

One Enterprise. One Anatomy.