Most Architecture Boards Approve Vendors — Not Architecture
- Sunil Dutt Jha
- Feb 5
- 4 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 only 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 vendor database can be used,
which cloud provider is allowed,
which vendor workflow tool is approved,
which vendor integration platform is preferred.
A project is considered “architecturally compliant” if:
it uses the approved vendor,
aligns with the preferred vendor technology stack,
and does not introduce an unapproved tool.
In this model, the architecture board becomes a gatekeeper for vendors, not a governor of enterprise anatomy.
Why This Happens (And Why It Feels Like EA)
This approach persists because it is what organizations have been taught for the last 25 years.
It is:
easy to operationalize — buy from the same vendor,
easy to audit — checklists and approvals exist,
politically safe — no anatomical decisions need to be challenged.
Vendor and tool decisions are tangible. They can be documented, approved, and enforced without questioning how the enterprise actually works.
Even in advanced environments — including recent US Federal government initiatives — organizations still ask vendors to explain complex programs in simplified terms, because structural understanding never became part of architecture practice.
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.
And mind it — this entire process revolves around IT vendor selection, yet it continues to be called an “Architecture Board” instead of what it really is: an IT vendor approval committee.
As a result, it feels like EA — but behaves only as IT coordination.
The Hidden Cost of Vendor-Centric “Architecture”
When architecture 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.
It’s like buying basketballs from the same store and expecting all players to acquire the same skills.
Over time, organizations accumulate:
multiple approval paths on the same platform,
duplicated logic across systems from the same vendor,
conflicting interpretations of the same policy,
operational confusion that cannot be traced to a single cause.
The irony is that tool standardisation increases the illusion of consistency — while anatomy inconsistency grows underneath.
The enterprise begins operating with 100 different anatomies instead of one.
Imagine a hospital where doctors treat patients based on 20 different understandings of human anatomy instead of one shared model. That is exactly what happens inside IT environments that standardize tools but not behavior.
What Real Architecture Compliance Would Actually Enforce
True architecture compliance has very little to do with vendors.
It asks different questions:
Does this initiative follow the same process sequencing as existing systems?
Does it reuse the same approval logic and rule conditions?
Does it operate using the same data definitions and decision boundaries?
Does it extend existing flows, or create parallel ones?
A project can be fully compliant with vendor standards — and still be anatomically non-compliant.
Why Architecture Boards Drift Toward Vendor Approval
This drift is not accidental.
Governing enterprise anatomy requires:
confronting inconsistencies across departments,
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.
That is why many architecture boards gradually become technology vendor approval councils, even while carrying the EA label.
The Consequence for EA Maturity
When architecture compliance becomes vendor compliance:
EA maturity plateaus at IT vendor coordination,
anatomy never stabilizes,
shadow anatomies grow project by project,
and complexity increases silently.
Organizations believe they are enforcing architecture — when they are only enforcing vendor uniformity.
This explains why, across government evaluations, we consistently see:
architecture boards in place,
standards published,
vendors controlled —
yet only 20–30% of real IT anatomy consistency exists.
The Quiet Reframe That Changes Everything
The moment organisations redefine compliance from:
“Are you using the approved technology and vendor?”
to:
“Are you following the approved anatomy?”
Enterprise Architecture 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.
The Real Distinction
IT vendor standardization creates the appearance of architecture.
Anatomy creates architecture itself.
Confusing the two is one of the main reasons Enterprise Architecture struggles to deliver real value.
