3 Sprachstruktur

Dieses Kapitel beschreibt die Struktur der ArchiMate-Modellierungssprache für Unternehmensarchitektur. Die detaillierte Definition und Beispiele für die Standardsammlung von Elementen und Beziehungen folgen in Kapitel 4 bis Kapitel 1

3.1 Überlegungen zur Sprachgestaltung

Eine zentrale Herausforderung bei der Entwicklung eines allgemeinen Metamodells für Unternehmensarchitektur besteht darin, ein Gleichgewicht zwischen der Spezifität von Sprachen für einzelne Architekturbereiche und einem sehr allgemeinen Satz von Architekturkonzepten herzustellen, die eine Sichtweise von Systemen als bloße Menge miteinander verbundener Entitäten widerspiegeln.

Die Gestaltung der ArchiMate-Sprache basiert auf einer Reihe relativ generischer Konzepte. Diese wurden in den folgenden Abschnitten für die Anwendung auf verschiedenen architektonischen Ebenen spezialisiert. Die wichtigste Gestaltungsbeschränkung der Sprache besteht darin, dass sie bewusst so klein wie möglich gestaltet wurde, aber dennoch für die meisten Aufgaben der Unternehmensarchitekturmodellierung nutzbar ist. Viele andere Sprachen versuchen, die Bedürfnisse aller möglichen Benutzer zu berücksichtigen. Im Interesse der Einfachheit des Lernens und der Anwendung wurde die ArchiMate-Sprache auf die Konzepte beschränkt, die ausreichen, um die berühmten 80 % der praktischen Fälle zu modellieren.

Dieser Standard beschreibt nicht die detaillierte Begründung für die Gestaltung der ArchiMate-Sprache. Der interessierte Leser wird auf [1], [2] und [3] verwiesen, die eine detaillierte Beschreibung der Sprachkonstruktion und der Gestaltungsüberlegungen enthalten.

3.2 Oberste Sprachstruktur

Abbildung 1 zeigt die oberste hierarchische Struktur der Sprache:

• Ein Modell ist eine Sammlung vonKonzepten– ein Konzept ist entweder einElementoder eineBeziehung
• Ein Element ist entweder ein Verhaltens-Element, ein Struktur-Element, ein Motivations-Element oder ein zusammengesetztes Element

Beachten Sie, dass diesabstrakteKonzepte sind; sie sind nicht dazu bestimmt, direkt in Modellen verwendet zu werden. Um dies zu kennzeichnen, werden sie in Weiß mit kursiven Beschriftungen dargestellt. Siehe Kapitel 4 für eine Erklärung der in Abbildung 1 verwendeten Notation.

Abbildung 1: Oberste Hierarchie der ArchiMate-Konzepte

3.3 Schichten der ArchiMate-Sprache

Die ArchiMate-Kernsprache definiert eine Struktur generischer Elemente und ihrer Beziehungen, die in verschiedenen Schichten spezialisiert werden können. Innerhalb der ArchiMate-Kernsprache sind drei Schichten wie folgt definiert:

1. DieGeschäfts-Schichtzeigt Geschäftsleistungen, die Kunden angeboten werden, die in der Organisation durch Geschäftsprozesse, die von Geschäftsakteuren durchgeführt werden, realisiert werden.
2. DieAnwendungs-Schichtzeigt Anwendungsdienste, die das Geschäft unterstützen, sowie die Anwendungen, die sie realisieren.
3. DieTechnologie-Schichtumfasst sowohl Informationstechnologie als auch operative Technologie. Sie können beispielsweise Verarbeitungs-, Speicher- und Kommunikationstechnologie im Rahmen der Anwendungswelt und der Geschäfts-Ebenen modellieren sowie operative oder physische Technologie mit Einrichtungen, physischer Ausrüstung, Materialien und Verteilungsnetzwerken modellieren.

