The (Mastering) ArchiMate FAQ

This page still needs to be updated for ArchiMate 3.0

I’ve received suggestions to create a FAQ for ArchiMate modellers, and recently I got another request, this time from Steve Else from EA Principals. I also sometimes get questions asked directly, which I attempt to answer in the LinkedIn ArchiMate Group or directly by email. Sometimes I get the same question multiple times. So, to make questions and answers accessible for all, I decided a while back that a FAQ would be a nice idea, so here it is (also thanks to Steve’s persistence): The (Mastering) ArchiMate FAQ.

Now, I need to make one thing clear: this is not an official FAQ from the owner of ArchiMate: The Open Group. The answers here are mine alone. This is an important distinction, because ArchiMate — as a language/grammar — has many different correct ways of modelling things, and so every answer is always a matter of taste. Hence the name (Mastering) ArchiMate FAQ, and not ArchiMate FAQ. And I apologise beforehand that I will regularly point you to my book for full(er) details (though much of this is basic stuff and is available for free as the syntax excerpt of the book). The FAQ is not meant to replace the book 🙂

I will add to this page, depending on questions I see more often. You can send questions to faq@masteringarchimate.com, or add them below. If they are asked often, I will add my personal reply here.

[Current Version: 1.0; Date 10 December 2014. No internal links on this page from questions to answers yet]

Questions

Learning & Using ArchiMate

  • How long does it take to learn ArchiMate well enough to start using it in a meaningful way for real enterprise work?
  • What is the best way to learn ArchiMate?
  • What is the best way to split up and synchronize work across an EA team using ArchiMate?

Understanding ArchiMate

  • What are the trickiest things about ArchiMate to remember?
  • Multiple relations are allowed by my tool between these two elements. Which relation should I use?
  • What is the difference between a Stakeholder, Actor, and Role?
  • ArchiMate is wrong on X, Y or Z!
  • Why is an Interface an active element? It only responds, does it not?
  • How do I model the ‘Business Services’ that my application provides?
  • Why is the ‘use’ relation Used-By and why does it arrow runs the way it does?

Modelling in ArchiMate

  • What is the best way to model X?
  • How would one model the Cloud?
  • How would model a concern — is there a best way?
  • Why doesn’t an application component, node or system software “process” anything?
  • How does one model business capability?
  • What is the best way to show a gap analysis?
  • What is the best way to link to BPMN?
  • What is the best way to link to UML?

Questions about the book & tool configurations

  • Why do you spend so little time on the ArchiMate extensions (Motivation Extension and Implementation & Migration Extension)?

Miscellaneous

  • Is ArchiMate an Open standard?

Answers

Learning & Using ArchiMate

  • How long does it take to learn ArchiMate well enough to start using it in a meaningful way for real enterprise work?

This is a dangerous question, because what is ‘well enough’ and what is ‘meaningful’? Much is a matter of taste (as much is if you are discussing the skill of using a language). The shortest time I have seen was 8 hours from someone new to the language and 3 hours from me. I coached someone who needed to model infrastructure for a project architecture. After these 8 hours he was able modelling this flawlessly according to the patterns that we used (from Mastering ArchiMate). In other words: learning ArchiMate and using well-designed patterns takes days, not months. ArchiMate itself is not very complex (less complex than BPMN and UML in my experience). Learning ArchiMate well enough to design scalable and robust patterns takes much longer.

  • What is the best way to learn ArchiMate?
  1. Practice (it’s really the only way to learn anything) on models that are actually used for decision making and discuss your models with peers.
  2. Get either a good training or read Mastering ArchiMate (or both) to get up to speed faster, it is easy to draw wrong conclusions and learn yourself mistakes and unlearning is a lot more difficult than learning.
  3. Certification can be a first basis. It teaches you the syntax (i.e., it teaches you to reproduce the standard), but not how to use the language well, how to choose your patterns and so forth. See also this blog post on Certification.

