|ArchiMate Made Practical|
Zie ook: ArchiMate in de praktijk
In our organization it is important to have a clear framework of concepts. To do this I would like to use an information model (business object model). How can I do this with ArchiMate modeling and what types of relationships can I use between the objects?
We can illustrate the answers to these questions with the fictitious example below. : The business rules we wish to describe are as follows: ‘An Employment object holds information about the relationship between an employee and an employer. Based on the Employment the Employee is obliged to be insured in the context of a certain Social Security Law. In addition, a non-worker can insure themselves on a voluntary basis. Within the Employment there are Working Periods which are distinguished by constant properties (e.g. wage data)’.
A simple model based on the description above is as follows:
- Figure 5: High-level information model
The relationships between business objects in this variant are indicated by associations. Associations are the weakest and most general form of relationship in ArchiMate and serve only to show that there is a relationship between the business objects. The example above is therefore semantically weak, though not incorrect. The reader can determine that; there are associations between the business objects, but what they mean is not expressed.
A model such as that shown above is eminently suitable for communication with stakeholders who have little or no knowledge of data modeling, such as stakeholders from the business or from management. They are also useful when modeling at an intermediate stage in which the information model is still being developed but the precise relationships between the information object is not yet known.
a more detailed variant looks as follows:
- Figure 6: Detailed information model
The relationships between business objects are styled by stronger forms of relationship types. This gives the model more meaning. In the example, the following relation types are used:
- Aggregation: The employment is an aggregation of an employee and an employer.
- Composition: The employment contains working periods.
- Specialization: An employee is a specialization of a natural person as well as the insured.
- Realization: The employment contract is a realization of an employment
In ArchiMate, it is not possible by default to add cardinality and optionality to these relationships. Specific domain languages (such as UML) are meant for that. Such properties can, however, be added in some tools.
In situations where the target audience is familiar with data modeling, and/or when there is a need for a more precise definition of the relationships between information objects, this second variant is better suited than the first variant.
It is of course also possible to derive the first variant from the second variant in case we need to do so for communication purposes, since it is only the level of abstraction (generality) that is being altered in the view. The pattern of associations remains identical. Thereby the simplified view can be displayed, even while it is under-pinned by the more detailed model.
Relationships with other good practices