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.
In the previous postings of this series we have introduced the (history of) the ArchiMate language, its underlying framework, the core concepts as well as its extensions. This should give you a good overview of the language. On the one hand it may seem complex (many concepts, many different types of relations). On the other: there’s a lot of structure and symmetry to the language, making it fairly easy to learn. Still, it is a good practice to tailor the language for use in your own organization. This posting is all about that: how do we customize ArchiMate for use in our organization?
Rationale for customization
It may seem counter-intuitive to want to tailor a language that is already an open standard, with the full specification available for everyone. Still, if you think about other types of languages, it actually makes a lot of sense:
In natural languages such as English or Dutch, there are many different dialects of one language, which sometimes lead to confusion. This happens when we give slightly different interpretation to certain words, or use colloquialisms, making it harder for listeners to understand exactly what we mean.
The same is true for different spellings, or slightly different grammatical constructions. Think about learning a new language: you start with simple grammar, and at some point you’ll be able to utter/write more complex sentences.
In programming a similar situation arises: even if we all use a standard programming language such as Python, coding conventions still help in making the code more readable and understandable.
In order to make sure that the ArchiMate language is used as effectively as possible within the organization, we strongly recommend customizing it. This involves two aspects: (1) deciding which concepts and relations to use, and (2) deciding on modeling patterns: how do we model certain common problems.
Deciding on concepts and relations
Even when considering only ArchiMate’s core: some concepts are used more frequently than others. For example: process, actor, and role are used more frequently than business collaboration, value, and meaning. It can be argued that the latter are more complex, and should therefore not be used at organizations that only just begin using ArchiMate. Similarly when a Process and a Role are to be connected, four different relation types can be used (association, uses / used by, and assignment), each having a different semantics. The number of permitted relations is huge, as the following table illustrates:
Going over all of them may be a bit much in terms of effort. In our consulting work, we therefore advise our clients to take a workshop approach – involving all key players making and using ArchiMate diagrams – where:
Concepts are discussed one at a time using the following questions: - What does the concept mean in general? - What does it mean for us? - Can we come up with useful examples? - Should we use it now, or put it on the list of concepts to reconsider at a later point?
Once a list of concepts has been established, it is time to do a similar exercise with the relations. For every concept, we answer the following questions: - What other concepts does this concept relate to? - Which relation type is to be used? - What does this mean for us? - Can we come up with a useful example? - What relations does the concept have to itself? - What does that mean? - Can we come up with a useful example?
The results of this mini project leads to a customized meta model which frequently resembles something along the lines of:
Also, per concept we make a little “spider web” along these lines:
When starting to model using ArchiMate, a second topic that deserves attention is the “way of modeling”. That is, which “patterns” do we use to model common problems? Typical issues that have to be dealt with are:
Is our model at the physical level (for example: representing the entire actual server park with all the blades, enclosures, racks etc.) or at the logical level (for example: representing the types of hardware that is used)?
Do we need naming conventions?
How do we use the application service concept: is it modeled with data objects in mind (for example a service around the “customer” data object), or is it related more to the (automatic execution of) business process?
How much detail do we need?
How do we represent our Service Oriented Architecture, and where do we position our Enterprise Service Bus?
The consistency and quality of ArchiMate models greatly improves by making sure that all architects on the team have a similar view on how to tackle these challenges. It also makes it easier to do solid analyses, since everybody knows and agrees on how the model is structured. It therefore also helps in making the right views for stakeholders throughout the enterprise!
In our next posting we zoom in on the use of viewpoints / visualization techniques using ArchiMate. The subsequent posting discusses patterns in more detail, including some of the subjects addressed in the above list. In the meantime: please drop us a note if you have any questions, or have best practices to share!
If you’d like to know more, please leave a comment. The next post in this series covers ArchiMate viewpoints. It is scheduled to be posted on the 25th of June.
Archimate® and TOGAF® are registered trademarks of the Open Group.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: