From Civil Blueprints to Enterprise Diagnosis: Why Architecture Needed Anatomy

How ICMG shifted the reference point from civil architecture to medical practice — anatomy, disorders, and diagnostic X-rays.

Execute Note Summary:

For years, Enterprise Architecture borrowed its reference point from civil architecture and civil engineering — blueprints, structures, layers, design, construction, and roadmaps. At ICMG, we shifted that reference point to human anatomy and medical practice, because an enterprise behaves less like a static building and more like a living organism. Human anatomy is not created; it is discovered, studied, mapped, and used for diagnosis. Similarly, enterprise anatomy already exists in the way strategy, process, systems/logic, component specifications, implementation tasks, and operations interact across projects, departments, and the whole enterprise.

This blog explains why ICMG Enterprise Anatomy™ is built on three foundations of enterprise diagnosis: explicit anatomy, recurring disorders and symptoms, and enterprise X-rays. The core point is simple: methods and frameworks can organize work, but diagnosis needs anatomy.

Overview

For years, Enterprise Architecture borrowed its language from civil architecture and engineering. Blueprints. Anatomy. Layers. Design. Construction. Roadmaps. Building blocks.

This language helped for a while. It gave people a way to think beyond isolated systems and projects. But over time, we saw a limitation. An enterprise is not a building.

A building may retain much of its architectural form for 30 years. Floors, columns, staircases, load-bearing anatomy, service shafts, entry points, and physical layout often remain largely stable.

An enterprise does not behave that way. Over the same period, an enterprise may change most of its people, systems, products, regulations, partners, vendors, data flows, operating practices, customer channels, pricing models, and technology platforms.

So if the enterprise is continuously changing, then civil architecture becomes a weak reference point. It explains design. But it does not fully explain diagnosis.

The Moment the Reference Point Shifted

Around 2009, one of the early Enterprise Anatomy conversations unfolded while we were waiting with John Zachman at an airport lounge. We had picked up a human anatomy book. The book had roughly 400 pages.

About half of it explained human anatomy — organ systems, organs, inter-relationships, flows, connections, and dependencies. But the other half of the book was equally important. It explained diseases, symptoms, and how symptoms map back to organs and organ systems. That was the shift.

The real insight was not only:

• Can an enterprise have anatomy?

The deeper question was:

• If an enterprise has anatomy, does it also have recurring disorders?

And if it has recurring disorders, then another question follows:

• Can we create diagnostic X-rays for enterprises?

That is when our reference point started moving away from civil architecture and toward medical practice.

Anatomy Is Not Created. It Is Discovered.

Human anatomy was not created by doctors. It already existed.

The organ systems were already there. The organs were already connected. Blood was already flowing. The nervous system was already coordinating. The body was already functioning. Medicine did not create anatomy.

Medicine discovered it, externalized it, named it, studied it, and used it for diagnosis.

That is the same logic we apply to enterprises. Enterprise anatomy already exists.

A bank already has lending anatomy. An airline already has passenger movement anatomy. A telecom operator already has service activation anatomy. A retailer already has fulfilment anatomy. A hospital already has patient-care anatomy. A manufacturer already has production and supply-chain anatomy.

Whether the organization has documented it or not, the anatomy exists in the way strategy, process, system logic, component specifications, implementation tasks, and operations interact across departments.

The problem is not that the enterprise has no anatomy. The problem is that the anatomy is mostly implicit and invisible.

It lives in people’s heads. It lives in systems. It lives in exceptions. It lives in meetings. It lives in spreadsheets. It lives in old decisions. It lives in workarounds.

So the enterprise operates. But it often cannot diagnose itself.

Why Civil Architecture Was Not Enough

Civil architecture helps us think about buildings. What is being designed? How should the space be organized? How should load move? How should people enter, move, and exit? How should utilities flow? How should the building behave anatomically?

Useful.

But when this analogy is applied directly to enterprises, it creates confusion. People start treating enterprise architecture as if it is mainly about diagrams, blueprints, layers, standards, roadmaps, and design artifacts.

Then the term “architecture” gets stretched. Application inventory becomes Enterprise Architecture. Cloud configuration becomes Cloud Architecture. Capability mapping becomes Business Architecture. System integration becomes Solution Architecture. Coding oversight becomes Technical Architecture. Governance boards become Architecture Practice.

