ArchiMate core - Framework

Bas van Gils & Sven van Dijk
Posted by Bas van Gils & Sven van Dijk on May 2, 2012

Enterprise Architecture, ArchiMate

Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.

This article takes you about four minutes to read.

The first post in this series explains how Archimate was introduced as a modeling language for enterprise architecture. The goal was explicitly not to replace existing modeling languages in the business and IT context, such as BPMN and UML. These languages focus on details within a domain, e.g. business processes or data structures. Archimate focuses on consistent alignment and coherence across all the domains of the enterprise. The Archimate framework gives structure to the language and brings together the mechanisms and properties that Archimate features to ensure this consistency and coherency. In this posting we will introduce the Archimate framework.

Three layers, three columns

The Archimate framework essentially is a matrix with three layers and three columns. All the components of the Archimate language, the concepts (icons) and relationships, fit in this matrix. The place in the matrix tells us something about the meaning and function of the component. In this posting we will only discuss the framework; we will cover individual concepts and relationships in subsequent postings. The Archimate framework is depicted below.

The layers

As the figure shows, Archimate organizes business, application and technology components in three horizontal layers. Concepts from the business layer model the products and services an organization offers to its customers, the business processes and functions that bring forth these products and services, and the roles and departments involved in executing processes and functions. The application layer focuses on systems and their functions, and the data components that are created, consumed and put in storage by the organization. Concepts in the technology layer model hardware, networks and system software that the organization uses to run automated processes.

The columns / aspects

The columns in the matrix show the following aspects: passive structure, behavior and active structure. Behavior elements obviously model elements of behavior; an example would be a business process. Active structure elements perform behavior, for example a department responsible for a business process. The passive structure models elements “on which behavior is executed”. In practice these are usually information or data elements.

This all sounds pretty abstract, so let’s explain this with a simple example. If we were to model the sentence “John reads a book”, then the verb “reads” is the behavior element. “John” (the object) is the one doing the reading so he would go into the active structure. “A book” (the subject) is the element that is consumed by Johns reading so it goes into the passive structure. Another example would be the processing (behavior) of an invoice (passive structure) by a clerk (active structure).

Connections between layers and columns

The strength of Archimate is the ability to model relations between elements in the different layers and columns, and thus the various domains of the enterprise. This is very powerful because it allows us to analyze risk and impact of changes to the architecture. The Archimate model can for example visualize how a server outage of server XYZ impacts applications and indirectly business processes and products.

We will use the diagram below to explain the most important Archimate mechanisms that ensure alignment and coherency among layers and columns.

Horizontal alignment

The diagram shows in each “box” of the matrix a key Archimate concept. It also shows the Archimate relationship between the concepts. We abstract from the meaning of the concepts here and concentrate on the alignment mechanisms. The diagram shows that the general mechanism is the same in each layer. Active structure elements are assigned to a behavior element, the connection is an assignment relationship. Behavior elements read, write and/or update passive structure elements. The connection is an access relationship.

Internal and external behavior, service orientation

In the behavior column we see a distinction between external and internal behavior. It separates WHAT is done from HOW that is done. WHAT is modeled as a service and describes the functionality that a user of that service enjoys. The HOW part models the internal operation that is needed to provide the service its users. The connection between a service and internal behavior elements is a realization relationship.

An example, a service that a bank offers to its customers is online account checking. This service and its characteristics (e.g. maximum number of accounts, service hours etc.) is modeled as a business service in Archimate. The processes (e.g. find customer and account) and information (e.g. transactions and account balance) that the service invokes are modeled separately. This distinction between internal and external behavior follows the principles of service oriented architecture.

Vertical alignment

The service concept is essentially the link between the layers. Elements in a higher layer use the services of a lower layer. The connection is a used by relationship. Another link between layers is that elements in lower layers realize comparable elements in a higher layer. In the diagram we see how an artifact in the technology layer realizes a data object, which in turn realizes a business object.

Derived relationships

The example question stated before was “How does an outage of server XYZ eventually impact business processes and products?” The diagram above shows that there is no direct connection between a server and a business process. But a fundamental principle in Archimate is that if a concept A is connected to B, and concept B is connected to C, then concept A and C are also connected. This is called the derived relationship principle. In the example we see that the server is assigned to infrastructure functionality, which in turn realizes an infrastructure service that is used by an application function that realizes an application service that is finally used by a business process. The server and the process are indirectly connected, so we can also derive a direct relationship between the two.

The mechanism of derived relationships allows making models as simple as possible because it allows abstracting from superfluous components in a diagram. An example that is often used in practice by enterprise architects use in practice of this is shown in the diagram above, as well as in the diagrams below. An application component is assigned to an application function. The application function models the internal behavior in terms of automated functionality that realizes an application service. We can use simplification offered by the derived relationship between the application component and the service and model that an application component realizes the service.

The derived relationship principle also allows organizations to tailor the Archimate meta model to their own needs by leaving out concepts that they wouldn’t use. We will describe tailoring the framework in more detail in posting 5.

If you’d like to know more, please leave a comment. The next post in this series covers the Archimate concepts. It is scheduled to be posted on 14th of May.

Archimate® and TOGAF® are registered trademarks of the Open Group.



Join 10.000+ others! Get BiZZdesign's latest articles straight
to your inbox. Enter your email address below:


Subscribe to Email Updates

comments powered by Disqus