A tool is not necessarily a prerequisite for learning the language. In fact, when I train people (I do this in-house once in a while), they may have done larger homework exercises in a tool, but in class I only use pen&paper, flip-overs and such. In fact, I had one colleague once attending and he had done everything on paper with a pen.

  • What is the best way to split up and synchronize work across an EA team using ArchiMate?

First, it is important to use a real modelling tool and not a graphical tool such as Visio or OmniGraffle. If you have enough work for a team (a single person can already do much), then working together in a single model is the way to go. I prefer using separate views for business, application (per application/platform) and infrastructure and such separate views can be maintained separately. Have one person own the complete model and have phases for each view in the model (e.g. work in progress, draft, validated). See the Model Use and Maintenance chapter of Mastering ArchiMate for a possible way to set this up.

Understanding ArchiMate

  • What are the trickiest things about ArchiMate to remember?

1. The fundamental split between active elements and their behaviour. A Business Function in ArchiMate is not an (abstract) ‘entity’ that performs behaviour (such as it is in some other EA methods), it is the behaviour of an (abstract) ‘entity’. See the blog entries on GOFBF and the ones leading to it. Note, these are old (from the ArchiMate 1.0 days, the  more recent explanation can be found in Section 10 of Mastering ArchiMate.

2. That not all models that are allowed by the language also make sense. This is comparable to the fact that in natural language you can form syntactically correct sentences that are meaningless. E.g. you could model that someone controls the LHC with an Excel spreadsheet, but that is not true (I hope). See an older post: ArchiMate is not a Language.

3. Class versus Instance modelling. Are your elements ‘kind of things’ or are they ‘things’? Read the A short “Class/Instance” Primer and Modelling Classes or Instance or Both parts about class versus instance in the blog post about modelling homogenous landscapes. Even the standard itself makes mistakes here, especially when defining the official viewpoints (as explained in the Discussing ArchiMate chapter of the book). Mixing the meta-model and a model is a common pitfall.

  • Multiple relations are allowed by my tool between these two elements. Which relation should I use?

First, read closely the ArchiMate Basics chapter of Mastering ArchiMate, which is also part of the free syntax excerpt that is downloadable as a PDF from the book’s main page. You will learn that each different relation type has a very well-defined meaning/use (except the catch-all Association). E.g. Access is only used to show that behavioural elements create/read/write/delete informational elements.

Then note the following:

  1. Don’t use the Association (which can be used as a catch-all) relation if another relation is possible. Be as specific as possible; you are modelling, not doodling. Good rule of thumb: Association is for wimps, real architects use a specific relation.
  2. Use structural relations to set up your landscape, and use dynamic relations (Trigger, Flow) separately to show sequence and information flow in that structured landscape. So, think separately about structural relations and dynamic relations.
  3. Furthermore, there are two kinds of relations: direct relations and derived relations (make sure you understand these from ArchiMate Basics chapter). In most cases, there is only a single direct structural relation that is appropriate between two elements. E.g., when you want to relate a Business Function with a Business Object, the one to use is the Access relation. Watch out for the Specialisation relation, it is not about elements but about kinds of elements. Read the A short “Class/Instance” Primer and Modelling Classes or Instance or Both parts about class versus instance in the blog post about modelling homogenous landscapes. The major exception to a single direct structural relation is the relation between process/function and service in the same layer. See The double use of Used-By and Pitfall 4 in the ArchiMate Basics chapter.
  4. Most other allowed relations are in fact derived relations for a chain of other relations and elements between the two you want to connect. Make sure you understand derived relations, and if your relation is not a direct one, make sure you understand the chain you are effectively summarising with your relation. Derived relations are a constant source of fun/confusion/etc., see also most “What is wrong with this picture” posts on this blog.
  • What is the difference between a Stakeholder, Actor, and Role?

First, read the description of the Core ArchiMate language in the ArchiMate Basics chapter of Mastering ArchiMate, this chapter is part of the free syntax excerpt of the book. Actor and Role’s basic use are explained there.

Actor and Role are part of ArchiMate’s core, the core is intended to model the architecture of the organisation, let’s call that a landscape. This can be either a current or a future landscape, of course. Stakeholder is part of the Motivation Extension, which was added in ArchiMate 2.0 to be able to model the ‘why’ of such a landscape, and the extension is almost completely separated from the core language.

Actor is meant to model a ‘physical’ actor at business level, but that is not just a person, but may be an organisational entity, such as a department. Role is an abstraction that is common in business descriptions that decouples the actor from his behaviour (e.g. a process). This decoupling enables flexibility and robustness in your models: if someone leaves the company and someone else takes his/her role, the model of the enterprise does not change. ArchiMate defines Role as ‘the responsibility for behaviour’. You generally use roles so you can make a model that is more robust under organisational change, but you can see Role as a ‘someone’ (or department, etc.), but you do not know exactly who (person) or what (department etc.). What is lacking is ‘identity’.

Stakeholder is a separate element that is only used to model the ‘owner’ of requirements, constraints, goals, etc. and there is no integration with the ‘actor’ elements in the core language. I personally think that is not the best solution (more information in Section 28.16 of Mastering Archimate and in the blog post Why is Stakeholder not a Role in ArchiMate?) and that it would be good to have a tighter integration of the core and the extensions and thinking stakeholders are not part of your business architecture is, I think, a mistake (see also section 12 of Mastering ArchiMate for a way the entire enterprise comes into play)

  • ArchiMate is wrong on X, Y or Z!

First: I agree. I know of various problem areas, omissions, even things I consider errors in ArchiMate. I’ve spent a whole chapter on this, including improvement suggestions, in the book.

Second: such a statement is often a matter of misunderstanding when coming from another domain (see next question for an example). Arguing from one perspective to ‘prove’ that ArchiMate has it wrong is akin to proving German is wrong because French (culture, and thus language) has different concepts.

Anybody up for a round of discussing Uncle Ludwig?

  • Why is an Interface an active element? It only responds, does it not?

This is one of the issues software engineers have to get to grips with when learning ArchiMate.

This question is sometimes asked by software engineers mainly. They see an interface as, say, a port on a computer where a program can connect to, then send a request and get a reply. For them, the program is active, the interface is passive, it reacts. But in ArchiMate it is not active versus reactive, it is active versus inactive. The ArchiMate split is has behaviour (active)/has no behaviour (passive). An interface in Archimate acts, even if it only re-acts. Maybe it would lead to less confusion is ArchiMate would say active versus inactive structure, instead of active versus passive structure.

  • How do I model the ‘Business Services’ that my application provides?

This is one of the issues software engineers have to get to grips with when learning ArchiMate.

The term ‘Business Service’ is used in ArchiMate differently from a rather common use in software engineering. Software engineers often use the term Application Service for a service provided by an application that is used by another application, and they use Business Service as the term for a service provided by an application that is directly used by ‘the business’ (read: humans). In ArchiMate, a Business Service is an element independent from applications, it is part of the ‘business layer’ and it is more a kind of an abstraction (just as ‘Business Object’ acts as an abstraction of what is represented in many ways in the architecture).

So, in ArchiMate, the ‘Sell Flowers’ (Business Service) that is Assigned-To a Florist Shop (Business Interface) that is part of the Florist (Business Role). There is no application in play at all. An automated shop in ArchiMate, could for instance be: Web Site (Application Component) has the Web Site (Application Interface) which is Assigned-To the ‘Sell Merchandise’ (Business Service) which is Used-By the Buy Merchandise  (Business Process) that is Assigned-To the Customer (Business Role). But we could also model: Web Site (Application Component) has the Web Site (Application Interface) which is Used-By the Buy Merchandise  (Business Process) that is Assigned-To the Customer (Business Role). ArchiMate leaves you with a lot of options, which makes it less predictable but also flexible in expressing what you need.

  • Why is the ‘use’ relation Used-By and why does it arrow runs the way it does?

This is one of the issues software engineers (especially UML users) have to get to grips with when learning ArchiMate.

Marc Lankhorst write the following answer in the LinkedIn discussion (used with permission):

This was chosen because it denotes the direction of service delivery. Perhaps the name ‘used by’ is a bit unfortunate, and ‘ delivery’ or something similar might have been better. One advantage of this is that it yields models with directionality, where the arrows point ‘upwards’ towards the client/user, as you can see in the Layered Viewpoint example in the standard.

Another reason is that it abstracts from the ‘caller’ or ‘initiator’, since a service may be delivered pro-actively. The direction of delivery is always the same, but the starting point for the interaction can be on either end. UML’s dependency is often used to denote the latter, showing that the caller depends on some operation that is called.

This is related to the question about the active/passive status of Interface. See also this blog post: Used-By Redux.

Modelling in ArchiMate

  • What is the best way to model X?

There are two answers to this one.

  1. There is no best way. Period. Having said that: Model the same thing always in the same way (use patterns) and use well-designed patterns, and only model that which has a use when modelled.
  2. My way, of course. Read the book 🙂
  • How would one model the Cloud?

Small question, big answer. Too big for this space. Generally, one can say that using the cloud does not change the essential structure of an enterprise architecture, there still are business processes, applications and infrastructure. They are just owned by other parties. See also the blog post Low-hanging Cloud on this site’s sister blog Chess and the Art of Enterprise Architecture.

What you model alway should depend on what you want to use the model for. You could bring SaaS back to just an Application Service for instance (as shown in section 7.14 of Mastering ArchiMate), the rest you do not know and leave out. I would probably model PaaS and IaaS in full (though with restrictions, see the blog post on modelling homogenous landscapes) because you actually decide on the architecture of your landscape when you use IaaS.

  • Why doesn’t an application component, node or system software “process” anything?

That is a good question. At the business level, we have both function and process and at the other levels we only have function. The best thing is to go back to the difference between business process and business function in ArchiMate first. The difference is not so much that this is different behaviour, but it is the same behaviour modeled from a different perspective. One is: what does it produce? (process), the other is what does it have in common? (function). The first is intuitively clear, the other less so. From the ArchiMate 1.0 days stems the Business Process vs Business Function post which is still by and large valid and it also lightly touches upon the issue at the other layers.

The real answer is: I don’t know, but I guess that the designers tried to keep the language as small as possible and decided that the same structure at the IT levels did not add much. And I agree, I do not miss it, while I would miss Process at the business level.

  • How does one model business capability?

At this point there is no decent way to model a capability as a single element in ArchiMate.

ArchiMate is based on an amalgam of many approaches and thoughts, originally mixed together by a consortium of businesses and university. Capability was not in that first mix and it has until now not been added. I guess Business Function was entered to play that role (given the notion of a ‘string of business functions’ that is mentioned in the standard and which is a phrase that is closely connected to the ‘capability’ mode of thinking for business functions). But at the same time ArchiMate got the fundamental actor/behaviour split and Business Function in ArchiMate became purely behavioural.

Some more information to read: Blog posts Missing from ArchiMate: Business Capability? and Modeling GOFBF. Sections 10 and 28.9 of Mastering ArchiMate.

  • What is the best way to show a gap analysis?

If you want to model the way your organisation creates a gap analysis (e.g. as part of the enterprise architecture processes), then the Gap Analysis itself could be a Business Object, which is created by (Access) the Create Gap Analysis Business Process which is performed by the Enterprise Architect Business Role.

There is a Gap element in the Migration & Implementation Extension (also poorly integrated with ArchiMate’s core) which you can Associate with any core element, including a Business Object (e.g. Gap Analysis) or Business Process (e.g. Create Gap Analysis)

See also Sections 20 and 28.16 of Mastering ArchiMate.

  • What is the best way to link to BPMN?

Is there a ‘best’ way? Not really, because ‘best’ depends on how you want to use the model and there is no ‘best’ for all uses. A possible (and proven in practice) way is in Section 25 of Mastering ArchiMate. I’m not going to repeat that entire chapter here…

  • What is the best way to link to UML?

I haven’t thought about this one yet. UML is rather broad in the sense that you can do much more with it than software architecture (and some even use it for enterprise architecture instead of ArchiMate) so I guess that there are many, many ways to link these.

Questions about the book & tool configurations

  • Why do you spend so little time on the ArchiMate extensions (Motivation Extension and Implementation & Migration Extension)?

The book is fully based on actual real-life large-scale ArchiMate deployment, as far as I know that largest deployment in the world (e.g. a model of 41,000 elements and relations that can be maintained by 1 fte and is integrated with BPMN models for the processes and various other administrations). The Motivation Extension was used to add Risk & Security to the models.

So, the short answer is: we did not use the extensions much, and as we did not use them, they did not end up in the book. Almost everything in the book is more than just theory/idea, it has proven itself in practice.

Why did we not use the Motivation Extensions much? Well, for the Implementation & Migration Extension, I was interested in using it, but we did not get around to doing so. With respect to the Motivation Extension, I think the idea of modelling your requirements and such this way does not really scale. At small scale it is only useful for toy problems and situations, and there modelling does not add much but it does add confusion for many readers. One of our team tried to use the Motivation Extension extension for a project architecture, and we had to leave it out because it scared people off. I think it actually did have a positive effect in terms of structuring your ‘why’, but the overall effect was negative. See also the blog post ArchiMate is overrated (and underrated).

So, the extensions are explained, but they are not extensively described in the book. Only the Motivation Extension is used substantially, but only for a single reason: it is very capable of modelling Risk & Security aspects in your landscape, which is very useful for Current State architectures and the way you can report about your landscape (‘in control’ and such).

Miscellaneous

  • Is ArchiMate an Open standard?

I don’t consider ArchiMate open. It is not royalty-free and it is not maintained by a not-for-profit organisation. ArchiMate is a commercial standard that is shared by a collaboration of vendors (who pay for the privilege) and exploited by a for-profit company (X/Open Ltd). Is that a problem? I don’t consider it a problem, but some people might. In any case it is good to be aware. It is a difficult subject, but if you’re curious see the explanations here (long) and here (follow-up).

NOTE for this page specifically: Comments are welcome, but they may be removed if they end up as a new or changed FAQ entry. This will keep the comments section manageable.

5 Responses to The (Mastering) ArchiMate FAQ

  1. Pingback: New: The (Mastering) #ArchiMate FAQ | Mastering ArchiMate

  2. John Gardner says:

    When I model Capabilities, I use the Service with default colours of each of the BADT domains. I also equate Service with ABB. Where I am creating a mixed model of ABB and SBB to define Capabilities, I use the Process, Application, Data (Object) and Node elements to represent each type of SBB.
    This approach (adaptation) allows me to create Strategic Models (pure Capabilities, Requirements and ABB), Architecture Models (mixed Capabilities, Requirements, ABB and SBB), and Solution Models (SBB).

  3. Guillaume says:

    I find interesting the colour schemes you use (blue : active, yellow : behaviour, green : passive), however isn’t it misleading as it’s different from ArchiMate colour scheme (implemented in modelling tools), hence applied by most people? I’m only discovering ArchiMate (I’ve used extensively UML, SysML & BPMN so far) and when I looked at a diagram that a colleague produced, I couldn’t understand the colours he used.
    Applying a different colour scheme seems risky to me as we move away from the “standard”. I’m interesting to know your opinion.

    • gctwnl says:

      I’m using the original ArchiMate colour scheme. And I provide this colour scheme for any tool I can. Currently BiZZdesign Architect and Archi.

      It is a pity that most tools use the simple layered scheme ad standard, these days. But then, most people only make a few simple models 😉. For more complex views whete more is modeled of the intricacies within a layer, the original scheme with my layer-adaptation works much better, as I’ve also been told by several people who have used it extensively.

      I understand your point, but the problem is not that big.

    • gctwnl says:

      Adding to my previous answer, you can read this explanation. Note this is still from the ArchiMate 1.0 days, so not all actual models shown in those posts are ArchiMate 2 compatible. And while you’re at it, another good post to read is this old one. It contains probably the single most effective decision made for modelling standards that positively affects communication with ArchiMate views.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s