Archimate uses the “Business Object” element to model a passive entity representing a concept or a business entity manipulated by behavioral business elements.
Creating a catalog of “Business Objects” is useful when you need to analyze links among application, data, process areas.
Consider concepts like “Purchase Order” or “Supplier”: they may appear as data input or output, part of the data architecture, stakeholders, roles in process diagrams.
It’s also important to model the information associated with each Business Objects. For instance, a “Purchase Order” may carry information about the kind and quantity/quality of goods or services, contractual information, cost accounting details, internal organization references (requester, buyer, authorizer). These information can be modeled in two ways:
- using the “Meaning” element in Archimate;
- using an aggregation.
I don’t like the second, because, while a Purchase Order has a defined identity and unity, the details of goods, outside the Purchase Order context, is ambiguous, because the same information can be related to a Purchase Request, a Delivery, a stock adjustments, etc.
In my Company, Caltagirone Group, I adopted the first notation, obtaining this kind of diagrams:
The detailed list of information carried by a Business Objects came at hand when we analyze the dynamic of this data across Business processes. Consider an order approval process; at a certain point, we will perform the “Check budget availability” activity, described in the following BPMN fragment:
This activity uses as data input the Purchase Order, and (if successful) update its state.
In order to perform the activity, only some of the attributes of the Purchase Order are required.
Separately, we can build a matrix, linking the architectural aspect and the process view:
This matrix shows us the dependency existing between process: The “check budget activity” cannot be executed before the “Cost center attribution” activity in a different process.
Clearly, this simple example doesn’t show other kind of constraints existing, that have influence on process execution, but is useful when we perform any gap and impact analysis according to the TOGAF framework, during the analysis phase of an organizational or software (usually both) change project.
Furthermore, it support any analysis on process optimization: for example, “Legal approval” activity doesn’t require all the information required by “Check budget”; maybe it can be performed before, or in parallel, with the other activity.