Pour tout randonneur, une carte est bien utile pour savoir où on est et quel chemin prendre pour aller là où on veut. De même, pour un système d’information, une équipe informatique a besoin de s’appuyer sur une cartographie pour adapter le SI aux enjeux du métier, sans parler de l’optimiser ou simplement de le maintenir en état de fonctionnement. Pourtant, la plupart des SI ne disposent pas de cartographie réellement opérationnelle, à la fois utile, utilisable et utilisée. Alors, comment mettre en place des cartographies qui repoussent l’inconnu, le Here be dragons des cartes anciennes ?
Après une période de développement des SI, beaucoup d’entreprise doivent aujourd’hui revoir leur cœur de SI – qui est obsolète, ou non adapté à la nouvelle configuration du marché -, ou optimiser leur portefeuille d’application pour réduire les coûts de possession en impactant le moins possible le service rendu au métier. Sans la carte du territoire, ces chantiers d’adaptation ou de transformations sont risqués et compliqués, et finissent être en retard et coûteux (s’ils finissent !). On construit rarement sur du green field : le brown field est quand même la situation la plus rencontrée.
Que trouve-t-on dans une cartographie de SI ?
Que contient une cartographie de SI ? A minima, elle contient le portefeuille applicatif, sa projection dans l’organisation, les dépendances entre ces éléments. Le portefeuille applicatif est l’inventaire de l’ensemble des applications et de leurs constituants. La projection dans l’organisation est le découpage des périmètres de responsabilité (et de financement) de ce même portefeuille. Enfin, les dépendances peuvent se comprendre comme des flux de données, définissant des relations producteur-consommateur entre applications. Ces éléments sont nécessaires pour appréhender le SI comme un système socio-technique : la combinaison d’éléments informatiques et de savoir-faire humains produit (ou devrait produire) une valeur supérieure à la somme des valeurs unitaires.
Ce noyau de cartographie est souvent complété par une projection du SI sur l’infrastructure, c’est-à-dire le déploiement des éléments applicatifs sur les ressources techniques. Cette information est généralement conservée et exploitée dans une CMDB (qui peut avoir les mêmes problèmes de fraîcheur et d’exhaustivité !). Elle sert à exploiter le parc technique pour atteindre les engagements de niveau de service, et potentiellement à l’optimiser sur un plan économique, dans une approche de FinOps.
Pour les cartographies les plus avancées, nous avons aussi une mise en correspondance entre le SI et les processus Métier, qui établit le lien entre les activités de processus et les éléments applicatifs. Cette relation fournit les dépendances entre le modèle opérationnel de l’organisation et le parc applicatif et d’identifier les « applications critiques », celles qui supportent les processus Métier les plus importants. Cette compréhension est utile pour orienter les efforts sur les enjeux métier. L’allocation des efforts n’est pas si évidente que l’on pourrait le penser, car elle doit tenir compte des dépendances entre applications. En effet, pour qu’un service métier soit rendu, toute la chaîne applicative qui le sous-tend doit fonctionner de bout en bout. . Par exemple, un bus de service qui n’a pas de valeur métier en soi, hérite souvent de la criticité des applications métier qu’il supporte. On peut aller encore plus loin en s’appuyant sur ce lien entre SI et processus pour rechercher l’efficience du SI en fonction de la valeur métier induite. Cette approche offre une alternative mieux-disante à la recherche de la réduction du coût absolu du SI (voir cet autre article du blog, Pour un nouveau contrat entre le métier et l’IT).
La difficulté à disposer d’une bonne cartographie
Pour qu’une cartographie puisse apporter de la valeur, elle doit être suffisamment à jour, suffisamment complète, suffisamment manipulable et intelligible par la plupart des acteurs et suffisamment employée dans la planification et la mise en œuvre des changements du SI. En matière de cartographie, la perfection n’est pas nécessaire. De toute façon, la carte n’est pas le territoire1 ! L’approximation est acceptable si les erreurs potentielles sont facilement détectables et réparables par les acteurs, que ce soit par des procédures ou des contrôles automatiques. Dans ces conditions, les acteurs ont une confiance fondée à s’appuyer sur la cartographie pour analyser le SI et prendre des décisions pertinentes sur les trajectoires des projets.
Une carte n’est pas le territoire qu’elle représente, mais, si elle est juste, possède une structure similaire à ce territoire, ce qui justifie son utilité
A Non-Aristotelian System and its Necessity for Rigour in Mathematics and Physics, Alfred Korzybski, 1931
Malheureusement, beaucoup de cartographies sont trop approximatives. Les acteurs doivent alors aller à la pêche aux informations et vérifier systématiquement toutes les informations présentées. Le bénéfice de la cartographie s’évapore complètement. Cette situation s’explique par la tragédie des communs2 : tout le monde bénéficierait d’une cartographie opérationnelle, mais personne n’a le temps/l’envie/la compétence (rayez la mention inutile) pour la mettre à jour. Ce conflit entre intérêt collectif et intérêt individuel peut être résolu par la gouvernance du système d’information, qui promeut les comportements de bons citoyens et instruit les écarts par rapport à cette norme. Les acteurs ont donc des incitations pour mieux coopérer entre eux. Ne haïssez pas les joueurs, mais le jeu3 !
Approche classique de mise en place de la cartographie
Dans une approche classique, les équipes produisent les dossiers d’architecture des applications, en responsabilité, et reversent les éléments d’information dans une base de connaissance commune, ladite cartographie. Le dossier d’architecture spécifie notamment l’implantation de l’application dans le SI : comment l’application interagit avec le reste du SI ? comment est-elle déployée au travers de l’ensemble de ses environnements ? comment cette implantation va se réaliser dans le temps ? La cartographie du SI est à la fois l’unification de ces « cartes locales » mais aussi la piste chronologie de la carte globale. Elle décrit à la fois l’état présent du SI, mais aussi l’état projeté au travers de plusieurs trajectoires (l’état passé peut aussi être intéressant dans le cas de rétrospective). En s’appuyant sur la cartographie, les acteurs construisent une compréhension commune de la situation, mais aussi s’entendent sur la cohérence de leurs plans d’action.
La cartographie du SI est parfois assimilé comme le dossier d'architecture du SI. Cela me semble être une erreur 🫣. Le dossier d'architecture ne se résume pas à des schémas d'implémentation ! Il contient tout un raisonnement qui conduit des enjeux métier aux exigences non fonctionnelles, puis aux choix d'implémentation et à la spécification des environnements. Ce raisonnement permet de comprendre l'existant et peut être remis en cause de façon consciente pour s'adapter à de nouvelles circonstances. De l'autre côté, la cartographie doit rester à un niveau de simplification suffisant pour rester exploitable. Bien sûr, quand on arrive sur une application dans la carte, il est intéressant de joindre le dossier d'architecture de celle-ci pour "creuser". Si on fait une analogie dans le monde du bâtiment, le plan cadastral nous donne l'organisation des parcelles tandis que le plan technique du bâtiment implanté sur la parcelle décrit sa structure. Le plan cadastral serait sûrement lourd à consulter s'il contenait la description détaillée des bâtiments.
Comment faire une cartographie en rétrospective ?
Et comment faire une cartographie si on n’a pas suivi cette approche classique ? Dans cette situation, on constate souvent une documentation écrite incomplète, non actualisée, voire absente ! La connaissance est dans la tête des acteurs (enfin, c’est ce qu’ils imaginent !) et ces derniers n’ont pas l’idée de renseigner une cartographie spontanément (vous vous rappelez la tragédie des communs ?). Les produits du marché visent la population des architectes, qui ne représentent qu’une toute petite fraction de la DSI et sont parfois jugés comme trop complexes pour les autres acteurs de la DSI. Dans ces conditions, les architectes collectent les informations et sont les seuls à renseigner le référentiel. Certes, nous avons une cartographie utile et utilisable, mais pas utilisée par le plus grand nombre 😞. Et cela dépend d’un effort important concentré sur un petit nombre d’acteurs, un effort qui se démultiplie quand il s’agit de reprendre l’existant (le fameux Here be dragons). Un autre frein dans cette démarche est le processus d’achat du produit. Il est compliqué de faire entendre le ROI d’une cartographie pour motiver cet achat. La perte de temps de la pêche aux informations ou les opérations « coup de poing » d’inventaire d’existant sont difficiles à valoriser pour alimenter le business case de l’achat du produit de cartographie.
Et si on doit démarrer léger ?
L’année dernière, j’ai eu l’opportunité de construire une alternative plus légère pour initier une cartographie sur tout ou partie du SI et commencer à explorer le Here be dragons. Elle se déroule en deux temps : une phase de collecte dans des feuilles de calcul, suivie d’une phase de contrôle basée sur une représentation graphique dynamique, affichable avec cet excellent outil qu’est Ilograph. L’affichage permet de valider en séance les renseignements collectés avec l’ensemble des acteurs. Cette approche permet de rassembler et de croiser le savoir des acteurs, qu’ils soient managers, développeurs ou opérateurs.
La modélisation du SI est volontairement simple. Le portefeuille applicatif est un ensemble de ressources organisé en une série de poupées gigognes : les organisations sont divisées en unités organisationnelles ; les unités organisationnelles sont en charges d’applications et ces applications sont implémentées par des composants. Le concept d’application est ici central, positionné entre l’organisation humaine et les composants déployés (voir Et pour vous, qu’est-ce qu’une application ?). Un point important dans cet exercice est d’identifier tous les éléments (et donc de fournir un identifiant à chacun). Curieusement, il n’y a pas toujours d’identifiant fixe et universel de disponible (par exemple, un code applicatif pour désigner une application). Dans ce cas, il faudra produire de façon arbitraire un identifiant pour poursuivre la démarche. Le tout premier bénéfice de la cartographie est de pouvoir nommer sans ambiguïté les constituants du SI 🙂 !
Ensuite, on formalise les flux d’informations entre les applications, les flux applicatifs. Les flux sont des abstractions au-dessus des flux techniques qui correspondent à des ouvertures de réseau. Pour reconstituer les flux applicatifs, on recherche leurs points de passage avec l’aide des opérateurs. Un point de passage peut être un job dans un ordonnanceur, un label d’un transfert de fichier, une souscription sur une API… Un flux applicatif est fréquemment composé de plusieurs flux techniques. De même, que pour les ressources, les flux sont identifiés.
La feuille de calcul est un bon support pour ce cas d’usage. Les acteurs sont habitués à ce format documentaire. Ce format est flexible : on peut ajouter des champs supplémentaires qui apportent une information pertinente dans le contexte.
L’export des données de la feuille de calcul vers un diagramme Ilograph est réalisé par un script Python, développé pour l’occasion. Ce script peut être adapté pour prendre en compte des particularités.
Le diagramme Ilograph fournit une représentation graphique bien adapté à des sessions de travail en groupe. On peut modifier à la volée l’affichage, en choisissant un niveau dans l’organisation des ressources (d’où l’intérêt des poupées gigognes plus haut) ou sélectionnant l’élément central à représenter. Il est possible d’adapter l’affichage en fonction du point abordé. Un autre intérêt par rapport à d’autres solutions de diagramming est la meilleure tolérance pour afficher des systèmes avec beaucoup de flux. Comme les systèmes d’information sont de plus en plus distribués, on a besoin de solutions qui nous permettent d’afficher ces graphes sans qu’ils ressemblent à une toile d’araignée (c’est joli, mais pas très utile ! ).
Il est aussi possible de compléter le modèle pour inclure les trajectoires de transformation de SI. C’est un point que je suis en train d’expérimenter (et ce sera sans doute l’objet d’un prochain article 😉).
TL;DR
Cartographier le SI est donc une activité essentielle de la DSI, dans le contexte actuel. Cette activité peut être découpée en deux volets : la cartographie des nouveaux pans du SI et celle de l’existant.
La cartographie des nouveaux pans implique de remettre de l’architecture intentionnelle dans la démarche des projets ou des itérations : instruire les dossiers d’architecture peut être une pratique à démarrer ou restaurer. Certes, il ne s’agit plus maintenant de produire des corpus documentaires volumineux comme avant, mais de réaliser une documentation efficace s’appuyant sur des pratiques modernes comme les ADR pour instruire les choix ou les DSL pour produire les schémas d’architecture.
La cartographie de l’existant implique de pouvoir récupérer la connaissance sur le SI qu’elle soit sur des supports écrits ou dans la tête des sachants et de la mettre en qualité.
Prioriser la remise en état de la connaissance du SI reste une tâche difficile. Aussi, une approche légère et itérative, comme décrite précédemment, peut amorcer un cercle vertueux qui démontre les bénéfices de disposer d’une cartographie du SI avec un investissement minimal. Ensuite, le passage vers une approche plus industrielle peut se produire pour fournir une cartographie à l’échelle de l’organisation et pour supporter l’ensemble des trajectoires dans le SI.
Crédits
- « A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness » (A Non-Aristotelian System and its Necessity for Rigour in Mathematics and Physics, Alfred )Korzybski, 1931) ↩︎
- https://fr.wikipedia.org/wiki/Trag%C3%A9die_des_biens_communs ↩︎
- https://www.youtube.com/watch?v=jxsx4WdmoJg ↩︎