Ce premier article de la série est dédié à l’explication du rôle de l’Architecture d’Entreprise sur les projets. Le second volet à paraître se concentrera sur les facteurs clés de succès de ces approches ainsi que les convictions d’enioka pour réussir.
Connaissance vs. compréhension
Dans le cadre des projets informatiques, des centaines d’actifs sont produits, allant des spécifications au code, en passant par les tests et la documentation. Cependant, ces informations peuvent rapidement se transformer en un enchevêtrement complexe de données qui s’accumulent au fil du temps, deviennent difficiles à naviguer, hétérogènes en termes d’apparence ou de contenu. Elles sont de plus souvent pas maintenues. Finalement, ces informations sont considérées comme obsolètes et finissent par être perdues.
Dans la vue ci-dessus du complexe d’affaires de La Défense, on distingue les routes, les bâtiments, les espaces piétons, les ponts, les infrastructures ferroviaires… À l’intérieur même d’un bâtiment, on trouve des étages, des systèmes de ventilation, des ascenseurs, des circuits électriques, de la plomberie, des fenêtres… L’esprit humain ne peut appréhender une infrastructure aussi complexe sans recourir à des vues simplifiées qui mettent l’accent sur certains aspects des composants et de leurs interfaces. Si vous avez un projet de piste cyclable reliant deux bâtiments, vous devez faire abstraction de leur intérieur tout en conservant les informations sur leurs interfaces avec l’infrastructure routière.
De la même manière, l’art de la modélisation de l’Architecture d’Entreprise consiste à créer et maintenir des abstractions permettant d’analyser les actifs informatiques et de les relier de manière compréhensible. À partir des connaissances sur la composition physique d’un système d’information, nous créons un modèle qui aide à comprendre son fonctionnement et les interdépendances entre ses composants.
L’objectif d’un modèle n’est pas de représenter fidèlement 100 % de la réalité, mais plutôt de sélectionner et de mettre en valeur certaines informations parmi tous les détails disponibles afin de produire une restitution utile à un objectif donné. Les cartes sont des outils de communication visuelle qui simplifient encore davantage le modèle en vues exploitables et faciles à comprendre. Dans la représentation ci-dessus, la même zone de La Défense est représentée différemment selon qu’elle est destinée à la navigation piétonne (partie gauche de l’image, extraite du site web de La Défense) ou à l’usage automobile (partie droite de l’image, extraite de la cartographie IGN issue de Geoportal). Certains éléments sont volontairement agrandis par rapport à leur échelle normale, car ce sont des repères facilitant l’orientation et la navigation dans l’espace.
Les modèles sont des outils permettant de comprendre une réalité complexe. Une même modélisation peut être restituée sous plusieurs formes en fonction des objectifs poursuivis. Garder ces objectifs en tête est essentiel lors de la création d’un modèle d’architecture d’entreprise afin de sélectionner les bons détails. Cela évite de gaspiller des efforts à modéliser des éléments non pertinents. Enfin, les représentations doivent être aussi intuitives que possible pour que les utilisateurs puissent les exploiter sans avoir besoin d’apprendre d’abord à lire le modèle. Lisez-vous la légende avant de regarder une carte ?
Travailler avec des abstractions
Les concepts de modélisation ne sont pas toujours naturellement équivalents à un actif physique dans le monde réel. Comme nous travaillons à une échelle spécifique et cherchons à masquer le fonctionnement interne d’une infrastructure complexe, nous regroupons des actifs sous un concept abstrait qui dissimule les détails les plus fins et crée des interfaces à ses frontières avec d’autres parties de l’infrastructure.
Qu’est-ce qu’un quartier, une ville, une région ? Les limites administratives suivent parfois une frontière naturelle, mais elles résultent souvent d’une décision humaine visant à diviser un territoire en zones plus petites et plus faciles à gérer. Ces différentes échelles d’abstraction permettent de répartir le travail et de spécialiser les administrations locales selon différents niveaux de responsabilité.
De la même manière, la modélisation de l’architecture d’entreprise permet de diviser un système d’information en sous-systèmes plus petits et gérables à différentes échelles, avec des équipes dédiées à chaque périmètre et responsables du maintien d’interfaces stables avec les autres systèmes. Le modèle reflète l’organisation actuelle ou souhaitée du système d’information.
Un bon modèle est celui dont les abstractions maximisent l’autonomie locale et minimisent les interdépendances entre les équipes.
En 1976, le statisticien britannique George Box a écrit la célèbre phrase : « Tous les modèles sont faux, mais certains sont utiles ». Cette citation illustre parfaitement notre approche dans la définition et l’utilisation des modèles d’architecture IT.
Le but de la modélisation appliquée à l’Architecture d’Entreprise
Le premier objectif d’une démarche de modélisation de l’architecture d’entreprise est de consolider et capitaliser la connaissance du système d’information afin de mieux le comprendre. En intégrant les évolutions futures dans le modèle, celui-ci permet ensuite aux entreprises d’analyser et de gérer l’impact de leurs projets. Enfin, il peut être utilisé comme un outil puissant pour mener des analyses systémiques sur l’ensemble du système IT et aider à élaborer une stratégie de transformation fondée sur divers critères.
Voici une proposition de grille de maturité de la modélisation de l’Architecture d’Entreprise (EAM – Entreprise Architecture Modeling) :
Faible niveau de maturité : Naviguer dans la connaissance
- Créer et maintenir des cartes d’ensemble avec un niveau d’information cohérent
- Aider à l’intégration des nouveaux arrivants en leur offrant une compréhension globale du fonctionnement du système
- Répondre aux besoins d’audit et de conformité
- Fournir des points d’entrée vers une documentation plus détaillée ou spécifique
Niveau de maturité intermédiaire : Gérer les impacts projets
- Anticiper en toute confiance les coûts, la planification et les effets secondaires d’un projet en comprenant comment il s’insère dans un macro-système existant
- Communiquer facilement avec les parties impactées en définissant clairement les interfaces et en utilisant un langage commun
Haut niveau de maturité : Alimenter la stratégie IT de l’entreprise
- Analyser les actifs informatiques selon différents critères et identifier les projets nécessaires
- Aider à arbitrer l’allocation des ressources en fonction de différentes priorités (obsolescence, satisfaction des utilisateurs, vulnérabilités…)
Comme ces objectifs se construisent les uns sur les autres pour atteindre les bénéfices les plus ambitieux de la modélisation de l’Architecture d’Entreprise, une connaissance approfondie et solide des actifs informatiques est indispensable afin d’ajouter de nouvelles dimensions d’analyse au modèle.