Die allgemeine Struktur von Modellen innerhalb der verschiedenen Ebenen ist ähnlich. Es werden dieselben Arten von Elementen und Beziehungen verwendet, obwohl ihre genaue Natur und Granularität variieren. Im nächsten Kapitel wird die Struktur des generischen Metamodells vorgestellt. In Kapitel 8, Kapitel 9 und Kapitel 10 werden diese Elemente spezialisiert, um Elemente zu erhalten, die einer bestimmten Ebene zugeordnet sind.

In Übereinstimmung mit der Serviceorientierung wird die wichtigste Beziehung zwischen den Ebenen durch die „Bereitstellung“-Beziehung gebildet[1]Beziehungen, die zeigen, wie die Elemente einer Ebene durch die Dienste anderer Ebenen bereitgestellt werden. (Beachten Sie jedoch, dass Dienste nicht nur Elemente in einer anderen Ebene unterstützen müssen, sondern auch Elemente in derselben Ebene unterstützen können.) Eine zweite Art von Verbindung wird durch Realisierungsbeziehungen gebildet: Elemente in niedrigeren Ebenen können vergleichbare Elemente in höheren Ebenen realisieren; beispielsweise ein

„Datenobjekt“ (Anwendungsebene) kann ein „Geschäftsobjekt“ (Geschäfts-Ebene) realisieren; oder ein

„Artefakt“ (Technologie-Ebene) kann entweder ein „Datenobjekt“ oder ein „Anwendungskomponente“ (Anwendungsebene) realisieren.

3.4 Das ArchiMate-Kernframework

Das ArchiMate-Kernframework ist ein Rahmen mit neun Zellen, der zur Klassifizierung von Elementen der ArchiMate-Kernsprache verwendet wird. Es besteht aus drei Aspekten und drei Ebenen, wie in Abbildung 2 dargestellt. Dies wird als ArchiMate-Kernframework bezeichnet.

Es ist wichtig zu verstehen, dass die Klassifizierung von Elementen anhand von Aspekten und Ebenen nur eine globale ist. Realitätsnahe Architektur-Elemente müssen nicht streng auf einen einzigen Aspekt oder eine einzige Ebene beschränkt sein, da Elemente, die verschiedene Aspekte und Ebenen verbinden, eine zentrale Rolle bei einer kohärenten architektonischen Beschreibung spielen. Zum Beispiel dienen Geschäftsrollen, die etwas vorwegnehmen gegenüber den späteren konzeptionellen Diskussionen, als Zwischenelemente zwischen „rein verhaltensbasierten“ und „rein strukturellen“ Elementen, und es kann vom Kontext abhängen, ob eine bestimmte Software als Teil der Anwendungsebene oder der Technologie-Ebene betrachtet wird.

Abbildung 2: ArchiMate-Kernframework

Die Struktur des Frameworks ermöglicht die Modellierung des Unternehmens aus verschiedenen Blickwinkeln, wobei die Position innerhalb der Zellen die Interessen des Stakeholders hervorhebt. Ein Stakeholder kann typischerweise Interessen haben, die mehrere Zellen umfassen.

Die Dimensionen des Frameworks sind wie folgt:

• Ebenen – die drei Ebenen, auf denen ein Unternehmen in ArchiMate modelliert werden kann – Geschäfts-, Anwendungs- und Technologie-Ebene (wie in Abschnitt 3.3 beschrieben)
• Aspekte:

— Deraktive Struktur-Aspekt, der die strukturellen Elemente darstellt (die Geschäftsakteure, Anwendungskomponenten und Geräte, die tatsächlich Verhalten zeigen; also die

„Subjekte“ der Aktivität)

— DerVerhaltens-Aspekt, der das Verhalten (Prozesse, Funktionen, Ereignisse und Dienste) darstellt, das von den Akteuren ausgeführt wird; strukturelle Elemente werden verhaltensbasierten Elementen zugeordnet, um zu zeigen, wer oder was das Verhalten zeigt

