Information domain

Uit Via Nova Architectura Wiki
Versie door Mdd (Overleg | bijdragen) op 16 jan 2014 om 14:43

(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Ga naar: navigatie, zoeken
Figure 2 02 Most Important relationships between concepts.png ArchiMate Made Practical

Zie ook: ArchiMate in de praktijk

Inhoud

Question

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?

Solution

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 2 05 Simple information model .png

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.

Consequences

Not applicable.

Alternatives

a more detailed variant looks as follows:

Figure 2 06 Detailed informationmodel.png

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

Not applicable.

Persoonlijke instellingen
Naamruimten

Varianten
Handelingen
Navigatie
Hulpmiddelen