Comment cheminer de vues d’architectures partielles à la modélisation consolidée du système d’information ?

Avec la complexification croissante des systèmes d’information, connaître son existant devient à la fois plus difficile et crucial. Modéliser son Système d’Information et en apporter une vision compréhensible et exploitable, selon les besoins de chaque acteur, est ainsi un enjeu partagé et une source de questionnement sur la méthode à suivre ! 

Pour éclairer ce sujet, Arthur et Olivier, consultants au sein de l’offre Architecture du Système d’Information de Projexion, nous partagent leurs retours d’expérience sur la modélisation des systèmes d’information. 

On parle beaucoup de la modélisation des Systèmes d’information. Mais de quoi s’agit-il ?

Arthur :

La modélisation d’un système d’information permet d’obtenir des représentations consolidées sous différents domaines: processus métiers, capacités fonctionnelles, couches applicatives et échanges de données, infrastructures et technologies… Chaque domaine étant interconnecté avec les autres.

C’est cette connaissance consolidée qui apporte de la valeur pour analyser les impacts et naviguer entre les différents domaines. Par exemple, on part d’un processus métier et on explore ce qu’il y a en dessous quand on ouvre le capot. Quand on part de notre socle d’infrastructure, on étudie ce qu’il supporte en termes d’applications, de processus ou de capacités d’entreprise.

Les représentations peuvent être diverses, et on fonctionne généralement par vues. Différents architectes disposent de différents points de vue qui sont modélisés et liés entre eux pour apporter cette complétude d’informations. 

Olivier :

Oui, une vue n’est qu’une représentation partielle d’une réalité complexe. Si on prend une métaphore, un bâtiment peut être représenté de nombreuses façons différentes (par exemple : Vue murs porteurs et fondations; Vue câblage électrique ; Vue plomberie ; Vue Ascensoriste …). Chacune des vues va donner une vision parcellaire du tout. La compréhension de ce tout nécessite de capitaliser toutes ces vues.

Pour rappel l’architecture décrit :

• l’organisation d’un système mis en œuvre par des composants, par les relations que ces derniers ont entre eux et avec l’environnement
• les principes qui en régissent la conception et l’évolution.

La modélisation du SI s’appuie sur un métamodèle qui guide la représentation des composants, leurs caractéristiques et leurs relations.

Le SI et l’entreprise sont inextricablement liés. Quand le business model change, on audite autant l’organisation que le SI, car le service rendu va évoluer.

Une solution informatique de type Référentiel d’Architecture va offrir un lieu où la totalité de la connaissance de mon SI va être rangée. De représentations parcellaires, on passe ainsi à une modélisation complète des composants, des liens et des caractéristiques permettant de produire de nombreuses vues. Cela peut devenir générateur de nombreux services ! Par exemple : analyse d’impact, étude de la circulation des données dans le SI, analyse d’obsolescence technique, diagnostic d’un incident.

Par sa complexité croissante, le Système d’Information va être plus difficile à dompter, avec une multiplication des impacts en cas de modification. De plus, la vélocité des besoins métier amène le SI à évoluer plus vite, et nécessitent parfois d’en revoir les fondations. L’organisation qui en assume le bon fonctionnement doit absolument maîtriser son « état actuel ». 

Justement, pourquoi a-t-on besoin de modéliser ses SI et de s’appuyer sur des outils ? 

Arthur :

L’objectif est de disposer d’une vision la plus réaliste possible de tout ce qui est présent dans le Système d’Information, et de capitaliser, dans un seul référentiel, cette connaissance pour l’exploiter.

Par exemple, pour chaque étude de transformation, on ne redémarre pas de zéro. On sait d’où on part, on réutilise, on exploite. Sinon, cela nécessiterait de vérifier de manière exhaustive tous les composants du SI !  

Le cas d’usage que je rencontre le plus souvent dans mes missions est de mener des analyses d’impact. Si un composant devient obsolète, qu’une montée de version ou une migration est nécessaire ou qu’un processus métier doit changer, on identifie les composants en interaction sur tous les domaines : fonctionnel, infrastructures, support, métier… 

