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.

It may be business analysis. It may be solution design. It may be technical design. It may be tool configuration. It may be governance. It may be implementation planning. But it 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.

I configure ServiceNow. That is real work. That is useful work. That is important work. But if P1–P4 are not explicit, I am not the architect of the project.

I configure Oracle. That is real work. That is useful work. That is important work. But if P1–P4 are not explicit, I am not the architect of the project. I am the Oracle configurator.

I configure SAP. That is real work. That is useful work. That is important work. But if P1–P4 are not explicit, I am not the architect of the project. I am the SAP configurator.

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.

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

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.

In many retail lending organizations, the Chief Architect role gradually shifts under delivery pressure. What begins as a mandate to define the Architecture to realise Strategy and apply it to Operation slowly narrows into design reviews, sprint oversight, and production escalations.

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.

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.

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