— Derpassive Struktur-Aspekt, der die Objekte darstellt, auf denen Verhalten ausgeführt wird; dies sind in der Regel Informationsobjekte in der Geschäfts-Ebene und Datenobjekte in der Anwendungsebene, können aber auch zur Darstellung physischer Objekte verwendet werden

Diese drei Aspekte wurden durch die natürliche Sprache inspiriert, in der ein Satz ein Subjekt (aktive Struktur), ein Verb (Verhalten) und ein Objekt (passive Struktur) hat. Durch die Verwendung der gleichen Konstrukte, die Menschen in ihrer eigenen Sprache gewohnt sind, ist die ArchiMate-Sprache leichter zu erlernen und zu lesen.

Da die ArchiMate-Notation einegrafischeSprache ist, bei der Elemente räumlich organisiert werden, ist diese Reihenfolge bei der Modellierung von keiner Bedeutung.

Ein zusammengesetztes Element, wie in Abbildung 1 gezeigt, ist ein Element, das nicht unbedingt in einem einzigen Aspekt (Spalte) des Frameworks Platz finden muss, sondern zwei oder mehr Aspekte kombinieren kann.

Beachten Sie, dass die ArchiMate-Sprache den Modellierer nicht dazu verpflichtet, eine bestimmte Anordnung wie die Struktur dieses Frameworks zu verwenden; es handelt sich lediglich um eine Kategorisierung der Sprachelemente.

3.5 Das ArchiMate-Standard-Modell

Das ArchiMate-Standard-Modell, wie in dieser Version der Norm beschrieben, fügt dem Core Framework mehrere Schichten und ein Aspekt hinzu. Die physischen Elemente sind in der Technologie-Schicht enthalten, um physische Einrichtungen und Geräte, Verteilungsnetze und Materialien zu modellieren. In diesem Sinne sind sie ebenfalls Kern-Elemente. Die Strategie-Elemente werden eingeführt, um strategische Ausrichtung und Entscheidungen zu modellieren. Sie werden in Kapitel 7 beschrieben. Das Motivations-Aspekt wird auf generischer Ebene im nächsten Kapitel eingeführt und detailliert in Kapitel 6 beschrieben. Die Implementierungs- und Migrationselemente werden in Kapitel 12 beschrieben. Das resultierende ArchiMate-Standard-Modell ist in Abbildung 3 dargestellt.

Abbildung 3: ArchiMate-Standard-Modell

Die ArchiMate-Sprache definiert keine spezifische Schicht für Informationen; jedoch werden Elemente aus dem Aspekt der passiven Struktur, wie Geschäftsobjekte, Datenobjekte und Artefakte, verwendet, um Informationsentitäten darzustellen. Die Informationsmodellierung wird über die verschiedenen ArchiMate-Schichten hinweg unterstützt.

3.6 Abstraktion in der ArchiMate-Sprache

Die Struktur der ArchiMate-Sprache berücksichtigt mehrere vertraute Formen der Abstraktion und Verfeinerung. Zunächst ist die Unterscheidung zwischen einer externen (Black-Box, Abstraktion von Inhalt der Box) und einer internen (White-Box) Sicht in der Systemgestaltung üblich. Die externe Sicht zeigt, was das System für seine Umgebung tun muss, während die interne Sicht zeigt, wie dies erfolgt.

Zweitens wird die Unterscheidung zwischen Verhalten und aktiver Struktur häufig verwendet, um das, was das System tun muss, und die Art und Weise, wie es dies tut, von den Systembestandteilen (Menschen, Anwendungen und Infrastruktur), die dies tun, zu trennen. Bei der Modellierung neuer Systeme ist es oft sinnvoll, mit den Verhaltensweisen zu beginnen, die das System ausführen muss, während bei der Modellierung bestehender Systeme es oft sinnvoll ist, mit den Menschen, Anwendungen und Infrastrukturen zu beginnen, die das System bilden, und dann die Verhaltensweisen dieser aktiven Strukturen detailliert zu analysieren.

