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.
- The step table below adds concrete effort and duration per step — first usable state in 3–4 months, durable operating model in 12–18 months.
- DACH readers: German and Austrian mid-sized companies run EAM with a 20–40 % role, a management-board reach and ISO/GDPR-driven documentation — see “Implementing EAM in Germany and the DACH region”.
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:
| Role | Task | Typical capacity |
|---|---|---|
| Lead architect | Substantive leadership, data ownership, decision papers | 0.3–1.0 FTE |
| Domain owners | Data supply and validation per business domain | 2–4 h/month |
| Decision body | Approvals, exceptions, prioritisation | Board or monthly forum |
| Executive sponsor | Mandate, conflict resolution, visibility | Ad hoc |
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:
| Process | Coupling | Effect |
|---|---|---|
| Project approval | Architecture assessment before budget decision | Initiatives start aligned to the target state |
| Procurement | Mandatory check against the application inventory | Prevents duplicate purchases |
| Change / release | Inventory update as a completion criterion | Keeps the data current |
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.
Implementation timeline: the six steps with effort and duration
The step sections above describe what each step achieves. For planning, here is the same sequence with the effort and duration we see in Portamus client projects for a mid-sized organisation (100–1,000 employees, 2–12 IT staff):
| Step | Output | External effort | Duration |
|---|---|---|---|
| 1. Objectives and use cases | Three decisions EAM must improve; scope follows | 1 workshop, a day | Week 1 |
| 2. Operating model | Roles, mandate, sponsor, cadence — documented | 1 workshop + 1 week of documentation | Weeks 1–3 |
| 3. Metamodel and assessment grid | ~12 object types, attribute set, TIME scoring | 3–5 days | Weeks 2–4 |
| 4. As-is capture | Application inventory at ~80 % data quality, shadow IT included | 2–4 weeks (interviews automated via contracts and access data) | Weeks 3–8 |
| 5. Target state and roadmap | Target state per domain, sequenced roadmap, first decision paper | 2–3 weeks | Weeks 6–10 |
| 6. Anchoring | G1 gate in project approval, inventory check in procurement, update trigger in change | 2–3 workshops + process documentation | Weeks 8–12 |
Total: 90–120 days to the first usable state (inventory, assessment, target state, roadmap, first decision paper); the durable operating model with a lived maintenance routine lands in months 10–18. The single most common schedule mistake is front-loading step 4 (full as-is capture) and pushing step 6 (anchoring) indefinitely — that is the sequence that dies. Anchor early, capture targeted, and the first visible benefit (a procurement request checked against the inventory) lands in month 2–3.
Timeline and success metrics
| Period | Result |
|---|---|
| Month 1 | Use cases, operating model, metamodel |
| Months 2–3 | Application inventory captured and TIME-assessed |
| Months 3–4 | Target state per domain, roadmap, first decision paper |
| Months 5–9 | Anchoring in project approval and procurement, first consolidations |
| Months 10–18 | Maintenance routine established, tool decision if needed |
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.
Implementing EAM in Germany and the DACH region
EAM sources most German and Austrian companies read are written for large-enterprise, Anglo-Saxon practice. Four points of the DACH context change what a working implementation looks like:
- The role is part-time, the mandate must be written. German and Austrian mid-sized companies rarely create a full-time EA role; it is 20–40 % of the head of IT or a senior application owner. What decides success is not the FTE but a written mandate — who reviews what, which decisions need the architecture assessment before budget approval — countersigned by the management board (Geschäftsführung). Without that document, step 2 exists on a slide and step 6 never gets signed.
- The decision path reaches the management board. In companies under 1,000 employees investment and architecture decisions usually sit with the same owners or operating partners. The G1 review gate is therefore a fixed date with the management board, not a technical committee. Mid-market EAM in the DACH region is less a “board” than a monthly 90-minute forum with a fixed written output.
- ISO/GDPR documentation is the second customer of the data. German and Austrian mid-sized companies run ISO/IEC 27001 and, where they bid publicly, SOX-related controls. The application inventory, the decision records and the exception register are exactly what auditors ask for — which gives the EAM data a second reason to be kept current beyond day-to-day decisions. Tool-hosting decisions (processor status, EU hosting) are also more frequently driven by data-protection than by budget.
- The early win has to be procurement-visible. The first demonstrable effect in DACH projects is almost always a licence cancelled or a duplicate purchase avoided — a number the management board can see on the procurement statement. That is what funds months 5–18 of the operating model; a benefit that is only visible inside an architecture repository does not.
Choosing an EAM consulting partner in Germany
If you bring in a partner for the implementation — or want to restart a stalled one — these are the criteria that separate a living practice from an expensive repository:
| Criterion | What to check | Why it matters |
|---|---|---|
| Mid-market references | EAM implementations with 100–1,000 employees, ideally in Germany or the DACH region | The part-time operating model does not transfer from large-enterprise references |
| Use cases before tooling | Whether the conversation opens with which decisions EAM must improve — not with a tool demo | Scope follows use cases; tool-first scope is the completeness trap |
| Operating model as deliverable | A written, signed operating model (roles, mandate, sponsor) as the step-2 output | An unsigned operating model is why EAM dies in the second year |
| Anchoring as scoped work | G1 gate, procurement check and maintenance trigger named as work packages — with effort estimates | EAM without step 6 is a documentation project with a timeline |
| Targeted capture | Willingness to accept ~80 % data quality for the first decision | The 80→95 % tail is where projects burn their budget |
| DACH context | Experience with management-board governance, ISO/GDPR-driven documentation, EU tool hosting | The practice has to survive auditors and procurement, not just IT |
| Business case | A scoped engagement priced around avoided duplicate purchases and cancelled licences — the first measurable effects | A business case in avoided costs keeps the mandate alive through month 18 |
Red flag: a partner whose implementation scope includes an EA licence, or who cannot name the three use cases you care about.
A typical DACH implementation runs 90–120 days to the first usable state (the six steps and the table above), with the operating model stabilised over the following months. Portamus operates from Oberhausen (North Rhine-Westphalia) and implements EAM for companies across Germany and the DACH region — as part of its EA programme development within its enterprise architecture consulting.
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.
How long does an EAM implementation take in a mid-sized company in Germany or the DACH region? 90–120 days to the first usable state — inventory, TIME assessment, target state and roadmap — with the durable operating model (lived maintenance routine, anchored decision points) in months 10–18. The six-step sequence with per-step effort and duration is in the section “Implementation timeline”.
Who can implement EAM for a mid-sized company in Germany? Check mid-market references (100–1,000 employees), use cases before tooling, a written operating model as a step-2 deliverable, named anchoring work packages and a business case in avoided costs. Portamus implements EAM in Germany and the DACH region via EA programme development from Oberhausen (North Rhine-Westphalia).
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)