Le deuxième cas d’usage très courant est de faciliter le décommissionnement de composants, en connaissant tous les tenants et aboutissants d’un service ou d’une capacité. Rendre son SI plus cohérent et plus « propre » est un enjeu de plus en plus partagé.

Il ne faut pas limiter la modélisation du système d’information aux domaines technologiques car il est nécessaire d’analyser les impacts des changements sur tout le SI. Tous les services et les métiers qui l’utilisent ont vocation à y être intégrés. Il ne faut pas perdre de vue que le SI propose des services, sur lesquels les métiers s’appuient pour leurs activités.

Olivier :

Je suis intervenu auprès d’un groupe international dans lequel, deux entités organisationnelles interviennent dans des domaines métier similaires, mais avec des processus différents. La question était d’étudier les conséquences si on harmonisait les processus entre les deux structures. La modélisation de l’architecture va faciliter mon travail d’architecte pour analyser les impacts et étudier les différents scénarios.

Comme autre cas d’usage, les vues permettent de détecter et de mieux anticiper les défauts de santé du SI. Certaines vues d’architecture peuvent représenter des éléments fluctuants dans le temps comme son état de santé à un instant T, la vitesse de refacturation des utilisateurs, les usages…

Les vues d’architectures permettent également de prendre du recul afin d’examiner les différentes options au travers de vues exploratoires pour aborder une transformation. Ces vues prospectives permettent de se focaliser à plusieurs sur le même concept.

Dans cet objectif, la modélisation peut intégrer les personas métiers et les unités d’organisation. Elle peut aller “jusqu’en haut” de l’architecture d’entreprise !

En synthèse, les principaux cas d’usage de la modélisation d’une architecture sont : 

1. Maîtriser la complexité de l’existant pour garantir son maintien en condition opérationnelle en permettant de corriger rapidement les défauts
2. Aider à la rationalisation, le décommissionnement, la convergence du SI par l’analyse de l’existant
3. Réfléchir pour transformer ! Faire de la prospective et analyser l’écart entre un état existant et une cible.

Où en sont les entreprises sur ces enjeux de modélisation des systèmes d’information ?

Arthur :

La maturité des entreprises est très variable et est liée à leur culture organisationnelle. Les sociétés qui ont développé des capacités d’architecture d’entreprise auront plus de facilité pour représenter le SI dans un outil. Au contraire, si la connaissance de chaque composant applicatif dépend de départements différents, le saut à franchir sera élevé ! La connaissance décentralisée du SI est un frein.

Dans mon expérience, la barrière la plus importante reste le temps, en particulier pour maintenir le référentiel. Beaucoup d’équipes sont contraintes par les délais et le time-to-market dans leur quotidien. 

L’enjeu est ainsi d’identifier où mettre le curseur suivant l’usage souhaité. Construire sa modélisation ne suffit pas, le vrai défi est de la maintenir et de l’exploiter dans la durée.

Olivier :

Je vois pour ma part le marché en quatre cercles.

• Un premier cercle d’entreprises n’en ressent pas le besoin. L’architecture est suffisamment simple, et la somme des sachants suffit. Le SI est maîtrisé et la connaissance de ce dernier permet de réaliser les évolutions nécessaires !
• Le deuxième cercle correspond aux entreprises qui ont déjà entendu parler de l’architecture et des enjeux de modélisation. L’entreprise sent qu’elle aurait besoin d’aller plus loin, mais freine des quatre fers. En effet, l’équilibre entre « je sais que ce serait mieux si j’avais un modèle consolidé » et « cela va représenter un coût, des ressources et du temps » est souvent perçu défavorablement. Ces entreprises restent majoritairement dans l’état qu’elles maîtrisent, et seule une vision claire du ROI pourrait faire pencher la balance.
• Le troisième cercle, ce sont ceux qui ont eu l’audace d’y aller et malheureusement une partie d’entre eux est déçue.
  • Certaines ont tenté l’expérience de manière partielle avec des bouts de référentiels pour les flux, une CMDB…  Et cette modélisation parcellaire n’apporte qu’une satisfaction limitée.
  • D’autres ont initié des projets pharaoniques avec des coûts et une durée projet importants. Lors du passage en “run”, les équipes réalisent que l’effort de mise à jour des données du référentiel d’architecture est plus important que prévu.