Eine dritte Unterscheidung besteht zwischen konzeptueller, logischer und physischer Abstraktionsebene. Dies hat seine Wurzeln in der Datenmodellierung: Konzeptionelle Elemente stellen die Informationen dar, die das Unternehmen für relevant hält; logische Elemente verleihen dieser Information eine logische Struktur zur Verarbeitung durch Informationssysteme; physische Elemente beschreiben die Speicherung dieser Informationen; beispielsweise in Form von Dateien oder Datenbanktabellen. In der ArchiMate-Sprache entspricht dies den Geschäftsobjekten, Datenobjekten und Artefakten sowie den Realisierungsbeziehungen zwischen ihnen.

Die Unterscheidung zwischen logischen und physischen Elementen wurde auch auf die Beschreibung von Anwendungen übertragen. Das TOGAF-Enterprise-Metamodell [4] enthält eine Reihe von Entitäten, die Geschäfts-, Daten-, Anwendungs- und Technologiekomponenten sowie -dienste beschreiben, um Architekturkonzepte darzustellen. Logische Komponenten sind implementations- oder produktunabhängige Kapselungen von Daten oder Funktionalität, während physische Komponenten physische Softwarekomponenten, Geräte usw. sind. Diese Unterscheidung wird im TOGAF-Framework in Form von Architekturbaukästen (ABBs) und Lösungsbaukästen (SBBs) erfasst. Diese Unterscheidung ist erneut nützlich, um Enterprise-Architekturen von hochabstrakten, allgemeinen Beschreibungen zu konkreten, implementierungsnahen Entwürfen zu entwickeln. Beachten Sie, dass Baukästen mehrere Elemente enthalten können, die typischerweise mit dem Gruppierungskonzept in der ArchiMate-Sprache modelliert werden.

Die ArchiMate-Sprache verfügt über drei Möglichkeiten, solche Abstraktionen zu modellieren. Erstens, wie in [6] beschrieben, können Verhaltenselemente wie Anwendungs- und Technologiefunktionen verwendet werden, um logische Komponenten zu modellieren, da sie implementationsunabhängige Kapselungen von Funktionalität darstellen. Die entsprechenden physischen Komponenten können dann mit aktiven Strukturelementen wie Anwendungs-Komponenten und Knoten modelliert werden, die den Verhaltenselementen zugeordnet sind. Zweitens unterstützt die ArchiMate-Sprache das Konzept der Realisierung. Dies lässt sich am besten durch Arbeit mit der Technologie-Schicht von unten nach oben beschreiben. Die Technologie-Schicht definiert die physischen Artefakte und Software, die eine Anwendungs-Komponente realisieren. Sie bietet auch eine Abbildung auf andere physische Konzepte wie Geräte, Netzwerke usw., die für die Realisierung eines Informationssystems erforderlich sind. Die Realisierungsbeziehung wird auch verwendet, um abstraktere Formen der Realisierung zu modellieren, beispielsweise zwischen einer (spezifischeren) Anforderung und einer (allgemeineren) Prinzip, wobei die Erfüllung der Anforderung die Einhaltung des Prinzips impliziert. Realisierung ist auch zwischen Anwendungs-Komponenten und zwischen Knoten zulässig. Auf diese Weise können Sie eine physische Anwendungs- oder Technologie-Komponente modellieren, die eine logische Anwendungs- oder Technologie-Komponente realisiert. Drittens können logische und physische Anwendungs-Komponenten als Metamodell-Ebene-Spezialisierungen des Anwendungs-Komponenten-Elements definiert werden, wie in Kapitel 14 beschrieben (siehe auch die Beispiele in Abschnitt 14.2.2). Dasselbe gilt für die logischen und physischen Technologie-Komponenten des TOGAF-Inhalts-Metamodells, die als Spezialisierungen des Knoten-Elements definiert werden können (siehe Abschnitt 14.2.3).

