ArchiMate Implementation and Migration Layer: Modeling

⏱ 24 min read

I have watched this play out more times than I care to count.

Sometimes it is a large telecom transformation programme, with an incumbent operator trying to modernise BSS while pushing ahead with 5G. Sometimes it is an EU-backed digital transformation tied to funding milestones, procurement lots, and enough governance forums to consume half the working week. The roadmap deck is approved. The migration views are polished. The target architecture looks clean, coherent, even elegant. The colours feel reassuring. TOGAF training

Then someone asks a very ordinary question.

What exactly changes in Q3?

Which system becomes authoritative first?

When do operations have to support two order flows at once?

Who is actually carrying the risk of coexistence?

What can really be decommissioned, and when?

And suddenly the room gets vague.

In my experience, that is the moment you find out whether the ArchiMate Implementation and Migration layer has been used properly or merely staged. Too often, it gets treated as decoration around a target architecture, a PMO timeline with ArchiMate icons, or a compliance artifact produced because procurement or governance expects “a roadmap view.” None of those uses is entirely pointless. But none of them is the real job. ArchiMate training

The Implementation and Migration layer exists to make change explicit. Not “show phases.” Change. Real change. Bounded work, concrete outcomes, transitional states, dependencies, implementation events, and the awkward temporary architecture nobody wants to pay for but everybody ends up operating.

I’ll say it plainly: if you cannot trace a work package to a deliverable, a plateau, and the core architecture elements it changes, you do not really have a roadmap. You have a presentation. ArchiMate in TOGAF

The telecom thread running through this article is familiar enough to be realistic: legacy BSS/OSS rationalisation, 5G rollout dependencies, CRM and order management transition, old mediation coexisting with event-driven integration, and a business that wants omnichannel journeys long before the architecture is remotely ready for them.

That uncomfortable middle is where good migration modeling actually lives.

The biggest modeling mistake: target-state pictures disguised as roadmaps

The classic anti-pattern is almost dull at this point.

Architects draw a baseline. Then they draw a target. Then they insert three plateaus called Phase 1, Phase 2, and Phase 3, usually with arrows moving neatly from left to right, as if sequencing has somehow become meaningful because the geometry is tidy. The semantics of architecture state and project planning collapse into one blurry concept.

It looks controlled. It rarely survives first contact with reality.

Why? Because those plateaus are not states. They are timeline buckets. They do not tell anyone what is true in the architecture during each stage of migration. They do not show when a capability becomes genuinely usable, when a system of record changes, when a temporary integration has to exist, or when operational support needs to absorb dual running. They hide the coexistence costs, which in telecom are usually where the pain sits.

Take a CRM modernisation example. If your migration architecture says:

• CRM Modernisation Phase 1
• CRM Modernisation Phase 2
• CRM Modernisation Phase 3

then you have told me almost nothing useful. I still do not know when the product catalogue becomes authoritative, when order decomposition moves from the old stack to the new one, whether customer agents are using one desktop or two, whether APIs and batch interfaces coexist for six months or for two years, or whether billing has any realistic chance of surviving the chosen sequence without manual reconciliation.

That is not pedantry. Those are the decisions that matter.

A plateau should answer a hard question: what is true in this state that was not true before?

If the name of a plateau can be swapped out for “Q2 2027” and nothing important is lost, it is weak. Maybe even useless.

Before the notation: what this layer is actually for

I do not think the core problem is that people have failed to memorise the definitions. Most enterprise architects can recite them well enough. The problem is that they use the notation without being clear about the purpose. Sparx EA best practices

In practical terms, the key concepts earn their keep like this:

A Work Package is a bounded unit of change execution. Not a giant programme. Not a vague strategic initiative. A coherent chunk of architecture change that can be reasoned about.

A Deliverable is something produced that can be reviewed, accepted, and that materially enables transition. A migration runbook. A target integration contract pack. A reconciled data model. A dual-stack support operating model.

