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 is the third posting in our series on using ArchiMate in practice. The goal of this posting is to come to grips with the structure of the language, building on the previous posting where we discussed the mind of the architect using the Frisco framework.
As a brief recap from our last posting, remember that the mental process of the architect follows certain steps:
Perceive: pure sensory input, what’s going on in the world around us?
Sense-making: leading to some conception of the domain under consideration
(Purposeful) abstraction: focus on part of the domain and crafting a model
Architecting: wondering what the fundamental organization as well as the principles underlying this fundamental organization are
Behavior and (active/passive) structure
For purposes of the discussion in this post, we look at the sense-making and abstraction process that leads to a mental model. (Neuro) scientists and psychologists have a lot to say about what’s going on in the brain when we try to make sense of the world. What is relevant from an architecture perspective is that we divide our conception in behavioral elements and structural elements that are somehow related. The following diagram illustrates this:
Consider the following simple example: we are in the middle of a busy city (e.g. Toronto) and see a man walking down the street. After some purposeful abstraction, we recognize a certain behavior (walking) and several structure elements (the man, the street, etc.). Simply put, everything that is not behavior (and is still of interest), must be structure.
Continuing this line of reasoning, a further distinction is made. If we look at the class of structure elements, then we can differentiate between things that exhibit behavior, and things that are somehow (otherwise) related to that behavior. The former is called active structure whereas the latter is called passive structure. To illustrate, consider the sentence “John buys a bike”. Note that:
“John” performs behavior. This will be represented by an active structure element
“Buying” is the actual behavior. It will be represented by a behavior element
“Bike” is the thing being bought. It is neither behavior, nor does it perform behavior. Therefore it will be represented by a passive structure element
The following diagram illustrates how these types of elements relate using an ERD-style notation:
Behavior element is an Element
Structure element is an Element
Active structure element is a Structure element
Active structure element performs behavior element
Passive structure element is a Structure element
Passive structure element is involved in behavior element
For the purists, note that:
A behavior element may be performed by zero or more active structure elements. The implication is that there is not always ‘something’ that exhibits this behavior.
Active structure element performs zero or more behavior elements. That is, things that can exhibit behavior need not always do so
Along the same lines: passive structure elements are optionally involved in behavior elements and vice versa. Things can exist without ever being involved in some sort of behavior.
The three domains
The distinction between structure and behavior is a powerful one. It allows us precisely to model what we see in the real world. In ArchiMate, though, another distinction is made: we recognize three layers (note: in many standards these layers are also called ‘domains’). Formally these are defined as follows:
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.
This structure appears to be logical and sensible. It allows us to differentiate between business architecture, information systems architecture and technology architecture for example. However, it also poses some challenges that are not always easy to solve. We will discuss these in more detail in posting 5 of this series.
ArchiMate core: the structure
If we combine the two categorizations of elements, then we end up with the following overall structure of the language:
While a full coverage of the actual concepts and relations that populate this framework is beyond the scope of this posting (please refer to the specification), we illustrate the main point with a small example:
Here we see a ‘Claim handling’ business process. In ArchiMate, a business process is a behavior element from the business domain. We have decomposed this process into 4 main steps (remember, ArchiMate is about ‘fundamental organization’ so we do not worry too much about the details). From our discussion earlier, we know that this behavior must be manifested by some structure element. Here, the structure elements are signified by a series of Business roles. Last but not least, we see that in the course of the process, certain automated functionality is required. The functionality is modeled with application services, which are behavioral elements from the application domain. This is where this example model stops. We would have to continue our analysis and modeling of this domain if we want to find out where this behavior manifests itself in terms of structural elements, e.g. application components.
Conclusion & outlook
In the next posting we will pick up our discussion on the foundations of the ArchiMate framework. We then look into the “internal/external” aspects of each of the layers. If you have any questions or suggestions: feel free to drop us a note! Stay tuned!
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: