Enterprise Intelligence

I’m called a Business Architect. But if my outputs mainly serve the CIO, I am not necessarily defining the enterprise. But unless my work defines D1–D15 × P1–P6 anatomy. I am creating CIO-facing business views. And CIO-facing business views are not the same as enterprise anatomy.

I’m called a Business Architect. But if I mostly create capability maps for IT programs, I am not necessarily defining business anatomy. But unless the capability map defines D1–D15 × P1–P6, it remains a business view. Not architecture.

I’m called a Business Architect. But if Sales, Finance, Operations, HR, Customer Experience, Support, and other departments do not use my work, then what business am I architecting? I am not defining business anatomy. I am producing business-facing views.

I’m called a Business Architect. But if my work is scoped by IT, funded by IT, consumed by IT, and mainly used to support IT execution, then my work still sits inside IT. Unless I define D1–D15 × P1–P6 anatomy, I am not architecting the business. I am translating it for IT.

I’m called a Business Architect. But if I only create business views, I am not defining business anatomy. If my work does not make D1–D15 × P1–P6 explicit, I am not architecting the business. I am representing it. And representation is not architecture.

I create value streams. That is real work. That is useful work.That is important work. But if the value stream does not link to P1 above and P3–P4 below, I am not defining architecture. I am drawing how value appears to move.

The enterprise is not one department. It is a system across sales, customer experience, operations, finance, HR, engineering, project delivery, product, marketing, legal, procurement, risk, support, partners, and technology.

A capability model answers one question: what areas exist in the enterprise? Architecture must answer what outcomes must be achieved (P1), how activities are sequenced (P2), how systems interact across rules, functions, UI, data, and timing (P3), and what components exist (P4). A capability map does not define these.

If we look closely at what most roles labeled as “architect” actually do, a pattern emerges. They write code, configure cloud services, set up networks, automate deployments, run DevOps pipelines, manage Agile delivery, review JIRA boards, and create capability models.

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

Enterprise Architecture (IT) is not failing. It is incomplete. Until P1–P4 are made explicit, P5 will continue to optimize fragments, and P6 will continue to absorb the consequences. That is why CIOs often feel: We have Enterprise Architecture, but complexity is still increasing.

Enterprise Architecture (IT) is not failing. It is incomplete. Until P1–P4 are made explicit, P5 will continue to optimize fragments, and P6 will continue to absorb the consequences. That is why CIOs often feel: We have Enterprise Architecture, but complexity is still increasing.

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.

Level 1 remains inside IT. Business departments are still external at this stage. That is why Level 1, even when strong, is not enterprise anatomy yet—it is IT anatomy convergence.

Most Enterprise Architecture “maturity models” measure capability. They describe whether an organisation has EA activities, governance forums, standards, repositories, tooling, and whether those activities appear more consistent over time. This is a useful lens for assessing the presence of EA practice. But it is not the lens ICMG Enterprise Anatomy™ uses. The ICMG Enterprise Anatomy™ model does not measure how mature your EA practice looks . It measures something else entire

Enterprise Architecture maturity is therefore not the progression of IT governance practices or tools. It is the elevation from isolated architectural activity toward explicit enterprise anatomy governing decisions across the organization.

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.

Organisations believe they are enforcing architecture — when they are only enforcing vendor and tool uniformity.

And so, like 1820 medicine, they certify surface practices — but lack anatomy understanding.

This isn’t Enterprise Architecture for a Bank. This is an IT roadmap, wearing a borrowed title. If 12 of the 15 critical banking functions were never touched, it’s not EA. It’s IT transformation mislabelled as Enterprise Architecture

This “Enterprise Architecture” covered perhaps 2–3 of the airline’s 15 core departments – maybe ~20% of the enterprise – leaving the other ~80% of the organization unmapped and unmanaged by any unified architecture.

Across the Middle East, “Enterprise Architecture” has become a brand — a badge claimed by banks, airlines, ministries, telecom giants, and consulting firms alike. But behind the banners and certifications, a pattern reveals itself.

Across the Middle East, everyone says they’ve “implemented EA.” → A national airline. → A major Gulf bank. → A digital authority in the region. → A global logistics player based in the UAE. → Even a ministry that awarded EA certifications. But when we looked under the hood? What we found wasn’t ENTERPRISE ARCHITECTURE.