A Plateau is a relatively stable architecture state. Not perfect. Not final. Just stable enough that operations, governance, and the business can understand what is now in place.

A Gap is what blocks movement between states. This is where prioritisation becomes honest.

An Implementation Event is a milestone that matters architecturally. “Legacy order capture decommissioned” is an implementation event. “Steering committee held” is not.

Where architects go wrong is surprisingly predictable. They over-model delivery governance inside ArchiMate, trying to turn the repository into a full programme plan, while at the same time under-modeling the transition states that actually matter. So you end up with diagrams full of workstreams and dates, but very little clarity on what the enterprise will look like while it is migrating. ArchiMate modeling guide

I am opinionated on this because I have seen the consequences up close. ArchiMate is excellent for exposing transformation logic. It is poor when people abuse it as a substitute for an integrated plan, backlog, benefits register, procurement tracker, release calendar, RAID log, and budget workbook all at once. That path leads to clutter and, sooner or later, a loss of credibility.

This distinction matters even more in EU institutional environments, where traceability is not optional. Funding lines, strategic objectives, and implementation measures need to connect. Auditability matters. But auditability does not mean stuffing every control artifact into a migration view. It means being able to explain how a change initiative leads to a transition state and from there to strategic and operational outcomes.

That is something else entirely.

A telecom case that looks simple and isn’t

Let’s make it concrete.

Imagine an incumbent telecom operator. Legacy CRM. Legacy order management. Billing that no one wants to touch, but everyone depends on. Service activation stitched together with a mixture of vendor products, brittle APIs, and old batch integrations that still run overnight because somebody, years ago, promised they were temporary. Mediation sits in the middle of more than anyone comfortably admits. At the same time, the operator is expanding 5G coverage and trying to support omnichannel journeys, bundled fixed-mobile offers, and wholesale partner onboarding.

The business asks for familiar outcomes:

• reduce order fallout
• shorten product launch cycles
• retire duplicate customer data stores
• support converged offers
• onboard partners faster
• improve customer experience without breaking fulfilment

This is not just an application architecture problem. It is very much a migration-layer problem.

You cannot cut over from that baseline to a clean target in one move. Network rollout and BSS change interact. Temporary interfaces are unavoidable. Operating model changes almost always lag software delivery, usually by months. IAM changes ripple into channel, agent desktop, partner access, and support tooling. Kafka-based event integration may simplify the future state, but it can make the transition messier if source systems have poor event quality or no decent contract discipline.

That is exactly why the Implementation and Migration layer matters here. It gives you a language for the uncomfortable middle.

Work packages are not projects, epics, or procurement lots

Another recurring mistake: people confuse work packages with whatever administrative structure already exists.

In real enterprises, one procurement lot may fund several architecture changes. One programme may contain many work packages. One work package may involve several teams, suppliers, or product owners and still represent one coherent change in architecture terms. Equally, a single project title might bundle several unrelated changes that should never be modeled as one thing.

This sounds fussy until you actually try to govern a roadmap.

Take “Digital Front Office RFP.” That is not a work package. It is a procurement label. It tells me almost nothing about the architecture change except that buying activity is involved.

“5G monetisation stream” is also too broad unless decomposed. It might include product catalogue changes, charging model updates, mediation enhancements, partner API exposure, and customer journey redesign. That is not one work package. That is a governance and budget bucket.

But “Introduce product-catalogue-driven order capture for mobile offers” could be a valid work package. It has architectural scope. It should produce observable deliverables. It changes specific application and data relationships. It has a bounded dependency profile.

That is the test I tend to use in practice:

• clear architectural scope
• observable deliverables
• traceable impact on architecture elements
• bounded dependencies

In EU institutional settings this gets distorted by funding structures all the time. Implementation planning often mirrors grant lines, framework contracts, or work orders rather than the actual logic of architecture change. Understandable, yes. Also dangerous. If you copy those structures directly into migration semantics, the roadmap starts reflecting administrative convenience rather than how the enterprise can actually move.

