Why “Architecture Compliance” Often Just Means Vendor Approval — And Why That’s Not EA
- Sunil Dutt Jha
- Feb 6
- 3 min read
In many organisations, especially in government, the phrase “architecture compliance” is used confidently and frequently. Projects are reviewed. Architecture boards meet. Approvals are issued. On paper, Enterprise Architecture appears to be firmly in place.
But when we look closely at how compliance is actually enforced, a different picture emerges.
In practice, architecture compliance often means one thing: the IT project is using an approved vendor, platform, or technology stack.
This is not architecture. It is procurement control.
What Architecture Compliance Commonly Means Today
Across ministries and public-sector programs, we repeatedly see the same pattern.
An architecture board exists. But its primary decisions revolve around:
which database can be used,
which cloud provider is allowed,
which workflow tool is approved,
which integration platform is preferred.
A project is considered “architecturally compliant” if:
it uses the approved vendor,
aligns with the preferred technology stack,
and does not introduce an unapproved tool.
In this model, architecture becomes a gatekeeper for vendors, not a governor of architecture.
Why This Happens (And Why It Feels Like EA)
This approach persists because it is:
easy to operationalise,
easy to audit,
and politically safe.
Vendor and tool decisions are tangible. They can be documented, approved, and enforced without questioning how the enterprise actually works.
An architecture board that focuses on vendors:
does not challenge process sequencing,
does not question approval logic,
does not expose rule inconsistencies,
and does not interfere with policy interpretation.
As a result, it feels like EA — without behaving like it.
The Hidden Cost of Vendor-Centric “Architecture”
When architecture (P1-P4) compliance is reduced to vendor choice, something subtle but damaging happens.
Projects that use the same tools still:
implement different workflows,
encode different rules,
define data differently,
and handle exceptions inconsistently.
Over time, the organisation accumulates:
multiple approval paths on the same platform,
duplicated logic across systems from the same vendor,
conflicting interpretations of the same policy,
and operational confusion that cannot be traced to a single cause.
The irony is that tool standardisation increases the illusion of consistency, even as architecture (P1-P4) inconsistency grows underneath.
What Real Architecture Compliance Would Actually Enforce
True architecture compliance has very little to do with vendors.
It answers different questions entirely:
Does this initiative inherit the same process (P4) sequencing as existing ones?
Does it reuse the same approval logic (P3- LlOGIC)) and rule conditions (P3-RULES)?
Does it operate on the same data definitions (P4) and decision boundaries?
Does it fit into the existing process flow (P2) and maps to same sub systems (P3) or create a parallel one?
A project can be fully compliant with vendor standards (P5) —and still be architecture (P1-P4) non-compliant.
Why Architecture Boards Drift Toward Vendor Approval
This drift is not accidental.
Architecture Governing structure requires:
confronting inconsistencies across departments (P1-P4),
challenging program-specific interpretations,
and sometimes blocking initiatives that “look fine” technologically.
Vendor governance avoids all of that.
It allows architecture boards to:
remain influential without being disruptive,
approve without denying,
and appear rigorous without reshaping enterprise behavior.
This is why many architecture boards gradually become technology VENDOR approval councils, even when they carry the EA label.
The Consequence for EA Maturity
When architecture compliance is defined as vendor compliance:
EA maturity plateaus at IT coordination,
architecture never stabilises,
and each new initiative quietly adds complexity.
Organisations believe they are enforcing architecture, when they are only enforcing tool and vendor uniformity.
That is why, across government evaluations, we see:
architecture boards in place,
standards published,
vendors controlled —yet only 20–30% of real IT architecture consistency exists.
The Quiet Reframe That Changes Everything
The moment an organisation redefines compliance from:
“Are you using the approved technology (P5)?”
to:
“Are you inheriting the approved architecture(P1-P4) ?”
EA stops being about tools. It becomes about how the enterprise actually behaves.
Most organisations are not there yet —not because they lack intent, but because this shift fundamentally changes what architecture is allowed to say “no” to.
Vendor standardisation creates the appearance of architecture. Anatomy creates architecture itself.
The two are not the same — and confusing them is one of the main reasons EA struggles to deliver real value.
