Archimate: Présentation

Introduction

Archimate® est un langage de modélisation d’architecture, publié par The Open Group. Archimate est la contraction de architecture et animate. Il s’agit d’un langage visuel (utilisant une iconographie), permettant de décrire des architectures. Cette modélisation peut être utilisée dans le cadre d’analyses, elle peut également être utilisée pour documenter une architecture, ou pour communiquer, auprès des parties prenantes.

Pour moi, les langages de modélisation, utilisés à l’échelle d’une entreprise, apportent avant tout une langue commune aux différents interlocuteurs. Il existe un grand nombre de langages de modélisation. On peut citer rapidement UML, le plus connu, mais également MDA, BPMN, SysML … alors pourquoi un de plus ? En fait, ces langages ne sont pas réellement comparables, car même s’ils ont des zones de recouvrement, ils n’opèrent pas tous sur le même domaine d’application.

Deux exemples :

• BPMN (Business Process Modeling Notation), est spécialisé dans la description de processus “Business”, mais il ne pourra pas décrire une infrastructure, ou apporter des éléments de justification,
• UML (Unified Modelisation Langage) est le plus proche de Archimate, mais il est plus bas niveau que Archimate. UML ne permettra pas de décrire une architecture d’entreprise globale, et réciproquement, Archimate ne peut pas modéliser les détails proposés par UML.

Si vous faîtes un peu de prospection, vous verrez d’ailleurs que l’on trouve de plus en plus d’articles qui associent ces langages, plutôt que de les comparer Combining ArchiMate® 3.0 with Other Standards – BPMN.

TOGAF®

The Open Group, le consortium à l’origine de Archimate, est également le créateur de TOGAF®, le framework d’architecture. On retrouve donc, dans le langage, la structure du framework.

Pour mieux comprendre ce qui suit, je vais décrire brièvement l’un des principaux composants de ce framework: l’ADM (Architecture Development model).

Globalement, l’ADM décrit la façon dont doivent être gérés les sujets d’architecture, et au-delà, l’activité d’architecture de l’entreprise. Il décrit un processus assez logique de développement d’une architecture: on commence par une description des processus métiers, des transformations à apporter (ou pas), puis l’on parle flux de données, avant de parler d’application, puis d’infrastructure. L’ADM ne s’arrête pas là, puisqu’il inclut également la transition architecture-projet, le suivi de l’implémentation, et la gestion des changements dans les processus d’architecture eux-mêmes.

.

Le modèle Archimate

Archimate® est composé d’éléments, classés selon deux axes :

• Les couches (layers en anglais)
• Les aspects (aspects)

Les couches sont les couches du modèle «TOGAF»: Business, Application, et Technology pour le noyau de Archimate (The Archimate Core Framework), auxquelles s’ajoutent les couches Implementation & Migration, et Strategy pour le langage complet (The Archimate Full Framework).

• La couche “Business” décrit les services délivrés aux clients, mais également les processus métiers, les acteurs de ces processus, …
• La couche “Application” décrit les applications, ainsi que les données supportant les processus métiers.
• La couche “Technology” regroupe tous les services nécessaires à l’hébergement des applications (réseau, stockage, …). La sous-couche physique décrit le matériel réalisant ces services (switches/routeurs, serveurs, …)
• Les éléments de la couche “Strategy” permettent la modélisation de la stratégie ou des choix de l’entreprise, ayant potentiellement un impact sur l’architecture.
• Enfin, la couche “Implementation & Migration” décrit, comme son nom l’indique, la réalisation de l’architecture définie. On peut y retrouver les différentes étapes du passage d’une ancienne, à une nouvelle architecture.

Transversalement aux couches, nous avons les “aspects”, au nombre de trois pour le noyau (Active, Passive, Comportement (Active Structure, Behavior, et Passive structure), auxquels s’ajoute l’aspect “Motivation” pour le modèle complet.

• L’aspect “Active Structure” représente les éléments structurels (les intervenants, les applications, le matériel, …),
• L’aspect “Behavior” décrit les rôles et les comportements des éléments de l’aspect “Active Structure”. On parle de processus, de fonctions, …
• L’aspect “Passive Structure” inclut tous les éléments sur lesquels s’appliquent les “comportements”. En fonction de la couche, on peut y trouver les produits, les données, …
• L’aspect “Motivation” est un peu à part. Il regroupe tous les éléments qui ont conduit aux décisions prises. On y trouve les motivations, les principes d’architecture, la stratégie de l’entreprise, …). Je vous renvoie à l’article sur le sujet : Archimate: les éléments de motivation

Le modèle est donc le suivant :

Les relations entre les élements

Les différents éléments d’architecture modélisés sont, bien sûr, reliés entre eux. Les relations possibles sont les suivantes:

L’un des reproches que je peux faire à Archimate, c’est la proximité “visuelle” de certaines de ses relations, qui n’aide pas à l’apprentissage du langage, ni à sa lecture. Il faut une certaine gymnastique cérébrale avant de maîtriser. Si vous n’avez pas la patience, une autre méthode moins “standard” est possible: vous pouvez utiliser un simple trait entre les éléments (relation association), et ajouter une légende à proximité.

Voici un exemple de schéma Archimate :

Les couches

Les éléments de la couche “Strategy”

Les éléments de cette couche permettent de modéliser les choix stratégiques de l’entreprise, et des architectes d’entreprise. On parle d’objectifs, de capacité, de ressources.

Attention à ne pas confondre les éléments de cette couche, avec les éléments de motivation, dont j’ai parlé dans un article précédent, et que j’évoquerai rapidement un peu plus loin dans l’article.

