La sortie récente de Obeo SmartEA 5.0 a été l’occasion pour nous de retravailler sur le modèle d’exemple fourni avec notre solution de cartographie (ce modèle est également consultable en ligne à travers un simple navigateur web).
Basé sur le cas fictif d’une agence de voyage appelée Voyage Discount, ce modèle a deux objectifs principaux.
Le premier est d’illustrer concrètement les différentes fonctionnalités offertes par Obeo SmartEA : la création de diagrammes ArchiMate et BPMN, la capacité à personnaliser les formes graphiques, la navigation dans le référentiel, la gestion des droits d’accès, la gestion des versions, etc…
Page d’accueil du référentiel Obeo SmartEA
Le deuxième objectif, tout aussi important pour nous, est de guider un nouvel utilisateur dans la prise en main de l’outil. A travers cet exemple, il doit pouvoir découvrir par lui-même comment l’outil peut répondre à ses besoins de cartographie et d’élaboration de transformations. Pour cela, l’exemple que nous fournissons doit l’aider à se projeter sur son propre contexte en lui permettant d’imaginer comment il pourrait cartographier sa propre organisation et son système d’information.
A travers cette série d’article, je vais donc tenter expliquer les règles de modélisation que nous avons suivies pour construire cet exemple. Celles-ci pourront vous guider dans l’élaboration de votre propre référentiel.
Définir un objectif de modélisation
Mais avant tout, il est important de préciser un point : une modélisation doit servir un objectif. Et en fonction de celui-ci vous ne modéliserez probablement pas les mêmes choses de la même façon : vous pouvez par exemple vous contenter d’une vue macroscopique sur l’organisation métier pour vous concentrer sur les applications. De même pour celles-ci, est-ce utile de détailler précisément leur déploiement ou plutôt les services qu’elles rendent au métier ? La réponse dépend du type d’analyse que vous avez à effectuer et des profils avec lesquels vous devez échanger.
Pour autant, dans la plupart des cas vous allez avoir besoin de renseigner quelques informations de base :
- l’organisation de votre entreprise : quels sont les principaux services métier, leurs rôles et les fonctions qu’ils exercent,
- les applications de votre système d’information : à quoi elles servent, qui les utilisent, avec quelles autres applications elles communiquent, où sont-elles déployées,
- l’infrastructure technologique : quels sont les principaux serveurs, quelles applications hébergent-elles, quelles technologies y sont déployées.
Le standard ArchiMate fournit un langage de modélisation qui permet d’adresser chacun de ces besoins. Mais ce standard est riche, il offre de nombreux concepts et beaucoup de liberté sur la façon de les mettre en oeuvre. Au final, sans quelques règles de modélisation communes, deux architectes obtiendront des résultats très différents, et qui pourront malgré tout être valides tous les deux !
Il est donc important de s’entendre sur quelques règles de base couvrant les besoins les plus fréquents, de manière à obtenir un référentiel homogène et qui soit interprété de la même façon par tous. Y compris, et surtout, par les outils d’analyse automatique dont vous aurez probablement besoin pour extraire des indicateurs, des vues calculées, des rapports ou des alertes.
C’est en effet l’un des intérêts majeurs d’une approche de modélisation par rapport à l’utilisation d’outils tels que Visio ou Powerpoint : les diagrammes que vous réalisez ne sont pas de simples dessins, ils produisent des données structurées. Autant faire en sorte que ces données soient exploitables !
Dans ce premier article, je vais me concentrer sur quelques règles de modélisation permettant de décrire l’organisation d‘une entreprise. L’intérêt étant de pouvoir s’en servir avec les équipes métiers pour analyser et expliquer comment le système d’information supporte les besoins des équipes métier, et ainsi évaluer leur alignement réciproque et les éventuels changements (organisationnels ou techniques) à opérer.
Modélisation des acteurs métier
Le premier réflexe quand on décrit une organisation est de représenter la décomposition en services et en équipes. C’est en effet de cette façon que la plupart des entreprises communiquent en interne (voire parfois en externe).
Pour cela ArchiMate propose le concept d’Acteur (Actor dans la spécification). Un acteur peut être une personne physique ou une personne morale. Nous pouvons utiliser ce concept pour représenter également un groupe de personnes (une équipe) qui joue un rôle dans l’entreprise.
Dans notre exemple Voyage Discount, nous avons donc représenté l’entreprise elle-même en tant qu’acteur, ainsi que ses principaux services (Administratif, Commercial, Marketing, SAV et Informatique) et les équipes qui les composent. Les différents niveaux étant reliés par des relations de composition.
L’entreprise Voyage Discount avec ses départements et équipes.
On peut voir ici un cas particulier : nous avons représenté sous forme d’un acteur le concept d’Agence. Dans le cas de Voyage Discount, il existe de nombreuses agences commerciales, toutes organisées de la même façon et dépendantes du département commercial. Plutôt que de modéliser en détail chacune des agences, ce qui n’est pas ce qui nous intéresse ici, nous avons fait le choix de ne créer qu’un seul acteur qui représente toutes les agences.
Pour éviter de trop complexifier un diagramme, nous conseillons, dans la mesure du possible, de dédier chaque diagramme à un objet principal en le représentant avec ses informations de premier niveau uniquement. Les informations propres à chaque sous-niveau étant représentées sur des diagrammes distincts.
De même plutôt que de montrer la relation de composition avec des liens, nous préférons montrer les sous-niveau sous la forme de “sous-boîtes”. Au passage, pour faciliter la lecture, nous pouvons aussi associer une image spécifique à chaque département. Et pour faciliter la navigation, nous pouvons aussi ajouter des raccourcis permettant d’accéder directement au diagramme de chaque département.
Vue des principaux départements de Voyage Discount
Rôles et fonctions métier
Pour chaque département nous pouvons aussi détailler les principales responsabilités (qui fait quoi). Pour ça nous devons distinguer deux aspects : le titre (comment les personnes sont identifiées au sein de l’entreprise), et les activités (ce qu’elles font concrètement) pour lesquels nous utilisons deux concepts différents d’ArchiMate :
- Rôle métier (Business Role) : on peut s’en servir pour décrire un titre, qui peut être affecté à plusieurs personnes, et à qui sont affectées un certain nombre d’activités. On utilise un nom pour le désigner. Cela correspond en quelque sorte à une fiche de poste.
- Fonction métier (Business Function) : une activité, potentiellement exercée par plusieurs rôles métier. Permet de décrire les missions d’un rôle. On utilise un verbe pour la désigner.
Liens entre acteurs, rôles et fonctions métier
Pour une meilleure lisibilité, on peut aussi représenter une partie de ces relations sous la forme d’imbrications.
Vue imbriquée des acteurs, rôles et fonctions métier
L’intérêt du concept de rôle est de pouvoir distinguer clairement un titre et la (ou les) personne(s) physique(s) qui l’exerce(ent).
Sans pour autant chercher à modéliser l’ensemble des employés, on peut également utiliser le concept d’acteur pour modéliser quelques personnes physiques clefs et les attribuer aux rôles. Ces informations peuvent être représentées graphiquement en utilisant les photos des personnes concernées.
Modélisation de personnes physiques
Au passage, vous pouvez noter l’utilisation du concept de Collaboration Métier (Business Collaboration), pour décrire le comité de direction. Il s’agit d’un un autre concept ArchiMate qui permet de décrire un ensemble d’acteurs ou de rôles qui travaillent ensemble.
Services et interfaces métier
Au final, à travers leurs fonctions, les rôles réalisent des services (Business Service) qui sont fournis à leur environnement. Ces services sont exposés via des interfaces (Business Interface) qui correspondent à la façon dont ces services sont consommés.
Liens entre rôles, interfaces, services et fonctions métier
Les services et les interfaces peuvent être ajoutés au diagramme précédent qui décrit le département Marketing.
Vue d'une organisation avec interfaces et services métier
Processus métier
Si l’on a besoin de décrire plus précisément une des activités d’un rôle pour spécifier une séquence d’actions ainsi que les ressources qu’elle consomme ou qu’elle produit, nous utilisons alors le concept de Processus métier (Business Process).
Par exemple, pour décrire les différentes étapes de la vente d’un séjour.
Processus métier ArchiMate
Le processus est déclenché par une évènement métier (Le client souhaite réserver un séjour) et, s’il va jusqu’au bout, provoque le déclenchement d’un nouvel évènement métier (séjour acheté).
Entre les deux, le processus se décompose en une succession d’étapes (proposer des séjours, établir la commande, etc). Sur chacune de ces étapes il est possible d’indiquer les données métier (Business Object) concernées. Au final, le processus permet de réaliser un ou plusieurs services métiers qui sont exposés vis à vis de l’environnement (ici, les différentes façons que le service commercial utilise pour vendre des séjours).
Avec ArchiMate, le processus est décrit de manière macroscopique, et c’est souvent largement suffisant lorsque l’on cartographie l’entreprise. Si par contre on a besoin de décrire ces processus de manière plus précise, on peut alors s’appuyer sur le standard BPMN. Dans notre exemple, nous avons utilisé une partie de la richesse de BPMN pour modéliser le processus de sélection d’un séjour par le client.
Processus métier BPMN
Un raccourci depuis le diagramme ArchiMate précédent permet d’accéder directement à ce diagramme BPMN.
Objets métier
Pour décrire les données, ArchiMate propose le concept d’Objet Métier. Là aussi, ArchiMate n’a pas pour vocation de permettre une description détaillée des données métier. Ce qui est important à ce niveau c’est de pouvoir décrire les principaux objets et leurs éventuelles relations. ArchiMate permet aussi de décrire les supports physiques de chaque donnée.
Objets métier
Ici également, on peut remplacer la forme ArchiMate par des images plus expressives.
Vue des objets métier avec des images
Et comme avec les processus, si l’on souhaite détailler ces objets métiers, on peut utiliser un autre langage, inspiré d’UML par exemple, pour définir les propriétés et les multiplicités des liens.
Modélisation des objets métier avec attributs et multiplicités
Toutes ces règles peuvent évidemment être adaptées en fonction de votre contexte et surtout de votre objectif.
Dans un prochain article, je décrirai les règles utilisées pour la modélisation du système d’information
.
