How to Implement Enterprise Architecture Management: A 6-Step Approach That Sticks

Summary: EAM implementations rarely fail on method and almost always on the operating model. Start with a complete as-is survey and you lose leadership attention before any benefit becomes visible. This article describes the approach proven in Portamus client projects: six steps from objectives through metamodel and target state to anchoring EAM in project approval, procurement and change — with a timeline, roles and metrics. What enterprise architecture management is we take as read; this is about getting it running.

Key takeaways

• Use cases first. Three concrete decisions EAM should improve — otherwise you produce documentation without an audience.
• Operating model before data capture. Roles, mandate and capacity determine survival.
• Minimal metamodel, about a dozen object types. Extend only on demonstrated need.
• First benefit in 90–120 days, not after a year.
• Anchoring in project approval, procurement and change is the step that decides success.
• Tool last. Software scales a practice; it does not create one.

Step 1: objectives and use cases

The first question is not “which tool?” but: which three decisions should be made better from now on? Typical answers from our projects:

• “Before every purchase we want to know whether the capability is already licensed.”
• “We want to estimate the impact of an ERP replacement on processes and interfaces.”
• “We want to see end-of-life risk before the vendor drops support.”

Each use case determines which data is actually needed. That is the most effective scope filter in the whole implementation: without a use case there is no reason to maintain an attribute.

Step 2: define the operating model

Before any data is collected, it must be clear who runs EAM. A durable model contains at least:

The sponsor is not a formality. They settle the unavoidable conflicts between project deadline and target architecture — and without that authority the deadline always wins. How principles, boards and review gates are shaped in detail is covered in EA governance.

Step 3: minimal metamodel and assessment grid

The metamodel defines which object types and attributes are maintained. Our starting point is about a dozen types:

Application, application service, business capability, business process, data object, interface, technology building block, organisational unit, project, requirement, principle, risk.

Per application a handful of attributes is enough at first: owner, department, annual cost, support/lifecycle status, systems of record, criticality. Add an assessment grid — we use the TIME model (tolerate, invest, migrate, eliminate) from application portfolio management, scored on business value and technical quality.

Where dependencies matter, model in ArchiMate — deliberately coarse and limited to a few viewpoints.

Rule of thumb: every attribute needs a use case and a source. Attributes with neither are never maintained.

Step 4: as-is capture — targeted, not complete

The inventory follows the use cases from step 1, not completeness for its own sake. Proven sources: contract and licence management, cost-centre reports, access and sign-on data, operations documentation, and structured interviews with domain owners.

Two practical notes from our IT landscape analyses:

• 80 % data quality is enough for the first decision. Getting from 80 to 95 % costs more than the first 80 — and never stabilises without ongoing use.
• Shadow IT belongs in the inventory. Departmental licence invoices and card statements are the most reliable source for it.

Step 5: target state and roadmap

The assessed inventory plus business strategy produce the target state per domain — coarse-grained, with named replacements, consolidations and investments. The gap between as-is and target yields the roadmap: sequenced initiatives prioritised by risk, value and dependencies.

Methodologically we lean on ADM phases B to F from TOGAF, tailored to the organisation’s size and maturity. The output is not a document for the archive but the template every future project request is checked against.

Step 6: anchoring — the step that decides success

EAM takes effect exactly where it is coupled to existing processes. Three couplings are non-negotiable:

The third coupling is the most frequently forgotten — and the most important one for data currency. An inventory maintained only in campaigns loses credibility within two years, and nobody comes back to it afterwards.

Timeline and success metrics

Measure decision impact, not documentation coverage:

• Share of project requests assessed architecturally before budget approval.
• Number of redundant systems retired or consolidated.
• Avoided duplicate purchases (documented cases).
• Inventory currency: share of records updated within six months.
• Lead time of an architecture decision.

Why EAM implementations fail

• Pursuit of completeness. The as-is survey outlasts leadership attention.
• Missing mandate. Recommendations without decision rights lose against project deadlines.
• No maintenance trigger. Without coupling to change and procurement, data ages out.
• Tool-centricity. The software gets implemented, the practice does not.
• Architecture in an ivory tower. Without domain owners as contributors, the substance is missing.
• No visible early win. Without a recognisable result in the first months, backing for the rest evaporates.

Frequently asked questions

How do you implement enterprise architecture management? In six steps: objectives and use cases, operating model, minimal metamodel, targeted as-is capture, target state and roadmap, anchoring in existing processes.

How long does an EAM implementation take? First usable state after three to four months; a durable operating model after 12 to 18 months.

Which roles does an EAM operating model need? Lead architect, domain owners, a decision body and an executive sponsor.

Which metamodel do you need to start? A minimal one with about a dozen object types; extend only on a demonstrated use case.

What is the difference between implementing EAM and implementing an EA tool? EAM implementation establishes a management practice; a tool scales that practice but never replaces it.

How do you measure success? By decision impact: assessed project requests, retired redundant systems, avoided duplicate purchases, data currency, decision lead time.

Why do EAM implementations fail? Pursuit of completeness, missing mandate, no maintenance trigger, tool-centricity.

What role does TOGAF play? It supplies the methodological core (Preliminary Phase and ADM); the implementation additionally covers operating model, data maintenance, process coupling and capability building.

Conclusion

An EAM implementation is an organisational endeavour, not a documentation one. The difference between a practice still alive after two years and an abandoned repository comes down to three decisions: clear use cases instead of completeness, an operating model with a mandate instead of good intentions, and coupling to project approval, procurement and change instead of an annual maintenance campaign. Our experience from Portamus projects: deliver a visible benefit in the first 120 days and you earn the time for everything else.

Want to implement EAM — or restart an initiative that has stalled? We shape use cases, operating model and roadmap into a form your organisation can carry. → Explore Portamus EA programme development

Sources

• The Open Group: TOGAF Standard, 10th Edition — Preliminary Phase, ADM (2022)
• The Open Group: ArchiMate 3.2 Specification (2022)