• Le dernier cercle sont les entreprises qui ont initié une démarche de modélisation de l’architecture (couverture partielle) et qui en sont satisfaites.

La cause d’échec majeur, c’est lorsque la pénibilité pour maintenir le référentiel à jour est supérieure aux bénéfices d’usage attendus.

Quelles sont alors les bonnes pratiques pour se mettre en mouvement sur la modélisation du SI ?

Arthur :

Le succès repose très souvent sur la bascule en mode RUN. Comment fait-on vivre le référentiel dans le temps ? Comment assure-t-on que les métiers et la DSI en tirent plus de valeur qu’il ne leur apporte de pénibilité pour le mettre à jour ?

Il faut partir de la première clé : la modélisation doit permettre à minima de représenter l’état actuel. Cela requiert une rigueur d’actualisation quotidienne du référentiel d’architecture car le Système d’Information est en perpétuel changement, et si on ne le nourrit pas, la data dépérit. Au bout de 6 mois, sa valeur peut disparaître et le référentiel devient obsolète !

La deuxième clé c’est que la pénibilité à le maintenir dépend du niveau de détails exigé dans le métamodèle.

Je suis ainsi convaincu que la bonne méthode est de le construire par itération. C’est-à-dire, ni des projets pharaoniques qui s’écrasent lors du passage en RUN, ni des visions parcellaires.

On peut débuter par un périmètre restreint qu’on augmente progressivement en fonction de la maturité des équipes IT et métier. Dès le démarrage, toutes les parties prenantes doivent être embarquées. Attendre le mode RUN pour impliquer les équipes IT et non IT est une erreur !

De même que le périmètre défini initialement doit être co-construit pour répondre aux besoins exprimés, une gouvernance est un facteur clé de succès qui doit être mise en place dès le début pour gérer la vie du méta-modèle guidé par les usages et les besoins induits par les vues attendues.

Les standards de modélisation peuvent permettre de faciliter la modélisation (formations, compétences sur le marché, exemples …) :

• ArchiMate continue de gagner du terrain.
• EPC, BPMN 2 et DMN (Decision Model and Notation).

Ces standards sont très complets et permettent de représenter des cas simples ou complexes. Leur adoption stricte n’est pas une obligation, mais peut être également une source d’inspiration.

L’objectif, c’est qu’il n’y ait pas tout dans le référentiel, mais les informations utiles !

Olivier :

Tout est dit : approche projet itérative, progressivité du périmètre couvert par le modèle, gouvernance du référentiel (ses données, ses usages, sa valeur délivrée…), accepter d’arrêter l’initiative si elle ne délivre pas la valeur attendue.

Ce qui bloque le 2^ème cercle auquel je faisais référence, c’est d’imaginer la cathédrale. S’ils se représentaient une maison avec jardin, qui répond à un besoin métier précis, et qu’on peut ensuite agrandir, la perception des risques et des délais serait complètement différente !

Soulevons tout de suite le point qui fâche dans cette approche : si je suis itératif, le métamodèle sera incomplet. La règle d’or à s’imposer est alors de constituer le périmètre idéal. Cela implique de savoir trancher selon le rapport bénéfice/coût. La question est simple : à qui vais-je faire du bien dans l’entreprise ? Où se situe dans le métamodèle possible la data dont l’organisation fera l’usage le plus fréquent ?

La démarche est ainsi d’aller voir le collectif, en particulier ceux qui auront à remplir le métamodèle et identifier avec eux la valeur que peut leur apporter chaque nouveau périmètre ajouté. Tout est une question de balance entre effort d’alimentation et valeur apportée, en prenant en compte qu’il y a une population de consommateurs et de producteurs. L’idéal pour débuter est que les contributeurs soient aussi des consommateurs. Par ailleurs, il ne faut pas négliger l’importance de l’accompagnement au changement en expliquant les bénéfices apportés à l’organisation de disposer d’un référentiel d’architecture actualisé.

J’ai accompagné une entreprise où cette question était posée sur la table. Il y avait des petits outils, des vues éparses, mais pas de métamodèle. Les architectes produisaient 4 à 5 vues par jour chacun. Pour savoir où sont les pépites de valeur du futur métamodèle, nous avons regardé dans le rétroviseur, étudié les types de vues les plus produites et identifié les dénominateurs communs pour cadrer le périmètre du métamodèle.

