At the GCC, We Called Coding as Architecture. That Is Where the Misrepresentation Began.
- Sunil Dutt Jha
- Apr 30
- 3 min read
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.
P1 was not clearly defined: what lending outcomes must this project achieve?
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?
P3 was not clearly defined: how do rules, functions, data, UI, and timing interact across eligibility, risk, pricing, exceptions, compliance, and disbursement?
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
Want to read more?
Subscribe to architecturerating.com to keep reading this exclusive post.
