2                      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 core concepts and relationships follow in Chapters 3, 4, 5, 6, and 7. The concepts and relationships of the two language extensions are described in more detail in Chapters 10 and 11. They provide a proper basis for visualization, analysis, tooling, and use of these concepts and relationships.

Sections 2.1 through 2.5 discuss some general ideas, principles, and assumptions underlying the development of the ArchiMate metamodel. Section 2.6 presents the ArchiMate Framework, which is used in the remainder of this document as a reference taxonomy scheme for architecture concepts, models, viewpoints, and views. Sections 2.7 and 2.8 describe the basic structure of the two language extensions. Section 2.9 briefly describes the relationship between ArchiMate and TOGAF.

2.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 1 illustrates that concepts can be described at different levels of specialization.

Figure 1: 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 “entity” and “relation”.

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

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.

2.2                 Core Concepts

The core language consists of three main types of elements (note, however, that the model elements often represent classes of entities in the real world): active structure elements, behavior elements, and passive structure elements (objects). 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 2).

Then there is the behavioral or dynamic aspect (center of Figure 2). The active structure concepts are assigned to behavioral concepts, to show who or what performs the behavior.

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, passive structure elements 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.

Figure 2: Generic Metamodel: The Core Concepts of ArchiMate[1]

Thus, the service is the externally visible behavior of the providing system, from the perspective of systems that use that service; the environment consists of everything outside this providing system. The value provides the motivation for the service’s existence. For the external users, only this exposed 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.

An interface provides an external view on the service provider and hides its internal structure.

2.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.

This collective behavior can be modeled as an interaction.

Figure 3: Collaboration and Interaction

2.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 7.5 on additional derived relationships. Furthermore, aggregation, composition, and specialization relationships are always permitted between two elements that have the same type.

2.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 2.2 and 2.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 relationships are used, although their exact nature and granularity differ. In Chapters 3, 4, and 5, we further develop these concepts to obtain concepts specific to a particular layer. Figure 2 shows the central structure that is found in each layer.

In line with service orientation, the most important relationship between layers is formed by “used by” relationships, which show how the higher layers make use of the services of lower layers. (Note, however, that services need not only be used by elements in a higher layer, but also can be used by elements in the same layer.) 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).

2.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 4.

It is important to realize that the classification of concepts 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 4: Architectural Framework

The structure of the framework allows for modeling of the enterprise from different viewpoints, where the position within the cells highlights the concerns of the stakeholder. A stakeholder typically can have concerns that cover multiple cells.

The dimensions of the framework are as follows:

•           Layers: The three levels at which an enterprise can be modeled – business, application, and technology:

—  The business layer offers products and services to external customers, which are realized in the organization by business processes.

—  The application layer supports the business layer with application services that are realized by (software) applications.

—  The technology layer offers infrastructure services (e.g., processing, storage, and communication services) needed to support applications, realized by computer and communication hardware and system software.

•           Aspects:

—  The active structure aspect represents the structural concepts (the business actors, application components, and devices that display actual behavior; i.e., the “subjects” of activity).

—  The behavior aspect represents the behavior (processes, functions, events, and services) performed by the actors. Behavioral concepts are assigned to structural concepts, to show who or what displays the behavior.

—  The passive structure aspect represents the objects on which behavior is performed. These are usually information objects in the business layer and data objects in the application layer, but they may also be used to represent physical objects.

Besides the core aspects shown in Figure 4 (passive structure, behavior, and active structure), which are mainly operational in nature, the work of an enterprise architect touches upon numerous other aspects, not explicitly covered by the ArchiMate Framework, some of which may cross several (or all) conceptual domains; for example:

•           Goals, principles, and requirements

•           Risk and security

•           Governance

•           Policies and business rules

•           Costs

•           Performance

•           Timing

•           Planning and evolution

