La plupart des équipes d’architecture se munissent d’un référentiel. En fonction du domaine d’intervention des architectes on retrouve des référentiels ayant pour objectif de répertorier différents types d’informations :

• relatives à l’architecture des différentes couches de l’entreprise, comme par exemple :
  • des objectifs et enjeux métiers
  • des processus métiers, des données métiers
  • des cartographies fonctionnelles
  • des applications et des flux de données inter-applicatives
  • des serveurs applicatifs, des réseaux, des capacités d’infrastructure
• relatives à la gouvernance de l’activité d’architecture, comme par exemple :
  • des décisions d’architecture
  • des backlogs de projets

Oui mais pourquoi faire ?

Sur la même logique qu’un projet, il est indispensable de s’interroger sur l’usage « métier » d’un tel référentiel. En effet le maintien et la mise à jour d’un référentiel d’architecture d’entreprise nécessitent un effort important.

Le référentiel d’entreprise est un moyen et non une fin en soit. Une équipe d’architecture qui serait accaparée à 80% par le maintien de son référentiel au détriment des activités d’architecture dont elle a la responsabilité manquerait à son objectif opérationnel.

Il est donc indispensable de s’interroger sur l’usage du référentiel et de ses données ainsi de le positionner comme un outil pour l’architecte : pour des analyses, des études d’impact, de la communication, de la cohérence avec d’autres équipes, de la connaissance d’un système complexe.

Peut-on s’en passer ?

Dans cette logique il peut parfois être tentant de s’en passer, voir de délaisser un référentiel existant inadapté et d’en abandonner la maintenance, découragé par l’effort nécessaire. Evidemment un référentiel non maintenu perd grandement de son utilité.

Mais dans ce cas comment collecter les données permettant la maitrise de l’entreprise ? Cela repose alors principalement sur les personnes et leurs connaissances ou alors sur une activité de collecte d’information « à la demande » lorsque le besoin s’en fait sentir.

Tout est alors question d’organisation et de criticité du système. Mais globalement il parait risqué de s’en passer totalement.

Mais alors où positionner le curseur ?

C’est LA question à se poser. Il faut dès le départ définir les données que l’on souhaite avoir à disposition pour assurer la maitrise global de l’entreprise et à contrario les données qui peuvent être captées à la demande sans nécessiter une perte d’énergie et d’efficacité trop importante.

La définition d’un méta-modèle pour les données structurées, d’une gestion documentaire, d’un gouvernance des documents et de leurs configurations, et finalement de tout élément intégrant le référentiel d’architecture sont des étapes préalables à ne pas sous-estimer.

Une bonne pratique serait de commencer par gérer des concepts simples et essentiels (par exemple une liste d’application et les domaines fonctionnels associés) à une maille moyenne. Rien n’empêchera d’affiner si le besoin s’en fait sentir. Etre trop ambitieux dès le départ induit le risque décrit précédemment : le découragement face à l’effort de mise à jour nécessaire.

Mais comme le promeut intelligemment CMMi dans ses pratiques génériques, pour qu’un processus fonctionne il est nécessaire de le piloter, de former les personnes concernées, de s’assurer de leur disponibilité pour le réaliser, de le contrôler et de reporter sur son résultat. N’oubliez pas que cela s’applique ici aussi ! Mais ceci est un sujet qui fera l’objet d’un autre article.

Et sous quel format gérer son référentiel d’architecture ?

Lorsque l’on parle de données gérées par le référentiel d’AE, cela ne présage pas du format dans lequel elles vont être gérées.

Vous pensiez outil de modélisation comme une évidence ? Rien n’est moins sur, car évidemment les outils de modélisation sont des outils puissants, mais ils permettent surtout la gestion de la donnée structurée. Qu’en est-il des slides ou autres représentation visuelles, des listes de décisions d’architecture, des objectifs stratégiques de l’entreprise ?

N’oubliez donc pas que les techniques de base de la gestion collaborative restent très efficaces : la gestion documentaire, les outils de gestion de contenu tels que les Wiki ou les forums sont des outils très complets pour gérer des informations qui peuvent bénéficier de la puissance de recherche par mots clés. Pour parler de référentiel il faut cependant les équiper de pratiques de gestion de configuration : de validation, de versionning, de diffusion, etc.

Jusqu’où peut aller un référentiel d’architecture d’entreprise ?

A vous de le définir en fonction des besoins de votre organisation ! Chaque cas est différent et le contexte, l’historique, l’organisation et l’ambition de l’entreprise sont des éléments à prendre en compte.

Voici ci-dessous un exemple de fonctions pouvant être réalisées par un référentiel d’architecture d’entreprise. Chaque organisation, quelque soit sa taille gagnera à s’équiper au bon niveau d’un référentiel d’architecture d’entreprise pour l’aider dans la maitrise de son existant et de ses transformations. Reste à trouver le votre !

Et oui car l’Architecture d’Entreprise est avant tout un outil pour SERVIR UN OBJECTIF MÉTIER.

L’Architecture d’Entreprise va permettre d’assurer une vision cohérente d’une solution sur les différents domaines architecturaux :

