I’m happy to announce the public availability (and downloadable PDF) of Mastering ArchiMate – Edition I, a book about the ArchiMate Enterprise Architecture language. My apologies for the inconvenience, but the book has its own full page now where information about the book is maintained, not just a blog post. See menu bar or just click here.
Comments on this post have been closed, please comment on the main book page.
R&A IT Strategy & Architecture 
Hi Gerben – book looks excellent! Reading it now. The PayPal page is in Dutch. Can you give an English version so that we can make an appropriate donation? Thanks – Jon
LikeLike
Still in Dutch. Both links. No option to click on an “English” translation, which is pretty rude of PayPal. If I could speak Dutch, I’d be looking for work in Amsterdam or Copenhagen. Very civilised. 🙂 Let us know if this gets sorted out.
LikeLike
The links have been repaired.
LikeLike
Cheers for the book. I will definitely have a look into it and from what I saw it’s going deeper than the “EA at work” I got.
Be sure to update your post with a right paypal link, you deserve it!
LikeLike
The links have been repaired. To be honest, the paypal link for donations is not the main driver for this book. It kind of bothers me that I have to pay so much attention to it instead of to the content. I am more curious how people are going to react to the content.
LikeLike
Congratulations! As an enterprise architect using ArchiMate and helping others use it, and as the Vice Chair of The Open Group ArchiMate Forum, this is a great gift!
LikeLike
Really impressive. Thank you for such a good book. I’m looking forward to reading the 2nd edition.
I’ve already donated for my “personnal use” even if I haven’t finish it yet.
Could you please contact me by email as I’d like to use it in a professional context.
LikeLike
I am interested in understanding more on your critisism of Interactions. I am new to Archimate. My background is in control engineering. I am looking for the a suitable way of describing control loop behaviour, the result of several functions (computation functions) and physical processes interacting in a control loop. The emergent behaviour and related requirements are in an analysis phase quite relevant to discuss without at all any link to a particular application collaboration, which to me is more part of the solution.
Perhaps my control loop should reside within the business layer of archimate, I am not sure, but still the interaction is important. I don’t find many good archimate examples, though.
What are your comments to this?
LikeLike
Dear Åsmund,
I don’t know if I completely understand your question. But it seems that you can have a Business Layer model with processes, regardless of the fact that they are automated or not. The control loop should then indeed have a representation at the Business Layer in the form of a Business Process or Function and internal (sub)processes.
I wonder what you mean with interaction. What I said about that in the “Discussing ArchiMate” chapter is that ArchiMate would work as well (even better) without it, as a special concept for the behavior of a collaboration is not necessary (the collaboration can be Assigned-To a function/process instead). The tool I generally work with allows that too. So, in ArchiMate 2.0 your ‘collaboration’ of automated (applications) and non-automated (roles) active objects could be modeled by Assigning them both to a Business Process which then is your ‘interaction’. You use Role, Application Component and Business Process and not Business Collaborations (impossible in ArchiMate 2.0 for partly automated processes) and Business Interactions (not necessary, as you can just use Business Process).
As you are the first to ask my comment on a question of ‘how to’, I’ll try to give an answer now. However (for others), it will be impossible for me to run a free one-man ‘how-to’ service for ArchiMate 😉
LikeLike
Thanks for the reply. (I just bought two copies of your book, understanding dutch wasn’t that hard..)
I really like the cleanlyness of Archimate, and believe it is good to limit the number of language primitives to something near the minimum necessary set.
If I understand you correctly, you say that there is no need for the specialised interaction type, you can always use function or process without loosing any information. I guess you are right. I still don’t understand exactly how to differentiate between process and function.
GW: Chapter “Advanced Patterns”, specifically Section 10, contains an in-depth discussion on process versus function.
LikeLike
Hi Gerben. Thanks for writing this book. Having only downloaded it (and donated…) today it already appears to have a wealth of interesting content that I think I will find very useful.
Great job!
LikeLike
The PDF files have been updated. Nothing has changed in the text except that the wording of the license has been improved.
LikeLike
I had to change the above text. I had to update the PDFs because I needed to conform to international ISBN rules. I will offer professionally printed copies through Amazon shortly, but these will be expensive.
LikeLike
Excellent introduction to the wonderful world of ArchiMate and some very solid patterns and ideas. Has certainly made me think a little differently.
LikeLike
Downloaded the book, made a donation of 10€ (and I sent an email for an invoice) before even reading it and advertised this page on my LinkedIn profile and Twitter. I’m anxious to read it as I have to come up with a EA mainly focused on a data warehouse solution.
LikeLike
Hi Gerben,
After a first pass on your book (rapid pass, as I did not pay yet 🙂 I noticed you don’t give any example for “derived viewpoints” of Archimate such as the landscape maps (as in section 8.4.18 of http://pubs.opengroup.org/architecture/archimate2-doc/chap08.html).
Is it because you did not find any useful meaning for this class of viewpoints ?
Note that I’m not really an Archimate practionner, but after some readings, I think these landscape viewpoints are an interesting outcome of the language.
LikeLike
On page 31 of the book it says: Lastly, #ArchiMate (and several tools) support ‘viewpoints’. Viewpoints are in fact subsets of the ArchiMate metamodel (the subset may include derived relations). A viewpoint may restrict which types of objects you may model and what relations are allowed between them. They are a sort of patterns, but not quite, as they do not so much prescribe how to model but only offer constraints in what you can do. I use ‘view templates’ for modeling (see Section 15 “Construction & Use Views” on page 97).
The idea behind viewpoints like those in ArchiMate (but not only ArchiMate) is that they provide some automated way to get a specific view on your landscape for a specific purpose. The problem lies in the word ‘automatic’. A technical viewpoint can only decide on grammatical rules what is relevant. And as Uncle Ludwig already explained half a century ago, your cannot create relevance by blindly following rules. As a result, those ‘grammatical viewpoints’ do not work very well. Maybe at a small scale, but they do not scale well in my experience.
The grammatical viewpoints using the relations and elements as mentioned in the spec also are generally not flexible enough in general to understand what is going on and give you the right result. Take viewpoint 8.4.16 form the specification as an example. Here you see that it shows the Application Component Realizing the Application Service. But what now if you do not have put that derived relation explicitly in your model? Suppose you correctly have set up an Application Function in between? Then this viewpoint in its simples incarnation might not show you the Application Component at all. 8.4.16 in that case only works when your tool calculates all the derived relations before deciding what to show. Possibly that means you programming complex viewpoints that contain all the possible routes by which you get from one object to another. Maybe it would work in that case, but that requires programming to get your view.
I am all in favour of providing good different views on your underlying model. But the choice of what goes in there is often semantical, not grammatical. You do not show all elements of type X attached to elements in type Y, but only a few that are relevant for the stakeholder. The rest only confuses. In the end, it is you as architect who has to decide what is relevant information for the stakeholder you want to show the view. The viewpoints of the standard may inspire you and sometimes they might work, but it will still be a lot of work.
WIth respect to the really nice intuitive view of 8.4.18, that looks like a nice Visio (OmniGraffle, Powerpoint, etc.) scheme to present a simple view. I have no idea what the elements types are, they seem to be applications, but they are not Application Components. I think they are Application Services, but without the little icon. I think such views are really useful. But the demand to construct them on top of a possibly detailed and rich model are in my guess often difficult. Again, what underlying relations must be available to be able to create this? You must have Business Functions directly using Application Services. But will you? What if your model is built using Business Processes using Application Services? Do you add all the extra relations? That has dire consequences for analysis if you get into really large models. Do you program viewpoints using the available routes between elements? Better, but a lot of work to set up and maintain.
And that leads to the another important point: presentation. If you want to do this automatically from a model, there is no tool that will give you a nice layout automatically That kind of design intelligence is beyond our computers. So, yes, you get a view with the right elements and relations of you use a viewpoint automatically created from your model. It will look terrible, though and you still need to do the work to present it properly. And that is 90% of the work. I you design the view by hand, you easily add something (say an extra Business Function and its dependencies). If you recreate the view from the model, you’ll have to run the viewpoint logic all over again and redo all the layout work, unless your tool understands calculating derived relations in the background and has been written with this kind of advanced functionality.
(A viewpoint like 8.4.18 being a possible exception to that rule, though even that one is not simple, if the model is rich and complex enough it might become impossible to create a nice layout like this, e.g. when a system is used in the upper-left and lower-right square and you have a few systems like that and you have a real organization with many more products and functions. Always watch out for those small and nice examples, do they scale to real life? They seldom do.)
So, it might work. But then, why do that for creating a simple message and not just create a Visio/OmniGraffle/etc. picture? There is no need to do everything from an ArchiMate model, especially not when presenting abstract and simplified views on your architecture. Your ArchiMate model might inspire you to create something nice in a drawing application. In many cases, that might be even less work.
(Reading the book , not (yet ;-)) paying and still getting a detailed answer. How’s that?)
LikeLike