Not all of these aspects can be completely covered using the standard language extension mechanisms as described in Chapter 9. In order to facilitate tool vendors and methodology experts in providing support for these aspects within the overall ArchiMate language, specific extensions can be added. These modular extension add new concepts, relationships, or attributes, while complying to the design restriction that ArchiMate is explicitly designed to be as small as possible.

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.

This issue of the specification addresses two such extensions: the Motivation extension and the Implementation and Migration extension. The Motivation extension is introduced in the next section and elaborated in more detail in Chapter 10. The Implementation and Migration extension is introduced in Section 2.8 and elaborated in more detail in Chapter 11. Other aspects may be addressed in future extensions of the language (see Chapter 12 for a more thorough discussion of this).

2.7                 Motivation Extension

The core concepts of ArchiMate focus on describing the architecture of systems that support the enterprise. Not covered are the elements which, in different ways, motivate the design and operation of the enterprise. These motivational aspects correspond to the “Why” column of the Zachman framework [8], which was intentionally left out of scope in the design of ArchiMate 1.0.

The Motivation extension of ArchiMate adds the motivational concepts such as goal, principle, and requirement. It addresses the way the enterprise architecture is aligned to its context, as described by motivational elements.

In addition, the Motivation extension recognizes the concepts of stakeholders, drivers, and assessments. Stakeholders represent (groups of) persons or organizations that influence, guide, or constrain the enterprise. Drivers represent internal or external factors which influence the plans and aims of an enterprise. An understanding of strengths, weaknesses, opportunities, and threats in relation to these drivers will help the formation of plans and aims to appropriately address these issues.

Figure 5 depicts that the core elements of an architectural description are related to motivational elements via requirements. Goals and principles have to be translated into requirements before core elements, such as services, processes, and applications, can be assigned that realize them. The possible relationships among motivational elements are explained in Chapter 10.

Another relationship between the core metamodel and the Motivation extension is that a business actor may be assigned to a stakeholder, which can be seen as a motivational role (as opposed to an operational business role) that an actor may fulfill.

The main reason to introduce motivational concepts in ArchiMate is to support requirements management and to support the Preliminary Phase and Phase A (Architecture Vision) of the TOGAF ADM, which establish the high-level business goals, architecture principles, and initial business requirements.

Requirements management is an important activity in the process of designing and managing enterprise architectures. Goals from various stakeholders form the basis for any change to an organization. These goals need to be translated into requirements on the organization’s architecture. This architecture should reflect how the requirements are realized by services, processes, and software applications in the day-to-day operations. Therefore, the quality of the architecture is largely determined by the ability to capture and analyze the relevant goals and requirements, the extent to which they can be realized by the architecture, and the ease with which goal and requirements can be changed.

Figure 5: Relationship between Core and Motivational Elements in ArchiMate

Principles and requirements are strongly related [3]. Principles are general rules and guidelines that help inform and support the way in which an organization sets about fulfilling its mission. In contrast, requirements constrain and shape a specific design of some enterprise architecture. This corresponds to the distinction between two commonly used interpretations of enterprise architecture: (i) as the structure of some organization in terms of its components and their relationships, and (ii) as a set of principles that should be applied to any such structure.^[2] The scope of the first interpretation concerns a single design of the organization, whereas the second concerns any possible design. Requirements are associated with the first interpretation. Instead, principles are independent of a specific design and have to be specialized into requirements in the process of designing the organization’s architecture. This makes the application of principles an important part of requirements management.

Inadequate requirements management is one of the main causes of impaired or failed IT projects [21], due to exceeding budgets or deadlines, or not delivering the expected results. This is well phrased by the following quote of Brooks [22]: “No other part of the work so cripples the resulting system if done wrong”. Therefore, the requirements management process and the architecture development process need to be well-aligned, and traceability should be maintained between requirements and the architectural elements that realize these requirements.

In the TOGAF Architecture Development Method (ADM) [4], requirements management is a central process that applies to all phases of the ADM cycle. While TOGAF presents “requirements” on requirements management, it refrains from mandating or recommending existing languages, methods, and tools from the area of requirements engineering. ArchiMate supports the requirements management process by means of the motivational concepts.

