Read in French
You can access the French translation of this document here.
FRONT MATTER
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 [1] and two great books [2] [3] 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.
Intended audience
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 [4] 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.
Structure
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 modeling 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 modeling 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
-
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 [5]. 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 registered 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
Why ArchiMate?
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 [6]) 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.
Language scope
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 (subject|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".
Value proposition
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 modeling tool. A good modeling tool simplifies the work and limits the burden of maintaining an architecture description. A good modeling tool helps you to maintain the coherence inside your model.
As soon as you move from drawing to modeling, you can also start exploring and analyzing gathered information. This is an often overlooked feature, but providing insight is another great value of ArchiMate modeling.
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" [7]. 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 modeling. This is the scope of ArchiMate.
-
Details mostly relies on domain specific language such as UML (for software design) or BPMN (for process modeling).
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…).
In short
-
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 [8]. 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 [9] perspective: we have to understand the broader context (our stakeholders’ concerns) to drive our own modeling 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 modeling 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.
An example
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 modeling 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 [10].
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.
Documenting viewpoints
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
-
Standard/metamodel: ArchiMate
-
Restriction on concepts: Only "basic" concepts, mostly Node and Communication Network but other concepts allowed if used on purpose
-
modeling 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 [11]:
-
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 Officer 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.
Fonts
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
Layout is a broad topic in modeling. 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
Language structure
Model and Metamodel
If you’re not already familiar with the notion of metamodel, here’s a short explanation:
A model is a simplified or abstract representation of something, useful for a specific purpose. A two-dimensional sketch of a kitchen is already a model of some sort as it allows you to determine if it will be easy to move around the room and to check if there’s enough room for the big fridge you’ve always wanted to own. When a need is frequent enough, it makes sense to standardise the way a model is drawn. For example, in construction industry, electricians and plumbers both have a need to prepare their work in advance, and both professions came up with their own standard way of drawing plans. All these conventions grouped together form a metamodel.
As ArchiMate is used to create models of your enterprise, these models have to comply with the ArchiMate metamodel. More precisely, ArchiMate metamodel defines some conventions such as:
-
The more generic thing in ArchiMate is called a concept.
-
A concept can be either an element or a relationship.
-
Not all relationships are valid between any couple of elements, and ArchiMate metamodel defines which one are valid and which one are not.
-
Elements are grouped into so-called "domains" which target different facets of the enterprise.
Architecture Domains
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 modeling of the solution itself through three layers (Business, Application and Technology).
-
Implementation and migration supports the modeling 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 and Motivation domains 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 [12].
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. In addition, elements are generic ones and are not usable as such in a real ArchiMate model.
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 purpose
-
Its behavior
-
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 Composition relationship [13].
This Composition relationship can be omitted if nesting [14] 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 [15].
The default generic [16] notation is to use a rectangle (with right angles) for Active Structure elements, and a rounded rectangle for Behavior elements. As for Composition, 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 Compositions 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 [17]. 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 [18]:
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 [19]:
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 Composition relationship. This implies that:
-
Service can be composed of other Services
-
Function can be composed of other Functions
-
Process can be composed of other Processes
Function and Process being both internal behaviors, it is also possible for one to be composed of the other, leading to:
-
Function can be composed of Processes
-
Processes can be composed of 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 Composition 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. External Behavior or Service) 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. But unlike Flows and Triggers which are often use between parts of the same system, Servings are almost always used between two different systems.
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":
Generic metamodel reference card
It is possible to summarize the generic metamodel of the ArchiMate Core Language (i.e. Core domain) this way:
In this visual "reference card", a relationship is allowed between the elements it start from or end at, but also between any of the elements visually contained in them.
For example:
-
A System can be assigned to some System Behavior, but also to Internal, Ordered Behavior (Process), Internal collection of behavior (Function), and External Behavior (Service).
-
A System triggers another System, but so is true between Internal, Ordered Behavior (Process) and External Behavior (Service).
Business Layer Elements
Until now, elements were only generic ones. Such generic elements are useful to explain the underlying structure of ArchiMate, but they can’t be used as-is in a model, and you’ll have to pick more precise elements depending on the type of system you’re working on. ArchiMate distinguishes three main types: Business, Application and Technology, and call them Layers.
The Business Layer is mainly used to model the organization of the enterprise (think "org chart"), services provided to (internal or external) clients, activities run by people, and information (at a conceptual level) needed to support these activities.
The main element type used to model a business system is the Business Actor. Like all Active Structure, its notation is a rectangle (with right angles), but with a small sticky man icon on the top right corner:
Business Actor can be used to model an individual, a team of any size or even a company. Its assigned behavior can be a mix of Business Processes, Business Functions or Business Services, and all of them access information or objects that we model through Business Object:
Business Layer reference card
Using the same layout as the one use for the generic metamodel reference card, here’s a simple reference card for Business Layer Elements:
Example
Coffee Around The Corner is the name of a fictious shop that we’ll use to illustrate some basic usage of ArchiMate in this section.
It’s a small shop in which Paul and Linda work together to provide some good hot drinks, but also some french pastries (Linda’s passion). In addition to be the one preparing drinks, Paul usually manages suppliers, stocks of raw material and, in fact, anything related to logistics. Linda on her side cooks pastries and manages shop accounting. Paul and Linda try hard to make most of their product themselve, so they focus only on a small number of drinks and pastries. They also offer free filtered and carbonated water to people who buy pastries. In addition to drinking and eating, people can also have fun and play pool.
The following example provides an overview of the small business:
-
The main services provided to customers are on the top
-
Internal activities are modeled as business functions
-
The (basic) organization of the shop is suggested by showing a generic Employees business actor, itself decomposed into Paul and Linda
-
Most important information supporting their business (such as raw material, products, customers…) are listed
It should be notted that this view follows no particular pre-defined viewpoint or convention. It’s sole purpose is to illustrate a basic usage of some elements. In the context of a real architecture description, a title and a legend should be added, and colors could be changed.
Application Layer Elements
The Application Layer is used to model applications that directly support business activities, either because they are used by the business or because they implement business rules. This excludes "commodity" softwares or middlewares such as the operating system itself, database management systems, message bus, application hosting platforms (J2EE, .NET, Node.JS…), etc. that will be modeled using elements from the Technology Layer.
The single element type used to model an application system is the Application Component. Like all Active Structure, its notation is a rectangle (with right angles), but with a specific icon on the top right corner:
Application Component can be used to model a solution, a single application or any of its part that can be deployed as a whole. Its assigned behavior can be a mix of Application Processes, Application Functions or Application Services, and all of them access data that we model through Data Object:
Unlike Business Objects which are conceptual information (e.g. Order or Invoice), Data Objects should be understood as data structured in an application specific way. This implies that a single Business Object can materialize into several Data Objects, either because it is easier for a single application to manipulate relational data (what needs to explicit some data that are common between concepts), or because several applications work with the same concept but each with a different way of modeling it (different set of attributes for example).
Application Layer reference card
Example
For their accountancy, Paul and Linda use a SaaS solution aimed at small and medium enterprises. Small Business Solution (that’s the name of the SaaS solution) in fact supports all aspects of their business:
-
Inventory
-
Contract Management
-
Purchasing
-
Invoicing
-
Accounting
-
Payroll
-
Tax
-
Reporting
It can also connect to the shop’s bank account to ease bank reconciliation, and can work hand in hand with a local POS (point-of-sale) system.
Technology Layer Elements
The Technology Layer is used to model a broad range of systems: software systems, hardware systems, network systems, physical systems, etc. The system type determines the element used to model the system itself (the Active Structure), and this, in turn, determines the element used to model the associated stock (the Passive Structure).
modeling software systems
Unlike Application Components which are used to model applications that directly support business activities, "commodity" softwares or middlewares can be modeled using the System Software element from the Technology Layer. Such "commodity" softwares includes (but are not limited to): the operating system itself, database management systems, message bus, application hosting platforms (J2EE, .NET, Node.JS…), etc.
Like all Active Structure, its notation is a rectangle (with right angles), but with a top right icon looking like a 3D disk:
It is sometime hard to draw a clear border between Application Components and System Sofytwares and one could argue that any software serves some purposes which are someone’s business. When in doubt, a good rule of thumb is to check if the value offerded by the software comes through its user interface, if yes, model it as an Application Component. Another good rule is to check if it makes sense to deploy the software alone, if not, there’s a high chance that this is only one supporting piece of a broader solution, and this piece should be modeled as a System Software.
System Software can be assigned to behavior which can be a mix of Technology Processes, Technology Functions or Technology Services, and all of them access files and raw data that we model through Artifact:
Unlike Business Objects and Data Objects which are both abstract, Artifact is more concrete and is usually used to model files that you store on a computer.
System Software reference card
modeling hardware systems
Any software system relies on an underlying (potentially virtual) hardware system. A typical example is the computer on which the software runs and which is made of multiple sub-systems such as the central processing unit or the graphics processing unit. Even though it rarely makes sense to model a solution at this level of detail, it is usually helpful to provide basic information about the kind of computer used (for example its architecture, and whether or not it is a virtual machine).
Such system is modeled using the Device element from the Technology Layer. It’s notation is a 3D box with a monitor icon on the top right corner:
Note that Device is not meant to model only computers, but any hardware onto which (some sort of) software can be deployed, or into which data can be stored. This includes network devices (routers, switches, firewall, access points…), NAS (Network Attached Storage), or any kind of appliance.
Devices can be assigned to behavior which (like System Software) can be a mix of Technology Processes, Technology Functions or Technology Services.
Devices and their behaviors access files and raw data that we also model through Artifact.
Device reference card
