If Architecture Changes With Every Architect, It Was Never Architecture
- Sunil Dutt Jha
- 3 days ago
- 6 min read
Updated: 20 hours ago
In a bank’s retail lending program, three architects led the platform across six years. Each transition was described internally as architectural transformation. But when we examined what actually changed, something uncomfortable became visible.
The architecture did not change. The implementation style did.
And because the industry casually labels implementation detail as architecture, the enterprise believed architecture was evolving.
It was not.
What Architecture Actually Is
In civil engineering, architecture is the complete structural visualization of a building:
What the building is meant to serve (hotel, house, hospital, stadium)
How spaces connect
How movement flows
How service subsystems integrate (water, power, ventilation)
Where boundaries exist
What relationships are mandatory
What cannot violate structural integrity
Architecture is the structural blueprint of the organism. Construction comes after.
Operations come after that.
If you are building a stadium:
P1 (Strategy): Football stadium.
P2 (Process): Entry flow, seating flow, exit flow, emergency evacuation, player access, VVIP movement.
P3 (Systems): Ticketing system, crowd control system, surveillance system, utilities system.
P4 (Components): Seating bowl, entry gates, evacuation corridors, structural spans, service cores.
All of above is defined before any material is chosen.
P5 — Construction
You may choose reinforced concrete, steel truss, or composite frame. That is P5 — construction choice. You may build it with reinforced concrete. Or steel truss. Or composite structure. You may change contractor. You may change construction technique.
That is P5.
But you do not redefine the stadium’s entry logic, evacuation structure, or structural spans every time a new contractor arrives. If you do, you never had architecture.
Apply That to Retail Lending
Now take the bank’s retail lending program.
Across three architects, the following did not change.
P1 — Strategic Structure Eligibility Strategy, Risk Appetite Strategy, Risk Scoring Strategy, Pricing Strategy, Override Authority Strategy, Approval Strategy, Regulatory Traceability Strategy, Capital Allocation Strategy, Settlement Strategy etc
These strategies define structural (architecture) intent. If these change, the organism changes. If these remain constant, architecture remains constant.
The bank’s risk appetite remained defined centrally.
High-risk overrides required audit visibility.
Regulatory traceability was mandatory.
Pricing must reflect risk and capital logic.
This is structural (architecture) purpose. It is independent of P5.
P2 — Process Structure
Application Intake Process, Eligibility Evaluation Process, Risk Scoring Process, Pricing Calculation Process, Override Recording Process, Approval Process, Disbursement Process, Settlement Process, Regulatory Reporting Process, Audit Trace Process
These processes define structural (architecture) sequence.
Eligibility precedes pricing.
Risk scoring precedes approval.
Override recording precedes disbursement.
Settlement follows confirmed approval.
If eligibility starts happening after approval, structure (architecture) changes.
If disbursement bypasses approval, structure (architecture) changes.
If sequence remains invariant, architecture remains intact.
This is structural sequencing. It is independent of P5 implementation.
P3 — Systems / Logic Structure
Eligibility Rule Subsystem, Risk Scoring Subsystem, Pricing Logic Subsystem, Override Control Subsystem, Approval Decision Subsystem, Disbursement Control Subsystem, Settlement Processing Subsystem, Regulatory Traceability Subsystem, Audit Logging Subsystem, Customer Data Validation Subsystem
These are required structural (architecture) subsystems. It does not matter how they are implemented. They must exist. There must be traceability across all decisions. These are structural (architecture) subsystems of the organism. Again, independent of P5.
P4 — Component Structure
Eligibility Component, Risk Scoring Component, Pricing Component, Override Component, Approval Component, Disbursement Component, Settlement Component, Audit Component, Regulatory Reporting Component, Customer Validation Component
These define structural boundaries.
Approval Component cannot bypass Risk Scoring Component. Disbursement Component cannot skip Approval Component. Override Component cannot bypass Audit Component. Pricing Component must consume Risk Scoring output.
These are structural component specifications and boundaries. Again, independent of P5.
This is architecture — P1 through P4.
This is the blueprint of the lending organism.
These (P1-P4) are defined before construction.
P5 - Construction (Implementation)
What Actually Changed
What Actually Changed Under Three Architects
Architect 1
Implemented centralized rule engines. Single eligibility service. Single pricing service. Synchronous integrations. On-prem hosting.
Architect 2
Distributed eligibility logic across channel services. Asynchronous risk scoring APIs. Embedded override UI in branch systems. Cloud deployment. API gateway introduction.
Architect 3
Microservices decomposition. Event-driven orchestration. Containerized deployment. AI scoring augmentation. Automated CI/CD pipelines.
Hosting changed. Topology changed. Granularity changed. Deployment changed. Tooling changed. Across all three versions, no strategy P1 was deleted. No process P2 sequence was inverted. No subsystem P3 disappeared. No authority boundary moved.
What didn't change?
But did the Eligibility Strategy change? Did the Risk Scoring Strategy change? Did the Disbursement Process change? Did the Settlement Strategy disappear? Did the Override Authority Strategy move outside audit control?
No.
All P1–P4 elements remained structurally (Architecture) identical.
Only P5 — implementation expression (style) — changed.
Why Enterprises Think Architecture Changed
Because we have trained ourselves to call construction (P5 implementation) style Architecture.
We say:
Microservices architecture
Cloud architecture
Three-tier architecture (UI, logic, data)
But UI, logic, and data are ingredients — not architecture.
Calling UI + logic + data “three-tier architecture” is like calling cement, sand, and steel "three-tier" Stadium architecture.
They are raw materials for construction. They are not the structural blueprint.
Cloud migration is called architecture. Microservices are called architecture. Container orchestration is called architecture. But those are construction decisions.
If changing construction (implementation) technique alters:
Decision authority (P1),
Process order (P2),
Regulatory traceability,
Subsystem relationships (P3),
then architecture was never clearly drawn. It was being remembered. Not visualized.
The Real Test
Architecture is the explicit structural visualization of:
Purpose (P1),
Sequence (P2),
Subsystems (P3),
Component boundaries (P4),
Interconnections across them.
P5 Construction implements that visualization.
Operations (P6) run it.
If three architects can change hosting model, integration topology, and code granularity — yet the structural relationships (P1–P4) remain intact — architecture is stable.
If each implementation rewrite redefines decision rights (P1), sequencing (P2), or subsystem authority (P3), then there was no stable architecture. There was evolving construction.
Architecture Models for Stadium vs Architeture Model of Software System
In a real stadium project, P1–P4 alone generate thousands of structured artifacts. For a large international stadium, the architectural and structural documentation set typically includes:
P1 — Strategy Level
Master planning documents, Capacity modeling, Safety compliance modeling, Evacuation strategy approval, Zoning and regulatory alignment drawings
P2 — Process Level
Entry flow simulations, Exit and evacuation simulations, Crowd density modeling, Emergency routing diagrams, Operational drill mappings
P3 — Systems Level
Ticketing system layout, Security surveillance system mapping, Utilities distribution mapping, HVAC network diagrams, Fire suppression system schematics
P4 — Component Level
Seating bowl structural drawings, Gate assemblies, Load-bearing column diagrams, Foundation blueprints, Service core component drawings
Across these layers, the number of drawings and structured diagrams easily reaches several thousand — often 3,000 to 5,000 or more — each serving different stakeholders across design, compliance, construction, and operations.
Now compare that to enterprise software “architecture.”
In many large programs, architecture is represented by:
One context diagram. One integration diagram. One deployment diagram. One infrastructure topology diagram. One logical component diagram. Maybe a sequence diagram.
Seven to ten diagrams — primarily focused on implementation topology.
UI layer.
Logic layer.
Data layer.
Cloud deployment.
API gateway.
Implementation details are documented. Structural invariants are not.
In civil engineering, P1–P4 are externalized exhaustively because structural failure is unacceptable.
In enterprise software, P5 is externalized heavily, while P1–P4 often remain implicit.
That is the asymmetry.
The Architecture Continuity Test
Over time, the industry has blurred distinctions that are fundamental in every serious engineering discipline.
We have confused deployment topology with architecture — assuming that moving from on-premise to cloud, or from monolith to microservices, represents structural redesign. In reality, hosting and topology decisions belong to implementation expression (P5). They do not define purpose, sequencing, authority, or subsystem invariants.
We have confused code granularity (P5 Task)) with Architecture (P1-P4) — believing that finer CODE (service) decomposition automatically means better architecture. Splitting a system into smaller coding units changes packaging. It does not change eligibility logic p3, approval sequencing p2, override authority p1, or regulatory traceability. Structural intent (P1–P4) is independent of how finely code is divided.
We have assumed that splitting coding granularity P5, changes enterprise decisions — when in reality it often only changes file boundaries. We have treated refactoring code P5 as if it were redesigning who makes decisions P1, in what order P2, and under what constraints P3.. Code can be reorganized endlessly, yet the underlying decision rights P1, process order P2, and subsystem relationships may remain identical. Decision lives in architecture P1-P4. Code organization lives in construction P5.
When these distinctions are not made explicit, every implementation rewrite feels like architectural change. But without structural movement across P1 (Strategy), P2 (Process), P3 (Systems / Logic), and P4 (Component boundaries), architecture has not changed. Only its construction has.
The Uncomfortable Reality
Architecture lives in P1–P4. Implementation lives in P5. Operations live in P6. Implementation should evolve. Architecture should remain structurally consistent.
Architecture should not fluctuate with personal preference. Implementation style can.
If architecture appears to change with every architect, what changed was implementation style.
If structural (Architecture) understanding shifts with construction technique, then architecture was never fully visualized. It existed inside someone’s head. Not as a shared structural model. And when that happens, every leadership change feels like architectural change.
But it is not. It is exposure of implicit structure i.e. P1-P4 (Architecture). Architecture is not construction P5. Architecture (P1-P4) is the structural visualization that construction TEAM implements (P5).
If that visualization changes every time a new architect arrives, it was never architecture.
It was interpretation. And interpretation is not continuity.
Three Questions Every Architect Must Answer — Or Stop Calling It Architecture
Question 1
How many structured architectural artifacts should exist before construction begins in a serious engineering discipline — and why does enterprise software operate with a fraction of that structural visibility?
Question 2
What exactly is being externalized in Architecture — structure (P1–P4) or construction (P5)?
Question 3
If changing implementation style alters decision authority, sequencing, subsystem boundaries, or traceability — was there ever a stable architecture to begin with?