Die ArchiMate-Sprache unterstützt bewusst keinen Unterschied zwischen Typen und Instanzen. Auf der Ebene der Enterprise-Architektur ist es üblicher, Typen und/oder Exemplare zu modellieren, anstatt Instanzen. Ebenso beschreibt ein Geschäftsprozess in der ArchiMate-Sprache keine einzelne Instanz (also eine Ausführung dieses Prozesses). In den meisten Fällen wird daher ein Geschäftsobjekt verwendet, um einen Objekttyp (vgl.eine UML®-Klasse), von dem mehrere Instanzen innerhalb der Organisation existieren können. Beispielsweise kann jede Ausführung eines Versicherungsantragsprozesses zu einer spezifischen Instanz des Versicherungsvertrags-Geschäftsobjekts führen, dies wird jedoch in der Enterprise-Architektur nicht modelliert.

3.7 Konzepte und ihre Notation

Die ArchiMate-Sprache trennt die Sprachkonzepte (also die Bestandteile des Metamodells) von ihrer Notation. Verschiedene Interessengruppen können unterschiedliche Notationen benötigen, um ein Architekturmodell oder eine Sicht zu verstehen. In diesem Punkt unterscheidet sich die ArchiMate-Sprache von Sprachen wie UML oder BPMN™, die nur eine standardisierte Notation haben. Das in Kapitel 13 erklärte Blickpunktmechanismus bietet die Möglichkeit, solche interessengruppenorientierte Visualisierungen zu definieren.

Obwohl die Notation der ArchiMate-Konzepte (und sollte) stakeholder-spezifisch sein kann, stellt die Norm eine gemeinsame grafische Notation bereit, die von Architekten und anderen, die ArchiMate-Modelle erstellen, verwendet werden kann. Diese Notation richtet sich an eine Zielgruppe, die mit bestehenden technischen Modellierungstechniken wie Entity-Relationship-Diagrammen (ERDs), UML oder BPMN vertraut ist, und ähnelt daher diesen. In den folgenden Abschnitten dieses Dokuments stellen die Symbole, die zur Darstellung der Sprachkonzepte verwendet werden, die ArchiMate-Standard-Notation dar, sofern nichts anderes angegeben ist. Die Standard-Notation für die meisten Elemente besteht aus einem Kasten mit einem Symbol in der oberen rechten Ecke. In mehreren Fällen kann dieses Symbol allein auch als alternative Notation verwendet werden. Diese Standard-Iconographie sollte möglichst bevorzugt werden, damit jeder, der die ArchiMate-Sprache kennt, die in der Sprache erstellten Diagramme lesen kann.

3.8 Verwendung von Verschachtelung

Die Verschachtelung von Elementen innerhalb anderer Elemente kann als alternative grafische Notation verwendet werden, um bestimmte Beziehungen auszudrücken. Dies wird ausführlicher in Kapitel 5 und in der Definition jeder dieser Beziehungen erläutert.

3.9 Verwendung von Farben und notationalen Hinweisen

In den Metamodell-Bildern innerhalb dieser Norm werden Graustufen verwendet, um Elemente zu unterscheiden, die den verschiedenen Aspekten des ArchiMate-Frameworks zugehören, wie folgt:

• Weiß für abstrakte (d. h. nicht instanziierbare) Konzepte
• Hellgrau für passive Strukturen
• Mittelgrau für Verhalten
• Dunkelgrau für aktive Strukturen

In ArchiMate-Modellen werden Farben keiner formalen Semantik zugeordnet, und die Verwendung von Farben bleibt dem Modellierer überlassen. Sie können jedoch frei verwendet werden, um bestimmte Aspekte in Modellen hervorzuheben. Beispielsweise werden in vielen der in dieser Norm präsentierten Beispielmodelle Farben verwendet, um die Schichten des ArchiMate-Core-Frameworks zu unterscheiden, wie folgt:

• Gelb für die Geschäfts-Schicht
• Blau für die Anwendungs-Schicht
• Grün für die Technologie-Schicht

Sie können auch zur visuellen Hervorhebung verwendet werden. Ein empfohlener Text mit Leitlinien ist Kapitel 6 von [1]. Zusätzlich zu den Farben können andere notatorische Hinweise verwendet werden, um die Schichten des Frameworks zu unterscheiden. Ein Buchstabe M, S, B, A, T, P oder I in der oberen linken Ecke eines Elements kann verwendet werden, um ein Motivations-, Strategie-, Geschäfts-, Anwendungs-, Technologie-, Physisches- oder Implementierungs- und Migrationselement zu kennzeichnen. Ein Beispiel für diese Notation ist in Beispiel 34 dargestellt.

Die Standardnotation verwendet ebenfalls eine Konvention bezüglich der Form der Ecken ihrer Symbole für verschiedene Elementtypen, wie folgt:

• Eckige Ecken werden verwendet, um Strukturelemente zu kennzeichnen
• Runde Ecken werden verwendet, um Verhaltenselemente zu kennzeichnen
• Diagonale Ecken werden verwendet, um Motivationselemente zu kennzeichnen

[1]Beachten Sie, dass dies in früheren Versionen der Norm als „benutzt von“ bezeichnet wurde. Aus Gründen der Klarheit wurde dieser Name in „dient für“ geändert.

3 Language Structure

This chapter describes the structure of the ArchiMate Enterprise Architecture modeling language. The detailed definition and examples of its standard set of elements and relationships follow in Chapter 4 to Chapter 1

3.1 Language Design Considerations

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.

The design of the ArchiMate language started from a set of relatively generic concepts. These have been specialized towards application at different architectural layers, as explained 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 try to accommodate the needs of all possible users. In the interest of simplicity of learning and use, the ArchiMate language has been limited to the concepts that suffice for modeling the proverbial 80% of practical cases.

This standard does not describe the detailed rationale behind the design of the ArchiMate language. The interested reader is referred to [1], [2], and [3], which provide a detailed description of the language construction and design considerations.

3.2 Top-Level Language Structure

Figure 1 outlines the top-level hierarchical structure of the language:

• A model is a collection of concepts – a concept is either an element or a relationship
• An element is either a behavior element, a structure element, a motivation element, or a composite element

Note that these are abstract concepts; they are not intended to be used directly in models. To signify this, they are depicted in white with labels in italics. See Chapter 4 for an explanation of the notation used in Figure 1.

Figure 1: Top-Level Hierarchy of ArchiMate Concepts

3.3 Layering of the ArchiMate Language

The ArchiMate core language defines a structure of generic elements and their relationships, which can be specialized in different layers. Three layers are defined within the ArchiMate core language as follows:

1. The Business Layer depicts business services offered to customers, which are realized in the organization by business processes performed by business actors.
2. The Application Layer depicts application services that support the business, and the applications that realize them.
3. The Technology Layer comprises both information and operational technology. You can model, for example, processing, storage, and communication technology in support of the application world and Business Layers, and model operational or physical technology with facilities, physical equipment, materials, and distribution networks.

The general structure of models within the different layers is similar. The same types of elements and relationships are used, although their exact nature and granularity differ. In the next chapter, the structure of the generic metamodel is presented. In Chapter 8, Chapter 9, and Chapter 10 these elements are specialized to obtain elements specific to a particular layer.

In alignment with service-orientation, the most important relationship between layers is formed by “serving”[1] relationships, which show how the elements in one layer are served by the services of other layers. (Note, however, that services need not only serve elements in another layer, but also can serve 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).

3.4 The ArchiMate Core Framework

The ArchiMate Core Framework is a framework of nine cells used to classify elements of the ArchiMate core language. It is made up of three aspects and three layers, as illustrated in Figure 2. This is known as the ArchiMate Core Framework.

