10                 Language Extension Mechanisms

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 3 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 notation which most people would barely use. The remainder of this section is devoted to a number of possible extensions mechanisms that, in addition to the core, are or can become part of the ArchiMate language.

10.1             Adding Attributes to ArchiMate Concepts and Relations

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 [13]). A profile is a data structure which can be defined separate 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: Profile Example

10.2             Specialization of Concepts

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 for the “parent” concept may not be allowed for the specialization. A specialized concept strongly resembles a stereotype as it is used in UML. Specialization of concepts 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 are used.

Figure 55 shows a number of examples of concept specializations that have proven to be useful in several practical cases.

Figure 55: More Examples of Specialized Concepts

Also, the concepts in the layer-specific metamodels can be considered specializations of the concepts in the generic metamodel of Chapter 3.

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.