Map governance and funding structures separately. Link them if you need to. Do not let them pollute the architecture model.

What a good plateau looks like

A strong plateau is not about theoretical elegance. It is about decision usefulness.

For the telecom case, I would much rather see plateaus like these:

Plateau A: Legacy-assisted omnichannel sales

New digital channels are live. Legacy CRM remains system of record. Product catalogue exists in duplicate. Agents use a federated desktop. IAM federation exists between old and new channel components. Some Kafka events are published for customer interaction updates, but the legacy stack still drives fulfilment.

Plateau B: Catalog-centralised capture

A central product catalogue becomes authoritative. New order capture supports mobile and broadband offers. Legacy billing remains in place. Order orchestration is split across old and new stacks. Customer profile sync runs between CRM and the new engagement layer. Inventory exposure is partial, so some validation remains batch-based.

Plateau C: Fulfilment-decoupled operating state

Event-driven orchestration is introduced. Selected activation APIs replace batch integrations. Fallout monitoring is centralised. Legacy mediation is partly retained for prepaid. A cloud-based integration platform and Kafka backbone handle new fulfilment events, but not every domain has migrated. Operations supports dual-run procedures explicitly.

These are useful because they describe stable truths. They reveal coexistence. They force the discussion about risk and cost.

Now compare them with “Wave 1,” “Release 2,” or “2027 transition.” Those labels are thin. They travel well in PowerPoint, but they are not architecture states.

A practical rule I use: plateau names should still make sense if the programme plan changes next month. Because, in my experience, it usually will.

The hidden cost nobody models: temporary architecture

This is the part most roadmaps quietly leave out.

And when they leave it out, they are lying.

Temporary architecture is not incidental. In large transformations it is often where the money goes and where operations gets hurt. Dual data synchronisation. Adapter APIs. Interim IAM federation. Reconciliation services. Shadow reporting. Manual control points. Stopgap monitoring. Custom bridges between old mediation and a new event bus. These are not side notes. They are the mechanism of survival during migration.

In telecom, examples are everywhere:

• a customer profile sync service between old CRM and a new digital engagement platform
• a mediation bridge between legacy charging and Kafka-based event streaming
• an interim order fallout console used by operations because end-to-end observability does not yet exist
• temporary identity brokering where a new IAM platform fronts old agent applications that cannot yet speak modern protocols cleanly
• a cloud API gateway wrapping services that are still implemented as old SOAP or even file-based interfaces underneath

If you model only the future architecture and the final decommissioning, governance will underestimate cost, support effort, cyber risk, and operational fragility. I have seen programmes promise decommission dates while quietly depending on temporary components that nobody had budgeted to operate securely.

The Implementation and Migration layer is one of the few places where this can be made explicit without turning everything into prose. Work packages create it. Deliverables define how it is accepted. Plateaus show when it exists. Gaps explain why it is necessary.

Strong opinion, yes: if a roadmap hides temporary architecture, it is usually performing optimism rather than architecture.

Weak versus strong modeling choices

Here is the contrast in plain form:

That table is simple, but it captures a lot of pain.

Gaps are not decorative leftovers

Gaps are often either missing entirely or labeled so vaguely that they might as well not exist. “Integration gap.” “Process gap.” “Technology gap.” Fine, but which one? Blocking what? Between which states? With what consequence?

This matters because gaps are where sequencing decisions become honest.

Suppose the telecom operator wants to move to catalog-driven order capture for converged offers. Some meaningful gaps might be:

• no canonical product model across fixed and mobile
• network inventory not exposed via stable APIs
• field service scheduling detached from order orchestration
• prepaid charging stack incompatible with the event model
• IAM role model not aligned between partner channels and internal assisted-sales tooling
• no rollback procedures for failed migrations of in-flight orders

