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, do not known how to choose one over the other or to put all this into practice.
It is 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 become certified by The Open Group. While such certification is needed in some contexts, it enforces the course to explain every bit of the specification in a relatively short training session, even though most people won’t use 50% of the concepts in the short term.
This book idea first emerged from the feedback of trainers who were frustrated to see that 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.
In addition, some more advanced modeling use-cases are also addressed and some specialized concepts (which might be needed for some people) will be introduced. Feel-free to skip these advanced use-cases if they do not match your needs as this book never assumes you have 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 wished 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. 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.
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
Kelly Cannon, The Open Group
License and trademarks
The writing of this book is a community-led effort. It is published under the Creative Common Attribution-ShareAlike 4.0 International . This content is the sole responsibility of the individual contributor(s) and is provided as a resource "as is" to anyone using the ArchiMate® standard. The Open Group does not in any way, explicitly or implicitly, warrant or endorse any of the claims, products, services, or information contained herein.
ArchiMate® is a registrered trademark of The Open Group.
UML® and Unified Modeling Language® are registered trademarks and BMM™, BPM™, Business Motivation Model™, and Business Process Modeling Notation™ are trademarks of the Object Management Group.
All other brands, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners.
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 text. 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 text. 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. 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.
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, and the 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. A model is a multidimensional representation that our brain has some difficulties working with. That’s the reason we rarely work on the model itself rather on a subset called a view. While doing so, we have to remember that (again) a view is not the model, only a (hopefully) useful abstraction. In turn the real question is: How do we decide what to left out in the process?
You should already have a good grip on this question, and ArchiMate provides a framework to solve this. 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 do not each have the same concerns and thus do not expect the same kind or amount of information. 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 target 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 referes to this as 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 are defining. Architecture views created with ArchiMate are usually diagrams, by 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 a 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 will have to have your CISO validate your choices (i.e. you don’t just have to inform them). What are your CISO key concerns? Security as a whole of course, but what is important for them 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 their concerns.
In addition to this, what level of detail do you need? Well, your CISO might not be too technical so you will 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 will not care about additional details.
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). 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 the tooling? Almost none. The only requirement is to be sure that the tool allows you add a label, comment or property. This ensure the reader knows 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 come 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 ensures 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 move from one viewpoint to another. Of course, few stakeholders will ever see the whole story, but, by this approach, you will 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 object 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 at maximum.
Less is more
Most people you work with do not know ArchiMate and will not see any difference 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
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 cannot 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 preferable most of the time.
Prefer nesting over relationships
While being less precise, nesting is usually easier to understand by people who are not familiar with ArchiMate. Nesting also helps people focus on less relationships and digesting 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
PART II - THE LANGUAGE
As seen before, ArchiMate contains a rich vocabulary that covers most enterprise architects’ needs. Language elements are classified in four domains: Motivation, Strategy, Core, Implementation and migration.
Each of these domains has its own purpose:
Motivation supports the modeling of the reasons that guide the design or change of the architecture.
Strategy supports the modeling of the strategic direction of an enterprise, how it wants to create value for its stakeholders, and the capabilities it needs for that.
Core supports the modelling of the solution itself through three layers (Business, Application and Technology).
Implementation and migration supports the modelling of implementation programs or projects, and migration planning.
These four domains are equally important for enterprise architecture, but we will not cover all of them in depth within this book. We’ll focus mainly on the Core domain because this is where most people start with.
ArchiMate Core Language
The generic metamodel and the system metaphor
ArchiMate has been created to help architects manage the complexity of large systems (such as an enterprise, an organization or an information system) and systems of systems. Part of the language finds its roots in system dynamics and thus the system metaphor is useful to understand the inner structure of ArchiMate .
Note that in what follows, the notation is very similar to ArchiMate default notation, but a bit simplified though. It is used here to help you understand the underlying structure of the language.
Systems and sub-systems
A system is a set of related components that work together in a particular environment to perform whatever functions are required to achieve the system’s objective.
A system can be further described by:
Its boundary (which makes it possible to know if something belongs to the system or to its environment)
Its interactions with its environment
Its resources (which can be of any kind: natural resources, tangible, intangible…)
If needed, a system can be decomposed into subsystems that can in turn, be further decomposed.
The human body is a good example: it is a system of systems, as can be seen in this simplified figure:
In fact, most of the time systems are part of a broader system. Going forward, unless specified, we’ll use "System" to denote both systems and subsystems.
In ArchiMate, decomposing an element into other elements of the same type is usually done through the Aggregation relationship .
This Aggregation relationship can be omitted if nesting  is used. These two diagrams convey the same meaning:
Structure and behavior
Being able to identify a system by its name is important, but the system’s name does not necessarily reflect its purpose. ArchiMate makes a clear distinction between the structural constituent of a system (called Active Structure) and its Behavior. We say that the Active Structure is assigned to its Behavior .
The default generic  notation is to use a rectangle (with right angles) for Active Structure elements, and a rounded rectangle for Behavior elements. As for Aggregation, the Assignment relationship can be omitted if nesting is used:
Let’s make our "Body System" a bit more detailed:
You’ll note that in this example, the choice has been made to use nesting (i.e. visual encapsulation) instead of explicitely showing Aggregations and Assignments relationships. If you wonder why, look at the "explicit" diagram which follows and consider which one is the easiest to understand and work with:
More about behavior
ArchiMate defines three types of behavior that serve different purposes.
External behavior: Service
Service is used for modeling the outside-in view on system’s behavior, i.e. the behavior as it is perceived from the outside of the system. When designing a new system, Service is often used to describe what the system must do from the perspective of its users . For existing systems, Service is commonly used for modeling an overview (also called black box view) of the system which abstracts its internals away.
Like all behaviors, Service is drawn as a rounded rectangle, but exhibits a "capsule" icon :
In our "Body System" example, previously described behaviors are in fact Services offered by body subsystems to the whole-body system:
Internal, ordered behavior: Process
Process is used for modeling the inside-in view on system’s behavior, i.e. the behavior as it happens inside the system. More than that, Process is used for modeling sequences of behavior, or behavior that have a beginning and an end.
Like all behaviors, Process is drawn as a rounded rectangle, but exhibits an "arrow" icon :
In our "Body System" example, we can easily find a good example of such Process:
Internal collection of behavior: Function
Function is also used for modeling system’s internal behavior. Unlike Process, Function has no beginning nor end. It represents a continuous behavior or is used to group other behaviors.
Most of the time Function will be used for modeling an inside-in view. As we’ll see later, it can also be used for modeling an inside-out view on a system’s behavior, i.e. a logical set of Services based on internal criteria.
Like all behaviors, Function is drawn as a rounded rectangle, but exhibits a "chevron" icon:
In our "Body System", the heart exhibits such a (hopefully) continuous behavior:
Relationships between behaviors
We’ve seen previously that in ArchiMate, decomposing an element into other elements of the same type is done through the Aggregation relationship. This implies that:
Service can aggregate other Services
Function can aggregate other Functions
Process can aggregate other Processes
Function and Process being both internal behaviors, it is also possible for one to aggregate the other, leading to:
Function can aggregate Processes
Processes can aggregate Functions
Service being an external behavior, it is seen as an abstraction of Functions or Processes. Such abstraction is modeled through the Realization relationship:
Again, like Aggregation and Assignment, this Realization relationship can be omitted if nesting is used. These two diagrams are equivalent:
Note in this last example, nesting is used twice but for different semantics:
"Digestive System" is assigned to the "Digestive Process"
"Absorbing nutrients from food" and "Eliminating wastes" are both realized by the "Digestive Process"
Whether or not to use nesting is both a matter of taste, communication, and of viewpoint: if your goal is to communicate what could be perceived as a behavior decomposition, then nesting is better. Alternatively, if your goal is to emphasize the differences between What is done and How it is done, then nesting should be avoided.
Relationships between systems
We’ve just seen the more frequent building blocks used to describe systems. As systems interact with each other, these interactions can be modeled through several relationships, each with their own semantic.
Sharing information, money, goods…
In system dynamics, systems can contain stocks. A stock is anything that exists within the system, performs no behavior by itself, and is accessed or acted upon by the system (like information, money, goods…).
In our "Human Body" example, blood, oxygen, carbon dioxide, nutrients and wastes are all examples of stocks.
In ArchiMate, the elements that are used to model stocks are classified as Passive Structure and will be covered later.
Systems can exchange or share stocks through Flows. Flows can be modeled between systems themselves (i.e. Active Structure), between their Behaviors or a mix of both.
Such Flows exist in our own body:
Temporal or causal relationship
Between (or inside) systems, some behaviors can affect other behaviors. This impact can be immediate or delayed, intentional or unintentional. For all those cases, in ArchiMate, we’ll use the Triggering relationship which is used to model the temporal or causal precedence of elements. Like Flows, Triggering can be modeled between systems themselves (i.e. Active Structure), between their Behaviors or between a mix of both.
Noting our "Body System" example, Triggering is seen in the following way:
Dependencies between systems
Systems exchanging stocks (i.e. Passive Structure) and affecting each other lead to dependency. In ArchiMate, we’ll use the Serving relationship to denote that some systems provide its functionality (i.e. Behavior) to other systems. As seen with Flows and Triggering, Serving can be modeled between systems themselves (i.e. Active Structure), between their Behaviors or a mix of both.
Very often, Serving, Triggering and Flows are the multiple sides of a same coin: the behavior on which we rely (ie. the behavior serving us) has to be triggered in some ways, and there is usually some information, money or goods exchanged. There is no magic rule to define if they point in the same direction of not, because this vary depending on the context.
For example, a reader may subscribe to a "Home delivery service" provided by the New York Times and in return, expect the newspaper to be delivered. For this to happen, the reader must pay (i.e. send money) for the service:
Passive structure (stocks)
We’ll end this chapter by focusing a bit more on stocks. We’ve seen that a stock is anything that exists within the system, performs no behavior by itself, and is accessed or acted upon by the system (like information, money, goods…).
In ArchiMate, the elements that are used to model stocks are classified as Passive Structure. They are depicted by a rectangular shape, and the most common notation is:
In ArchiMate, Passive Structures are accessed by Active Structures (i.e. systems) or Behaviors. Access relationship is tricky because it is always defined from the Active Structure or Behavior to the Passive Structure, but it visually depicts the type of access:
As often in ArchiMate, it is also possible to nest the Passive Structure inside the Active Structure or Behavior as an alternate notation. There are plenty of examples of Passive Structures in our "Body System":