ArchiMate metamodel – tips to understand it better – Part 1
ArchiMate metamodel – tips to understand it better – Part 1
If you already tried to use ArchiMate you have most probably already said to yourself – there is so many possible relationships and elements – how should we use them? Which relationships are allowed? How we should structure our models? Well – if you keep asking these questions – be informed that you are not alone. Those are some of the typical questions I’m getting whenever I’m delivering ArchiMate training. Today’s article is about metamodels – the visual instruction how to use ArchiMate.
What is metamodel and why it is so important?
So, let’s start with basics – what is metamodel? According to presentation, given by Gonzalo Génova, the Open Management Group defines metamodel as abstract syntax, that helps us interconnect models, that explains possible ways to do it. 
In ArchiMate we use metamodels to understand what elements we have, how they are connected to each other, what are the main patterns for designing the architecture and how we connect layers together.
Metamodels in ArchiMate – Top level language structure
In ArchiMate we have many metamodels. We have a top-level language structure metamodel (see below) which helps us understand language basics. This metamodel provides us with information on basic language structure.
We could read out of it that every model consists of concept, while concept could be either an element or relationship (or relationship connector). In simple words: in order to create a model, you need some elements connected by relationships. Both elements and relationships could be split into categories.
The generic metamodel is considered the main one – it shows us how structure and behavior elements are connected and what are the basic rules.
Generic metamodel is a base metamodel for other layers – rules applicable to it are cascaded down into all the layers: Strategy, Business, Appication, Technology, Physical and Implementation & Migration.
(Source: https://pubs.opengroup.org/architecture/archimate3-doc/chap04.html ) On that metamodel we could observe main relationships that are used between given elements – that means not all of them are shown.
If you are interested in full matrix of relationships (which relationships are allowed between any pair of element) please refer to Relationship Tables
In this article I’d like to share with you one tip on how to read the metamodel.
Metamodels are always structured the same, regardless of layers. We could divide the whole metamodel into three parts - three columns.
Those are, starting from the left: Passive Structure Elements, Behaviors and Active Structure Elements. You could see them marked on technology layer metamodel below:
(Source: https://pubs.opengroup.org/architecture/archimate3-doc/chap10.html) We have Artifact as the passive structure element, Technology Service, Process, Function, Interaction and Event as behaviors and multiple active structure elements such as Node and its specializations: System Software and Device
Tip: If you have hard time to remember all relationships you could use following rules: You always assign Active Structure Element capable of performing behavior to a Behavior: You need Behaviors to access passive structure objects:
Let’s consider following technology and application layer examples of those rules:
In this example we have basic database handling scenario. We could easily divide that into three columns: • On the right-hand side, we have three active structure elements: Database Management System System Software with its Code Interface that serves our CApp Application Component • In the middle we have Behaviors: Update Data application process that is responsible for changing the content of Customer Data, DBHandler responsible for changing the content of Customer Database and DBService which serves Update Data. • On the left-hand side we have Passive Structure Elements: Customer Data on application layer and it’s physical realization in form of Customer Database on Technology layer. As you see, the Active Structure Elements are always assigned to Behaviors, and Behaviors are always accessing Passive Structure Elements.
To sum up, let’s look on main takeaways from this article:
• Metamodels are a visual help to understand ArchiMate and to establish a reference to a modelling structure. • There are multiple metamodels in ArchiMate, including top-level language structure and generic metamodel. • Top-level language structure shows us how ArchiMate is designed, what is the model, concept and what kind of elements and relationships categories we have. • Generic metamodel tells us what the language structure is, what are the most common relationships between elements and gives us a hint on how to organize models. • We could divide our models into three columns: Active Structure Elements, Behaviors and Passive Structure Elements. • Active Structure Elements are assigned to Behaviors, while Behaviors accesses Passive Structure Objects.
Information technology is constantly evolving. Organizations that can stay ahead of the curve are more likely to achieve success. As an IT executive, you are responsible for equipping your team with the necessary knowledge and skills. This will help them navigate their environment and outperform the competition.
According to LinkedIn, 40% of recruiters now utilise skills data when making hiring decisions. How do your business skills match up? Learning the right business administrative skills can make a big difference in how employers view your qualifications. Knowing which specific abilities they look for in job candidates is essential if you want to be successful.
Immerse yourself in this insightful video presentation where we unfold the compelling synergy of Artificial Intelligence (AI) and DevOps. This captivating content on AdvisedSkills dives deep into how AI-driven automation can significantly enhance DevOps practices.
Agile Transformation is sweeping across the business world, bringing promise of rapid delivery, heightened productivity, and improved customer satisfaction. Yet, the reality can often be grim. According to an Accenture study, a staggering 70% of Agile Transformations fall short of achieving their objectives.