- actor is assigned to role
i.e. an actor is is able to fulfill a role - role is assigned to process
i.e. actors fulfilling a role execute the assigned process (or possibly: are allowed to execute that process if that is the preferred interpretation) - application component realizes application service
application service is used by process
application components offer their functionality to the (business) environment by means of services. The used by relation expresses that (actors involved in) processes use the functionality described by these application services
By using different types of components and different types of relations, architects should be able to craft fairly precise models on how the enterprise is structured architecturally. So far so good. But what if a relation type is missing? I.e., you want to express something for which there is no natural ArchiMate'ish expression?
Naturally, ArchiMate is setup to be a language that can easily be extended, either by adding concepts / relation types or by using profiles to add meaning to concepts / relations. However, in consulting assignments I have found that people are reluctant to do so, and tend to stick to the default set of concepts and relations.
Last week I ran into a situation where I was doing a session on the ArchiMate metamodel for a specific client. We ran into two situations where a "governs" relation type was required:
- actor governs actor
to express the fact that, for example, one department governs another, which is intended to mean that it oversees / facilitates the other department - process governs actor
to express the fact that, in a context where most processes are executed automatically by a machine (computer system), one process governs the other. More specifically, it triggers, pauses, updates information, reads status information, etcetera
