The Common Defense: We’re Doing IT Architecture, Not EA

Most teams don’t deny Enterprise Architecture anymore. They step down from it.

...we’re not doing EA. We’re doing IT Architecture.

At first glance, that sounds reasonable. A scoped position. A focused role.

But when we examine what actually exists inside most programs, a different picture emerges.

What is being called “IT Architecture” is often:

• Cloud service selection

• IAM configuration

• API contracts

• CI/CD pipelines

• Deployment automation

These are all valid activities. But they are not architecture.

Stage 1 — The Real Problem Statement

The issue is not that teams are not doing Enterprise Architecture.

The issue is:

What is being done does not qualify even as IT Architecture.

Because IT Architecture itself requires:

• Defined system behavior across business flow (P2)

• Traceable system and sub-system logic (P3)

• Explicit component specifications (P4)

Without these, what remains is execution.

What Exists vs What It Really Means

Let’s be precise.

Azure / GCP “Architecture” exists → What it actually means: Service selection and configuration (P5)

API design exists → What it actually means: Interface definition without orchestration (partial P3, no P2 linkage)

DevOps pipelines exist → What it actually means: Deployment automation (P5)

So the enterprise believes architecture exists.

But structurally:

• P2 (process sequence) is not defined

• P3 (system logic across interactions) is not traceable

• P4 (component specifications) are not established

Case Study 1— Digital Lending Platform

A mid-size bank modernizes its lending stack.

What exists:

• 140+ microservices

• API gateway

• Azure cloud architecture

• CI/CD pipelines across environments

From the outside, this looks like strong IT Architecture. But when a simple change is introduced —“Modify pricing logic based on new risk thresholds” — the system reveals its reality.

What is missing:

• No explicit P2 sequence across:

  application → eligibility → scoring → pricing → approval

  
  

• No traceable P3 interaction between:

  risk scoring logic, pricing logic, override rules, and approval logic
  

• No defined P4 components for:

  pricing, risk, override, audit

What happens:

• Teams conduct multiple dependency meetings

• Each service owner interprets impact independently

• Conflicting changes are introduced across services

Measured impact:

• Change analysis time → 2–3× increase

• Release delay → ~25% slippage

• Rework in pricing-related releases → 30–35%

The system is functioning. But it is not architected.

Stage 2–7 — Why This Happens

This is not a tooling issue. It is a missing anatomy problem.

Stage 2 — No explicit P1 definition No clarity on outcomes like risk appetite, pricing strategy, override boundaries.

Stage 3 — No P2 sequence modeling End-to-end flow is assumed, not defined.

Stage 4 — No P3 logic traceability Interactions among rules, functions, UI, data, and timing are not visible.

Stage 5 — No P4 component specification Core system parts are not structurally defined.

Stage 6 — P5 dominates everything Execution becomes the only visible work.

Stage 7 — P6 operates on fragmented understanding Operations rely on people, not structure.

The Critical Distinction

This is where the confusion must end.

Architecture = Definition + Visualization (P1–P4) Coding = Implementation (P5)

What most teams call “IT Architecture” today is:

Implementation activities without prior definition.

What Happens When the Chief Architect Resigns

This is where the impact becomes visible. If architecture truly exists (P1–P4 defined), a leadership transition does not disrupt structure. But when “architecture” is actually:

• Cloud configurations

• Pipeline knowledge

• Service-level familiarity

Then the architecture leaves with the person. Because what existed was not architecture. It was memory.

Observed impact post-exit:

• Change impact analysis → 2–3× slower

• Cross-system change cost → 30–40% higher

• Release delays → 20–30%

• Dependency mapping → shifts from model → meetings

Financial Exposure

This is not a theoretical issue. When code is mistaken for architecture:

• Annual change cost inflation → 15–30% of IT budget

• Rework across programs → 20–35% of delivery effort

• Vendor dependency increases due to lack of internal structural clarity

• Decision cycles extend from hours to weeks

The cost is not just technical. It is structural.

Diagnostisc Summary

The industry believes it has moved from Enterprise Architecture to IT Architecture.

In reality, it has moved from Architecture to Execution.

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.