2.8                 Implementation and Migration Extension

The Implementation and Migration extension of ArchiMate adds concepts to support the late ADM phases, related to the implementation and migration of architectures: Phase E (Opportunities and Solutions), Phase F (Migration Planning), and Phase G (Implementation Governance).

This extension includes concepts for modeling implementation programs and projects to support program, portfolio, and project management, and a plateau concept to support migration planning. The proposed extension aims at covering the main concepts of program and project management standards and best practices, such as MSP [23], PRINCE2 [24], and PMBoK [25]. Concepts that are specific to one of these methods are not part of the extension, but may be defined as specialization of the generic concepts. In this way, the set of concepts and relationships that are defined in the extension is kept at a minimum.

Furthermore, concepts or relationships from the ArchiMate core or the Motivation extension are re-used where possible. Figure 6 depicts the relationship between concepts from the Implementation and Migration extension and concepts from the ArchiMate core and Motivation extension. A deliverable may realize core elements within an architecture. A gap may be associated with any number of core elements. A location may be assigned to work packages and deliverables. A work package realizes requirements indirectly through the realization of core elements (e.g., an application component, business process, or service). Also, core elements are linked to the other concepts of the Motivation extension by means of derived relationships. The possible relationships among implementation and migration, core, and motivational elements are explained in more detail in Chapters 10 and 11.

Figure 6: Relationships between Motivational, Core, and Implementation and Migration Elements

2.9                 ArchiMate and TOGAF

The ArchiMate language, as described in this Technical Standard, complements TOGAF [4] in that it provides a vendor-independent set of concepts, including a graphical representation, that helps to create a consistent, integrated model “below the waterline”, which can be depicted in the form of TOGAF views.

The structure of the core ArchiMate language closely corresponds with the three main architectures as addressed in the TOGAF ADM. This is illustrated in Figure 7. This correspondence would suggest a fairly easy mapping between TOGAF views and the ArchiMate viewpoints.

Figure 7: Correspondence between ArchiMate and TOGAF

Some TOGAF views are not matched in the ArchiMate core, however. Partially, this is because the scope of TOGAF is broader and in particular addresses more of the high-level strategic issues and the lower-level engineering aspects of system development, whereas the ArchiMate core is limited to the enterprise architecture level of abstraction. However, the two language extensions, described in Chapters 10 and 11, address these additional issues. They define concepts such as goal, principle, and requirement, as well as the planning and migration-oriented concepts. Figure 8 illustrates this.

Figure 8: Correspondence between ArchiMate (including extensions) and TOGAF

Although some of the viewpoints that are defined in TOGAF cannot easily be mapped onto ArchiMate viewpoints, the ArchiMate language and its analysis techniques do support the concepts addressed in these viewpoints. While there is no one-to-one mapping between them, there is still a fair amount of correspondence between the ArchiMate viewpoints and the viewpoints that are defined in TOGAF. Although corresponding viewpoints from ArchiMate and TOGAF do not necessarily have identical coverage, we can see that many viewpoints from both methods address largely the same issues.

TOGAF and ArchiMate can easily be used in conjunction and they appear to cover much of the same ground, although with some differences in scope and approach.

2.10             Use of Colors

In the metamodel pictures within this specification, colors are used to distinguish concepts belonging to the different aspects of the ArchiMate Framework: green for passive structure, yellow for behavior, and blue for active structure. In ArchiMate models, there are no formal semantics assigned to colors and the use of color is left to the modeler. However, they can be used freely to stress certain aspects in models. For instance, in many of the example models presented in this specification, colors are used to distinguish between the layers of the ArchiMate Framework: yellow for the business layer, blue for the application layer, and green for the technology layer. They can also be used for visual emphasis. A recommended text providing guidelines is Chapter 6 of [2].

Footnotes