Deriving the Target-State Model

Copy-delete-paste produces a target model with no traceable link to the baseline and no record of why each change was made. When the programme is audited or the design changes, nobody can tell which elements were carried over unchanged, which were modified, and which are new. 'Tidying arrows' is especially risky because it hides semantic changes behind presentation edits.

A more defensible method:

1. Fix the baseline. Freeze the as-is model as a versioned baseline; do not edit it in place.
2. Derive, don't copy. Create the to-be as a derivation from the baseline, recording for each element whether it is retained, modified, removed, or added. A derivation relationship (or a change log keyed to element IDs) gives traceability.
3. Change one concern at a time. Apply the automation change, then the application retirement, then the orchestrator introduction, so each change is reviewable.
4. Re-validate relationships after each change. Deleting a manual station orphans its access and serving relationships; each orphan must be resolved deliberately, not by tidying.
5. Record rationale for each removal and addition against the programme objective.

The output is a to-be model plus a traceable change record, not just a redrawn picture.

The to-be model should not invent a parallel capability. The capability map already owns 'Sortation' at Level 2; the to-be model should realise it.

The standard pattern is a realisation relationship from the elements that deliver the capability to the capability itself. In practice:

• The to-be Business Processes (the automated sorting line) realise the 'Sortation' capability.
• The 'Sortation Orchestrator' application, via the application services it provides, contributes to the same capability - typically through the business process it supports, so the chain is Application Component → Application Service → (serving) Business Process → (realisation) Capability.

Direction: realisation points from the realising element to the capability (process → capability). Do not draw the capability realising the process.

This keeps one capability element as the single point of truth and lets the CIO see, for the same capability, which processes and applications deliver it in the to-be state - which is exactly the question the capability map was built to answer.

ArchiMate is not a scheduling language, so the model should capture the structural fact and leave the dates to a roadmap or plan.

The structural fact is that during the overlap both the old and new application components coexist and both support the sorting process. Model that directly:

• Keep the legacy applications in the to-be model as elements with a defined end state (e.g. marked as 'to be retired'), rather than deleting them, because they are still part of the to-be landscape during the overlap.
• Show both the new scanners/orchestrator and the legacy applications serving the relevant business process during the transition.
• If you need to distinguish states, use a plateau concept (baseline, transition, target) rather than inventing new element types.

For the three-month overlap specifically: record it in the transition/roadmap view or as a dated work package, not as a relationship in the core model. Putting durations on serving or flow relationships is not what those relationships mean, and it will mislead anyone reading the model as a static description. The model says what coexists; the roadmap says when.