• Métier : L’organisation, les processus, les utilisateurs, etc.
• Système d’Information : Les fonctions applicatives à couvrir, les applications impactées (existantes ou à construire), les échanges de données entre les applications, la gestion des données de référence, les technologies ou solutions sur étagère (COTS) choisies, etc.
• Infrastructure : Les serveurs, le réseau, les flux, etc.

L’architecture obtenue n’a qu’un seul objectif : assurer que les objectifs métier seront atteints.

La première question à se poser est donc : « Quels objectifs métiers souhaite-t-on atteindre avec cette initiative ? ». Et de trouver la réponse là où se trouve la vraie valeur pour l’entreprise.

Prenons un exemple : si un acteur métier lance une initiative et demande à avoir une meilleure capacité d’analyse de son activité. D’accord, mais en quoi cela va apporter de la valeur à l’entreprise ? Est-ce que le fait d’avoir une meilleure connaissance de son activité va lui permettre in fine de fidéliser des clients, d’améliorer son image ? Si cela lui permet uniquement de gagner quelques heures de travail chaque semaine le retour sur investissement sera faible. Par contre si cela lui permet d’identifier des axes d’amélioration de sa chaine logistique, cela pourrait avoir un impact structurant sur les coûts de production.

La seconde question à se poser est alors : « Est-ce que les objectifs métiers concourent à l’atteinte des objectifs stratégiques de l’entreprise ? »

On peut citer quelques exemples courants d’objectifs métiers stratégiques :

• Diminuer le time-to-market (délai de mise sur le marché d’un nouveau produit ou service)
• Améliorer la rentabilité d’un produit
• Cibler de nouveaux clients
• Se développer sur un nouveau marché
• Fidéliser ses clients, améliorer son image de marque
• Diminuer les coûts de fonctionnement de l’entreprise

Il ne s’agit donc pas de se limiter à l’application d’une méthodologie ou d’un framework d’architecture, mais de se poser les bonnes questions pour fiabiliser l’alignement du Système d’Information avec le Métier, mais aussi et surtout avec la Stratégie de l’entreprise.

Contrairement aux idées reçues un architecte d’entreprise n’est pas un expert. AU CONTRAIRE !

Dans l’écosystème d’un projet de transformation l’architecte d’entreprise a la responsabilité d’assurer la cohérence globale de la solution. Pour cela il va falloir qu’il sache comprendre et se faire comprendre de personnes ayant des profils et des attentes très différentes :

• Le Top Management
  • Il définit la stratégie de l’entreprise et cela va driver les initiatives de transformation de l’entreprise.
  • L’architecte d’Entreprise peut être amené à restituer les conclusions de son étude directement au Top Management pour fiabiliser l’impact de la transformation à venir.
• Les acteurs métier
  • Ils sont idéalement les premiers sponsors de la transformation car ils attendent une plus-value concrète sur leur activité.
  • Ils possèdent une forte spécialisation et s’attendent à être compris rapidement. Leur métier leur parait évident et leurs modes de fonctionnement sont ancrés dans leurs habitudes. Il est nécessaire non seulement de les comprendre mais aussi de leur proposer de prendre du recul sur leur fonctionnement pour atteindre leurs objectifs.
  • Plusieurs métiers sont fréquemment impliqués dans un même projet de transformation. Le rôle de l’Architecte d’Entreprise dans ce contexte sera d’éviter de former des silos métiers en assurant une continuité globale des processus entre les différents métiers.
• Le directeur des systèmes d’information
  • Il a fréquemment des objectifs de rationalisation de son SI et des coûts associés.
  • Il a une préférence stratégique entre les solutions développées en spécifiques pour son entreprise ou des produits sur étagère (COTS) – buy or make.
• Les chefs de projet du système d’information
  • Ils ont un projet à délivrer et souhaitent donc limiter sa complexité et les adhérences de leur projet avec des contraintes « extérieures ». Ils vont donc avoir tendance à vouloir maîtriser toutes les composantes du projet, indépendamment de la logique fonctionnelle de la transformation.
  • Leurs préoccupations sont concrètes et immédiates : respect couts/planning.
• Les intégrateurs
  • Ils peuvent avoir tendance à survendre leur technicité pour s’assurer d’une implication maximale dans le projet.
  • Ils doivent comprendre, partager et appliquer des orientations d’architecture définis par l’Architecte d’Entreprise.
• Les éditeurs
  • Ils tentent de démontrer la couverture de leur solution, en minimisant parfois les écarts par rapport au besoin métier.
• Les architectes techniques, ou responsables de l’infrastructure technique qui hébergent le système d’information
  • Ils mettent à disposition les environnements adaptés en suivant les consignes de rationalisation et de mutualisation définies par leur management
• Les responsables de la sécurité
  • Ils sont en charge d’assurer la sécurité des données de l’entreprise

L’Architecte d’Entreprise devra donc démontrer une forte capacité d’intégration pour parler le langage de chacune de ces personnes et de persuasion pour leur démontrer que les orientations proposées sont les plus avantageuses globalement.

Il devra être polyvalent, en étant en capacité d’appréhender efficacement le métier concerné, l’organisation et les modes de fonctionnement de l’entreprise, mais également de parler avec des experts comme des architectes techniques ou des éditeurs.