Gap Analysis Before a Migration: Modeling the Baseline and Target
A media company plans to replace a monolithic 'Content Management System' (CMS) with a microservices platform over 18 months. The architect must present a migration plan to the steering committee. Current state: the CMS is an application component realized by a single technology node; it provides a 'Content Publishing' application service consumed by the 'Publish Article' business process. Target state: three application components (Authoring, Rendering, Distribution) each providing a service, all on a container platform. The committee specifically wants to see what changes, what stays, and what is at risk during the transition. A colleague suggests simply drawing the target-state diagram and 'mentioning the current state in the slide notes.'
1. Explain why a target-only diagram is insufficient for this request, and describe how ArchiMate represents baseline, target, and the transition itself.
Read the worked answer
Why target-only fails: The committee asked three questions - what changes, what stays, what is at risk during transition. A target-only diagram answers none of them: it cannot show what is being removed, what is preserved, or what must coexist during cutover. The 'slide notes' approach loses traceability and cannot be validated.
ArchiMate representation:
- Baseline architecture - the current CMS, its node, and the 'Content Publishing' service as-is.
- Target architecture - the three components and the container platform.
- Transition architectures - intermediate states (e.g., Month 6: Authoring service live, CMS still serving Rendering/Distribution). These are first-class: a migration is a sequence of plateaus, not a single jump.
- Implementation & Migration elements - work packages (e.g., 'Build Authoring Service'), deliverables, and plateaus to sequence them; gaps can be expressed as the difference between baseline and target (e.g., a service present in target but absent in baseline).
Judgement rule: when a stakeholder asks about change over time, baseline + target + at least one transition plateau is the minimum honest model. A target-only view is a future-state view, appropriate for a different question ('where are we going?'), not for 'how do we get there safely?'
2. During transition, both the legacy CMS and the new Authoring service will provide a 'Content Publishing' service simultaneously for about four months. How should this be modeled, and what risk does the model surface?
Read the worked answer
Model it explicitly as coexistence, not as a replacement. In the transition plateau, show both the CMS and the Authoring component realizing/ providing a service that the 'Publish Article' process consumes. If the two services are distinguishable (e.g., legacy vs. new), model two services (or one service with two realizing components) and show the business process served by whichever is active - and be explicit about routing.
Risks the model surfaces:
- Ambiguous provider - if both components realize the same service, the model shows two providers; the committee must decide routing/ownership. This is exactly the kind of risk a baseline/target model exposes that a target-only diagram hides.
- Dual-running cost and data divergence - two content stores during coexistence; the model can show the data objects each touches to make divergence visible.
- Cutover dependency - the 'Publish Article' process depends on a service whose provider is changing; the model should show the work package that retires the CMS and the plateau at which the new provider becomes sole.
Judgement: a model that shows only the target would have presented this four-month overlap as a clean switch - misleading the committee about risk. The value of the transition view is precisely that it makes the messy middle visible.