Each one may be useful. But useful work is not automatically architecture.

In medicine, the test is not whether someone created a diagram. The test is whether the anatomy is understood, whether symptoms are connected to anatomical causes, and whether diagnosis is evidence-based. That is the standard we need in enterprises.

The Three-Part Medical Reference

Medical practice rests on three core layers.

First, there is anatomy.

The body is understood through organ systems, organs, tissues, flows, dependencies, and inter-relationships.

Second, there are diseases and symptoms.

A symptom is not treated as an isolated event. It is traced back to organs, organ systems, biological functions, and failure patterns.

Third, there are diagnostic instruments.

X-rays, scans, blood tests, and other instruments help move diagnosis from opinion to evidence.

This is the structure we wanted to replicate for enterprises. Not the medical language for drama. But the diagnostic discipline.

Three Scopes of ICMG Enterprise Anatomy™

ICMG Enterprise Anatomy™ works at three levels.

First, there is Project Anatomy.

Every project has P1–P6.

P1: Strategy — direction and value outcomes to achieve.

P2: Process — sequence of activities required to realize the strategy.

P3: Systems / Logic — systems and sub-system logic that execute or enforce business flow across data, rules, functions, access, UI, timing, and interactions.

P4: Component Specifications — the parts that make those systems real: data, functions, rules, events, interfaces, UI, network, and other component specifications.

P5: Implementation Tasks — people and IT tasks that build, modify, configure, or deploy components.

P6: Operations — business, service, and IT operations that run, monitor, maintain, and stabilize the service.

If a project does not have explicit P1–P6, then implementation starts carrying assumptions. That is how projects get delivered without being anatomically defined.

Second, there is Department Anatomy.

Each department has its own internal anatomy. A department is not just a box on an org chart. It has its own internal functions, decisions, systems, components, implementation tasks, and operations.

For example, a Revenue Management department in an airline may have internal functions such as pricing, fare class control, seat inventory protection, demand forecasting, promotion logic, upgrade logic, ancillary revenue logic, disruption rebooking logic, and revenue leakage monitoring.

So department anatomy means defining the department’s internal functions — F1–F15 where relevant — across P1–P6.

That is F1–F15 × P1–P6 inside the department.

Third, there is Enterprise Anatomy.

At enterprise level, the organization must be defined across D1–D15 departments/functions and P1–P6 perspectives.

That is D1–D15 × P1–P6.

This is where the enterprise becomes visible as one organism.

The Three Foundations of Enterprise Diagnosis

Foundation 1 — Enterprise Anatomy

This defines what exists.

Project Anatomy — P1–P6

Department Anatomy — F1–F15 × P1–P6

Enterprise Anatomy — D1–D15 × P1–P6

Foundation 2 — Enterprise Disorders and Symptoms

This defines what repeatedly goes wrong, and how symptoms map back to anatomical gaps.

For example: revenue leakage, margin absorption, delay, rework, customer promise failure, regulatory escalation, operations memory dependency.

Foundation 3 — Enterprise X-Rays

This defines how the enterprise diagnoses itself using traceability, instead of relying on opinion, dashboards, reports, or consultant interpretation.

Foundation 1 — Enterprise Anatomy

For us, ICMG Enterprise Anatomy™ means making the enterprise explicit across functions and perspectives.

At industry level, this means defining D1–D15 — the actual departments or functions through which an enterprise behaves.

For an airline, for example:

D1 Strategy, D2 Network Planning, D3 Schedule Planning, D4 Revenue Management, D5 Sales and Distribution, D6 Customer Experience, D7 Airport Operations, D8 Flight Operations, D9 Crew Planning, D10 Maintenance and Engineering, D11 Safety and Compliance, D12 Finance, D13 HR and Training, D14 IT and Data, D15 Partners and Support

Across each department, P1–P6 must be explicit.

P1: Strategy — direction and value outcomes to achieve.

P2: Process — sequence of activities required to realize the strategy.

P3: Systems / Logic — systems and sub-system logic that execute or enforce business flow across data, rules, functions, access, UI, timing, and interactions.

P4: Component Specifications — the parts that make those systems real: data, functions, rules, events, interfaces, UI, network, and other component specifications.