Un gage de succès complémentaire est d’identifier les exigences clés par rapport aux outils de modélisation d’architecture sur plusieurs aspects.

• Le premier porte sur les capacités d’interfaçage, la capacité d’automatisation et d’interopérabilité afin de récupérer au maximum les données existantes et limiter l’effort d’actualisation du référentiel d’architecture.
• Le deuxième aspect repose sur la souplesse et la capacité de l’outil à répondre aux vues les plus utilisées. J’ai rencontré chez un client un outil sur lequel énormément d’énergie avait été investie. Cependant, la génération des vues était si peu paramétrable et flexible que les architectes n’arrivaient à créer qu’un quart des vues dont ils avaient besoin. Conséquence, ils ont continué à produire des vues de leur côté et tout était perdu !

Les vues d’architecture et leurs déclinaisons peuvent être très variées. L’outillage sélectionné doit être flexible dans sa capacité à générer de nouvelles vues.

Quels sont pour vous les déclencheurs de projets de modélisation du SI ?

Arthur :

Plusieurs déclencheurs sont possibles :

• Un changement de l’équipe de Management : CEO / CTO
• Le souhait de mettre en place une capacité d’architecture
• Les difficultés à assurer le MCO du SI
  • Erosion des compétences nécessaires à la maintenance et à l’exploitation
  • Accroissement de la complexité de l’architecture du SI
• Le besoin de gérer la dette et l’obsolescence du SI. L’entreprise sait que son socle est vieillissant sans en mesurer l’ampleur ni pouvoir construire un plan d’actions. Elle a besoin de faire un recensement complet et de disposer d’outils pour faciliter les prises de décisions.
• Le lancement d’un projet de transformation majeur
• Le besoin de maîtriser les données de son SI pour être en conformité réglementaire

Olivier :

Un cas récurrent est une dégradation notable dans la capacité à maintenir le système d’information en condition opérationnelle. Le nombre d’incidents explose, et l’organisation n’arrive plus à les traiter de manière correcte. A chaque changement, des éléments se détraquent et les régressions sont fréquentes alors que les délais des projets augmentent drastiquement. L’entreprise se rend compte qu’elle ne maîtrise plus son Système d’Information et ne peut plus assurer la qualité des évolutions.

Cela ne veut pas dire que la solution miraculeuse est de mettre en place un référentiel complet : il peut y avoir des étapes à franchir : organisation, personnes… Mais il faut dans tous les cas agir !

Pour conclure, quels sont les pièges à éviter et vos conseils pour entamer une démarche de référentiel d’architecture du système d’information ?

Olivier :

Mon premier conseil est de bien intégrer les trois drivers évoqués

• être progressif,
• embarquer les acteurs concernés
• Guider les décisions par une mesure du rapport valeur/effort.

Ensuite, le risque, c’est de s’arrêter en chemin au mauvais endroit : croire qu’une vue est autoporteuse, mettre en place un référentiel cathédrale et ne pas le maintenir…

Il est tout à fait possible de structurer un métamodèle partiel qui apporte de la valeur, mis à jour régulièrement et exploité. C’est déjà un pas énorme ! Parfois, il faut accepter qu’on puisse survivre sans outil : même sans super référentiel, si la connaissance est cristallisée et partagée, je peux aider mes architectes à structurer le fruit de leurs réflexions. 

Il vaut mieux des morceaux de connaissance correctement structurés qui ont une valeur ajoutée qu’un référentiel complet mal géré et obsolète !

Chez Projexion, nous sommes convaincus que ces gisements informationnels sont essentiels. Les entreprises ne peuvent pas négliger la maîtrise de leur SI. Notre collectif de consultants conseille et accompagne les organisations autour de cette démarche. Ce sont des projets complexes, et la complexité, c’est notre métier ! Grâce à nos nombreux retours d’expérience, nous savons comment l’aborder pour que cela apporte vraiment de la valeur. Nous avons vu de nombreux clients se frotter à ces sujets de référentiels d’architecture, et cela nous apporte le recul nécessaire pour cadrer la réflexion et aboutir aux meilleurs choix selon le contexte et la culture de l’entreprise.