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 !