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.
This FAQ also contains frequently asked questions about the book.
[Current version: Nov 1, 2017]
Sorry, no handy links to the answers yet.
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)?
- Can I annotate the PDF?
- Is it possible to read the book on a smart phone or small tablet/reader?
- Why is there no mobile (Kindle/iBooks/EPUB/MOBI) version?
- Do you offer volume discounts and/or educational discounts?
- I’m from the EU. Can I get a Reverse VAT Invoice for the PDF?
- Do you offer a bundle of the physical book and the PDF?
- Can I share a single PDF copy with multiple people?
- 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?
- 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.
- 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.
- 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.
- The fact that ArchiMate has four to six different ways (and different philosophies, not all congruent) to use abstractions in your model. See the book 😉
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 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: Using association when another relation is possible 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 Aspect (previously 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 there has been a reorganisation and some other department than before takes a 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 other ways in the architecture, such as am Artefact or Material).
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).
Can I annotate the PDF?
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. Here is a list from a few years ago of environments and what I know about this feature. As far as I know, little has changed since.
|Reader||Device||Operating System||Annotations||Reported on|
|Preview.app||Mac||OS X 10.9 (Mavericks)||NO||Mar 14, 2015|
|Acrobat Reader||PC||Windows 7||YES||Mar 14, 2015|
|Acrobat Reader||iPhone, iPad||iOS 8||NO||Mar 14, 2015|
|Goodreader||iPhone, iPad||iOS 8||YES||Mar 14, 2015|
|PDF-Xchange Viewer||PC||Windows 7||YES||Mar 14, 2015|
|Evince||PC||Linux/Fedora 21||YES||Mar 14, 2015|
|PDFAnnotator||Thinkpad Tablet||Windows 8.1||YES||Mar 14, 2015|
|Native PDF viewer||PC||Windows 8||YES||Mar 14, 2015|
As you can see, most platforms do have a reader that allows annotations. Those that don’t (Preview.app on Mac OS X or Acrobat Reader on iOS) actually have a bug
Is it possible to read the book on a smart phone or small tablet/reader?
PDF is a fixed layout format, so the pages are static in their layout and do not change depending on e.g. window size. The layout is optimised for the paper book (e.g. two column text is easier to read than one very wide column). That makes it unpractical to read the PDF on a phone or small tablet, you need a lot of scrolling. Reading it on a large tablet or large computer screen is ideal. The PDF does have an advantage over the paper book in size: you can scale up as far as you like without text or diagrams becoming pixelated: everything is ‘infinite resolution’ (except a few non-essential illustrations).
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 volume discounts (starting at 5 books). The discount calculations are complex but are based on establishing a progressive discount percentage on every next book in the volume and I can do mixes of PDF and hardcover if need be (but the hardcover stuff is more complex, see below). An excerpt of the PDF volume price list (all prices pre-tax, if any) is shown here:
|Total||Discount||Discount per book percentage||Effective price per book|
|Mastering ArchiMate PDF|
|1||€ 26.99||€ –||0.0%||€ 26.99|
|5||€ 128.25||€ 6.70||5.0%||€ 25.65|
|10||€ 229.43||€ 40.47||15.0%||€ 22.94|
|20||€ 429.68||€ 110.12||20.4%||€ 21.48|
|50||€ 996.24||€ 353.26||26.2%||€ 19.92|
|100||€ 1,763.84||€ 935.16||34.6%||€ 17.64|
|150||€ 2,333.07||€ 1,715.43||42.4%||€ 15.55|
|200||€ 2,810.32||€ 2,587.68||47.9%||€ 14.05|
|250||€ 3,263.98||€ 3,483.52||51.6%||€ 13.06|
The purchase of a volume of PDF licenses is technically done through selling you a 100% discount coupon code for use on the normal web site channel. The discount code can be used the number of times of the volume size. The coupon code is not transferable (you cannot resell it or its use). This mechanism also allows be to do handle VAT purchases inside the EU (which are not directly supported on the web site). For small (< 5) volumes administration cost may apply.
A comparable discount mechanism for hardcovers exists, but as hardcovers have a production cost that is fixed, the effective discount decreases more slowly as the volume increases. For 10 hardcovers it is around 8.5%. Note that the hardcover prices are discounted from the list price, and that a sale includes transport (so the actual offer depends also on your location). Note also that hardcovers take several weeks to arrive after payment has been received. The US approximate discount rate is:
|Total||Discount||Discount per book percentage||Effective price per book|
|Mastering ArchiMate HC US|
|1||$ 63.99||$ –||0.0%||$ 63.99|
|5||$ 310.79||$ 9.16||2.9%||$ 62.16|
|10||$ 584.63||$ 55.27||8.6%||$ 58.46|
|20||$ 1,129.41||$ 150.39||11.8%||$ 56.47|
|50||$ 2,717.06||$ 482.44||15.1%||$ 54.34|
|100||$ 5,121.86||$ 1,277.14||20.0%||$ 51.22|
|150||$ 7,255.76||$ 2,342.74||24.4%||$ 48.37|
|200||$ 9,264.03||$ 3,533.97||27.6%||$ 46.32|
|250||$ 11,240.09||$ 4,757.41||29.7%||$ 44.96|
EU prices follow a comparable discount mechanism.
Payments are possible by wire to an IBAN (free in the EU SEPA area). Cost of payment is for the buyer. Paypal payment is possible as well, again: fees for the buyer.
Contact me for an offer.
I’m from the EU. Can I get a Reverse VAT Invoice for the PDF?
I do not accept reverse VAT purchases through the DPD mechanism. I do accept these for volume purchases (>4 books). I can do a reverse VAT purchase for fewer books, but I do add administration costs (as this is a lot of tax administration work for me for a single sale). Contact me.
Do you offer a bundle of the physical book and the PDF?
Sometimes. While the likes of Amazon have very slick interactions with Ingram (which produces the hardcover), if I want to sell hardcovers myself, I have a lot of work to do (time consuming administrative actions) to make this happen. Given how little time I have for all of this, I need to minimise doing individual hardcover transactions if there is another option, unless that individual action is worth it (such as with a volume sale). Also, transport is expensive for just a single hardcover (and varies depending on where you live, so I cannot offer a clear price and have to calculate every single time). I probably have to ship non-trackable as it otherwise may become too expensive, but there is the risk of a package getting lost. Who carries that risk? And to top it off, the whole process takes about 4 weeks to get you that hardcover. Buy from Book Depository, and you have the book in a few days at a good price with free transport.
So, if you really want it, I might be able to sell you a single licenses bundle, but it won’t be extremely cheap. Expect something like Amazon US/UK price (which is list price as I write this) + 50% of the PDF price and buyer carries transport risk. (I will pass on Ingram information I receive about production status so you will know I actually put it in production). It will be affordable in the US and the EU and in Australia (where Ingram has printing operations I can use).
Can I share a single PDF copy with multiple people?
No. Each PDF copy is to be stamped with the name and email address of the user it is licensed to. Volume purchases (see above) are done via a mechanism where every PDF user in the volume still gets a private copy.
The idea behind this is that you pay per ‘single use’. A paper book has ‘single concurrent use’ built in as there is only a single physical copy. A PDF has not. The PDF is therefore stamped with the name of the licensed user and a license is ‘per single person’. There are no DRM mechanisms to enforce this. Nothing will stop you physically to share, but you and the one using it will be aware that you are (enabling) fraud. I assume you are decent and law-abiding and that you are not out to defraud me from (potential) income for the work that has gone into the book.
If you share your copy, the person you are sharing it with is more likely to share again, handing a copy out that has your identification in it. After all, the illegal copies carry your name, not theirs. So, please don’t share, you are breaking my friendly form of anti-piracy. I’ve experienced that when a ‘free’ copy is out in the world (before I used this system), less than 1% pays. Even people who would otherwise have paid will not pay. Even decent people working for decent organisations from countries where piracy is low will not pay. That has to do with psychology: >99% don’t pay if they already have the product. So, it may feel like a victimless crime to share, but you will in fact in the end be potentially destroying >99% of my sales.
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.