Cinq étages pour qu'un train parte à l'heure
Sur Le Chemin de fer, un train qui part à l'heure est le résultat de cinq étages de décision qui ne se commandent pas les uns les autres. Le ministère fixe la politique de transport et signe les conventions de financement. Le régulateur garantit que chaque exploitant accède au réseau aux mêmes conditions. L'autorité de sécurité homologue le matériel et les lignes. Le gestionnaire d'infrastructure entretient la voie et attribue les sillons. Les exploitants, enfin, font rouler leurs trains dans ce cadre.
Aucun de ces étages ne pose un rail. Tous décident de ce qu'on a le droit de poser, de qui le vérifie, et de qui rend des comptes quand ça dérape.
L'architecture d'entreprise vit dans la même pile. Au-dessus d'elle, la gouvernance de l'entreprise. En dessous, les projets qui livrent. Entre les deux, une pratique que TOGAF appelle la gouvernance d'architecture, avec un organe (le conseil d'architecture), un rituel (la revue de conformité) et une organisation qui porte tout cela (la capacité d'architecture).
Ce billet descend cette pile étage par étage. D'abord ce qu'est une gouvernance et où se place celle de l'architecture. Puis pourquoi, quoi et comment gouverner, avec le dépôt qui en garde la trace. Ensuite le conseil, ses responsabilités et ses droits de décision. La conformité et ses six degrés. Pour finir, la capacité d'architecture, ses quatre finalités, et la manière de la bâtir avec l'ADM lui-même.
Gouverner une architecture, ce n'est pas la dessiner. C'est décider qui a le droit de la changer, vérifier que ce qui se livre lui ressemble, et pouvoir dire après coup qui a tranché.
La gouvernance, de l'entreprise à l'architecture
Le ministère ne conduit aucun train. Il fixe un cap, délègue, contrôle et demande des comptes. C'est la définition la plus courte de la gouvernance : diriger et contrôler sans faire soi-même.
Trois mots, trois périmètres
ISO/IEC 38500, la norme de gouvernance des technologies de l'information, décrit la gouvernance comme une boucle : évaluer, orienter, surveiller. Ce que la série en retient tient en quatre traits. Des décisions prises au bon niveau de la hiérarchie, et assumées à ce niveau. Une direction qui s'accompagne d'un contrôle. Un traitement équitable des préoccupations de toutes les parties, et de la transparence sur ce qui a été décidé. Des comportements pilotés par des mesures plutôt que par des injonctions.
Quatre questions résument l'exercice : pourquoi gouverner, quoi, quand et comment.
La gouvernance d'entreprise est le premier étage. Les principes publiés par l'OCDE la décrivent comme l'ensemble des relations entre la direction, le conseil d'administration, les actionnaires et les autres parties prenantes, et comme la structure par laquelle on fixe les objectifs puis on en surveille l'atteinte.
La gouvernance d'architecture est un étage plus bas. TOGAF la définit comme la pratique par laquelle les architectures d'entreprise, et les autres architectures, sont gérées et contrôlées à l'échelle de l'entreprise. Elle hérite des règles de l'étage supérieur. Elle ne les réinvente pas.
Une pile emboîtée
Dans une grande organisation, cette pile compte au moins cinq niveaux : la gouvernance corporate, celle de l'architecture d'entreprise, celle de l'architecture métier, celle des architectures de domaine (données, applications, technologie) et celle de l'implémentation. La gouvernance de la sécurité et du risque les traverse tous, parce qu'un risque accepté au niveau d'un projet engage l'entreprise entière.
Chaque niveau existe aussi à plusieurs échelles géographiques : global, régional, local. Une direction régionale peut avoir son propre conseil d'architecture, tant que ses décisions restent dans le cadre fixé au-dessus d'elle.
La gouvernance d'architecture n'a pas d'autorité propre. Elle emprunte la sienne à la gouvernance d'entreprise, et la rend aux projets sous forme de contrats et de revues.
Pourquoi gouverner, quoi gouverner, comment
Le cahier des charges d'une étude de ligne dit ce qu'on attend du bureau d'études. La convention de financement dit ce que la région attend du constructeur. L'homologation vérifie que ce qui a été construit correspond à ce qui a été promis. Trois documents, trois moments de contrôle.
Pourquoi. Sans contrôle, il n'y a aucune raison de développer une architecture cible. Si personne ne vérifie que les projets la respectent, la cible reste un dessin, et l'entreprise paie des architectes pour produire des dessins.
Quoi. On gouverne deux choses : le développement de l'architecture cible elle-même, et tous les changements qui entrent dans sa portée. Un projet qui touche un domaine couvert par la cible est dans le champ, qu'il le veuille ou non.
Comment. Les architectes et les implémenteurs sont dirigés et contrôlés par les parties prenantes. Pour le projet d'architecture, l'instrument est l'énoncé des travaux d'architecture, complété par la liste de contrôle de la cible. Pour le projet d'implémentation, ce sont le contrat d'architecture et la spécification des exigences.
Le dépôt de gouvernance
Le registre de l'infrastructure ferroviaire ne contient pas que des plans. Il garde aussi les décisions d'homologation, les dérogations accordées et leurs dates d'échéance. Le dépôt de gouvernance joue ce rôle pour l'architecture. TOGAF y range trois familles d'information.
| Famille | Ce qu'elle contient | À quoi elle sert |
|---|---|---|
| Données de référence | Procédures, guides, standards adoptés, cadres externes (ITIL, COBIT) | Guider les projets pendant l'implémentation |
| Statut des processus | Demandes de conformité en cours, demandes de dispense, évaluations ouvertes | Savoir où en est chaque dossier |
| Informations d'audit | Actions terminées, décisions et leurs responsables, précédents | Rendre des comptes, et juger les cas suivants à l'aune des anciens |
La troisième famille est celle qu'on néglige. Sans elle, chaque dispense se discute comme si c'était la première, et personne ne peut dire pourquoi une exception accordée il y a deux ans ne s'applique pas aujourd'hui.
Six bénéfices hérités de la gouvernance d'entreprise
TOGAF prête à la gouvernance d'architecture six caractéristiques venues tout droit de la gouvernance d'entreprise. Elles servent de test : une gouvernance à qui il en manque une n'en est pas une.
Le dépôt de gouvernance vaut par sa troisième famille : les décisions passées, avec le nom de ceux qui les ont prises. C'est ce qui transforme une suite d'exceptions en jurisprudence.
Le conseil d'architecture
Le comité des investissements de l'autorité d'infrastructure ne trace pas les lignes. Il examine les dossiers que la planification lui soumet, arbitre entre deux tracés, refuse un budget ou accorde un délai. Le conseil d'architecture est son équivalent.
TOGAF le décrit comme un groupe d'exécutifs responsable de la revue et de la maintenance de l'architecture, et de la surveillance de la stratégie quand le cycle entre en phase H. Il doit avoir des responsabilités et des capacités de décision identifiées, et des limites d'autorité écrites. Un conseil dont on ne sait pas ce qu'il n'a pas le droit de décider finit par ne rien décider.
Sa composition suit la pile vue plus haut : des représentants globaux et des représentants locaux, pour un périmètre qui peut être l'entreprise entière, une région ou une ligne métier. En pratique, un conseil de cinq à dix membres fonctionne. Au-delà, il devient une assemblée.
Trois familles de responsabilités
| Famille | Responsabilités |
|---|---|
| Générales | Faire progresser la maturité de la discipline ; garantir la cohérence entre sous-architectures ; faire appliquer la conformité ; fixer des cibles de réutilisation ; maintenir la flexibilité de l'architecture face aux besoins métier et aux technologies nouvelles ; offrir une voie d'escalade visible pour les décisions hors cadre |
| Opérationnelles | Surveiller et contrôler les contrats d'architecture ; se réunir à cadence régulière ; veiller à une implémentation cohérente ; arbitrer les ambiguïtés et les conflits escaladés ; accorder des dispenses compatibles avec la stratégie ; recommander des changements de politique (calendrier, ressources, technologie) ; publier l'information sous contrôle ; valider les niveaux de service et les économies rapportés |
| De gouvernance | Produire un matériel de gouvernance utilisable ; offrir un mécanisme d'acceptation formelle de l'architecture par consensus et publication autorisée ; fournir le contrôle fondamental de l'implémentation ; maintenir le lien entre implémentation, stratégie d'architecture et objectifs de l'entreprise ; repérer les écarts et planifier le réalignement, par dispense ou par mise à jour de la politique |
Les droits de décision
Un conseil qui décide de tout bloque tout. La répartition qui tient est celle-ci : le conseil possède le processus et formule les recommandations ; les parties prenantes décident de la cible, des délais et de son application.
Concrètement, le conseil dit « ce projet s'écarte de la cible sur ces trois points, voici ce que nous recommandons ». Le sponsor répond « on réaligne », ou bien « on accepte l'écart et on en porte le risque ». Les deux réponses sont légitimes. Ce qui ne l'est pas, c'est l'écart que personne n'a nommé.
C'est la même logique que pour les principes d'architecture : rédigés par les architectes, approuvés par le conseil, portés par la direction.
Les listes de contrôle en arbre de décision
Les listes de contrôle de conformité de TOGAF couvrent le matériel et les systèmes d'exploitation, les services logiciels et le middleware, les applications, la gestion de l'information, la sécurité, l'administration des systèmes, les méthodes et outils d'ingénierie. Le conseil ne les lit pas ligne à ligne en séance. Il s'en sert comme d'un arbre de décision, et chaque feuille de l'arbre finit dans le dépôt.
Le conseil possède le processus, pas la cible. Il recommande, trace et escalade ; ce sont les parties prenantes qui décident de la cible, des délais et de ce qu'on fait des écarts.
La conformité d'architecture
Aucun tronçon n'ouvre au service commercial sans homologation. L'autorité de sécurité ne refait pas les études : elle vérifie que ce qui a été construit correspond à ce qui a été autorisé. La revue de conformité d'architecture fait exactement cela pour un projet.
Deux fonctions se partagent le travail. La fonction architecture prépare les architectures de projet, et peut participer aux choix technologiques et aux achats, pour que la conformité soit construite plutôt que constatée. La gouvernance d'entreprise et IT, elle, définit une revue formelle de conformité des projets, avec ses jalons, ses listes de contrôle et ses suites.
Pourquoi une revue, et quand
Une revue de conformité sert d'abord à attraper les erreurs tôt, quand elles se corrigent encore à peu de frais. Elle sert aussi à repérer les standards qui méritent d'être modifiés, les services propres à une application qui pourraient devenir partagés, et les écarts à signaler aux fournisseurs.
Le bon moment est celui où le projet a un concept de solution mais pas encore de contrats signés. Assez tard pour qu'il y ait quelque chose à examiner, assez tôt pour qu'un refus coûte peu.
Six degrés de conformité
« Conforme » cache six situations distinctes. TOGAF les nomme pour que le verdict d'une revue soit sans ambiguïté. Je garde les termes anglais entre parenthèses, parce que le français n'a qu'un mot là où le standard en a deux.
| Degré | Ce que l'implémentation fait de la spécification | Verdict |
|---|---|---|
| Sans rapport (irrelevant) | Aucune caractéristique commune avec la spécification | La question ne se pose pas |
| Cohérente (consistent) | Quelques caractéristiques communes, implémentées comme prévu ; d'autres manquent, et l'implémentation ajoute des éléments hors spécification | Acceptable, écarts à documenter |
| Respectueuse (compliant) | Tout ce qui est implémenté figure dans la spécification et la respecte, mais une partie de la spécification n'est pas implémentée | Acceptable, reste à planifier |
| Conforme (conformant) | Toute la spécification est implémentée comme prévu, mais l'implémentation ajoute des éléments hors spécification | Acceptable, ajouts à justifier |
| Pleinement conforme (fully conformant) | Correspondance totale entre spécification et implémentation | Acceptation formelle |
| Non conforme (non-conformant) | Au moins une caractéristique de la spécification est implémentée autrement que prévu | Dispense ou réalignement |
Si tu ne retiens qu'une ligne du tableau, retiens la dernière. C'est la seule qui déclenche une action obligatoire. Les quatre du milieu disent toutes la même chose : acceptable, mais note l'écart au dépôt.
Une revue de conformité sert à nommer précisément l'écart, à l'écrire, et à décider qui en porte le risque. Refuser n'en est qu'une issue parmi d'autres.
La capacité d'architecture
L'autorité d'infrastructure a une direction de la planification : des gens, des rôles, un budget, des méthodes, des archives. Personne ne la considère comme un projet. C'est une unité opérationnelle qu'on gère comme les autres. La capacité d'architecture est cette direction, côté entreprise.
TOGAF la décrit comme une capacité métier à part entière, avec ses structures (conseil, bureau d'architecture, équipes de domaine), ses rôles et compétences, ses processus. Elle se gère comme toute unité opérationnelle, avec les capacités de gestion que cela suppose : finance, risque, performance, fournisseurs, services, communication, ressources, qualité, configuration, environnement.
Quatre finalités
Le schéma national, le corridor régional, la ligne : trois cartes, trois horizons, trois niveaux de détail. La capacité d'architecture sert quatre finalités qui suivent la même pente, du plus large au plus détaillé.
| Finalité | Portée | Détail | Horizon |
|---|---|---|---|
| Soutenir la stratégie | Large ou étroite, selon la question posée | Faible : cibles et feuilles de route | Trois à dix ans |
| Soutenir le portefeuille | Un sujet (un segment, un programme) | Faible, mais des contraintes détaillées pour les projets | Deux à cinq ans |
| Soutenir les projets | Étroite : un projet | Détaillé, plus de contraintes que de guidance | Moins de deux ans |
| Soutenir la livraison de solution | Un projet, une solution | Le plus détaillé, jusqu'au physique | Moins de deux ans |
Une même capacité peut servir les quatre, mais pas avec les mêmes personnes ni les mêmes livrables. L'architecte qui écrit la feuille de route à dix ans et celui qui tranche un choix de middleware ne regardent pas la même carte.
Construire la capacité avec l'ADM
Une ligne s'étudie en plusieurs passes, de l'esquisse au détail. La capacité d'architecture se construit de la même manière, et avec le même outil : l'ADM appliqué à lui-même, comme à n'importe quelle autre capacité métier.
| Ce qu'on définit | Phase de l'ADM | Ce que ça produit |
|---|---|---|
| Le contexte | B, partielle, au niveau stratégique | Où se place l'architecture dans l'entreprise |
| Les objectifs | A, au niveau capacité | Ce que la capacité doit livrer, et pour qui |
| La gouvernance | B, aux niveaux segment et capacité | Conseil, droits de décision, revues |
| L'alignement avec les autres cadres | B et C | L'articulation avec la gestion de portefeuille, de projet et des opérations |
| Le content framework et le métamodèle | C | Ce que le dépôt contient, et comment c'est typé |
| Le modèle d'organisation | B | Structures, rôles, compétences |
| Le modèle de processus | B, C, D | L'ADM adapté, les procédures de gouvernance, l'outillage |
| La feuille de route | E | Les incréments de la capacité |
| L'établissement | F et G | Le plan, puis la mise en place gouvernée |
Le détour peut paraître théorique. Il a un mérite concret : la capacité d'architecture subit la même gouvernance que ce qu'elle gouverne. Elle a une cible, des écarts, des revues.
Ce que la capacité rapporte
Les bénéfices, tels que TOGAF les liste, sont ceux d'une gouvernance qui fonctionne. Une redevabilité plus transparente et une délégation d'autorité informée. Une visibilité qui sert les processus internes autant que les demandes externes. De la valeur créée pour l'entreprise et ses actionnaires par la mesure et le retour d'information. La réutilisation de processus, de concepts et de composants. Une gestion proactive des risques. Et la protection du patrimoine existant, par la réutilisation de ce qui est déjà là.
La capacité d'architecture est une capacité métier comme les autres : on la dote, on la mesure, on la gouverne. Et on la construit avec l'ADM, ce qui est la meilleure preuve que la méthode tient.
Scénario B : le GAO mesure la capacité d'architecture des agences fédérales
Un régulateur qui inspecte les gestionnaires d'infrastructure avec la même grille, année après année, et publie ce qu'il trouve : voilà le seul emprunt que je fais au Chemin de fer ici. Le reste est un cas réel, sans aucun rail.
Le Government Accountability Office (GAO) est l'organe d'audit du Congrès américain. Depuis le Clinger-Cohen Act de 1996, les grandes agences fédérales doivent tenir une architecture de leurs systèmes d'information, que la circulaire A-130 de l'OMB nomme architecture d'entreprise, et le GAO vérifie régulièrement qu'elles le font sérieusement. Pour cela, il a construit son propre instrument : l'Enterprise Architecture Management Maturity Framework (EAMMF).
Le cadre
La première version date de 2002, suivie d'une version 1.1 en avril 2003. La version 2.0, publiée en août 2010 sous la référence GAO-10-846G, est celle qui sert encore de référence. Elle s'appuie sur les versions précédentes, sur les travaux du Federal CIO Council et sur les commentaires des agences et d'experts du domaine.
Le cadre décrit sept stades de maturité, numérotés de 0 à 6, depuis le stade où l'organisation prend conscience de l'architecture d'entreprise jusqu'à celui où elle l'améliore en continu pour optimiser l'ensemble de ses activités. À chaque stade correspondent des éléments fondamentaux (core elements), répartis en quatre familles : gouvernance, contenu, usage, mesure. Une agence atteint un stade quand elle satisfait pleinement tous les éléments de ce stade et des stades inférieurs.
Le document est explicitement conçu pour deux usages : l'audit externe par le GAO, et l'auto-évaluation par les agences elles-mêmes. C'est un modèle de maturité, du type que TOGAF recommande d'adopter dans son chapitre sur les modèles de maturité d'architecture, lequel prend pour exemple l'ACMM du Department of Commerce.
Ce que le GAO a trouvé
Le GAO a appliqué son cadre aux grandes agences fédérales à plusieurs reprises et a publié les résultats. Son rapport GAO-06-831 d'août 2006, Enterprise Architecture: Leadership Remains Key to Establishing and Leveraging Architectures for Organizational Transformation, évalue vingt-sept ministères et agences avec la version 1.1 du cadre, en cinq stades : sept seulement avaient dépassé le stade initial, et aucun n'avait satisfait tous les éléments des stades quatre et cinq. Bureau de programme et architecte en chef existaient pourtant dans plus de neuf agences sur dix. L'élément de gouvernance qui manquait le plus souvent était un comité représentant toute l'entreprise pour diriger, superviser et approuver l'architecture, en place chez 57 % d'entre elles seulement. Les éléments les moins satisfaits étaient ceux de l'usage et de la mesure de l'architecture.
Deux constats reviennent d'un rapport à l'autre, et ce sont ceux de ce billet. Le premier : une architecture sans gouvernance active ne progresse pas, quel que soit le volume de documents produits. Le Department of Commerce satisfaisait 87 % des éléments du cadre et restait classé au stade 1, parce que son comité d'approbation ne représentait pas toute l'entreprise. Le second : presque personne ne mesure la valeur que l'architecture produit. Le rapport GAO-12-791 de septembre 2012, Organizational Transformation: Enterprise Architecture Value Needs to Be Measured and Reported, lui est entièrement consacré. La plupart des agences n'avaient pas d'approche établie pour mesurer et rapporter les résultats de leur architecture, et le GAO recommandait d'en faire une exigence.
Ce qui rend le cas précieux pour nous : c'est une capacité d'architecture évaluée de l'extérieur, avec une grille publique, par un auditeur qui n'a aucun intérêt dans le résultat. Peu d'entreprises s'offrent ce regard. Celles qui le font découvrent en général la même chose que le GAO. Les livrables et les postes existent. Le comité qui engage toute l'entreprise, et la mesure de ce que l'architecture rapporte, manquent.
La capacité d'architecture se mesure de l'extérieur, avec une grille publique. Quand le GAO l'a fait, les lacunes récurrentes n'étaient pas dans les livrables : elles étaient dans l'instance qui engage toute l'entreprise et dans la mesure de la valeur.
Points clés
- La gouvernance d'architecture n'a pas d'autorité propre : elle l'emprunte à la gouvernance d'entreprise et la rend aux projets sous forme de contrats, de revues et de dispenses.
- Le conseil d'architecture possède le processus et les recommandations ; les parties prenantes décident de la cible, des délais et du traitement des écarts.
- Une revue de conformité situe l'écart parmi six degrés, l'écrit au dépôt et désigne qui en porte le risque.
- La capacité d'architecture est une capacité métier, avec ses structures, ses rôles, ses processus et ses capacités de gestion ; elle sert quatre finalités, de la stratégie à dix ans à la livraison d'une solution.
- On construit la capacité avec l'ADM lui-même, et on la fait mesurer de l'extérieur : chez les agences fédérales, le GAO a trouvé les lacunes récurrentes dans l'instance de gouvernance qui engage toute l'entreprise et dans la mesure de la valeur.
Dans la série
Palier 3 : Faire rouler les trains. Domaine : Pilotage.
- Précédent : Le référentiel d'architecture : métamodèle, dépôt, continuum
- Suivant : Lexique TOGAF : les termes de l'architecture d'entreprise
- Vue d'ensemble : Architecture d'entreprise : par où commencer
Pour aller plus loin
- Phase préliminaire : la capacité d'architecture et ses principes : la capacité au moment où on la crée, avant le premier cycle.
- Phase G : contrats d'architecture, conformité et équipes agiles : la conformité vue depuis le projet, contrat par contrat.
- TOGAF Standard, 10e édition, Enterprise Architecture Capability and Governance, publié par The Open Group : la source pour le conseil, la conformité, les contrats et la capacité.
- ISO/IEC 38500 : la gouvernance des technologies de l'information pour l'organisation.
- ISO/IEC/IEEE 42010 : parties prenantes, préoccupations, points de vue et vues.
- ISO 31000 : le management du risque, celui qui traverse tous les niveaux de gouvernance.
- OCDE, Principes de gouvernance d'entreprise du G20 et de l'OCDE, édition 2023 : la définition de la gouvernance d'entreprise dont celle de l'architecture hérite.
- Government Accountability Office, rapports consultables sur gao.gov par leur référence : GAO-10-846G, Organizational Transformation: A Framework for Assessing and Improving Enterprise Architecture Management, version 2.0 (août 2010) ; GAO-06-831, Enterprise Architecture: Leadership Remains Key to Establishing and Leveraging Architectures for Organizational Transformation (août 2006) ; GAO-12-791, Organizational Transformation: Enterprise Architecture Value Needs to Be Measured and Reported (septembre 2012).