Architecture Is Not Material Selection — Nor Construction Diagrams
- Sunil Dutt Jha
- 3 days ago
- 4 min read
The Stadium Example Applied to Enterprise Software
Architecture Is Defined Before Construction Begins
If UI, Logic, and Data are considered architecture in software, then by the same logic, the architecture of a stadium should be defined by the grade of steel used, the cement mix ratio, and the reinforcement bar thickness.
No serious engineer would accept that.
Steel grade is construction detail. Cement composition is construction detail. Rebar diameter is construction detail. They belong to implementation.
Stadium architecture is defined long before material selection. Architecture defines purpose, flow, subsystem behavior, and constraints. Construction implements that definition.
The same order applies to enterprise software.
Large Stadium — Thousands of Architecture Drawings
For a 60,000-seat international stadium, architecture includes thousands of drawings — often 3,000 to 5,000 or more.
At the purpose level, there are master planning documents, capacity modeling, safety compliance layouts, evacuation approval diagrams, and zoning alignment drawings.
At the movement level, there are entry circulation plans, exit release sequencing diagrams, emergency evacuation routing models, and crowd density simulations.
At the subsystem level, there are ticket validation logic maps, access control rules, surveillance system coverage plans, fire suppression activation triggers, and utilities distribution logic.
At the constraint level, there are load transfer models, beam and column alignment drawings, corridor width mandates, structural clearance requirements, and non-interference specifications.
None of these describe cement brand. None of these describe steel supplier.
They describe purpose, flow, logic, and constraints.
That is architecture.
Only after that is finalized do engineers choose reinforced concrete, steel truss, or composite materials. That is construction.
Small Stadium — Same Order, Smaller Scale
Now consider a smaller indoor stadium designed for 1,000 people.
The scale reduces. The load magnitude reduces. The number of drawings reduces.
But the order does not change.
First comes purpose definition. Then movement flow. Then subsystem logic. Then constraint specifications. Only then does material selection occur.
Architecture always precedes construction — whether the stadium holds 1,000 people or 60,000.
Scale changes quantity. It does not reverse sequence.
The same principle applies to enterprise systems.
What Most Software “Architecture” Actually Documents
Now look at enterprise software repositories.
Most contain:
A context diagram. An integration diagram. A deployment diagram. An infrastructure layout. Maybe one logical component view. Five to ten diagrams. Almost all focused on P5 IT Tasks.
Which cloud region hosts the service. Which API calls which. Which container runs where. Which database is used. Which load balancer routes traffic.
These are P5 implementation details.
They are equivalent to documenting crane positioning, cement logistics, and material transport — and calling it stadium architecture.
What Software Architecture Must Actually Show
Architecture in enterprise software must visually define:
P1 Strategy — what decisions the system is designed to make. P2 Process/Sequence — what order of execution must never change. P3 System Logic — where rules execute and how they relate. P4 Component Specifications — what transitions and validations cannot be bypassed.
These define enterprise meaning.
P5 IT Tasks build that meaning into code.P6 IT Operations execute that meaning daily.
If P1–P4 are not explicitly visualized, then the enterprise does not have architecture. It has construction documentation.
Architecture Is the Visual Model
If the stadium analogy holds — and it does — then architecture cannot be material selection. It must be the full visual model of purpose, flow, logic, and constraints.
In software terms:
Architecture is not cloud topology. Architecture is not container layout. Architecture is not code granularity. Architecture is not UI–Logic–Data layering.
Architecture is the visual model of P1 Strategy, P2 Process/Sequence, P3 System Logic, and P4 Component Specifications.
Everything else is construction. When construction detail is mistaken for architecture, implementation rewrites feel like architectural change.
But without movement across P1–P4, architecture has not changed. Only its construction has.
Architecture Continuity Test — Chief Architect (IT/Software) Accountability
If architecture is truly the visual model of P1 Strategy, P2 Process/Sequence, P3 System Logic, and P4 Component Specifications, then its continuity cannot depend on a person.
The real test is simple.
If the Chief Architect (IT/Software) leaves tomorrow, can another architect inspect the P1–P4 model and understand:
What decisions the system is designed to make?
What order must never change?
Where system rules are defined and executed?
What transitions and validations cannot be bypassed?
If those answers require explanation instead of inspection, architecture is not externalized. It is memorized. Memorized architecture is fragile.
If the enterprise repository mainly contains P5 IT Task diagrams — deployment views, microservice topology, cloud layouts — then the enterprise owns construction documentation, not architecture.
Architecture must be visible without narration. It must be reviewable by risk, product, compliance, IT, and operations. It must survive leadership change.
P1–P4 define architecture. P5 IT Tasks build it. P6 IT Operations run it.
If a change in Chief Architect (IT/Software) results in reinterpretation of decision rules, sequencing, or system boundaries, then architecture was never clearly visualized.
It was being interpreted.
And interpretation is not continuity. Architecture continuity is not about retaining people. It is about externalizing the visual model.
If that model exists clearly across P1–P4, the enterprise is stable. If it does not, every leadership transition becomes a structural risk — even when systems appear to be running.
