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 email@example.com, or add them below. If they are asked often, I will add my personal reply here.
[Current version: Sep 11, 2017]
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?
- 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?
- 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)?
- Why is there no mobile (Kindle/iBooks/EPUB/MOBI) version?
- Do you offer volume discounts and/or educational discounts?
- Is ArchiMate an Open standard?
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?
- 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.
- 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.
- 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.
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 the book.
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. Mixing the meta-model and a model is a common pitfall. Edition III goes deeper into this than previous versions.
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. 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:
- 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.
- 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.
- 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 Serving and Pitfall 4 in the ArchiMate Basics chapter.
- 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 that 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 the book and in the (older) 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 the book 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 in each edition, including improvement suggestions.
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 Serving 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. Note, Used-By has been renamed to Serving in ArchiMate 3.
Modelling in ArchiMate
What is the best way to model X?
There are two answers to this one.
- 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.
- 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 the book), 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.
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 the book. Of course 🙂
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 the book. 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 extensively 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. But it’s not part of my actual expertise and thus also not part of the book.
Questions about the book & tool configurations
Why do you spend so little time on the Motivation Aspect and the Implementation & Migration Layer?
The book is fully based on actual real-life (often large-scale) ArchiMate deployment, as far as I know at some point the largest deployment in the world (e.g. a model of tens of thousands 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 Aspect was used to add Risk & Security in those models.
So, the short answer is: we did not use these 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 them much? Well, for the Implementation & Migration Layer, I was interested in using it, but we did not get around to doing so. There are also limitations and it is the question if this is something one should solve in the language or more in the tool (‘versions of the landscape). With respect to the Motivation Aspect, 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, these are explained, but they are not extensively described in the book. Only the Motivation Aspect 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).
Why is there no mobile (Kindle/iBooks/EPUB/MOBI) version?
I get this question a lot, so I am answering it here. I originally started Edition I as an Apple iBooks project, being blown away by the original iBooks presentation. I worked on this from March 2012 until August 2012 and then had to give it up:
- Apple iBooks did (and does) not support vector images. Even if iBooks Author accepted vector images (PDF or SVG, I don’t remember), on iBook production these images were translated to pixel images. For very large diagrams and Apple’s chosen maximum pixel size, the contents became unreadable.
- Even if I would have accepted too-low resolution/too small images, navigating them in iBooks is a pain. iBooks uses the pinch movements for getting in/out of the image, instead of zooming the image. So, setting up zooming for large diagrams was in the end effectively not doable. The workarounds I tried never worked properly. I even investigated dynamic HTML5 builders like Hype, but in the end decided that this was undoable with respect to the amount of work required (and me doing this in my own free time).
So I had to move to paper, but I wanted to keep some sort of electronic option open. Given I want to support electronic and paper with a single work flow (not laying out two separate books, thank you), I had to go for paper and some sort of electronic export. I first tried Apple Pages (for paper & EPUB) and but this was in many other ways so limited (e.g. no automatically maintained references to other parts of the book for instance, so “see diagram 312 on page 200” would become a nightmare of manual maintenance) that I had to give it up. I looked at creating a real app, but that would exclude paper. In the end, I used Adobe InDesign CS6 for Edition I and decided that it would be paper and PDF for electronic.
When Edition II was nearing completion, and I wanted a different distribution of the PDF (as there were many downloads, but not so many purchases, not even at the ridiculous low price I had set) I looked at Kindle again as they promised they could handle PDF. It turned out that their idea of handling PDF is to take the PDF document, OCR it and turn it into EPUB. The effect was very funny: no single image was retained. I looked at several other setups that proposed to turn my PDF into an eBook (stuff used for magazines on iPad etc.), these required all kind of troublesome work flows and often were priced for Rupert Murdoch, not for me. So, there you have it: will there be a Kindle or iBook version? I’d love to have one, but I researched every opportunity and in the end had to give it up. This is what it is and there will be no Kindle version.
There are very good PDF readers for iPads and such (e.g. Goodreader for iPad), so PDF is certainly ‘good enough’. Even if it was technically feasible, it would mean a lot of work, an independent second book and hardly any revenue: selling a book for Kindle means that you have to go for very low prices and large volume. Amazon asks a ‘delivery fee’ based on file size (very nice when all your 350 diagrams become pixel instead of small (and perfect) vector) and 30% of the selling price for books between US$2.99 and US$9.99. But that is not all. The 30% is only for a limited number of countries. Ask a price over $10 (or do not allow text-to-speech, very funny for books with many diagrams like mine) and Amazon takes 65% of the selling price everywhere (and of course the delivery fee). Remember, we’re talking delivering a file, not producing and distributing a physical book. Distributing as PDF via independent ‘digital goods delivery’ services (I use the excellent services of DPD) is currently the only electronic option for a large, very graphical, low volume book like mine.
The PDF’s content is protected. Your PDF reader won’t let you print the document (if you need a paper version, it is available separately). Your PDF reader will also not let you change the content. But what you are allowed to do is add annotations to the file, such as highlighting and comment balloons. The settings of the file allow this, but not every reader implements this correctly.
Do you offer volume discounts and/or educational discounts?
Yes. For the hardcover edition this depends on where you live, because transport cost is added to the mix and the price of production depends on where it is produced (UK, US, AU), so I cannot give numbers.
For the PDF version, which costs €26.99 ex VAT (all prices are ex VAT, you pay your country’s VAT tariff when you are in the EU) I have a spreadsheet table. I offer discounts on the PDF for five copies or more (the reason being that a volume sale is quite a bit of work and for two copies means a lot of work for us both and hardly any discount). Here is the table (I can do all the amounts in between):
|Total||Discount||Discount per book||Discount per book percentage||Effective price per book|
|Mastering ArchiMate PDF nr. of licenses|
So, 10 PDF licenses cost €229.06, which is a €40.84/15% discount and effectively €22.91 per book. 30 PDF licenses comes with approximately a €200 discount.
Delivery takes place by selling you in fact coupon codes which you are then only supposed to use for people of your own organisation (with your organisation’s email addresses). This means that you cannot shuffle the copies around in your organisation, each PDF copy is licensed to an individual. The reason is that there is no technical DRM on the PDF (which is nice for you), but as soon as a (semi-)anonymous copy starts floating around, I will sell <1% of what I normally sell.
There is no separate educational discount, but if you are a very poor institution, I’m flexible 🙂
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.