P5: Implementation Tasks — people and IT tasks that build, modify, configure, or deploy components.

P6: Operations — business, service, and IT operations that run, monitor, maintain, and stabilize the service.

That is the anatomy. D1–D15 × P1–P6.

Not a diagram. Not a maturity model. Not a governance board.

An explicit representation of how the enterprise behaves.

Foundation 2 — Enterprise Disorders and Symptoms

Once anatomy is explicit, symptoms can be understood differently.

A flight delay is not just a delay.

It can expose a Schedule Planning disorder. It can expose a Revenue Management disorder. It can expose a Crew Planning disorder. It can expose a Maintenance readiness disorder. It can expose an Airport Operations disorder. It can expose a Customer Experience disorder. It can expose a Partner coordination disorder. It can expose an IT/Data timing disorder.

Without anatomy, every department explains the symptom from its own view.

Operations sees workload. IT sees system defects. Finance sees cost. Customer Experience sees complaints. Revenue Management sees inventory leakage. Crew Planning sees duty-time constraints.

Each view may be valid. But no single view explains the organism. That is why enterprises need disease and symptom mapping.

A recurring issue is rarely “just a process problem” or “just an IT problem". It is often an anatomical misalignment across departments and perspectives.

Examples of Airline Disorders

In an airline, disorders show up as repeated symptoms that everyone recognizes but few can trace anatomically.

1. Disruption Recovery Disorder

Flights are delayed, passengers are rebooked manually, airport teams improvise, customer support volume rises, and compensation cost increases.

Symptoms: The visible symptom is delay handling.

The anatomical gap may sit across Schedule Planning, Revenue Management, Crew Planning, Airport Operations, Customer Experience, Finance, IT/Data, and Partners.

2. Revenue Leakage Disorder

Seats are available but not monetized correctly. Rebooking consumes higher-value inventory. Fare class rules are bypassed. Upgrade logic is inconsistent. Compensation and vouchers are applied unevenly.

Symptoms: The symptom appears in margin.

The anatomy may be broken across Revenue Management, Sales and Distribution, Customer Experience, Finance, and IT/Data.

3. Crew Legality Ripple Disorder

A small schedule change creates multiple crew duty conflicts, last-minute replacements, hotel cost, passenger delays, and operational rework.

Symptoms: The visible symptom is crew shortage.

The anatomical gap may sit across Schedule Planning, Crew Planning, Flight Operations, HR and Training, Airport Operations, and Finance.

4. Maintenance Readiness Disorder

Aircraft readiness is not synchronized with schedule recovery, gate planning, crew availability, and passenger communication.

Symptoms: The symptom appears as aircraft not ready, gate change, delay extension, or flight cancellation.

Departments: The anatomy may be broken across Maintenance and Engineering, Schedule Planning, Airport Operations, Flight Operations, Crew Planning, Safety and Compliance, and IT/Data.

5. Customer Promise Disorder

Digital channels promise a status, refund, voucher, seat, baggage update, or service recovery option that airport operations or support teams cannot fulfill.

Symptoms: The symptom appears as customer complaints.

Departments: The anatomical gap may sit across Customer Experience, Sales and Distribution, Airport Operations, Partners and Support, Finance, and IT/Data.

6. Baggage Traceability Disorder

Passenger is rebooked, but baggage status does not move with the passenger decision. Airport teams intervene manually. Customer support cannot answer. Compensation increases.

Symptoms: The symptom appears as baggage complaint.

Departments: The anatomy may be broken across Airport Operations, Partners and Support, Customer Experience, IT/Data, and Finance.

7. Regulatory Compliance Timing Disorder

A regulatory or safety condition is discovered late in the operating flow, after decisions have already moved through schedule, crew, maintenance, airport, and customer channels.

Symptoms: The symptom appears as last-minute reversal, manual approval, or compliance escalation.

Departments: The anatomy may be broken across Safety and Compliance, Flight Operations, Maintenance, Crew Planning, Airport Operations, and IT/Data.

8. Partner Handoff Disorder

Ground handlers, catering, baggage partners, airport authorities, or code-share partners receive incomplete or late information. The airline appears disorganized even when internal teams have acted.

Symptoms: The symptom appears as partner failure.