It is important to understand that the classification of elements based on aspects and layers is only a global one. Real-life architecture elements need not strictly be confined to one aspect or layer because elements 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 roles serve as intermediary elements between “purely behavioral” elements and “purely structural” elements, and it may depend on the context whether a certain piece of software is considered to be part of the Application Layer or the Technology Layer.

Figure 2: ArchiMate Core 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 in ArchiMate – Business, Application, and Technology (as described in Section 3.3)
• Aspects:

— The Active Structure Aspect, which represents the structural elements (the business actors, application components, and devices that display actual behavior; i.e., the

“subjects” of activity)

— The Behavior Aspect, which represents the behavior (processes, functions, events, and services) performed by the actors; structural elements are assigned to behavioral elements, to show who or what displays the behavior

— The Passive Structure Aspect, which 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

These three aspects were inspired by natural language where a sentence has a subject (active structure), a verb (behavior), and an object (passive structure). By using the same constructs that people are used to in their own languages, the ArchiMate language is easier to learn and read.

Since ArchiMate notation is a graphical language where elements are organized spatially, this order is of no consequence in modeling.

A composite element, as shown in Figure 1, is an element that does not necessarily fit in a single aspect (column) of the framework but may combine two or more aspects.

Note that the ArchiMate language does not require the modeler to use any particular layout such as the structure of this framework; it is merely a categorization of the language elements.

3.5 The ArchiMate Full Framework

The ArchiMate Full Framework, as described in this version of the standard, adds a number of layers and an aspect to the Core Framework_._ The physical elements are included in the Technology Layer for modeling physical facilities and equipment, distribution networks, and materials. As such, these are also core elements. The strategy elements are introduced to model strategic direction and choices. They are described in Chapter 7. The motivation aspect is introduced at a generic level in the next chapter and described in detail in Chapter 6. The implementation and migration elements are described in Chapter 12. The resulting ArchiMate Full Framework is shown in Figure 3.

Figure 3: ArchiMate Full Framework

The ArchiMate language does not define a specific layer for information; however, elements from the passive structure aspect such as business objects, data objects, and artifacts are used to represent information entities. Information modeling is supported across the different ArchiMate layers.

3.6 Abstraction in the ArchiMate Language

The structure of the ArchiMate language accommodates several familiar forms of abstraction and refinement. First of all, the distinction between an external (black-box, abstracting from the contents of the box) and internal (white-box) view is common in systems design. The external view depicts what the system has to do for its environment, while the internal view depicts how it does this.

Second, the distinction between behavior and active structure is commonly used to separate what the system must do and how the system does it from the system constituents (people, applications, and infrastructure) that do it. In modeling new systems, it is often useful to start with the behaviors that the system must perform, while in modeling existing systems, it is often useful to start with the people, applications, and infrastructure that comprise the system, and then analyze in detail the behaviors performed by these active structures.

A third distinction is between conceptual, logical, and physical abstraction levels. This has its roots in data modeling: conceptual elements represent the information the business finds relevant; logical elements provide logical structure to this information for manipulation by information systems; physical elements describe the storage of this information; for example, in the form of files or database tables. In the ArchiMate language, this corresponds with business objects, data objects, and artifacts, along with the realization relationships between them.

The distinction between logical and physical elements has also been carried over to the description of applications. The TOGAF Enterprise Metamodel [4] includes a set of entities that describe business, data, application, and technology components and services to describe architecture concepts. Logical components are implementation or product-independent encapsulations of data or functionality, whereas physical components are tangible software components, devices, etc. This distinction is captured in the TOGAF framework in the form of Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs). This distinction is again useful in progressing Enterprise Architectures from high-level, abstract descriptions to tangible, implementation-level designs. Note that building blocks may contain multiple elements, which are typically modeled using the grouping concept in the ArchiMate language.