Those are not decorative labels. Those are reasons some transitions are feasible and others are fantasy.

When stakeholders argue over roadmap order, I often suggest modeling the gaps first. The conversation sharpens very quickly. Politics has less room to hide when the blockers are visible and tied to concrete architecture elements.

A gap should be tied to a plateau transition and connected to the business capability, application component, data object, or technology service it affects. “Inventory API gap blocks automated fulfilment in Plateau B to C transition” is useful. “Technology gap” is not.

Sequencing change when dependencies cross layers and suppliers

Reality is messy. Network engineering moves at one speed. BSS vendors at another. Security has its own gate. Data governance wants model discipline after years of neglect. Procurement imposes sequencing nobody would choose voluntarily. Operations needs support models before it accepts anything. Cloud landing zones are ready for one domain and not another. Kafka is available, but event ownership is a mess. IAM is being modernised in parallel and suddenly becomes a dependency for agent desktop migration.

The Implementation and Migration layer does not solve all of that.

What it can do is provide a common architecture logic for sequence and dependency.

For example, a credible sequence might look like this:

1. Expose inventory APIs for selected domains.
2. Centralise product catalogue for mobile and broadband offers.
3. Introduce order orchestration for mobile first.
4. Migrate assisted sales desktop for the affected product scope.
5. Retire duplicate capture logic only after operational controls are proven.

Organizations often get this backward. They launch the front end first without aligning the product model. They implement orchestration before event quality is good enough to trust. They commit to decommissioning before coexistence controls are funded. Or they let a supplier roadmap dictate architecture sequence because the contract timing is awkward.

In EU institutional and regulated environments, framework agreements and supplier constraints can absolutely force strange sequencing. Fine. But the architecture should reveal that constraint, not politely pretend it does not exist. If a mandated procurement sequence creates a temporary plateau with ugly coexistence, say so.

You do not need every dependency note inside the diagram. Sometimes that turns the view into sludge. But the transition logic should still be visible in the model.

A small sketch of that logic might look like this:

Not sophisticated. But honest.

Deliverables are not bureaucracy if you use them properly

Architects often resist deliverables because they feel too project-management-heavy. Fair enough. If you put every document and work product into a migration diagram, the result will be unreadable and irritating.

But that does not mean deliverables are useless. It means they need to be used selectively.

A deliverable is valuable when it represents an acceptance-worthy output that changes roadmap confidence. In telecom transformation, good examples include:

• target integration contract pack for partner onboarding
• data migration rehearsal report
• IAM federation design and security sign-off for dual-stack channel access
• decommissioning runbook for legacy order capture
• operational support model for coexistence between old billing and new orchestration
• Kafka topic contract set and event quality controls for fulfilment events

Bad deliverables are generic sludge: “solution implemented,” “design completed,” “testing done.” Those are project status phrases, not architecture-enabling outputs.

Not every view needs every deliverable. Please do not build the giant wall chart. Use focused migration viewpoints. One for executive transition states. One for domain architects. One for temporary architecture and coexistence. One for governance dependencies, if needed.

A worked mini-roadmap

Here is a compact example I would actually use.

Baseline

Legacy CRM holds customer master. Order capture is duplicated by channel. Provisioning is batch-driven. Bundled offers cause frequent fallout. Billing is deeply coupled to old order structures. Agent desktop is fragmented. IAM is inconsistent across channels.

Work packages

• establish central product catalogue
• implement mobile-first order orchestration
• create customer data synchronisation service
• migrate agent desktop for assisted sales
• decommission legacy mobile order capture

Plateaus

1. baseline legacy state
2. channel-modernised but legacy-authoritative state
3. catalogue-authoritative coexistence state
4. mobile fulfilment modernised state
5. legacy mobile capture retired state

Key gaps

• missing unified eligibility rules
• incomplete inventory API exposure
• unsupported rollback procedures
• inconsistent IAM role mapping for agent and partner access

Implementation events

