Qu'est-ce que ArchiMate ?

ArchiMate est un langage de modélisation pour l'architecture d'entreprise : une norme de The Open Group, et le seul langage largement utilisé conçu pour ce travail. Là où UML décrit du logiciel et BPMN décrit un processus, ArchiMate décrit une organisation : ce qu'elle fait, ce qui la soutient et sur quoi cela tourne, dans un seul modèle avec un seul vocabulaire.

Ce qu'il fait et que rien d'autre ne fait, c'est franchir les frontières. Un diagramme de classes ne peut pas dire qu'un logiciel soutient un processus métier. Un diagramme de processus ne peut pas dire de quel serveur le processus dépend. ArchiMate peut dire les deux sur la même image, avec les mêmes onze types de relation d'un bout à l'autre, et c'est toute sa raison d'être.

ArchiMate organise tout son jeu d'éléments sur une grille. D'un côté, les couches, qui disent à quelle distance du métal se trouve un élément. De l'autre, les aspects, qui disent quel genre de chose c'est. Chaque type d'élément du langage occupe exactement une case.

Les aspects forment le second axe et sont plus simples : un élément est actif (il fait quelque chose - un acteur, un composant, un noeud), comportement (quelque chose qui est fait - un processus, une fonction, un service), ou passif (quelque chose sur quoi on agit - un objet métier, un objet de données, un artefact). Les éléments actifs se dessinent à angles droits, le comportement à angles arrondis, et les éléments passifs sous forme d'objet.

Apprendre la grille, c'est l'essentiel de l'apprentissage du langage. Dès que vous savez qu'un "service" est un élément de comportement et qu'il existe à chaque couche, vous savez déjà ce que sont un service métier, un service applicatif et un service technologique, et l'article sur les couches ne fait plus que remplir les détails.

La notation d'ArchiMate est l'inverse de celle d'UML. UML donne à chaque type de diagramme ses propres formes : des ovales pour les cas d'utilisation, des losanges pour les décisions, des boîtes isométriques pour les noeuds. ArchiMate donne à presque tout un rectangle et distingue les éléments de trois autres façons.

Les éléments sont la moitié facile. Les onze types de relation sont là où les modèles réussissent ou échouent, et quatre d'entre eux portent l'essentiel du sens :

La distinction que l'on rate en premier, c'est service rendu contre réalisation. La réalisation dit "ceci est cela, rendu réel" ; le service rendu dit "ceci aide cela". Un composant de paiement réalise le service de paiement (la même capacité à deux niveaux d'abstraction) et le service de paiement sert le processus de commande (deux choses différentes, l'une utile à l'autre). Les inverser produit un modèle qui a l'air correct et répond faux aux questions d'impact - voir l'article sur les relations.

Comparez avec la figure d'ouverture. La version UML sait que Claim.submittedOn est une date ; la version ArchiMate n'en a aucune idée. La version ArchiMate sait qu'une panne de la base des sinistres finit par empêcher un assuré de déclarer un sinistre ; la version UML ne sait même pas formuler la question.

Les deux sont complémentaires plutôt que rivaux, et une pratique saine emploie les deux : ArchiMate pour le paysage, UML pour les systèmes qui s'y trouvent. Ce qui ne marche pas, c'est un langage étiré pour faire les deux, ce qui donne en pratique un modèle ArchiMate avec des attributs greffés ou un diagramme de classes avec des serveurs dessinés à côté des classes.

1. Modéliser toute l'entreprise. Personne ne termine et personne ne lit. Modélisez la partie dont dépend une décision, et arrêtez-vous.
2. Utiliser l'association pour tout. Un modèle dont tous les traits sont de simples associations ne porte pas plus d'information qu'une photo de tableau blanc. Si vous ne savez pas choisir une relation précise, vous ne comprenez pas encore le lien.
3. Une vue géante. Le modèle est le modèle ; une vue est une fenêtre dessus pour un public. Cinq vues ciblées valent mieux qu'une affiche. Les points de vue sont le mécanisme.
4. Des composants applicatifs nommés d'après les équipes. Les équipes sont réorganisées deux fois par an, pas les systèmes. Nommez le système.
5. Sauter la couche motivation. Six mois plus tard, personne ne se souvient quelle exigence justifiait le morceau bizarre, et il disparaît.