Lire en anglais
La version anglaise de ce document est accessible ici.
PREAMBULE
Pourquoi ce livre ?
Plus de 15 ans après sa naissance, le standard ArchiMate® est souvent perçu comme difficile à apprendre et complexe à utiliser. Malgré une spécification officielle relativement courte[1] et deux superbes livres [2] [3] à son propos, un grand nombre de gens sont dépassé par le nombre de concepts , ne savent pas lequel choisir plutôt qu’un autre ou comment mettre tous ces concepts en pratique.
Il est recommandé de suivre un cours officiel sur ArchiMate®, mais de telles formations sont conçues pour permettre aux étudiants de réussir les examens de certification officiels et d’obtenir la certification de l’Open Group. Même si cette certification est nécessaire dans certains contextes, elle induit que le cours va devoir expliquer tous les moindres détails de la spécification dans un temps relativement court, bien que la plupart des gens n’utiliseront à court terme que 50% des concepts.
La genèse de ce livre émerge des retours d’expérience des formateurs qui étaient frustrés de voir leurs nouveaux étudiants incapable d’appliquer les nouvelles connaissances apprises, alors que dans d’autre contextes ( plus informels), il était possible d’expliquer rapidement comment utiliser un petit sous ensemble d’ArchiMate® et d’avoir des personnes opérationnelles en quelques heures. Il est alors apparu clairement qu’il y avait une place pour une introduction simplifiée à ArchiMate.
Public Cible
Ce livre est une tentative à résorber ce vide. Il a pour objectif de permettre la découverte pratique du standard au même titre qu’un cours d’introduction "101" qui doit permettre à quiconque avec des connaissances en Technologies de l’Information [4] de comprendre les principes fondamentaux d’ArchiMate® et de produire des modèles valides et utiles dans une courte période de temps.
Quel contenu ? Quelle aspiration pour cet ouvrage ?
L’objectif de ce livre implique qu il n’abordera pas la totalité des aspects du standard ArchiMate®, mais au contraire il va se concentrer sur un petit sous ensemble d’éléments et de relations qui sont suffisamment génériques pour couvrir les besoins de modélisation les plus fréquents. Le livre se limitera au domaine principal ("Core Domain") qui est composé des couches Métiers, Application et Technologies.
Note pour les lecteurs aguerris: vous risquez d’être surpris par endroits par la manière dont les choses sont présentées ou expliquées. Vous auriez choisi un autre élément, une autre relation ou désiré que le sens exact d’une autre relation dérivée soit mieux expliqué. Si cela arrive, gardez en tête que la connaissance que vous avez acquise est issue de plusieurs années de pratique. Notre objectif n’est pas d’expliquer aux lecteurs les détails les plus théoriques mais simplement de leur permettre de mettre en pratique le plus rapidement possible.
Structure
Le livre est découpé suivant la structure ci dessous:
-
Partie I – Introduction, définit le but et le périmètre du standard ArchiMate®, et fournit les recommandations génériques sur les points de vue et les vues.
-
Partie II – Le Langage, décrit la structure du langage et le métamodèle générique au travers de la métaphore du "Système" et présente le sous ensembles des concepts qui seront utilisés tout a long de l’ouvrage. Les cas d’usages communs et leur point de vue seront présentés , et ( pour certains) une approche plus détaillée sera étudiée.
-
Partie III – Sujets Avancés & Methodologie, adresse certaines des questions plus courantes à propos d’ArchiMate® ou de la modélisation en tant que telle, présente les différentes approches pour structurer le contenu d’un modèle , et enfin d’échanger autour des avantages des modèles de référence.
-
Partie IV – Bibliothèque d’exemple de points de vue, fournit un point de départ basé sur un ensemble de points de vue type.
-
Partie V – L’outil de modélisation Archi, fournit des trucs et astuces pour ceux qui utilisent l’outil open source de modélisation Archi
Remerciements
La communauté des utilisateurs d’ArchiMate® remercient la contribution des personnes suivantes dans le développement de cette version et des versions antérieures de ce document:
-
Jean-Baptiste Sarrodie, BNP Paribas
-
Jean-Denis Laval, BNP Paribas
-
Kelly Cannon, The Open Group
License and trademarks
L’écriture de ce livre est un effort collaboratif. Il est publié sous la licence Creative Common Attribution-ShareAlike 4.0 International [5]. Son contenu est la seule responsabilité de ses contributeur(trices) et est fourni comme une ressource "en l’état" pour toute personne utilisant le standard ArchiMate®. L’Open Group ne justifie ni n’approuve en aucune manière aussi bien explicitement qu’implicitement l’une ou l’autre des allégations, produits, services ou renseignements contenus dans cet ouvrage. ArchiMate® est une marque déposée par l’Open Group.
UML® et Unified Modeling Language® sont des marques déposées et BMM™, BPM™, Business Motivation Model™, et Business Process Modeling Notation™ sont des marques déposées de l’Object Management Group.
Toutes les autres marques , société ,et noms de produits sont utilisés uniquement à titre d’information et peuvent être des marques de commerce qui sont la seule propriété de leurs propriétaires respectifs.
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 (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".
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 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" [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 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…).
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 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.
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 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 [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
-
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 [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 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.
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 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
langage structure
Comme vu précédemment, Archimate dispose d’un vocabulaire fourni qui peut couvrir les besoins de la plupart des architectes d’entreprise. Les éléments de langage sont classifiés en quatre domaines: Motivation , Stratégie, Centrale , Déploiement et Migration
Chacun de ces domaines a son propre usage:
-
Motivation permet la modélisation des raisons qui sont à la source de la modélisation ou du changement de l’architecture
-
Stratégie permet la modélisation des directions stratégiques de l’entreprise , comment celles contribuent à la création de valeur pour les parties prenantes, et les capacités nécessaires à leur réalisation.
-
_Central _ permet la modélisation de la solution au travers de trois tiers (Métier, Application et Technologie).
-
Déploiement et Migration permet la modélisation des programmes ou des projets de déploiement ainsi que des plannings de migration
Ces quatre domaines sont tout aussi importants pour l’architecture d’entrerprise, mais nous ne les couvrirons pas tous en détail au sein de ce livre. Nous allons nous concentrer sur le domaine Central car c est par ce domaine que la pluprt des personnes abordent Archimate.
Le langage Central Archimate
Le métamodel générique et la métaphore du système
ArchiMate a été créé pour faciliter les architectes dans la gestion de la complexité des systèmes ( tels qu une entreprise , une organisation ou un système d’information) et de système de systèmes. Une partie de ce langage tire son origine de la dynamique des systèmes et donc la métaphore du système est utile pour comprendre la structure fondamentale d’Archimate [12].
Par la suite,la notation est très similaire de celle par défaut d’Archimate mais elle a été un peu simplifiée. Elle est va vous permettre de mieux comprendre la structure du langage Archimate. ===== Systèmes et sous systèmes
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.
Un système est un ensemble de composants qui fonctionnent ensemble dans un environnement spécifique pour réaliser toutes les fonctions nécessaires à la réalisation des objectifs de ce système.
Un système peut être plus précisément décrit par:
-
Ses limites/frontières ( qui permettent de savoir si quelque chose appartient au système ou à son environnement)
-
Son but
-
Son comportement
-
Ses interactions avec son environnement
-
Ses ressources (qui peuvent être de tout type: naturelle, tangible, intangible…)
Si nécessaire, un système peut être décomposé en sous-systèmes qui peuvent à leur tour être eux aussi décomposés.
Le corps humain est un bon exemple: c est un système de systèmes comme présenté sur ce diagramme simplifié:
En fait, la plupart du temps les systèmes font eux même partie d’un plus large domaine. Dans la suite de l’ouvrage , sauf si explicitement indiqué, le terme "Système" sera utilisé pour décrire aussi bien un système qu’un sous système.
Dans Archimate, décomposer un élément en d’autre éléments du même type est généralement effectué via la relation d' Agrégation [13].
Cette relation d'Agrégation peut être omise si l on réalise une imbrication [14] . Ces deux diagrammes véhiculent le même sens:
Structure et comportement
Etre en mesure d’identifier un système par son nom est important mais le nom du système ne reflète pas forcément son but. Archimate assure une distinction claire entre les constituants structurels du système ( appelés Structure Active) et leur Comportement. On considère alors que les Structure Active sont assignées à leur Comportement [15].
La représentation générique [16] par défaut pour les "éléments de type Active Structure est un rectangle (à bords à 90°/droits) , et un rectangle à bords arrondis pour les éléments de type Comportement . Pour l'Agrégation, la relation d Assignation peut être omise si l’imbrication est mise en oeuvre:
Rentrons dans les détails de notre "Corps Humain" de manière plus détaillée:
Vous remarquerez que dans cet exemple, le choix s’est porté sur une représentation basée sur l’imbrication ( par exemple avec de l’encapsulation visuelle) au lieu de représenter les relations d'Agrégations et d' Assignation. Si vous vous demandez pourquoi, regardez le diagramme "explicite" ci dessous et décidez lequels des deux diagrammes est le plus simple à comprendre et à travailler avec : image::images/core_7.png[maxwidth=70%, align="center"]
Détaillons le comportement
ArchiMate définit trois types de comportements qui ont chaun leur utilité:
Comportement Externe: Service
Service est utilisé pour modéliser is used for modeling the outside-in view on system’s Comportement, c est à dire le comportement tel qu il est perçu vu de l’extérieur du système. Lors de la modélisation d’un nouveau système Service est souvent utilisé pour décrire ce que le système doit réaliser de la perspective de ses utilisateurs. [17]. Pour les systèmes existants, Service est souvent utilisé pour modéliser une vue générale (aussi appelée vue boite noire ) du système qui masque son fonctionnement interne.
Comme tous les comportements, Service est représenté comme un rectangle à angles ronds, mais il se distingue via une icone "capsule" [18]:
Dans notre "Corps Humain", les comportements décrits précédemment sont en fait des Services offerts pas des sous systèmes du corps à l’intégralité du système complet.
Comportement interne , ordonné: Processus
Processus est utilisé pour modéliser la vue interne inside-in sur le comportement du système, c.a.d le comportement tel qu il se déroule au sein du système. Plus que cela, Processus représente une séquence de comportements qui accomplit un résultat spécifique, ou un comportement qui a un début et une fin.
Comme tous les comportements, Processus est représenté comme un rectangle à angles ronds, mais il se distingue via une icone "flèche" [19]:
Dans notre exemple du "Corps Humain", nous pouvons facilement trouver un bon exemple d’un tel Processus:
Ensemble de comportements internes: Fonction
Fonction est aussi utilsiée pour modéliser le comportement interne d’un système. Contrairement au Processus, Fonction n’a ni début ni fin. Il représente un ensemble de comportements ou est utilisé pour groupés d’autre comportements
basés sur des critères spécifiques, tels que les ressources, les compétences ou le lieu.
La plupart du temps, les Fonctions seront utilisées pour modéliser une vue inside-in. Comme nous le verrons plus tard, ce concept peut aussi être utile pour modéliser une vue inside-out sur le comportement du système, c est à dire , un ensemble logique de Services basés sur des critères internes.
Comme tous les comportements, Fonction est représentée comme un rectangle à angles ronds, mais il se distingue via une icone "chevron":
Dans notre "Corps Humain", le coeur affiche un tel comportement continu (on l’espeère):
Relations entre comportements
Nous avons déjà vu qu’au sein d’ArchiMate, la décomposition d’un éléments en autre élément du même type est réalisée via la relation d'Agrégation. ce qui implique que:
*Un Service peut agréger d’autre Services *Une Fonction peut agréger d’autre Fonctions *Un Processus peut agréger d’autre Processus
Fonction et Processus étant tous deux des comportements internes, il est aussi possible que l’un puisse agréger l’autre, ce qui a pour conséquence:
*Une Fonction peut agréger des Processes *Un Processus peut agréger des Fonctions
Service étant un comportement externe, il peut être considéré comme une abstraction des Fonctions ou des Processus. De telles abstractions sont modélisées au travers de la relation de Réalisation :
A nouveau, comme l'Agrégation et l'Assignation, cette relation de _Réalisation peut être omise si l’imbrication est mise en oeuvre. Les deux diagrammes suivants sont équivalents:
A noter que dans ce dernier exemple, l’imbrication est doublement utilisée mais avec des sémantiques différentes:
-
Le "Système Digestif" est assigné au "Processus Digestif"
-
"Absorption des Nutriments issus de la nourriture" et "Eliminer les déchets" sont tous deux réalisés par le "Processus Digestif"
Utiliser ou non l’imbrication est surtout une question de gout, de communication ou de point de vue: si votre objectif est de communiquer ce qui pourrait être perçu comme une décomposition de comportements, alors l’imbrication sera à privilégier. Alternativement si votre but est de mettre en avant les différences entre ce qui est réalisé et comment il est réalisé , alors l’imbrication doit être évitée.
Relations entre systèmes
Nous venons de passer en revue les éléments constitutifs les plus fréquemment utilisés pour la description des systèmes. Comme les systèmes interagissent les uns avec les autres, leurs interactions peuvent être modéllisées au travers de plusieurs relations, qui ont chacune leur propre sémantique.
Partagé l’information, argents, biens…
En dynamique des systèmes, les systèmes peuvent contenir des stocks. Un stock est tout ce qui existe dans le système qui n’a aucun comportement par lui même, qui est accédé par ou qui subit l’action du système (comme l’information, l’argent, les biens…).
Dans notre exemple du "Corps Humain", sang, oxygène, dioxyde de carbone, nutriments et déchets sont tous des exemples de stocks.
Dans Archimate, les éléments qui sont utilisés pour modéliser les stocks sont classifiés sous la forme de Structure Passive et ceci sera couvert plus tard.
Les systèmes peuvent échanger ou partager des stocks au travers des Flux. Les Flux peuvent être modélisés entre systèmes (Structure Active ), entre leur Comportements ou entre un mélange des deux.
De tels Flux existent dans notre propre corps:
Relations temporelles ou causales
Entre (ou au sein de) systèmes, certains comportements peuvent agir sur d’autre comportements. Cet impact peut être immédiat ou retardé, intentionnel ou inintentionnel. Pour tous ces cas, dans Archimate, nous allons utiliser la relation de Déclenchement qui peut être utilisée pour modéliser la précédence temporelle ou causale des éléments. Comme les Flux, les Déclenchements peuvent être modélisés entre systèmes (Structure Active ), entre leur Comportements ou entre un mélange des deux.
En revenat à notre exemple du "Corps Humain", les Déclenchements sont perceptibles de la manière suivante:
Dépendances entre systèmes
Le fait que des systèmes s’échangent des stocks ( par exemple les Structures Passives) et que leur comportement puissent s’impacter fait naître des dépendances. In Archimate, nous allons utiliser la relation de Service (Serving) pour indiquer que certains systèmes fournissent un comportement ( Comportments) utile à un autre système. Comme présenté avec les FLux et les Déclenchements , les relations de Service ( Serving) peuvent être modélisées entre systèmes (Structure Active ), entre leur Comportements ou entre un mélange des deux.
Très souvent, les relations de Service(Serving), Déclenchements et Flux sont les différentes faces d’une même pièce: le comportement sur lequel on s’appuie ( ie. le comportement qui nous sert) doit être déclenché d’une certaine manière, et il y a généralement un échange d’information, de capitaux ou de biens. Il n’y a pas de règle maqique pour définir s’ils sont dirigés dans la même direction ou pas car ceci varie suivant le contexte.
Par exemple, un lecteur peut souscrire à un "service de livraison à domicile" fournit par le journal "Le Monde" et en retour, il s’attend à ce que son journal lui soit livré. Pour que cela advienne, le lecteur doit payer (ie envoyer de l’argent) pour ce service:
Structure Passive (stocks)
Nous finirons ce chapitre en détaillant un peu plus le sujet des stocks. Nous avons vu qu’un stock est tout ce qui existe dans le système qui n’a aucun comportement par lui même, qui est accédé par ou qui subit l’action du système (comme l’information, l’argent, les biens…).
Au sein d’Archimate, les éléments qui sont utilisés pour modéliser les stocks sont classifiés en tant que Structure Passive. Il sont décrits sous la forme de d’un rectangle dont la notation la plus commune est la suivante:
Au sein d’Archimate, les Structures Passives sont systématiquement accédées par des Structures Actives ( ie Systèmes) ou des Comportements. La relation d’accès est subtile car elle est toujours définie de la Structure Active ou du Comportement vers la Structure Passive mais le sens de la flêche représente visuellement le type d’accès. Il s’agit du seul type de relation ayant cette représentation.
Comme souvent dans Archimate, il est possible d’imbriquer une Structure Passive au sein d’une Structure Active ou d’un Comportement sous forme de notation alternative. Notre "Système Crops Humain" dispose de plusieurs exemples de Structure Passive:
image::images/core_24.png[maxwidth=70%, align="center"