Every specific purpose and usage of an architecture modeling language brings about its own specific demands on the language. Yet, it should be possible to use a language for only a limited, though non-specific, modeling purpose. Therefore, the ArchiMate core language, embedded in the ArchiMate metamodel, as described in Chapters 2 to 7, contains only the basic concepts and relationships that serve general enterprise architecture modeling purposes. However, the language should also be able to facilitate, through extension mechanisms, specialized, or domain-specific purposes, such as:
• Support for specific types of model analysis
• Support the communication of architectures
• Capture the specifics of a certain application domain (e.g., the financial sector)
The argument behind this statement is to provide a means to allow extensions of the core language that are tailored towards such specific domains or applications, without burdening the core with a lot of additional concepts and notations which most people would barely use. The remainder of this section is devoted to a number of possible extension mechanisms that, in addition to the core, are or can become part of the ArchiMate language.
As said before, the core of ArchiMate contains only the concepts and relationships that are necessary for general architecture modeling. However, users might want to be able to, for example, perform model-based performance or cost calculations, or to attach supplementary information (textual, numerical, etc.) to the model elements. A simple way to enrich ArchiMate concepts and relationships in a generic way is to add supplementary information by means of a “profiling” specialization mechanism (see also [11]). A profile is a data structure which can be defined separately from the ArchiMate language, but can be dynamically coupled with concepts or relationships; i.e., the user of the language is free to decide whether and when the assignment of a profile to a model element is necessary. Profiles can be specified as sets of typed attributes, by means of a profile definition language. Each of these attributes may have a default value that can be changed by the user.
We can distinguish two types of profiles:
• Pre-defined profiles: These are profiles that have a predefined attribute structure and can be implemented beforehand in any tool supporting the ArchiMate language. Examples of such profiles are sets of attributes for ArchiMate concepts and relationships that have to be specified in order to execute common types of analysis.
• User-defined profiles: Through a profile definition language, the user is able to define new profiles, thus extending the definition of ArchiMate concepts or relationships with supplementary attribute sets.
Example
Table 25 below shows possible profiles with input attributes needed for certain types of cost and performance analysis of architecture models [19]. Each “used by” relationship may have a weight (indicating the average number of uses); each (business, application, or infrastructure) “service” may have fixed and variable costs and an (average) service time; and each structure element (e.g., business role, business actor, application component, device) may have fixed and variable costs and a capacity.
Table 25: Profile Example
|
“Used By” Profile |
“Service” Profile |
“Structure Element” Profile |
|||
|
Attribute |
Type |
Attribute |
Type |
Attribute |
Type |
|
Weight |
Real |
Fixed cost |
Currency |
Fixed cost |
Currency |
|
|
|
Variable cost |
Currency |
Variable cost |
Currency |
|
|
|
Service time |
Time |
Capacity |
Integer |
Specialization is a simple and powerful way to define new concepts based on the existing ones. Specialized concepts inherit the properties of their “parent” concepts, but additional restrictions with respect to their use may apply. For example, some of the relationships that apply to the “parent” concept need not be allowed for the specialization.
Specialization of relationships is also allowed. Similar to specialization of concepts, a specialized relationship inherits all properties of its “parent” relationship, with possible additional restrictions. For example, two specializations of the assignment relationship may be used to model responsibility versus accountability. Another example is a specialization of the flow relationship to model material flow in a supply chain. Specialization of the specialization relationship itself is not allowed.
A specialized concept or relationship strongly resembles a stereotype as it is used in UML. Specialization of concepts and relationships provides extra flexibility, as it allows organizations or individual users to customize the language to their own preferences and needs, while the underlying precise definition of the concepts is conserved. This also implies that analysis and visualization techniques developed for the ArchiMate language still apply when the specialized concepts or relationships are used.
Figure 60 shows a number of examples of concept and relationship specializations that have proven to be useful in several practical cases.
Figure 60: Examples of Specialized Concepts and Relationships
As the above examples indicate, we may introduce a new graphical notation for a specialized concept, but usually with a resemblance to the notation of the parent concept; e.g., by adding or changing the icon. It is also possible to use a <<stereotype>>-notation as in UML. Finally, for a specialized concept, certain attributes may be predefined, as described in the previous section.
Downloads of the ArchiMate documentation, are available under license from the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document C13L.