The Order-to-Cash Plateau
A retail bank has modelled its order-to-cash process. The process has three sub-processes: Capture Order, Fulfil Order, and Invoice Customer. A junior modeller has drawn Fulfil Order and Invoice Customer each as a separate Business Process, with a data object 'Order Record' as input to both, and has added a Business Actor 'Customer' with a triggering relationship directly into Capture Order. The architecture board complains the diagram 'shows the customer doing work' and that the two downstream processes 'look parallel even though invoicing only starts after fulfilment completes'. A separate reviewer notes the Order Record is shown twice, once per process, and asks whether that is legal.
1. Evaluate the junior modeller's use of the triggering relationship from Customer into Capture Order. Is it correct, and what is the cleanest fix if not?
Read the worked answer
A Business Actor may be the source of a triggering relationship to a Business Process, so the arrow itself is legal. The board's complaint is a semantic one: a trigger means the process is started by the event, and modelling the actor as the trigger implies the actor performs a hand-off event rather than being the party whose request initiates the behaviour.
The cleaner pattern depends on intent:
- If the customer's request is the initiating event, model a Business Event (e.g. 'Order Requested') and trigger the process from that event, with the Customer as the actor that causes the event (or as the process's serving actor via a serving relationship).
- If you want to say the process serves the customer, use serving from the process to the actor, not triggering.
Recommendation: keep the trigger but source it from a Business Event, and add a serving relationship from Capture Order to Customer. This removes the 'customer does work' reading and preserves the initiation semantics.
2. The reviewer asks whether showing 'Order Record' as input to both Fulfil Order and Invoice Customer is legal, and how to represent that invoicing only starts after fulfilment. Answer both.
Read the worked answer
Legality: Yes. A Business Object may be the source of multiple access relationships; each is a separate access instance. There is no rule that a data object can have only one consuming process. So the duplication is not an error.
However, the meaning matters. If both processes read the same record, use access (read) from each process to a single Business Object. If one process updates it, mark that access as write. Drawing two separate object symbols is a presentation choice; the model should have one Business Object element with two access relationships.
Sequencing: The diagram shows no ordering, so the reader infers parallelism. Fix it with the correct dependency:
- If invoicing is a distinct process that must follow fulfilment, add a triggering relationship from Fulfil Order to Invoice Customer (the completion event triggers invoicing).
- If invoicing is really a step inside fulfilment, it should be a sub-process or a Business Service invoked within Fulfil Order, not a peer process.
Do not use a flow relationship between two processes to mean 'sequence' - flow is for passing something (e.g. a value or object) between behaviours, and it does not by itself assert temporal order in the way triggering does.
3. The junior modeller wants to nest all three sub-processes inside a parent 'Order-to-Cash' process. What does ArchiMate say about this, and what caveat applies to the access relationships?
Read the worked answer
Composition (or aggregation) of Business Processes is permitted: a process may be composed of sub-processes. Nesting the three sub-processes inside 'Order-to-Cash' is valid and is a common way to show decomposition without inventing new element types.
Caveats:
- Access relationships do not automatically inherit. If 'Order Record' is accessed by a sub-process, the access is between that sub-process and the object, not between the parent and the object, unless you also draw it. Do not assume the parent 'owns' the access.
- Triggering across the boundary. If the parent is triggered by the Order Requested event, the trigger attaches to the parent; the sub-processes are still individually triggered as drawn. Mixing parent-level and child-level triggers can create confusing double-initiation - pick one level for the external trigger.
- Composition vs aggregation. Use composition when the sub-processes are wholly part of the parent and cannot exist independently; aggregation if they are shared or independently meaningful. For an order-to-cash pipeline, composition is usually the honest choice.
Result: nest for decomposition, but re-draw the access relationships at the level where the reading/writing actually happens.