The Telemetry Dashboard That Kept Crossing Layers
A retail bank is modeling a real-time fraud-alert dashboard. The lead architect has drawn a single diagram in which: a 'Fraud Analyst' business actor triggers a 'Review Alert' business process; that process is realized by an 'Alert Service' application component; the component is served by a 'Rules Engine' technology node; and a 'Dashboard Screen' business object is shown being used by the business process. During review, a stakeholder asks why the dashboard screen (a UI element) sits in the business layer while the alert service sits in the application layer, and whether the 'serving' relationship between the business process and the application component is correct. The architect insists 'it all works together, so one diagram is fine.' The team has 40 minutes to fix the model before a governance board.
1. Using ArchiMate layering and the service-orientation principle, identify the two most significant modeling errors in this diagram and explain why each violates the language's intent.
Read the worked answer
Error 1 - A UI screen modeled as a business object used by a business process. In ArchiMate the business layer expresses what the business does (behavior) and what it needs (business objects that are meaningful to the business, e.g., a fraud case or a customer record). A dashboard screen is a technology/application artifact. Modeling it as a business object conflates the application's internal structure with business meaning. The correct treatment: the screen is an application-layer element (or simply not modeled at the business layer at all); the business process should be served by an application service, not directly use a screen.
Error 2 - Direct 'serving' from business process to application component without going through a service. ArchiMate's service-orientation principle says a layer exposes services that higher layers consume; the realization relationship runs from the realizing element (application component) to the service it realizes, and the higher-layer element is served by that service. Drawing the business process straight to the component skips the application service and hides the contract. Correct pattern: Business Process --served by--> Application Service <--realization-- Application Component.
Judgement rule: one diagram may span layers (that is legitimate and common), but each element must stay in its own layer and connections must cross layers only via services. 'It all works together' is not a layering argument.
2. The architect proposes to fix things by simply relabeling the 'Dashboard Screen' as a 'business service.' Is that a valid fix? Justify with reference to what a business service must represent.
Read the worked answer
No - relabeling does not fix a layer error; it relocates it. A business service must represent a service the business offers to its environment (e.g., 'Fraud Alerting Service' offered to customers or regulators), with business meaning and typically a business interface. A screen is an internal application artifact with no external business contract.
A defensible correction is one of two moves:
- Promote the real service: model a business service 'Fraud Alert Notification' that the process realizes, and let an application service (realized by the alert component) serve it. The screen disappears from the business layer.
- Drop the screen from this view entirely: views should answer a stakeholder question; a governance board asking about fraud handling does not need UI widgets.
Exam-relevant point: ArchiMate distinguishes service (a unit of functionality exposed to the environment, with a contract) from interface (the access point) and from internal behavior. Calling an internal artifact a service to satisfy a layering rule inverts the semantics. The test is: does some external party consume this with an expectation of value? If not, it is not a service.