|
Cette tribune est le deuxième volet d'une série proposée par la SSII Dreamsoft (groupe SoluCom) autour des architectures orientée services (SOA).
Pourquoi cartographier ?
Dans le cadre d'un projet d'urbanisation, la cartographie est avant tout une photographie de l'existant informatique d'entreprise, le support d'une analyse initiale conduisant à la construction du système d'information urbanisé.
L'écart entre existant et cible urbanisée étant souvent considérable, la cartographie est également un véritable plan qui jalonne les progrès du système d'information sur sa trajectoire d'évolution.
| |
|
Cartographie et référentiel
|
| |
La cartographie du système d'information c'est :
 Un référentiel contenant les différents objets du système d'information (applications, fonctions, serveurs, etc.) et les associations qui les relient (mon application X automatise la fonction F et est hébergée par mon serveur Y),
Des représentations graphiques synthétiques illustrant ce référentiel.
Contrairement à certaines idées reçues, le projet de cartographie ne présente pas de difficulté méthodologique majeure :
"Je définis un méta-modèle" en choisissant les objets permettant de décrire le système d'information, leurs attributs, leurs associations,
"Je prépare l'inventaire" en déclinant le méta-modèle dans un format de collecte pratique (souvent par le biais de feuilles Excel),
"J'inventorie" avec les Maîtrises d'Ouvrage et les Maîtrises d'uvre,
"Je dessine" différentes vues de mon système d'information.
Malheureusement, cette simplicité de principe n'empêche pas les erreurs. La plus grossière et la plus fréquente consiste à négliger le référentiel et à passer directement à la représentation.
Un raccourci hâtif qui non seulement limite la richesse de la cartographie mais surtout, entraîne une gestion complexe et parfois douloureuse à l'échelle de tout un système d'information (plusieurs dizaines d'applications).
| |
|
Une cartographie, des cartographies
|
| |
La cartographie reprend la décomposition verticale de l'entreprise et du système d'information présentée dans le premier volet de notre série (lire l'article du 27/02/2006), tant du point de vue des objets inventoriés, que de celui des représentations.
Si chacune de ces représentations a une valeur particulière, elles s'accompagnent de risques tout aussi caractéristiques.
La cartographie des macro-processus
Il s'agit d'une description générale des métiers de l'entreprise. Indispensable dans le cadre d'une démarche Top-Down, elle facilite également la lecture des autres cartes par le "novice", en lui offrant un point d'ancrage "non-informatique".
Le piège serait d'oublier que le processus métier n'est pas un objet de système d'information et de vouloir le détailler à tout prix.
Comme nous le verrons dans le prochain volet de notre série, une modélisation détaillée des processus est nécessaire, mais se doit de participer à une démarche d'entreprise. Elle fournit de la matière à l'urbaniste comme elle en fournit au "risk manager", au responsable ISO, ou à d'autres...
La réduire à une démarche de DSI risquerait non seulement de froisser les autres acteurs de l'entreprise, mais aussi de complexifier inutilement la gestion du changement.
La cartographie fonctionnelle
Au cur de l'Urbanisation, elle représente les traitements d'information nécessaires à la réalisation des processus et garantit la conformité de l'applicatif aux besoins des métiers.
Le modèle le plus fréquent est celui du Plan d'Occupation des Sols (POS) qui identifie des zones fonctionnelles indépendantes (les référentiels, les échanges avec l'extérieur, etc.) et les détaille en quartiers et îlots.
L'écueil le plus fréquemment rencontré réside dans la difficulté à faire de la fonction un objet propre. Dans une approche Top-Down, elle est trop souvent un calque des processus, dans une approche Bottom-Up, un calque des applications.
La cartographie applicative
Elle liste les applications utilisées au sein de l'entreprise.
Indispensable dans le cadre d'une démarche Bottom-Up, elle est la cartographie la plus parlante théoriquement, puisqu'elle représente de manière unique ce qu'utilise le métier, ce que conçoit le maître d'ouvrage, et ce que développe le maître d'uvre.
La difficulté est ici de s'accorder sur la définition de l'application. Un maître d'uvre inclura par exemple certains outils de supervision, de sécurité, voire des plates-formes de développement et des solutions d'intégration.
Les cartographies techniques
Elles décrivent les infrastructures qui sous-tendent les applications (développement, hébergement, réseau & télécoms, etc.).
Le problème est que le socle technique d'une entreprise est trop vaste et multidimensionnel pour faire l'objet d'une seule représentation.
| |
|
La cartographie, outil de communication
|
| |
Parce qu'elles explicitent le patrimoine informatique de l'entreprise, les représentations graphiques représentent un formidable vecteur de communication pour une DSI, à condition de choisir le bon message.
Ce bon message doit démontrer la valeur ajoutée de la DSI (et de la démarche d'urbanisation) : "Voici les outils que nous mettons à la disposition des utilisateurs et qui répondent à leurs besoins".
Il doit donc être bâti autour de la cartographie applicative et de la cartographie des macro-processus, et non autour d'un plan d'occupation des sols.
Trop d'entreprises pensent aujourd'hui que la cartographie fonctionnelle est une fin en soi. Elle est avant tout un moyen, un outil d'urbaniste peu lisible par le reste de l'entreprise.
Dernière dérive : Vouloir à tout prix exposer un maximum d'information (notamment technique) dans les représentations graphiques. Elles sont une vision synthétique du référentiel du système d'information : augmenter le détail de ce qui est communiqué, c'est accroître le risque de désaccord et la difficulté de lecture.
Mariano Boni et Laurent Besset
|
Dossier