The ArchiMate language has three ways of modeling such abstractions. First, as described in [6], behavior elements such as application and technology functions can be used to model logical components, since they represent implementation-independent encapsulations of functionality. The corresponding physical components can then be modeled using active structure elements such as application components and nodes, assigned to the behavior elements. Second, the ArchiMate language supports the concept of realization. This can best be described by working with the Technology Layer upwards. The Technology Layer defines the physical artifacts and software that realize an application component. It also provides a mapping to other physical concepts such as devices, networks, etc. needed for the realization of an information system. The realization relationship is also used to model more abstract kinds of realization, such as that between a (more specific) requirement and a (more generic) principle, where fulfillment of the requirement implies adherence to the principle. Realization is also allowed between application components and between nodes. This way you can model a physical application or technology component realizing a logical application or technology component, respectively. Third, logical and physical application components can be defined as metamodel-level specializations of the application component element, as described in Chapter 14 (see also the examples in Section 14.2.2). The same holds for the logical and physical technology components of the TOGAF Content Metamodel, which can be defined as specializations of the node element (see Section 14.2.3).

The ArchiMate language intentionally does not support a difference between types and instances. At the Enterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances. Similarly, a business process in the ArchiMate language does not describe an individual instance (i.e., one execution of that process). In most cases, a business object is therefore used to model an object type (cf. a UML® class), of which several instances may exist within the organization. For instance, each execution of an insurance application process may result in a specific instance of the insurance policy business object, but that is not modeled in the Enterprise Architecture.

3.7 Concepts and their Notation

The ArchiMate language separates the language concepts (i.e., the constituents of the metamodel) from their notation. Different stakeholder groups may require different notations in order to understand an architecture model or view. In this respect, the ArchiMate language differs from languages such as UML or BPMN™, which have only one standardized notation. The viewpoint mechanism explained in Chapter 13 provides the means for defining such stakeholder-oriented visualizations.

Although the notation of the ArchiMate concepts can (and should) be stakeholder-specific, the standard provides one common graphical notation which can be used by architects and others who develop ArchiMate models. This notation is targeted towards an audience used to existing technical modeling techniques such as Entity Relationship Diagrams (ERDs), UML, or BPMN, and therefore resembles them. In the remainder of this document, unless otherwise noted, the symbols used to depict the language concepts represent the ArchiMate standard notation. This standard notation for most elements consists of a box with an icon in the upper-right corner. In several cases, this icon by itself may also be used as an alternative notation. This standard iconography should be preferred whenever possible so that anyone knowing the ArchiMate language can read the diagrams produced in the language.

3.8 Use of Nesting

Nesting elements inside other elements can be used as an alternative graphical notation to express some relationships. This is explained in more detail in Chapter 5 and in the definition of each of these relationships.

3.9 Use of Colors and Notational Cues

In the metamodel pictures within this standard, shades of grey are used to distinguish elements belonging to the different aspects of the ArchiMate framework, as follows:

• White for abstract (i.e., non-instantiable) concepts
• Light grey for passive structures
• Medium grey for behavior
• Dark grey for active structures

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 standard, colors are used to distinguish between the layers of the ArchiMate Core Framework, as follows:

• Yellow for the Business Layer
• Blue for the Application Layer
• Green for the Technology Layer

They can also be used for visual emphasis. A recommended text providing guidelines is Chapter 6 of [1]. In addition to the colors, other notational cues can be used to distinguish between the layers of the framework. A letter M, S, B, A, T, P, or I in the top-left corner of an element can be used to denote a Motivation, Strategy, Business, Application, Technology, Physical, or Implementation & Migration element, respectively. An example of this notation is depicted in Example 34.

The standard notation also uses a convention with the shape of the corners of its symbols for different element types, as follows:

• Square corners are used to denote structure elements
• Round corners are used to denote behavior elements
• Diagonal corners are used to denote motivation elements

[1] Note that this was called “used by” in previous versions of the standard. For the sake of clarity, this name has been changed to “serving”.