3                       Language Structure

The unambiguous specification and description of enterprise architecture’s components and especially of their relationships requires an architecture modeling language that addresses the issue of consistent alignment and facilitates a coherent modeling of enterprise architectures.

This chapter presents the construction of the ArchiMate architecture modeling language. The precise definition and illustration of its generic set of concepts follow in Chapters 4, 5, 6, 7, and 8. They provide a proper basis for visualization, analysis, tooling, and use of these concepts.

Sections 3.1 through 3.5 discuss some general ideas, principles, and assumptions underlying the development of the ArchiMate metamodel. Section 3.6 presents the ArchiMate framework, which will be used in the remainder of this document as a reference taxonomy scheme for architecture concepts, models, viewpoints, and views.

3.1                Design Approach

A key challenge in the development of a general metamodel for enterprise architecture is to strike a balance between the specificity of languages for individual architecture domains, and a very general set of architecture concepts, which reflects a view of systems as a mere set of inter-related entities. Figure 2 illustrates that concepts can be described at different levels of specialization.

Figure 2: Metamodels at Different Levels of Specificity

At the base of the triangle we find the metamodels of the architecture modeling concepts used by specific organizations, as well as a variety of existing modeling languages and standards; UML is an example of a language in this category. At the top of the triangle we find the “most general” metamodel for system architectures, essentially a metamodel that merely comprises notions such as “object”, “component”, and “relation”.

The design of the ArchiMate language started from a set of relatively generic concepts (higher up in the pyramid). These were then specialized towards application at different architectural layers, as will be explained below.

The most important design restriction on the language is that it has been explicitly designed to be as small as possible, but still usable for most enterprise architecture modeling tasks. Many other languages, such as UML 2.0, try to accommodate all needs of all possible users. In the interest of simplicity of learning and use, ArchiMate has been limited to the concepts that suffice for modeling the proverbial 80% of practical cases.

3.2                Core Concepts

The language consists of active structure elements, behavioral elements and passive structure elements. The active structure elements are the business actors, application components and devices that display actual behavior, i.e., the ‘subjects’ of activity (right side of the Figure 3). Then there is the behavioral or dynamic aspect (center of Figure 3). The active structure concepts are assigned to behavioral concepts, to show who or what performs the behavior.

Figure 3: Generic Metamodel: The Core Concepts of ArchiMate

The passive structure elements are the objects on which behavior is performed. In the domain of information-intensive organizations, which is the main focus of the language, these are usually information or data objects, but they may also be used to represent physical objects. These three aspects – active structure, behavior, and passive structure – have been inspired by natural language, where a sentence has a subject (active structure), a verb (behavior), and an object (passive structure).

Second, we make a distinction between an external view and an internal view on systems. When looking at the behavioral aspect, these views reflect the principles of service orientation. The service concept represents a unit of essential functionality that a system exposes to its environment, and it provides a certain value (monetary or otherwise), which thus provides the motivation for the service’s existence. For the external users, only this external functionality and value, together with non-functional aspects such as the quality of service, costs, etc., are relevant. These can be specified in a contract or Service Level Agreement (SLA). Services are accessible through interfaces, which constitute the external view on the active structural aspect.

3.3                Collaboration and Interaction

Going one level deeper in the structure of the language, we distinguish between behavior that is performed by a single structure element (e.g., actor, role component, etc.), or collective behavior (interaction) that is performed by a collaboration of multiple structure elements.

A collaboration is a (temporary) grouping (or aggregation) of two or more structure elements, working together to perform some collective behavior. This collective behavior can be modeled as an interaction.

Figure 4: Collaboration and Interaction

3.4                Relationships

Next to the core concepts outlined above, ArchiMate contains a core set of relationships. Several of these relationships have been adopted from corresponding relationship concepts that occur in existing standards; e.g., relationships such as composition, aggregation, association, and specialization are taken from UML 2.0, while triggering is used in many business process modeling languages.

Note:      For the sake of readability, the metamodel figures in the next sections do not show all possible relationships in the language. Refer to Section 8.5 on additional derived relationships. Furthermore, aggregation and composition relationships are always permitted between two elements that have the same type.

3.5                Layering

The ArchiMate language defines three main layers (depicted with different colors in the examples in the next chapters), based on specializations of the core concepts described in Sections 3.2 and 3.3:

1.          The Business Layer offers products and services to external customers, which are realized in the organization by business processes performed by business actors.

2.          The Application Layer supports the business layer with application services which are realized by (software) applications.

3.          The Technology Layer offers infrastructure services (e.g., processing, storage, and communication services) needed to run applications, realized by computer and communication hardware and system software.

The general structure of models within the different layers is similar. The same types of concepts and relations are used, although their exact nature and granularity differ. In the next chapters, we will specialize these concepts to obtain more concrete concepts, which are specific for a certain layer. Figure 3 shows the central structure that is found in each layer.

In line with service orientation, the most important relation between layers is formed by “used by” relations, which show how the higher layers make use of the services of lower layers. (Note, however, that services may not only be used by elements in a higher layer, but also by elements in the same layer, as is shown in Figure 3.) A second type of link is formed by realization relationships: elements in lower layers may realize comparable elements in higher layers; e.g., a “data object” (Application layer) may realize a “business object” (Business layer); or an “artifact” (Technology layer) may realize either a “data object” or an “application component” (Application layer).

3.6                The ArchiMate Framework

The aspects and layers identified in the previous sections can be organized as a framework of nine “cells”, as illustrated in Figure 5. The cells in this framework are a subset of the cells in, for example, the Zachman framework [5], [9]. Often used architectural domains can be projected into this framework; Figure 5 shows an example of this.

It is important to realize that the classification of concepts based on conceptual domains, or based on aspects and layers, is only a global one. It is impossible to define a strict boundary between the aspects and layers, because concepts that link the different aspects and layers play a central role in a coherent architectural description. For example, running somewhat ahead of the later conceptual discussions, (business) functions and (business) roles serve as intermediary concepts between “purely behavioral” concepts and “purely structural” concepts.

Figure 5: Architectural Framework

Besides the core aspects shown in Figure 5 (passive structure, behavior, and active structure), which are mainly operational in nature, there are a number of other important aspects, some of which may cross several (or all) conceptual domains; for example:

         Goals

         Security

         Governance

         Costs

         Performance

         Timing

         Planning and evolution

The aspects may be added to the models by means of additional concepts, relationships, or attributes. Also, it may be useful to add concepts or attributes related to the design process rather than to the system or organization that is to be described or designed. Examples of such concepts or attributes are requirements and design decisions. These aspects may be addressed in future extensions of the language (see Chapter 1 for a more thorough discussion of this).