The ArchiMate Files – 5. specialization

Bas van Gils & Sven van Dijk
Posted by Bas van Gils & Sven van Dijk on Nov 28, 2011

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 is the fifth posting in our series on using ArchiMate in practice. The goal of this posting is to come to grips with the use of specialization in architecture models. We discuss the main idea as well as implications and benefits.


Formally, the specialization relation is defined as follows

The specialization relationship indicates that an object is a specialization of another object

While the definition is not particularly eloquent, it is clear that it denotes the “is-a” relation, which is how many people use it. More formally, if A is a specialization of B then we say that “A is a B”. As an example, if we model that “Employee is a specialization of Person” then we say that “every Employee is a Person”.

In practice we see that the specialization relation / is-a relation is (sometimes) also used to model type-instance. If B is a type and A is an instance of that type, than we say that “A is a B”. In mathematics, B would be denoted as a set, and A would be part of its population (i.e. A Î B). A typical example would be to express the fact that Carol is a Person (i.e. Carol is the instance, Person the type). This is useful – and perhaps even necessary – at the infrastructure level where we are mainly interested in the types of nodes (with hardware and software) rather than all the physical instances that we can find in the server room.


One of the key advantages of using specialization lies in the fact that the ‘children’ inherit properties from their ‘parents’. The following example illustrates this:

  • Suppose we have three concepts: Person, Employee, Patient
  • We model the fact that each person must have a birthday, social security number, name, etcetera
  • We model the fact that both Employee and Patients are specializations of Person
  • We now know that Patients and Employees also must have these properties. This is a consequence of inheritance
  • We now only have to  model the ‘additional’ properties that these concepts have

In other words, we model these properties once and re-use them many times. This mechanism tends to make models more elegant, and more elegant to read. It is amazing that this mechanism is used so seldom, as it is quite close to the way our brain works (it is also used in Linguistics, Biology and many other disciplines) with some pretty big advantages.


The specialization relation is used mostly in the context of (re-use of) patterns. For example, we could model the fact that core data objects have certain properties (ownership, stewardship, etc.) and then re-use those properties through specialization. Similarly, we specify that a process has certain properties, and re-use those properties through the specialization relation. This example is illustrated below, which comes from a real case that we did with a client:


The idea was to develop a “plug and play process architecture” where a process is customized based on the starting trigger.

We started with the very simple observation that a business event triggers an end-to-end process with three main steps. We receive the message, processes it, and send a notification. Not very fancy, but still. The next step was to model the fact that we have several types of business events using a specialization relation. These are more ‘concrete’ than the abstract event, and therefore we highlight them using a different color.

Depending on the event that fires, different versions of the end-to-end process manifest themselves, also modeled using the specialization relation. The actual differences between them are represented by the fact that we “plug in” separate process steps using an aggregation relation. These building blocks, of course, are a specialization of the ‘process message’ step in the organizational process. The one thing that remains unclear (or at least: isn’t obvious from this view) is the relation between A1 and A2. For this particular case that was not a big issue: we recognized the need for using well-defined business rules to map out the flow of one process step to another, and dealt with that during the design phase. This example shows that with relatively few concepts and relations, quite elaborate architecture models can be made.

Before we move to the conclusion of this posting, it should be noted that the visualization above may not be appealing to many: the model is powerful, though, and we can and should create different visualizations for various stakeholders, depending on what we are trying to achieve and who we are communicating with. This is the main topic for the next posting.

Conclusion & outlook

In the next posting we will move from the fundamentals and structure of the language itself, and discuss the mechanism of views and viewpoints to create different visualizations for key stakeholders. If you have any questions or suggestions: feel free to drop us a note! Stay tuned!

Delivering Business Outcome with TOGAF and ArchiMate


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