Pourquoi les principes d’architecture restent bien souvent lettre morte, bien qu’ils soient pertinents et reflètent les orientations que l’on souhaite donner au SI ?
Lorsque l’on s’interroge sur les causes sous-jacentes à ce constat, on se rend rapidement compte qu’il manque souvent un aspect concret pour permettre aux équipes de conception et de développement de les mettre en œuvre.
En effet, qu’implique concrètement l’application d’un principe qui dit que « Les données sont des actifs » ?
Que doivent faire un chef de projet Peoplesoft et un développeur Ruby pour appliquer ce principe ?
A quoi servent ces principes et comment les exploiter sur un plan opérationnel ?
La hiérarchie des principes
En premier lieu, il nous semble important de classer les principes dont nous parlons. Car tous ne sont pas de même niveau et n’ont donc pas le même usage. Le modèle ci-dessous propose une hiérarchie des principes d’architecture :
Les principes de gouvernance
Le premier bloc regroupe les principes métier. Il s’agit des principes directeurs de l’architecture d’entreprises, ceux qui déclinent directement des normes de régulation, de la stratégie métier et IS/IT qui en découle.
Sur ce bloc vient s’attacher le deuxième niveau qui pose le cadre d’architecture adopté par l’organisation (Architecture framework de type TOGAF, Zachmann ou autre), ainsi que les règles d’urbanisation propres au SI.
Ces deux premiers blocs jouent un rôle dans la gouvernance de l’architecture d’entreprise : ils servent à la prise de décision. Ils vont permettre d’évaluer la conformité des solutions proposées en phase d’analyse de besoin ou de cadrage lors des Quality Gates appropriés (Comité d’engagement, comité d’architecture, Comité de pilotage etc …). A ce titre, en amont, ils constituent également un excellent outil de communication entre la DSI et les lignes métier afin de partager un référentiel de travail commun sur une base formelle.
Les règles d’application
Afin de garantir l’application des principes d’architecture, pour les deux autres blocs inférieurs, il faut s’appliquer à les décliner de façon opérationnelle dans le contexte technique du SI. Ceci permet de donner des indications claires aux différents acteurs en charge de la réalisation des projets.
À partir des principes il faut d’abord décliner des règles de conception. Les règles de conception définissent les orientations pour le design des solutions. Elles peuvent par exemple imposer l’usage d’un système de gestion d’authentification centralisé (SSO), la traçabilité systématique de toutes les opérations CRUD, l’utilisation de protocoles chiffrés dans les échanges inter-applicatifs. Ces règles orientent donc le « comment » de l’implémentation mais restent à un niveau logique.
Pour appliquer factuellement ces règles, elles sont déclinées en règle d’implémentation. Ces règles sont destinées aux développeurs et leur donnent des indications concrètes sur la façon de concevoir le code dans leur outil de développement. Les règles d’implémentation désignent par exemple le framework à utiliser pour accéder au SSO, les instructions utilisées pour tracer les instructions CRUD dans le SGBD, les certificats utilisés (notamment versions de TLS) pour la sécurisation des échanges.
Ces règles d’implémentation sont spécifiques au langage ou à l’univers technologique dans lequel elles doivent être appliquées. Elles fournissent aussi des liens vers les patterns d’implémentation : le code du framework dans le gestionnaire de source, des exemples de codes issus de projets existants et des forums doivent permettre de discuter les usages de ces patterns.
Explications par l’exemple
Dans le schéma ci-dessous, on représente l’enchainement des principes liés au principe directeur « l’information est un actif de l’entreprise » :
Cette déclinaison des principes d’architecture jusqu’aux règles d’implémentation permet de collaborer avec les leaders techniques. Cela facilite la promotion des meilleures pratiques et facilite la réutilisation des frameworks ou services qui sont instanciés dans l’entreprise. Elles facilitent aussi la réception des développements réalisés par des tiers en fournissant des points auditables dans le code pour valider la conformité avec le cadre technique.
En conclusion, nous réfutons catégoriquement la croyance, trop largement véhiculée, selon laquelle l’élaboration des principes d’architecture n’est qu’une théorie abstraite et éloignée des réalités du « terrain ». Il faut retenir que les principes ne sont pas là pour n’être que de « beaux principes », mais qu’il s’agit véritablement d’une façon de réaliser l’architecture dans le code des applications.
Co-écrit par Stéphane DEGOIS et Gilles WAGENER associés ARCHR