Departments: The anatomical gap may sit across Partners and Support, Airport Operations, Flight Operations, Customer Experience, IT/Data, and Finance.

9. Schedule-Revenue Conflict Disorder

Schedule recovery protects operational continuity but damages revenue protection, upgrade logic, seat inventory, and customer priority.

Symptoms: The symptom appears as revenue leakage or passenger dissatisfaction.

Departments: The anatomy may be broken across Schedule Planning, Revenue Management, Customer Experience, Airport Operations, and IT/Data.

10. Operations Memory Disorder

The airline runs because experienced managers know what to do. When those managers are unavailable, disruption response slows, exceptions multiply, and decisions become inconsistent.

Symptoms: The symptom appears as dependency on people.

Departments: The anatomical gap is that D1–D15 × P1–P6 has not been externalized.

These are not isolated issues. They are enterprise disorders. And they cannot be diagnosed properly unless the airline anatomy is explicit.

Foundation 3 — Enterprise X-Rays

The third layer is diagnosis. In medicine, a doctor does not rely only on symptoms.

A doctor uses instruments.

X-rays, scans, blood tests, ECGs, and other diagnostic methods help reveal what is happening inside the body.

Enterprises need the same discipline.

Not reports. Not dashboards alone. Not governance packs. Not application inventories.

Enterprise X-rays must show traceability.

How does P1 strategy connect to P2 process? How does P2 process connect to P3 system and sub-system logic? How does P3 logic connect to P4 components? How do P4 components connect to P5 implementation tasks? How does P5 implementation connect to P6 operations?

Where does the flow break? Where is cost being absorbed? Where is risk being transferred? Where is margin leaking? Where is customer promise disconnected from execution?

That is diagnosis. Without X-rays, enterprises keep treating symptoms.

They add tools. They change vendors. They reorganize teams. They automate workflows. They create dashboards. They launch transformation programs. But the underlying anatomy remains implicit. So the symptoms return.

Why This Matters for CEOs

This is why the CEO cannot treat Enterprise Architecture as an IT concern. EA (IT) may define the anatomy of the IT department — applications, infrastructure, data, platforms, integrations, technology operations, controls, and technology change.

That is valid within IT.

But EA (Enterprise) must define the anatomy of the enterprise as an organism. A CEO does not need to become a drafting architect. That is not the point.

The CEO must think like an enterprise doctor. Because the CEO owns the consequence when the enterprise is run through symptoms without anatomy.

If revenue is leaking, that is a symptom. If margin is being absorbed, that is a symptom. If customers receive inconsistent promises, that is a symptom. If regulatory change creates rework, that is a symptom. If transformation programs keep delaying value, that is a symptom. If departments rely on memory and workarounds, that is a symptom.

The question is: Where is the anatomy broken?

What We Learnt from Zachman — and Where We Extended It

John Zachman’s contribution was foundational. His work forced the industry to understand that an enterprise must be described through explicit, structured elements — not random IT diagrams.

At ICMG, we worked closely with John across certification, training, awards, consulting conversations, and workshops.

But the medical reference took us further.

The question was no longer only: What are the elements of the enterprise?

The question became:

What is the anatomy of the enterprise, what are its recurring disorders, and how do we diagnose them?

That is where ICMG Enterprise Anatomy™ emerged. Not as a replacement for disciplined enterprise thinking. But as an extension of it into diagnosis.

The Real Test

The test is not whether an organization uses TOGAF, Zachman, ArchiMate, COBIT, ITIL, Agile, cloud, or any other method.

The test is simpler.

1. Does it expose the enterprise anatomy?

2. Does it connect symptoms to anatomical gaps?

3. Does it help diagnose where strategy, process, systems/logic, component specifications, implementation tasks, and operations are misaligned?

4. Does it do this across the departments that actually run the enterprise?

If yes, it is moving toward architecture. If no, it may still be useful. But it is not yet diagnosis.

Diagnostic summary

Civil architecture helped the enterprise world borrow the language of design. But medical practice gives us the language of diagnosis.

And enterprises today do not only need more design language. They need anatomy. They need disease and symptom mapping. They need diagnostic X-rays.

That is why we shifted the reference point.

From civil architecture. To medical practice.

One Enterprise. One Anatomy.