Why Spend $1 Million and Wait 18 Months for Enterprise Architecture?

Enterprise architecture is often presented as a large transformation program.

The organization approves a significant budget, selects an EA platform, defines a framework, conducts workshops, collects information and begins documenting the current state.

Twelve or eighteen months later, it may have:

• capability maps;

• process diagrams;

• application inventories;

• technology standards;

• target-state architectures;

• transformation roadmaps;

• a large architecture repository.

But a basic question remains:

Can business leaders use any of this to make a better decision today?

Can the Sales leader understand why conversion is declining?

Can Operations identify why fulfilment repeatedly breaks?

Can the CFO trace where revenue leakage originates?

Can a transformation leader see which departments, processes, systems and responsibilities will be affected by a proposed change?

If the answer is unclear, the organization may have implemented an EA platform without creating an enterprise decision capability.

The problem is not simply the cost

A million-dollar investment is not necessarily excessive if it creates measurable enterprise value.

The larger problem is the traditional delivery model:

Invest heavily at the beginning, model the enterprise for 12–18 months and expect the business to use the architecture later.

This approach creates three risks.

First, business priorities change while the architecture is being developed.

Second, transformation projects continue moving independently of the EA program.

Third, many of the resulting models are primarily understood and maintained by architecture and technology teams.

The organization waits for the architecture to become complete. The enterprise, however, never stops changing.

A different starting point for enterprise architecture

ICMG proposes a different model:

Start with a working industry reference anatomy, calibrate it to the enterprise, activate it around real business use cases and expand it through subscription.

The organization does not need to model everything before receiving value.

It can begin with:

• one department;

• one business-critical journey;

• one transformation program;

• one operating problem;

• one important management decision.

The first objective is not to complete enterprise architecture.

The first objective is to make one important part of the enterprise understandable and diagnosable.

Begin with an Enterprise Anatomy Model

Traditional EA frequently starts with separate business, application, data and technology viewpoints.

The ICMG model begins with the connected anatomy of the enterprise.

The anatomy traces how an intended outcome is produced across six perspectives:

• P1 — Strategy: intent, objectives, policy and business rules;

• P2 — Process: business activities and operating flow;

• P3 — System Logic: decisions, rules and system behavior;

• P4 — Components: business, information and technology components;

• P5 — Implementation: projects, responsibilities and execution tasks;

• P6 — Operations: performance, issues, impacts and outcomes.

Technology remains important, but it is no longer treated as an isolated architecture landscape.

Applications, data and infrastructure are connected to the business intent they support, the processes they enable, the implementation work they require and the operational outcomes they influence.

Do not begin from a blank page

ICMG begins with an industry reference anatomy developed through structured study of enterprise structures, departments, functions, operating models and representative use cases.

The reference anatomy is not imposed as the customer’s final architecture.

It acts as a researched starting hypothesis.

ICMG then calibrates it against the enterprise to determine:

• what exists;

• what is organized differently;

• what has been combined;

• what has been outsourced;

• what is duplicated;

• what operates informally;

• what is unique to the enterprise;

• where actual relationships differ from the reference model.

This produces a verified enterprise anatomy without spending months rediscovering basic industry structure through blank-page workshops.

Use cases make architecture operational

An architecture model becomes far more useful when it explains how real work is performed.

That is why the ICMG model is activated through business use cases such as:

• lead-to-order;

• pricing approval;

• customer onboarding;

• procurement-to-payment;

• loan origination;

• claims settlement;

• product launch;

• regulatory reporting;

• incident-to-resolution.

Each use case is traced from business intent through process, logic, components, implementation and operations.

This helps the enterprise see:

• how an outcome is expected to be produced;

• which departments and functions participate;

• where dependencies exist;

• where the expected trace breaks;

• which parts of the enterprise will be affected by change.

The architecture is no longer a collection of abstract diagrams. It becomes a model of how the enterprise works.

Anatomy Navigator for department users

Most business users do not want to search through a large EA repository. They want to understand their department. The Anatomy Navigator allows department users to explore:

• their functions;

• their important use cases;

• relevant processes and decisions;

• applications and tools;

• operating responsibilities;

• upstream and downstream dependencies;

• current issues;

• proposed changes;

• affected business outcomes.

A Sales team can navigate Sales Anatomy.

A Finance team can navigate Finance Anatomy.

An Operations team can understand how its responsibilities connect to other departments, systems and outcomes.

Department users do not need to learn a specialist architecture notation before benefiting from the model.

Diagnostic Bench for business leaders

Business leaders usually approach architecture with a problem, not with a request for a diagram.

The Diagnostic Bench allows them to begin with questions such as:

• Why is this outcome not being achieved?

• Where is the operating model breaking?

• Is the problem in policy, process, logic, components, implementation or operations?

• Which departments are involved?

• Which issue is a root cause and which is only a symptom?

• What else will be affected if we change this process or system?

The Diagnostic Bench uses the connected enterprise anatomy to expose:

• affected use cases;

• broken relationships;

• possible failure locations;

• related issues and impacts;

• missing evidence;

• candidate causes;

• areas requiring validation;

• potential change consequences.

This turns enterprise architecture into a diagnosis and decision-support capability.

The subscription model

Instead of approving a large 18-month EA implementation, the organization subscribes to a progressively expanding architecture capability.

A typical model could include:

Initial activation

• access to the relevant industry reference anatomy;

• calibration of one priority area;

• platform configuration;

• initial department anatomy;

• 10–20 critical use cases;

• Anatomy Navigator activation;

• one live diagnosis through the Diagnostic Bench.

Monthly expansion and maintenance

• additional use cases;

• additional departments and functions;

• architecture updates;

• issue and impact analysis;

• change-impact assessments;

• transformation traceability;

• architecture reviews;

• operating-model updates;

• periodic validation and recertification.

The enterprise receives usable releases continuously rather than waiting for one final delivery.

The first 90 days must support a real decision

The first release should not end with an architecture presentation.

Within 90 days, leadership should be able to use the anatomy to understand a real problem, assess a proposed change or support a live transformation decision.

That is the test of whether enterprise architecture is becoming operational.

The new buying question

The organization should no longer be asked:

Are you prepared to approve a million-dollar, 18-month enterprise architecture program?

The better question is:

Which department, transformation or business problem should we make diagnosable first?

Enterprise architecture does not need to begin as a large technology-led implementation.

It can begin as a focused business decision capability—and expand as its value becomes visible.

New Enterprise Architecture

Start with one important decision.

Activate a verified enterprise anatomy.

Make it accessible to departments.

Use it to diagnose real business problems.

Expand it continuously through subscription.

Do not wait 18 months to receive an architecture that may already be ageing.

Start using enterprise architecture while it is being built.