Why this book?
More than 15 years after its creation, the ArchiMate standard is still often perceived as hard to learn and complicated to use. Despite a relatively short official specification  and two great books   about it, a lot of people are overwhelmed by the number of concepts, don’t known how to choose one over the other and don’t know how to put all this into practice.
It is of course possible (and recommended) to follow an official course on ArchiMate, but such trainings are designed to make it possible for people to take the official exams and to get certified by The Open Group. While such certification is great and needed in some contexts, it implies that the course has to explain every bit of the specification in a relatively short time, while most people won’t use more than 50% of if in the short term.
This book idea first emerged from the feedback of trainers who were frustrated to see that (despite being certified) new trainees were not able to actually apply their new knowledge, while in some other (more informal) contexts, it was possible to quickly explain how to use a small subset of ArchiMate and have people up and running in few hours. It became clear that there was a place for a simplified introduction to ArchiMate.
This book is an attempt at filling this gap. It is intended as a practical discovery of the standard, a "101" that should allow anyone with a little Information Technology background  to understand the foundations of ArchiMate and produce valid and useful models in a short amount of time.
What’s in, what’s out?
This book’s purpose implies that not all aspects of ArchiMate will be covered, but instead it will focus on a small subset composed of elements and relationships that are generic enough to cover the most frequent needs. It will also focus more on the Core domain which consist of the Business, Application and Technology layers.
Provide examples are built upon this small subset, But some more advanced use-cases are also addressed. In these advanced use-cases, some more specialized concepts (which might be needed for some people) will be introduced. Feel-free to skip these advanced use-cases if they don’t match you needs as this book never assumes you’ve read them.
A special note for the advanced reader: you might be surprised here and there, by how things are presented or explained. You might have chosen another element, another relationship or whished the exact meaning of some derived relationship was better explained. If this happens, keep in mind that the knowledge you have is the result of several years of practice, and that our goal is not to make people understand these more theoretical details, but simply to allow them to practice as soon as possible.
The structure of this book is as follows:
Part I – Introduction, introduces the goal and scope of the ArchiMate standard, and provides general guidance on viewpoints and views.
Part II – The Language, describes the language structure and generic metamodel through the "System" metaphor and then presents the small subset of concepts that will be used throughout this document. Common use-cases and viewpoints are presented, and (for some of them) a more in depth approach will be studied.
Part III – Advanced Topics & Methodology, answers some common questions about ArchiMate or the modelling practice itself, presents the different approaches to structure the model content, and discuss the advantages of reference models.
Part IV – Sample Viewpoint Library, provides a starting point for a good set of viewpoints.
Part V – Archi Modelling Tool, provides useful tips and tricks for those who use Archi opensource modelling tool.
ACKNOWLEDGEMENTS The ArchiMate User Community gratefully acknowledges the contribution of the following people in the developments of this and earlier versions of this document:
Jean-Baptiste Sarrodie, BNP Paribas
Jean-Denis Laval, BNP Paribas
PART I - INTRODUCTION
When I am asked the question What is ArchiMate?, I usually provide the same simple answer: A (foreign) language for Enterprise Architecture. But the real question people should ask is Why ArchiMate?. And here is my answer…
Before even starting to speak about ArchiMate, we have to widen the scope to the practice of Enterprise Architecture. Enterprise Architecture is about understanding the complexity in which an organization evolves and helping this organization to manage changes. In this context, "Enterprise" is not a synonym for "organization" but is the purpose (some would say the story ) of this organization. Thus, as Enterprise Architects, we have to first understand this purpose and share it with all stakeholders. Then, the preparation work can begin and, again, we have to share it with all stakeholders.
Simply put, communication is more than half of the work of an Enterprise Architecture practice.
But if communication is such a big part of our job, then how can we make sure we are understood? How can we find the best way to communicate?
Telling stories with visuals is an ancient art. We’ve been drawing pictures on cave walls for centuries. It’s like what they say about the perfect picture book. The art and the text stand alone, but together, they create something even better.
Architecture description and communication
In our practice, communication is embedded in what we call "architecture description". This architecture description should be as effective as possible and mix both visuals and texts. But as it targets multiple stakeholders, we, in effect, often end up describing the same architecture using multiple "stakeholder-related dialects".
And here is the start of the answer to our question: ArchiMate has been designed from the very beginning to support effective communication. ArchiMate is not about standard boxes and lines, it is all about a common language that provides the foundations for a good architecture description. In addition, the ArchiMate standard also provides some guidance on this topic.
Using this "language" analogy, and simplifying a bit: * ArchiMate contains a rich vocabulary that covers most domains of Enterprise Architecture (Strategy, Motivation, Transformation, Business, Application and Technology). * ArchiMate is based on a grammar similar to natural language (subjet|verb|object) to describe what people or "things" do, and adds an external, service oriented, view of those activities. * ArchiMate (default) notation is very similar to spelling as it provides a way to "save ideas on paper".
Using the language without its notation is already of great value as it allows people to understand each other. By "each other" I mean people from the organization you work in, but also people from other organizations you interact with. Should you have a need for some external help for your architecture work, you can simply ask for people who know ArchiMate.
Of course, using the notation is another value increment, as it will allow you to mix visuals and texts. However, some stakeholders may be unsure of such a formal notation, so don’t hesitate to simplify it as much as possible, or even use an alternate notation in some cases. You should always keep in mind that ArchiMate is not the goal, but simply a means to achieve it. The real goal is to make your architecture easy enough to understand so that people can make the right decisions, and decide which moves are the correct ones.
Of course, one could simply use pen and paper (or drawing tools) to work with ArchiMate, and this would already be of great value. I personally almost always use whiteboards to discover a new topic, elicit discussions with stakeholders and first draft an architecture. But at some point, the volume of information to keep at hand requires a tool. In the context of ArchiMate, such tool is known as a modelling tool. A good modelling tool simplifies the work and limits the burden of maintaining an architecture description. A good modelling tool helps you to maintain the coherence inside your model.
But as soon as you move from drawing to modelling, you can also start exploring and analyzing gathered information. This is an often overlooked feature, but providing insight is another great value of ArchiMate modelling.
When (not) using ArchiMate?
So, is ArchiMate a one size fits all language? Is it the perfect solution for any problem you might have? Of course not!
As with any solution, ArchiMate has been designed to solve a specific problem. In our case this problem is the (in)ability to describe an architecture in a way that makes it understandable by most stakeholders. So as soon as we move out of this scope, then ArchiMate gradually becomes inappropriate.
The best way to understand it is to see a typical architecture work as Damien Newman’s "the Squiggle" . When first confronted by a new topic to work on, we then start to understand it. This "research" forces us to go back and forth with one simple goal: finding the right question to answer. Then we slowly move to the "coherence" phase in which we can explore possible answers to our refined question. Once this is done, we can then move to the "details" phase in which we dig deeper into the details needed for implementation (whatever "implementation" means in our context).
For each of these phases, we need to rely on different methods and tools:
"Research" mostly relies on note taking tools in whatever form (pen & paper, mind mapping…)
"Coherence" mostly relies on common language and high level modelling. This is the scope of ArchiMate.
"Details" mostly relies on domain specific language such as UML (for software design) or BPMN (for process modelling).
A good architecture description should of course contain all this, but at the minimum, we should make sure we have a good and coherent overview. It’s ArchiMate’s role to support such overview, but also to provide "links" to other phases through some well thought overlaps (high level concepts like Capability and Resources, but also Grouping, to link with "Research" ; Business Process, Application Components and Nodes to link with "Details" in UML and BPMN…).
If you work in the field of Enterprise Architecture, being able to communicate with your stakeholders is key.
When dealing with architecture, communication is achieved through an architecture description.
An architecture description that targets Enterprise Architecture’s stakeholders must rely on a common language.
ArchiMate has been designed with this exact goal in mind: providing a common language for Enterprise Architecture.
ArchiMate provides value in increments: common language, common notation, ability to analyze gathered information.
ArchiMate is not a silver bullet.
ArchiMate should be used to create an overview of an architecture with just enough details (and if needed those details can then be described using other, more suited, domain specific languages).
Importance of viewpoints
The same way "This is not a pipe" as it is only the representation of a pipe, a model is neither the reality, only a (hopefully) useful abstraction. But a model is a multidimensional thing that our human brain has some difficulties working with, that’s the reason why we rarely work on the model itself but on subset called a view. While doing so, we have to remember that (again) a view is not the model, only a (hopefully) useful abstraction. So the real question is: How do we decide what to left out in the process?
Most of you should already have a good grip on this question, but ArchiMate provides a good framework for this as it has been designed from the ground up to allow architects to communicate their work in a coherent and effective way. This is made possible not only by a good set of concepts, but also by the idea of architecture viewpoints, borrowed from the ISO/IEC 42010 . In short, an architecture viewpoint is a set of conventions that can be used to produce an architecture view (a view could be a diagram, a catalog, a matrix or any useful way of describing a subset of your architecture) to answer a known concern from a known set of stakeholders.
ArchiMate framework for defining & describing viewpoints
Know your stakeholders
The very first step is to clarify who will observe and read (part of) your architecture description. It should be clear that your organization’s CEO, a product owner or a network engineer don’t have the same concerns and thus don’t expect the same kind or amount of information. So making sure you know who your stakeholders are and what drives them is key: your CEO will most certainly focus on the strategic aspects while an engineer will check if chosen technology is the right one and if some established principles or rules are taken into account.
This is sometime referred to as an outside-in  perspective: we have to understand the broader context (our stakeholders’ concerns) to drive our own modelling choices.
Set the purpose
Of course, modeling is never done for its own sake, and you most certainly have other reasons to create or update your model. That’s what ArchiMate call the purpose dimension. There are three common categories of purpose:
Informing viewpoints are used to achieve understanding or obtain commitment. Such viewpoints often target a broad audience and should be simplified and straight to the point. The main goal is to elicit feedback to make sure that the communication is effective.
Deciding viewpoints support the process of decision-making and often target managers. Gap analysis and scenarios comparison often fall in this category. The main goal is to obtain a decision or a choice between several options.
Designing viewpoints support the design process from initial sketch to detailed design. They typically targets subject matter experts. The main goal is usually to define or refine a target.
This is sometime referred to as an inside-in perspective: our own needs drive our modelling choices.
Define the content
With a clear view on the purpose, your stakeholders and their concerns, you should now be able to define the level of detail or abstraction needed. ArchiMate call this the content dimension and suggests the following three categories:
Overview: this groups viewpoints providing a helicopter view on a subject which usually mixes multiples domains (such as Strategy, Motivation or Core) and/or layers (Business, Application and Technology). Such viewpoints usually targets decision-makers or enterprise architects.
Coherence: the usual goal of coherence viewpoints is to focus on one specific topic, but seen through multiple, complementary, angles. The emphasis is often on collaboration between people, processes or tools.
Details: as its name implies, detailed viewpoints focus on one specific topic and zoom in only one of its aspects. This level of detail usually target subject matter experts or software engineers.
Choose the best representation
The last step is to choose the best representation for the viewpoint you’re defining. Architecture views created with ArchiMate are usually diagrams, but using the information provided by the underlying model content, it is also possible to create catalogs or matrices. In fact any data visualization technics could be used.
If you and your architecture team often work with projects’ team to design their target architecture, you will, at some point, have to present this architecture to your organization’s CISO (Chief Information Security Officer). Of course, you’ll have to have your CISO validate your choices (i.e. you don’t just have to inform her). But what are your CISO key concerns? Security as a whole of course, but what is important for her in your organization? For the sake of this example, let’s simplify and assume that your CISO mainly focuses on dataflow related to the internet. This will lead you to contribute to the project’s architecture description to address her concerns.
In addition to this, what level of detail do you need? Well, your CISO might not be too technical so you’ll have to provide an overview, not something too detailed.
Lets summarize: for each project, you should provide a short document that allows the CISO to quickly understand project’s impacts on the internet dataflows. Nothing more is needed because you know that your CISO won’t care.
What we have done here is defining an architecture viewpoint. Note that there’s no link with ArchiMate for the moment and that’s on purpose: ArchiMate is only one of the different ways to produce a view, but you could decide to use another (potentially custom) methodology, or even a drawing tool. Of course, using ArchiMate and a modelling tool will allow you to have a coherent set of views and will provide additional benefits (you can query your model and create some automated analysis). So, assuming you’ve decided to use this standard in your work, we can further describe your viewpoint.
What kind of "document" will you show to your CISO? You could decide to provide the catalog of network flows related to internet and impacted by the project. A picture being worth a thousand words, you decide to provide some diagrams. However, does your CISO know ArchiMate? Maybe just a little bit or even not at all, so you decide to use only a subset of ArchiMate (Node, Network…). In addition, because several network security experts often do it that way using drawing tools, you decide to draw network zones as big boxes inside which you put nodes (that you call "servers" for your CISO). Being trained in ArchiMate, you know that the right relationship to link (communication) networks and nodes (as servers) is association, but association is not meant to be shown as nested, but in this case you decide that nesting would really ease communication with your CISO and avoid them having to take time and learn something new, so you accept this non standard use of nesting .
You decide that flows that are at risk will be colored red because this is the de facto standard. Nevertheless, you know that the network team will reuse this document but some people are color blind, so you use labels as well as color so that the document is still usable for them.
Viewpoints’ documentation usually combines at least one view example, a textual description and a more formal one consisting of the following attributes (here illustrated with the previous example):
Viewpoint Name: Internet Dataflow Viewpoint
Key stakeholder: CISO
Key concerns: Avoid any security breach related to internet dataflows
Purpose: Make a decision: obtain CISO’s agreement on target Architecture
Level of detail: Overview
Type of representation: Diagram
Restriction on concepts: Only "basic" concepts, mostly Node and Communication Network but other concepts allowed if used on purpose
Modelling conventions: Network zones will be modeled using Communication Network as big boxes inside which Nodes will be nested. Associations will be used to connect them. This is a non normative usage of nesting that is accepted in this viewpoint to ease communication. Flows (modeled using flow relationship) that are at risk will be colored red and label "risk" (to make it still readable for color blind people and/or when printed in black & white
Other: Limit yourself to a maximum of 20 concepts and should be printable in letter/A4.
About viewpoint enforcement in tools
How much of what precedes impacts tool? Almost none. The only requirement is to be sure that the tool lets you add a label, comment or property to a view to know that the view was created with a specific viewpoint in mind. Is it useful to have a tool that forces you to use only a very restricted set of concepts? No because in some cases you might need a concept which was not planned when defining the viewpoint but makes sense in some very specific cases.
Story and viewpoint journeys
Last but certainly not least, viewpoints never comes alone. They are the scenes in your movie, they are part of a broader story. This implies that when defining them, you should make sure that each of them build upon the others. Doing so makes sure the concepts you will use will serve a coherent purpose and will connect together in your model.
For example, using only a viewpoint focusing on business processes, and one focusing on applications structure would lead to a model in which you have two disconnected pools of concepts (one to describe the business, one to describe the applications). Adding a viewpoint whose goal is to describe which applications supports your processes immediately creates the needed glue between the two previously described pools of concepts.
You can thus see your architecture description as a journey in which you moves from one viewpoint to another. Of course, few stakeholders will ever see the whole story, but, by this approach, you’ll provide a common frame for everyone to understand which role it plays.
For example, one could imagine this journey as a generic backbone :
Present the organization purpose and motivation, its place into the broader enterprise (organization’s motivation viewpoint, targets CEO)
Present the course of action, strategic goals and outcomes of your organization and how they rely to its purpose and broader motivation (strategic vision viewpoint, targets CxO)
Present the capabilities impacted by the new strategy (capability map viewpoint, targets CxO and top management of impacted capabilities)
Show the key business processes affected for each of the capabilities previously identified. Visually, each business process element encapsulate the main applications used to support it, this non standard nesting stands for a reverse serving relationship (business process impact analysis viewpoint, targets Business Analysts and Product Owner)
For each business objet appearing in the process descriptions, provide a more detailed description with an emphasis on personal data (information model viewpoint, targets Chief Data Owner and CISO)
For each application previously identified, do a gap analysis focusing on added, changed or decommissioned components and flows (application gap analysis viewpoint, targets application teams, Product Owners and Lead Developers)
For each new application or component, provide a description of the underlying generic technology architecture that will be common to all environments (logical technology diagram viewpoint, targets Lead Developers and IT Operations Team)
Tips & tricks for better views
Small is beautiful
Most diagrams will be seen on screen and seldom printed, thus limit yourself to diagrams that fit your screen and don’t force you to scroll. If printed, consider that they should be perfectly readable on a half letter or A5 sheet of paper.
Don’t use too many elements, 20 is a good number, 40 a maximum.
Less is more
Most people you work with don’t know ArchiMate and won’t see any difference at all between all those boxes and arrows, so don’t force them to learn a new standard to understand your work. Try to limit the number of different types of elements and relationships used. Two or three of each is usually a maximum before people get lost.
Color is (not) important
Color for element
Despite what some people think, color has no meaning in ArchiMate. It is made clear in the specification that "there are no formal semantics assigned to colors and the use of color is left to the modeler". Thus color should be used only to ease communication.
Typical use-cases for colors are:
Emphasize what is in or out of scope
Gap analysis (distinguish was element is added, modified or changed)
Making some property visible
So unless you explicitly have to distinguish layers and have no specific graphic charter in your organization, there is no reasons to stick with the, too often seen, yellow, blue and green.
An advice: define a set of 20 colors that best match you company’s graphic charter and use it in a way that makes your architecture views appear as if they were part of any corporate document. Here’s a good start:
Color for relationships
In addition, relationships are first class citizen in ArchiMate, so you should take care of them.
Here are several common options:
Use a "light" or low saturated color if emphasis is on elements.
Use a saturated color if relationships are as important as elements.
Use the same base color as for related elements.
Color should also be used to make it easier to focus on the key message. For example, if a process view shows both assignments and triggers, having triggers using the same color as Business Processes, and assignments using the same color as Business Roles makes it easier to understand.
Always add a legend
You can’t expect people to spontaneously understand elements, relationships and your use of colors. Always add a legend. Period.
If people value your work, then chances are that they will reuse your views in their documents. It is therefore important to make sure that people can understand them in these contexts. Thus, they should contain:
a title which should make clear what the diagram type and scope are,
a legend (did I say that you should always add a legend?),
a way to identify version, status (draft, validated…) or date of last update.
Font should be easy to read, and contrast should be good. Centered text is better most of the time.
Prefer nesting over relationships
While being less precise, nesting is usually easier to understand by people who don’t know ArchiMate. Nesting also helps people focus on less relationships, getting only the key message.
Layout is a broad topic in modelling. There’s no single bullet in this aspect but several tricks can be used:
Limit line crossing as much as possible.
Size conveys information: bigger elements will be understood as being more important. Use it purposefully.
Align elements on a grid and between each other.
Use whitespace to suggest grouping or layering instead of actually using a visual group.
Choose a style and be coherent in your model