Des systèmes de plus en plus compliqués…
…et une nécessité de contrôle de plus en plus poussé.
Les systèmes que nous observons, utilisons et essayons de transformer aujourd’hui sont les résultats de processus de construction par morceaux et par couches successives. Ces strates sont intimement liées à la variabilité des domaines :
- paradigmes de pensées différents (approches par les fonctions, les objets, les services, les événements, les systèmes, voire les agents…),
- métiers nouveaux, compétences en pleine évolution, et désynchronisation entre les deux,
- technologies différentes (langages pour lesquels on a arrêté de parler de génération, frameworks sophistiqués et souvent incompatibles entre eux…),
- déploiements sur des infrastructures différentes et des architectures de déploiement variées (CPU, machines, n-tiers, virtualisation, grid computing, cloud…),
- standards multiples (ouverts, propriétaires, de facto, stables ou en cours d’étude, normes internationales, best practices..),
- découpages organisationnels qui changent souvent, dans une recherche effrénée de l’organisation idéale,
- etc…
Les systèmes sont donc compliqués par ces approches multiples et imbriquées, en plus de représenter des réalités elles-même complexes. La course en avant, qui fait rage depuis 30 ans, s’accompagne de recherches de réductions des coûts, malgré ces changements incessants qui eux, entraînent une consommation de ressources pour simplement suivre les tendances (syndrome de la reine rouge),
Paradoxalement, dans ce contexte où garantie et contrôle devraient être en constante amélioration, les efforts de conception globale du système, les plans du système, la description de son architecture, sa documentation et celle de son fonctionnement, ont été progressivement éliminés des préoccupations des concepteurs et des DSI. Ainsi aujourd’hui, on se trouve avec des systèmes compliqués, faits d’une multitude de constituants (personnes, acteurs, rôles, fonctions, services, applications, projets, programmes, batches, IHM, processus, équipes, machines, réseaux…) pour lesquels nous n’avons ni inventaires fiables, ni descriptions des liens et dépendances.
La cartographie habituelle, une perte sèche
Pourtant, régulièrement, des objectifs de transformation du système impliquent de faire des bilans de ces informations manquantes pour calculer les impacts des modifications envisagées (financiers, certes, mais aussi organisationnels, stratégiques, voire simplement humains). Des inventaires sont donc constitués ponctuellement pour répondre à des questions contextuelles précises. Certaines sont simples et ne portent que sur des aspects très étroits du systèmes (Pouvons-nous éliminer les transferts de fichier FTP non sécurisés, et quels sont les impacts ?), d’autres concernent l’ensemble des préoccupations autour du système (Évolution multi-canal de tous les systèmes en liaison avec les clients). Les informations descriptives nécessaires sont collationnées en représentations ad hoc, en réponse à ces questions épidermiques : les cartographies. Seules les informations qui semblent pertinentes pour traiter du problème sont ainsi réunies, par un choix étroit des types de constituants analysés et du périmètre organisationnel : c’est le syndrome de la simplicité qui fait croire qu’une analyse réduite d’un problème complexe le rend simple.
Dans cette genèse réside le premier problème des cartographies : elles ne répondent qu’à la question posée, et leur coût ne peut guère être reporté sur d’autres utilisations qui en rendraient la constitution moins dispendieuse. Car ces bilans coûtent cher, c’est leur deuxième inconvénient : ils monopolisent des compétences multiples pour rechercher, trier, valider, représenter les données nécessaires. Ils prennent donc un temps fou, ce qui entraîne le troisième inconvénient : le bilan est obsolète avant même d’être terminé, c’est inéluctable. On parle de snapshot (instantané) pour montrer que la vie et les modifications du système se poursuivent après la période de collecte d’informations.
La conséquence de ces trois inconvénients est claire : contextuels, hyper-adaptés à une seule question, coûteux et obsolètes rapidement, ces bilans ne sont pas du tout ré-utilisables, ils correspondent à un investissement perdu qu’il faut renouveler pour chaque question. La maîtrise du système qu’ils semblent apporter n’est qu’apparente et même cette impression ne dure que très peu de temps.
La cartographie et ses données
Le domaine scientifique de la cartographie géographique nous donne des clefs sur la différence entre la carte et les données utilisées pour la produire. Une base de données cartographique ne contient pas des dessins, mais des informations factuelles sur des caractéristiques terrestres. Ces données ont une valeur sémantique forte en plus de leur valeur numérique. La carte est une exploitation possible de ces données, chaque carte exploitant certaines des valeurs sémantiques. Confondre la carte avec les données revient à n’avoir qu’une seule carte, donc un point de vue unique qui ne peut pas traiter des multiples préoccupations. De plus la carte est alors extraordinairement délicate à mettre à jour.
Dans nos disciplines comme en cartographie géographique, les mêmes données doivent permettre de constituer plusieurs représentations en fonction des préoccupations : cartes de niveaux, cartes routières, cartes topologiques ou cartes administratives deviennent ainsi cartes fonctionnelles, cartes applicatives, cartes des processus, cartes d’urbanisation, voire cartes technologiques et même cartes géographiques pour représenter les implantations physiques de salles machines.
Architecture et structure 