Dans un premier post de blog, j’ai expliqué quelques règles de modélisation qui nous ont permis de modéliser la couche métier de Voyage Discount, l’agence de voyage fictive qui nous sert de modèle d’exemple dans Obeo SmartEA.
Dans ce deuxième article, je vais traiter des couches applicatives et technologiques : comment cartographier le système d’information déployé chez Voyage Discount ?
Comme je l’ai précisé précédemment, il n’y a pas une seule façon de modéliser un existant : tout dépend de l’objectif à atteindre et des interlocuteurs avec qui vous serez amené à partager le résultat. Quelles que soient les règles que vous mettez en oeuvre, l’important reste de bien les identifier et de les partager avec les personnes qui travaillent avec vous sur le même référentiel.
Ici, nous allons présenter quelques règles de base qui restent applicables dans de nombreux cas. Il vous restera à les adapter, en les simplifiant ou en les étoffant, pour qu’elles correspondent au mieux à votre contexte et à vos objectifs.
Avec ArchiMate, le standard de modélisation qui est supporté par Obeo SmartEA, la description d’une application sépare la partie structurelle de la partie comportementale.
Structure d’une application
La structure d’une application est décrite à l’aide d’un composant applicatif (Application Component), qui est une “unité autonome, déployable indépendamment, réutilisable et remplaçable”.
Pour représenter simplement les flux entre les applications, il est possible d’utiliser la relation de type “Flot” (flow) et indiquer le type d’information qui transite.
Flux entre applications
Pour être plus précis sur le type des données échangées entre les applications, il est conseillé de les modéliser en tant que telles avec l'aide d'objets applicatifs (Data Object).
Objets applicatifs transitant entre applications
Mais la modélisation des flux ne dit rien sur l’architecture des échanges. Si l’on souhaite décrire cet aspect, il est possible d’utiliser les interfaces (Application Interface) qui servent de point d’accès aux utilisateurs (couche métier) ou aux autres applications (couche applicative).
Communication par interfaces applicatives
Ces deux types de modélisation (les flux et les interfaces) sont complémentaires, ils peuvent être utilisés simultanément.
Comme dans notre cas du système de réservation, lorsque l’application est complexe et que l’on a besoin de préciser le rôle joué par certains sous-composants, on peut être amené à détailler la structure interne d’une application en modélisant les composants dont elle est constituée. On peut également utiliser les notions de spécialisation pour modéliser différentes catégories de composants.
Composition et spécialisation des applications
La même modélisation peut être rendue plus lisible en utilisant des images et des conteneurs.
Représentation améliorée des applications
Comportement d’une application
Pour décrire le comportement d’une application, ArchiMate propose deux concepts principaux :
- les services applicatifs (Application Service) : spécifient les fonctionnalités exposées auprès de l’environnement
- les fonctions applicatives (Application Function) : spécifient les fonctionnalités internes d’une application
Une fonctionnalité externe (service) est généralement implémentée par une ou plusieurs fonctionnalités internes (fonctions), elles-mêmes attribuées au composant applicatif.
Fonctions et services d'une application
Les services sont exposés à l’environnement via les interfaces de l’application (Application Interface). Le lien avec la couche métier s’établit depuis les services applicatifs vers les fonctions métier ou les processus, et depuis les interfaces applicatives vers les rôles métier.
Liens entre applications et métier
Ce principe de modélisation permet à la fois de distinguer la structure vis à vis du comportement, mais aussi ce qui est interne par rapport à ce qui est externe. L’intérêt est de pouvoir décrire qu’un même service est potentiellement rendu par plusieurs applications, et réciproquement.
Mais ces règles sont assez fastidieuses à mettre en oeuvre au pied de la lettre car elles multiplient le nombre d’objets et de relations à modéliser. En pratique, il est conseillé de procéder à quelques simplifications qui facilitent à la fois la modélisation (moins d’objets à créer), le maintien de la cohérence dans le temps (moins de risques d’erreur), et la lisibilité des diagrammes (plus concis).
Simplifications des règles
Ainsi, lorsque l’ensemble des fonctionnalités internes modélisées sont accessibles depuis l’extérieur, on peut se contenter de ne modéliser qu’un seul service qui les représente toutes et de rattacher ce service directement à l’application plutôt qu’à chacune des fonctionnalités.
De la même façon, si tous les rôles d’une équipe utilisent la même interface applicative, on peut se contenter d’établir un lien vers l’équipe, plutôt que vers chacun des rôles.
Un même service implémentant toutes les fonctions
Une modélisation plus précise ne sera effectuée que pour préciser des cas particuliers ou insister sur un aspect d’architecture qu’il est important de décrire.
Attention toutefois à simplifier avec précaution ! En effet, tout raccourci de modélisation devra être connu des outils qui effectuent des traitements automatiques (analyse d’impact, génération documentaire, vue synchronisée, etc) car sinon leurs résultats seront faussés.
La façon dont chaque règle peut éventuellement être simplifiée doit donc elle-même faire l’objet d’une règle qui formalise ce cas particulier. Par exemple, modéliser qu’une application réalise un service signifie que chaque fonction attribuée à cette application réalise elle aussi ce service, même si le lien n’existe pas explicitement dans le modèle.
Si ce n’est pas le cas, alors chaque fonction devra explicitement préciser quel(s) service(s) elle réalise.
Chaque fonction implémentant un service spécifique
Déploiement des applications
Les règles précédentes permettent de décrire les applications indépendamment de la façon dont elles sont construites ou déployées. Nous allons voir maintenant comment décrire cet aspect au travers de quelques règles de modélisation de la couche technologique.
Pour cela nous utilisons principalement quatre concepts ArchiMate :
- Noeud (Node) : ressource, généralement virtuelle, sur laquelle sont exécutés des logiciels et des fichiers (artefacts).
- Machine (Device) : cas particulier de noeud qui est physique (serveur, PC, etc).
- Logiciel Système (System Software) : environnement logiciel exécutant les artéfacts.
- Artéfact (Artifact) : généralement un fichier physique, contient des données, un script, un document, etc.
Pour relier ces concepts entre eux, nous utilisons essentiellement le lien d’affectation, qui peut s’interpréter, en fonction des cas, par “exécute” (pour un logiciel système) ou “héberge” (pour un noeud et une machine). Nous pouvons ainsi construire une chaîne de composants depuis la machine physique jusqu’aux fichiers.
Déploiement d'une application
Le diagramme ci-dessus s’interprète donc de la manière suivante :
- “Serveur Voyage Discount 1” tourne sous “Linux RedHat ES 6”.
- “VM Finances” est déployée sur “Serveur Voyage Discount 1” et fait tourner un “Linux RedHat ES 4.3”.
- Sur “VM Finances” une configuration logicielle “Config x-ERP” fait s’exécuter le logiciel “x-ERP 7.4” avec un ensemble de fichiers de paramétrage “Configuration comptabilité pour Voyage Discount”
Parmi tous ces objets technologiques, c’est le noeud “Config x-ERP” qui réalise l’application “Logiciel de comptabilité”. Physiquement, cette configuration pourrait être déployée sur une autre machine sur laquelle tourne Linux. Et potentiellement, le composant applicatif pourrait être implémenté (réalisé) par une autre configuration logicielle, voire un autre système.
Le même modèle peut également être représenté de la manière suivante :
Vue améliorée du déploiement
Au niveau global, il est également possible de décrire, de façon macroscopique, l’ensemble des serveurs utilisés par l’entreprise Voyage Discount et la façon dont ils sont (ou pas) connectés au réseau interne.
Infrastructure générale
Comme pour les flux entre applications, on peut également utiliser la relation de “Flot” pour décrire certains échanges entre serveurs. Par exemple pour décrire la stratégie de sauvegarde des différents environnements.
Flux entre machines
L’ensemble des règles décrites dans ces deux articles ne sont évidemment pas exhaustives et n’ont pas vocation à couvrir l’ensemble des situations et des besoins que vous pourrez rencontrer dans votre entreprise.
Elles ne constituent pas non plus une démarche d’architecture. Pour cela il existe des cadres tels que TOGAF qui décrivent comment aborder le problème d’une transformation à l’échelle de l’entreprise et quoi modéliser à quel moment. Comme je l’ai écrit dans l’article précédent le plus important est que la modélisation serve un objectif. A partir de là en découlent les éléments à modéliser, avec quel niveau de granularité et avec quelle précision.
J’espère simplement que ces règles pourront vous aider à entamer une démarche de modélisation avec ArchiMate pour pouvoir cartographier votre existant, tant métier qu'applicatif, et élaborer vos premières cibles de transformation.
