And calling implementation leadership as architecture is how HQ keeps funding the wrong thing.

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

If I am a coder and I am called an architect…it usually means the architect is missing.

The problem is not that I am doing the wrong work. The problem is that my work is being called by the wrong name.

The problem is not that EA is missing. The problem is that IT Architecture itself is not being done. And the simplest test remains: If your architecture leaves when your Chief Architect leaves, it was never architecture. It was memory.

If architecture is actually code management: Knowledge is embedded in pipelines, logic is embedded in services, decisions are embedded in individuals. When the person exits, there is no architecture to transfer. Only execution to reverse-engineer.

The market has more architects than ever before. Cloud Architects. Digital Architects. Solution Architects. Enterprise Architects. Transformation Architects. On paper, architecture capability has scaled. In reality: Architecture itself has not.

So how did we arrive at this point? Because over time, a dangerous simplification took root: Architecture = Understanding how to build systems= Knowing how to assemble services= Being good at configuring cloud tools= Smart coding

If your Chief Architect (IT/Software) exits tomorrow: How many programs slow down? How many require reverse engineering? How many begin asking, Why was this designed that way?

What Breaks? After all, diagrams exist. Repositories are populated. Teams are in place. What could possibly break tomorrow?

Measure exposure if key architectural authority exits—and quantify the operational and financial impact of personal dependency

Confusing architecture with construction (coding & configurations) does not break systems immediately. It breaks capital efficiency.

When Construction (Coding & Configuration) is mistaken for Architecture. Lifecycle cost is 8–20× initial build.

When architecture lives in memory instead of in an explicit model, the organization doesn’t fail immediately. It becomes 30–40% more expensive to change, 2–3× slower to analyze impact, and structurally exposed to rework.

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.

Calling UI + Logic + Data “three-tier architecture” is like calling sand, steel, and cement the architecture of a metro rail pillar. Sand, steel, and cement are essential materials.

So, Approve construction (implementation) decisions if you want. But do not call them architecture. Architecture must outlive the architect. If it does not, it was never architecture.

Architecture lives in P1–P4. Implementation lives in P5. Operations live in P6. Implementation should evolve. Architecture should remain structurally consistent.

If anatomy is explicit, transitions become events — not disruptions. That is the dividing line. And it is visible long before someone submits a resignation letter.

Does the project has ONE architecture (anatomy) to externalize? Or does it believe architecture is a rotating interpretation? The CIO’s request for a FastTrack Rating did not solve the problem. It revealed the truth. And that truth was anatomy.

The real question is not whether someone will leave. The real question is whether your enterprise architecture survives when they do.

In construction, nothing is allowed to exist unless it is drawn. In software, most of what matters is never visualised—still exist inside the mind of the people and we still call it architecture.

A Chief Architect exits. Delivery slows. Confusion increases. And everyone realises—too late—that something critical has vanished. This isn’t about individual capability. It’s about how architecture is held inside an enterprise. Below are seven questions that come up repeatedly when organisations reflect honestly on what went wrong—and what needs to change.

This case is part of a 100-diagnostic series exposing how US enterprises have mislabeled operational wins as “Enterprise Architecture progress” for over two decades. Across sectors, a recurring illusion is mistaking API exposure for true enterprise architecture maturity. Leading eCommerce platforms opened their systems to merchants and developers, accelerating partner onboarding and integration variety. Yet, without a modeled enterprise structure, APIs became patchwork gatewa