The Merged Model That Wouldn't Reconcile
Two business units of a manufacturer each maintained their own ArchiMate model. Unit A models 'Order Management' as a Business Process; Unit B models 'Order Management' as a Business Service. Both have an element called 'Customer Master' - in A it is a Business Object, in B it is a Data Object in the application layer. A merger programme wants a single group model. The integration architect proposes to merge by name: anything called 'Order Management' becomes one element, anything called 'Customer Master' becomes one element, and the type differences are 'just notation'. A data governance lead objects that merging the two Customer Master elements would create a single point of truth that does not exist in reality, because the two units hold different customer records.
1. Evaluate the 'merge by name' proposal. What is wrong with it in ArchiMate terms?
Read the worked answer
Merge-by-name conflates identity with label. In ArchiMate, an element's identity is its type plus its definition, not its name. Two elements with the same name but different types are different things:
- 'Order Management' as a Business Process and as a Business Service are not the same element. A process is a behaviour; a service is an externally visible capability. Merging them destroys the distinction the modellers made and will mislead anyone reading the merged model.
- 'Customer Master' as a Business Object and as a Data Object sit in different layers with different meanings: the business-level concept versus its application-level representation. They may be related (realisation or representation) but they are not identical.
The phrase 'just notation' is the tell: type is semantics, not decoration. Merging on name alone produces a model that looks unified but asserts identities that are not true. The correct first step is a reconciliation: for each name collision, decide whether the elements are the same concept, related concepts, or genuinely different concepts.
2. How should the two 'Order Management' elements be reconciled, and how should the process/service pair be represented in the merged model?
Read the worked answer
First establish what each unit actually meant. It is common for one unit to model the behaviour and the other the service exposed by the same capability - in which case they are related, not identical.
If they are the same underlying capability:
- Keep one Business Service 'Order Management' as the externally visible offering.
- Keep (or create) the Business Process that realises it, and draw realisation from the process to the service.
- If the two units genuinely run separate processes, keep both processes and let both realise the single service, or keep two services if the offerings differ.
If they are genuinely different concepts that happen to share a name:
- Rename to disambiguate (e.g. 'Order Management (Unit A process)' vs 'Order Management Service (Unit B)').
- Do not force a merge; record the relationship (if any) explicitly.
The merged model should show the process/service relationship where it is real, and the naming should make the distinction legible to readers who knew only one unit's model.
3. The governance lead says the two Customer Master elements must stay separate. How do you model that while still giving the group a coherent view?
Read the worked answer
Accept the governance constraint: if the two units hold different customer records, a single Business Object would assert a single source of truth that does not exist. Keep them separate.
Model it as:
- Two Business Objects, e.g. 'Customer Master (Unit A)' and 'Customer Master (Unit B)', each owned by its unit's process.
- Their application-layer representations as separate Data Objects, each related to its own business object (via realisation or representation, depending on how you read the relationship).
- If there is any synchronisation between them, model it explicitly - a data flow or a process that reconciles them - rather than implying it by merging.
- If the group wants a single conceptual 'Customer' for reporting, introduce a separate higher-level concept and relate the two unit-level objects to it (e.g. via specialisation or a realisation to a group-level business object), so the group view is an abstraction over two realities, not a false identity.
This gives the group a coherent picture while preserving the governance truth: two records, two owners, an explicit relationship between them.