• first mobile offer launched on new catalogue
• assisted sales moved to new desktop
• legacy mobile capture disabled

What this demonstrates is simple but important: the roadmap is about architectural truth, not just chronology.

Another sketch:

Even this simple outline is more useful than many elaborate programme decks, because it tells you what becomes true, and when.

Stop forcing one giant diagram to do everything

This is worth saying directly.

One giant migration diagram is usually a sign that nobody has decided what question the view is supposed to answer.

When I see a single view with all work packages, all applications, all milestones, all vendors, all regions, all temporary interfaces, and all programme streams crammed onto one page, I know two things: it took ages to produce, and almost nobody will use it well.

It becomes unreadable. Audience fit disappears. Semantics drown in clutter.

A more credible approach is a small family of views from one repository:

• an executive roadmap view with major plateaus and implementation events
• a domain architect view with work packages and impacted business/application/technology elements
• a transition-state view focused on temporary architecture and coexistence
• a dependency-focused view for programme governance and steering

Telecom makes this especially obvious. Network teams and BSS stakeholders rarely need the same detail in the same view. Operations needs to see support implications. Security wants IAM and trust boundaries. Product teams care about catalogue authority and offer launch implications. Finance asks when duplicate platforms can be retired. One picture will not satisfy all of that without becoming terrible.

Consistency across views matters far more than heroic single-diagram ambition.

Where ArchiMate should stop

This is an important boundary.

Do not force the Implementation and Migration layer to hold sprint plans, detailed cost plans, vendor resource allocations, cutover task lists, legal procurement workflow details, or the full dependency register. It is not built for that, and trying to make it so will leave your architecture repository bloated and brittle.

Link externally instead:

• programme plan
• RAID log
• dependency register
• benefits case
• solution design packs
• cutover plans
• procurement artifacts

Architecture loses credibility when it tries to become the master document for everything. I have watched teams spend months maintaining “comprehensive” repositories that nobody really trusted because they were impossible to keep coherent. Traceability matters. Semantic overload does not improve traceability.

In regulated and EU settings especially, people often confuse the need for evidence with the need to model everything. They are not the same thing.

Governance is where migration models prove their worth

A migration model sitting quietly in a repository is not enough. Its value shows up in steering.

Used properly, these artifacts should support architecture review boards, transformation steering committees, procurement checkpoints, and operational readiness reviews. The good questions are not abstract.

What temporary architecture are we accepting?

What can be decommissioned, and when?

What gap blocks movement to the next plateau?

Which work package changes the architecture versus merely implements within it?

Can prepaid remain on legacy charging through Plateau B without creating unacceptable operational risk?

Is network API maturity sufficient for automated business fulfilment?

What is the real cost of dual customer master during coexistence?

Those are governance questions with architecture consequences.

A useful operating routine is quite simple:

• review plateaus quarterly
• update implementation events when material changes occur
• retire obsolete work packages instead of preserving fiction
• challenge decommission assumptions explicitly
• review temporary architecture as a cost and risk item, not just as a technical detail

That last point matters more than people think. Temporary architecture has a nasty habit of becoming permanent if governance does not keep asking when it dies.

Common traps in EU public-sector and regulated environments

Some mistakes are especially common in public-sector, institutional, and regulated landscapes, and telecom shares many of them.

Roadmaps are written to satisfy funding approval rather than execution reality. Target states get fixed too early, while transition states are ignored because they are politically inconvenient. Procurement lots are mistaken for architecture increments. Compliance controls are modeled as if they were migration states. Decommissioning disappears from the roadmap because ownership is awkward and no one wants to carry the risk.

Telecom adds its own familiar complications: regulated interfaces, data residency constraints, multi-vendor landscapes, externally imposed deadlines, and dependencies on national infrastructure or partner ecosystems.

The lesson is not complicated. Treat constraints explicitly. Make coexistence visible. Separate administrative structures from architecture semantics. If something is politically awkward but architecturally real, model it anyway.

