Business information modeling with Archimate

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:
Archimate PO Business Object

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:
BPMN activity frag
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:
Information/process matrix
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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s