The Ambiguous Application Interface
An insurance firm is documenting a claims platform. The solution architect has drawn: a Business Service 'Claim Registration', realised by an Application Service 'Register Claim', which is realised by two Application Components - 'Web Portal' and 'Claims Engine'. The Web Portal calls the Claims Engine over a REST API. The architect has drawn a single serving relationship from Web Portal to Claims Engine and labelled it 'REST'. A reviewer objects that (a) the Application Service is realised by two components, which 'double-counts' the service, and (b) a serving relationship is the wrong way to show an API call. The architect also wants to show that the Claims Engine depends on a mainframe database, and has drawn a dependency from the Application Component straight to a Technology Node.
1. Is it valid for one Application Service to be realised by two Application Components? Explain how realisation works and what the reviewer may actually be seeing.
Read the worked answer
Yes, it is valid. Realisation is many-to-many: an Application Service can be realised by more than one Application Component, and a component can realise more than one service. The reviewer's 'double-counting' worry is a misreading - two realisations do not create two services.
What the reviewer may actually be objecting to is granularity. If 'Register Claim' is realised partly by the Web Portal and partly by the Claims Engine, the service is really an aggregate of two finer-grained services. The cleaner model is often:
- Web Portal realises an Application Service such as 'Claim Capture UI'.
- Claims Engine realises 'Claim Persistence'.
- A composed 'Register Claim' service is realised by both, or the two services are composed into the higher-level one.
So the answer is: legal as drawn, but check whether the service is being used to hide two distinct capabilities. If so, decompose rather than flatten.
2. The architect drew a serving relationship from Web Portal to Claims Engine, labelled 'REST'. Critique this and give the correct modelling.
Read the worked answer
Two problems.
- Direction and meaning. Serving means 'provides functionality to'. Web Portal uses the Claims Engine's functionality, so if anything the Claims Engine serves the Web Portal - the arrow should run from Claims Engine to Web Portal. As drawn, it says the portal provides functionality to the engine, which is backwards for a call.
- The label 'REST' is not an ArchiMate concept. A protocol is not a relationship type. If you need to capture the API, model it explicitly.
Correct patterns:
- Serving: Claims Engine → serving → Web Portal (the engine provides its capability to the portal).
- Explicit interface: model an Application Interface 'Claims REST API' as part of (composition) the Claims Engine, and have the Web Portal access or be served through it. This is where the protocol belongs - as an attribute or name on the interface, not on the relationship.
- Flow if you need to show data passing at runtime: Web Portal → flow → Claims Engine, carrying the claim data.
Recommendation: serving from engine to portal, plus an Application Interface owned by the engine, with the protocol recorded on the interface.
3. The architect drew a dependency from the Claims Engine (Application Component) directly to a Technology Node. Is this acceptable, and what would you recommend?
Read the worked answer
It is syntactically legal - dependency is a catch-all and ArchiMate does not forbid cross-layer dependency - but it is a weak and often misleading choice.
Why it is weak:
- A dependency says 'some dependency exists' without saying what kind. The reader cannot tell whether the engine is hosted on the node, uses a service the node provides, or merely needs it to exist.
- It skips the Technology layer's own semantics, so the model loses the ability to answer 'which technology service does this app consume?'
Better modelling:
- If the engine is hosted on the node: use assignment (Application Component assigned to Technology Node), or model the node as realising a Technology Service and have the component served by it.
- If the engine uses a database: model a Technology Service (or a System Software / Artifact) for the database, have the node realise or host it, and draw serving from the service to the Application Component.
- Reserve dependency for genuinely unclassified dependencies, and prefer a more specific relationship wherever one exists.
Recommendation: replace the dependency with assignment (hosting) plus a serving relationship to a Technology Service for the data store.