Especially that.

A practical method you can use next week

If I had to give a consulting team a lightweight method for Monday morning, it would be this:

1. Identify baseline pain and non-negotiable target outcomes.
2. Define three to five meaningful plateaus.
3. Identify the gaps between each plateau.
4. Derive work packages from gap closure and transition logic.
5. Add deliverables only where acceptance changes confidence.
6. Mark implementation events that matter to architectural decisions.
7. Create at least two views for different audiences.

And a few heuristics I trust:

If a plateau cannot be described operationally, refine it.

If a work package has no affected architecture elements, question it.

If temporary architecture is absent, you are probably missing risk.

If decommissioning is not modeled, your cost assumptions are suspect.

If Kafka appears in the target state but event ownership and quality are not addressed in the transition, you are doing aspirational integration architecture.

If IAM changes are treated as background plumbing, expect nasty surprises in channels, operations, and support.

For telecom specifically, I always check:

• systems of record
• product catalogue authority
• order orchestration ownership
• API maturity
• field operations impacts
• billing coexistence
• customer data authority
• IAM and federation implications
• event quality if using Kafka or similar
• decommission triggers, not just decommission aspirations

That checklist catches more bad roadmaps than most formal methods I have seen.

The awkward middle is the real architecture

Let’s come back to the opening failure mode.

The problem with many ArchiMate roadmaps is not that they are ugly. It is that they are too tidy. They show ambition without transition truth. They imply sequence without exposing dependency. They celebrate the target while concealing the temporary architecture, dual running, and operational compromises that determine whether the transformation can survive contact with reality.

The Implementation and Migration layer is valuable precisely because it can make those things explicit. Work packages. Deliverables. Plateaus. Gaps. Implementation events. Not as notation theatre, but as a way to describe survivable change.

In complex telecom transformation, the hard part is rarely imagining the target state. Most teams can draw a perfectly decent target in a week. The hard part is acknowledging the middle: the coexistence, the adapters, the interim IAM, the half-modern fulfilment, the duplicated data, the temporary controls, the things that are ugly but necessary.

Model that middle properly and your roadmap becomes governable.

Avoid it, and ArchiMate becomes just another polished fiction.

FAQ

How many plateaus are too many in one roadmap?

Usually, more than five in a single executive view is a warning sign. Domain views can support more, but if stakeholders cannot explain the difference between adjacent plateaus in operational terms, you probably have too many, or they are poorly defined.

Should implementation events match programme milestones exactly?

Not necessarily. Some programme milestones are administratively important but architecturally irrelevant. Use implementation events when they signal a meaningful change in architecture state or transition readiness.

Do I need to model every deliverable in ArchiMate?

No. Only the ones that materially enable transition or improve confidence in it. Otherwise, you clutter the model and people stop using it.

How do I represent temporary coexistence without cluttering the repository?

Use dedicated transition-state views. Keep the executive roadmap clean, then show temporary services, sync mechanisms, IAM bridges, and operational controls in focused domain or coexistence views.

Can procurement packages be shown as work packages?

Only when the scope genuinely aligns with a coherent architectural change. Often it does not. If you force that match, you distort the roadmap.

Frequently Asked Questions

What is enterprise architecture?

Enterprise architecture aligns strategy, business processes, applications, and technology. Using frameworks like TOGAF and languages like ArchiMate, it provides a structured view of how the enterprise operates and must change.

How does ArchiMate support enterprise architecture?

ArchiMate connects strategy, business operations, applications, and technology in one coherent model. It enables traceability from strategic goals through capabilities and application services to technology infrastructure.

What tools support enterprise architecture modeling?

The main tools are Sparx Enterprise Architect (ArchiMate, UML, BPMN, SysML), Archi (free, ArchiMate-only), and BiZZdesign. Sparx EA is the most feature-rich, supporting concurrent repositories, automation, and Jira integration.