Les éléments sont les suivants :

La définition des éléments Resource et de Capability sont standards. Celle des éléments Value Stream et Course of action nécessite quelques explications

• Value Stream représente une suite d’activité générant un résultat pour un client, un utilisateur final, ou une partie prenante,
• Course of Action représente une approche ou un plan, pour mettre en place / configurer des Capabilities ou des Resources d’une entreprise afin d’atteindre un but.

Tous les éléments sont décrits en détails dans la spécification.

Les éléments de la couche “Business”

Les éléments “Business” permettent de décrire des organisations et des processus métiers. Ces éléments sont indépendants de tout élément technologique. On se situe au niveau des métiers, et de l’entreprise.

Tous les éléments sont décrits en détails dans la spécification

L’exemple précédent montre un aperçu de ce que l’on peut faire avec ce genre d’élément.

Les éléments de la couche “Application”

Les éléments “application” décrivent les applications, leurs comportements, les services qu’elles fournissent, leurs interactions, … Avec ces éléments, on voit bien que Archimate et UML ne se place pas au même niveau. Archimate restera global, et servira à décrire un système d’information, par exemple, alors qu’avec UML, on pourra descendre bien plus bas, et modéliser les interactions fines.

Les éléments de la couche “Technology”

Sous le terme “Technology”, sont regroupés des éléments d’infrastructure globalement (serveurs, réseau, stockage, …).

Archimate permet de parler des composants informatiques de l’infrastructure, mais pas seulement. La sous-couche physique permet de modéliser des éléments de structure, comme les bâtiments, des équipements, …

Les éléments de la couche “Implementation & Migration”

Ces éléments servent à décrire la phase de déploiement des architectures définies. Cette couche est utile, lors du passage de la phase purement architecture, à la phase projet.

Deux classes d’éléments sont disponibles : ceux qui concernent l’architecture proprement dite, et ceux qui sont plus orientés “projet”.

Personnellement, j’ai tendance à bien ségréguer le travail d’architecture, de la gestion de projet. Je veux dire que, pendant cette phase, le rôle d’un architecte est avant tout d’aider le chef de projet dans l’élaboration de son plan, en fournissant les éventuelles contraintes techniques. Son rôle n’est pas de définir des work packages, ou des déliverables.

J’utilise souvent ces éléments pour décrire les étapes d’une migration, mais sans aller jusqu’au niveau “Work Package”. L’exemple ci-dessous est assez grossier, mais il résume bien l’utilisation des éléments de cette couche.

Les éléments de Motivation

Les éléments de motivation servent à décrire ce qui a conduit à l’architecture définie : les raisons, principes, règles, … tout ce qui a motivé les décisions d’architecture. Motivation elements are used to model the motivations, or reasons, that guide the design or change of an Enterprise Architecture.

La liste des éléments est relativement exhaustive :

Je ne détaillerai pas plus ces éléments car ils font l’objet d’un article spécifique

Relations TOGAF / Archimate

Comme je l’ai expliqué précédemment, les couches de Archimate peuvent être reliée aux différentes étapes de l’ADM de TOGAF.

Avant de conclure

Il est important de comprendre que Archimate n’impose pas de “Patterns”, ni d’agencement. Cela veut dire que chacun est libre de modéliser les choses comme il l’entend, en fonction du sujet, et de ce qu’il veut montrer/démontrer. C’est un point un peu déroutant au début. En partageant avec les collègues, je me suis aperçu que nous avions des approches très différentes dans la façon de modéliser.

Par exemple : comment modéliser le fait qu’une application soit Active/Active, ou qu’une infrastructure soit redondée. Nous pouvons

• Descendre dans les détails, en modélisant les instances, en montrant les services de répartition de charge (load balancing),
• Rester haut niveau, en ne décrivant qu’une seule “boîte”,
• Choisir une voie intermédiaire en utilisant des éléments comme les “groupes”, les composants “Application collaboration”, ou “Technology collaboration”.

La validité de ces approches ne dépend que de l’auditoire finalement. Si vous vous adressez à des clients, il est fort probable que la solution “haut niveau” suffise. Si vous vous adressez à des développeurs, il faudra fournir quelque chose de plus détaillé. Cette approche est est celle de TOGAF : une même architecture doit être présentée selon plusieurs vues, en fonction de ce que l’on veut montrer, et de l’auditoire.

Pour moi, ce point est le second inconvénient de Archimate. En effet, comme je le soulignais en introduction, un langage de modélisation, utilisé à l’échelle d’une entreprise, facilite les discussions entre les différentes équipes, en proposant justement un langage commun. Mais ceci n’est possible que si nous avons un minimum de formalisme. La liberté qu’offre Archimate limite les effets normalisateurs du langage.

Conclusion

Nous venons de parcourir très rapidement, les concepts liés à Archimate. C’est un langage simple, facile à appréhender, et suffisamment flexible pour s’adapter à un très grand nombre de situations. Les versions 3.0, et 3.1 renforce les éléments de motivations, de migration, et de stratégie, ce qui étend le domaine d’application de Archimate, à autre chose que l’architecture proprement dite.

Personnellement, je m’y suis intéressé à la suite de ma certification TOGAF®. Je ne l’utilise pas systématiquement, mais assez régulièrement. Les éléments qui reviennent le plus dans mon utilisation sont les éléments de motivation, et ceux de “Implementation et migration”. Dans les deux cas, il s’agit soit d’une aide à la décision, soit d’un outil de communication avec le chef de projet, les utilisateurs, …

Le langage Archimate est encore relativement récent, par rapport à d’autres langages comme UML. Il évolue très régulièrement.