Ce qui est posé sous le ballast
Sur Le Chemin de fer, le gestionnaire d'infrastructure tient deux choses que personne ne voit depuis le quai : les archives techniques et le registre de l'infrastructure. Les premières gardent les plans, les notes de calcul et les dossiers d'homologation de chaque ouvrage. Le second dit, pour chaque mètre de ligne, ce qui est posé : le type de rail, la date de pose, la section électrique, l'appareil de voie, la signalisation.
Le jour où une région demande de relever la vitesse sur un tronçon, tout part de là. Si le registre est tenu, l'étude dure quelques semaines. S'il ne l'est pas, on envoie des équipes sonder le ballast pour redécouvrir ce qu'on a soi-même posé trente ans plus tôt.
L'architecture d'entreprise a le même problème, et la même réponse. Quinze billets de cette série ont produit des visions, des catalogues, des matrices, des feuilles de route, des contrats. La question de celui-ci : où tout cela est rangé, en quels termes c'est décrit, et comment on le retrouve quand le cycle suivant démarre.
Une architecture qu'on ne peut pas retrouver n'existe plus. Le référentiel est ce qui transforme une suite de projets en une connaissance qui s'accumule.
Vue d'ensemble : quatre notions pour un seul référentiel
TOGAF, le cadre publié par The Open Group, répond avec quatre notions qui s'emboîtent. Elles sont décrites dans la partie Architecture Content du TOGAF Standard.
Le content framework classe : il dit quels types de livrables et d'artefacts une architecture produit, et où chacun se range. Le métamodèle d'entreprise nomme : il liste les entités dont parlent ces artefacts (une capacité, un processus, une application, un écart) et les relations qu'elles entretiennent. Le dépôt d'architecture stocke : c'est l'endroit où tout cela vit, avec les standards, les modèles de référence et les décisions de gouvernance. Le continuum d'entreprise situe : il classe chaque actif du plus générique au plus spécifique et dit d'où il vient.
| Notion | La question qu'elle règle | Sur Le Chemin de fer |
|---|---|---|
| Content framework | Quels documents produire, et où chacun se range | Le plan de classement des archives techniques |
| Métamodèle d'entreprise | De quoi parlent ces documents, en quels termes, avec quelles relations | Le vocabulaire du registre : voie, appareil de voie, section, poste |
| Dépôt d'architecture | Où tout cela est stocké, versionné et retrouvé | Les archives techniques et le registre de l'infrastructure |
| Continuum d'entreprise | D'où vient chaque brique, du générique au spécifique | Fiches internationales, spécifications européennes, règles maison |
Les quatre se lisent dans cet ordre, parce que chacun a besoin du précédent. On ne range pas sans classement, on ne classe pas sans vocabulaire, et le continuum ne sert à rien si le dépôt est vide.
Classer, nommer, stocker, situer : quatre verbes, un seul référentiel. Qu'un seul manque, et le dépôt redevient un répertoire partagé où personne ne retrouve rien.
Le content framework
Sur Le Chemin de fer, les archives techniques ne sont pas un tas de dossiers. Un plan de classement dit qu'un dossier d'ouvrage d'art se range à tel endroit, qu'une notice de signalisation va ailleurs, et ce que chaque dossier doit contenir pour être recevable. L'archiviste n'a pas inventé ce plan pour chaque ligne : il est commun à tout le réseau.
Le content framework joue ce rôle. C'est un cadre de catégorisation du contenu architectural : il structure la description de l'architecture, les artefacts qui la composent et les modèles qu'on utilise pour les produire. Il définit aussi les artefacts à produire, ce qui en fait une liste de contrôle autant qu'un plan de classement.
Sa structure de haut niveau reflète les phases de l'ADM. Une bande haute pour ce que posent la phase préliminaire, la phase A et la gestion des exigences : principes, vision, exigences, contraintes, hypothèses, écarts. Une bande centrale pour la définition d'architecture, avec la motivation (moteurs, objectifs), le métier, les systèmes d'information (données et applications) et la technologie, soit les phases B, C et D. Une bande basse pour la réalisation : les opportunités, les solutions et le plan de migration des phases E et F, puis la gouvernance de l'implémentation de la phase G. La gestion du changement, la phase H, court en bande latérale parce qu'elle touche tout.
données, applications
Chaque livrable trouve donc une place dans la vue d'ensemble. Un catalogue de capacités va dans la définition, côté métier. Une matrice écarts / solutions va dans la réalisation. Un journal de décisions va dans la gouvernance. Personne n'a à se demander où ranger.
TOGAF n'est pas le seul à proposer un cadre de contenu. Le cadre de Zachman, le DoDAF du département de la Défense américain ou le NAF de l'OTAN en sont d'autres. Le choix dépend du cadre d'architecture qu'on a adopté et de l'outil qu'on utilise, et dans tous les cas le cadre s'adapte : on retire les catégories qu'on ne produira jamais, on en ajoute si le métier l'exige.
Ce qu'on y gagne tient en cinq points. Un modèle détaillé des produits du travail d'architecture. De la cohérence entre projets, parce que deux équipes rangent les mêmes choses au même endroit. Une liste de contrôle, qui dit ce qu'il reste à produire. Moins de trous, puisqu'une case vide se voit. Et des standards, parce qu'un livrable qui a une place attendue finit par avoir une forme attendue.
Le content framework décrit les documents de l'architecture, pas l'architecture elle-même. C'est le plan de classement, pas le contenu des dossiers.
Le métamodèle d'entreprise
Le registre de l'infrastructure ne vaut que par son vocabulaire. Une « voie », un « appareil de voie », une « section élémentaire », un « poste » : chaque terme a une définition, et des relations fixées (une section appartient à une ligne, un appareil de voie relie deux voies). Sans ce vocabulaire, deux directions régionales décrivent le même aiguillage avec deux mots, et l'application nationale ne consolide rien.
Le métamodèle d'entreprise est ce vocabulaire pour l'architecture. Il définit les entités (les types de choses dont on parle) et leurs relations. Il sert de kit de départ sur les types de choses à couvrir, donne leur contexte aux artefacts, et permet de vérifier qu'un langage de modélisation couvre bien tout ce qu'on veut décrire. Ce qu'il apporte se résume en trois mots : cohérence, complétude, traçabilité. On remonte d'un composant technologique jusqu'à l'exigence qu'il satisfait parce que le métamodèle a prévu la chaîne de relations.
Le métamodèle est propre à chaque entreprise. TOGAF en propose un, mais c'est une base de travail. Un bon métamodèle conditionne ce que la capacité d'architecture pourra faire : si l'entité « écart » n'existe pas, personne ne fera d'analyse d'écarts outillée.
Le schéma ci-dessous redessine la base que propose le standard : des entités générales qui traversent les domaines, puis les entités de chaque domaine, reliées par quelques relations types.
Sur la notation, TOGAF n'impose rien. Un catalogue peut être un tableur, une matrice une feuille, un diagramme un dessin ArchiMate, BPMN, UML, un organigramme ou un modèle entité-association. Le métamodèle dit de quoi on parle, la notation dit comment on le dessine. Le langage ArchiMate, publié par The Open Group lui aussi, est conçu pour s'aligner sur le métamodèle TOGAF, mais rien n'oblige à l'adopter.
Il y a deux manières de construire son métamodèle, et elles ne partent pas du même bout.
| Approche | Point de départ | Ce qu'elle garantit | Ce qu'elle risque |
|---|---|---|---|
| Depuis les points de vue | Les préoccupations des parties prenantes, les vues qui y répondent, puis les entités nécessaires à ces vues | Chaque entité sert au moins une vue qu'on produit vraiment | Oublier une entité que personne n'a réclamée mais dont la traçabilité a besoin |
| Depuis un métamodèle établi | Le métamodèle TOGAF, ArchiMate ou celui d'un outil, qu'on élague | Un vocabulaire éprouvé, compatible avec les outils du marché | Garder des entités qu'on ne tiendra jamais à jour, par confort |
Dans les deux cas, deux règles valent. Réduire le métamodèle à la finalité de la capacité : si l'architecture sert à prioriser un portefeuille, elle n'a pas besoin de modéliser chaque champ de base de données. Et tenir chaque entité à jour : une entité qu'on ne maintient pas sort du métamodèle, parce qu'un modèle à moitié faux est pire qu'un modèle incomplet.
Un métamodèle se juge au nombre d'entités qu'on tient réellement à jour, pas au nombre d'entités qu'il déclare.
Le dépôt d'architecture
Revenons aux archives techniques et au registre de l'infrastructure. Ce ne sont pas deux armoires. C'est une gestion documentaire pour les plans, une base de données pour le registre, des référentiels de normes, un journal des décisions du comité des investissements. Plusieurs outils, une seule logique de rangement.
Le dépôt d'architecture suit le même modèle. TOGAF le décrit comme une partie du dépôt d'entreprise, celle qui tient les sorties des projets d'architecture. Physiquement, c'est souvent un outil de modélisation, un outil d'analyse, des fichiers et une gestion documentaire. Logiquement, c'est un ensemble de compartiments dont chacun répond à une question.
Le compartiment métamodèle garde la méthode adaptée et le métamodèle de l'entreprise : la version de l'ADM qu'on applique vraiment, et le vocabulaire de la section précédente. La capacité d'architecture décrit l'organisation qui fait le travail : compétences, structure, charte.
Le paysage d'architecture contient les architectures elles-mêmes, aux trois niveaux vus au début de la série : stratégique (le schéma national), segment (le corridor régional), capacité (la ligne). Et à chaque instant : référence, transitions, cible, chacune à son niveau d'abstraction.
La bibliothèque de référence rassemble les guides, gabarits, patrons et modèles de référence que l'entreprise a adoptés pour aller plus vite. La bibliothèque de standards liste ce qu'il faut respecter, en quatre classes : standards métier, de données, d'applications, de technologie. Sur Le Chemin de fer, c'est l'écartement, la tension de la caténaire, le système de signalisation : ce qui rend les tronçons interopérables.
Le dépôt de gouvernance garde la trace de l'activité : journal des décisions, évaluations de conformité, évaluations de capacité, calendrier, portefeuille de projets, mesure de performance. Le dépôt des exigences conserve les exigences aux trois niveaux, et il garde plusieurs cycles, contrairement à la spécification des exigences qui ne vaut que pour un cycle. Le paysage des solutions décrit enfin les briques de solution déployées, le pendant physique du paysage d'architecture.
| Compartiment | Qui l'alimente le plus | Qui le lit le plus |
|---|---|---|
| Métamodèle | Phase préliminaire | Toutes les phases |
| Capacité d'architecture | Phase préliminaire | Conseil d'architecture, phase H |
| Paysage d'architecture | Phases B, C, D | Phases A, E, G |
| Bibliothèque de référence | Phase préliminaire, retours de phase H | Phases B, C, D |
| Bibliothèque de standards | Conseil d'architecture | Phases B, C, D, G |
| Dépôt de gouvernance | Phases F, G, H | Conseil d'architecture, audit |
| Dépôt des exigences | Gestion des exigences | Toutes les phases |
| Paysage des solutions | Phases E, F, G | Phases A et B du cycle suivant |
Deux flux alimentent le dépôt depuis l'extérieur : les modèles de référence externes (ceux d'un secteur, d'un éditeur, d'une administration) et les standards externes (normes ISO, règlements, spécifications techniques). Une instance le pilote : le conseil d'architecture, qui décide ce qui entre dans la bibliothèque de standards et ce qui en sort. C'est le sujet du billet suivant.
On ne dépose pas dans le dépôt en fin de projet. Chaque phase de l'ADM y lit en entrant et y écrit en sortant.
Le continuum d'entreprise
Quand le bureau d'études trace une ligne nouvelle, il ne repart jamais de zéro. Il y a les fiches de l'Union internationale des chemins de fer, génériques, qui valent pour tout réseau. Il y a les spécifications techniques d'interopérabilité européennes, plus précises, qui valent pour les réseaux de l'Union. Il y a les règles du gestionnaire national, propres à son réseau. Et il y a le dossier de la ligne, qui ne vaut que pour elle. Chaque étage spécialise le précédent.
Le continuum d'entreprise est cette échelle, appliquée aux actifs du dépôt. Il structure et classe les actifs, fournit un contexte à la réutilisation, et explique comment une solution générique devient, étage par étage, une solution propre à une organisation.
TOGAF le découpe en deux continuums parallèles. Le continuum d'architecture va des architectures de fondation (les principes généraux qui valent partout) aux architectures de systèmes communs (la sécurité, la gestion de réseau, des problèmes que toutes les entreprises partagent), puis aux architectures sectorielles (la banque, la santé, la distribution) et enfin aux architectures propres à l'organisation. Le continuum de solutions suit les mêmes quatre étages côté implémentation : solutions de fondation, de systèmes communs, sectorielles, propres à l'organisation.
L'un guide l'autre. Une architecture sectorielle dit ce qu'une solution sectorielle doit offrir. En retour, la solution sectorielle, une fois déployée, soutient et précise l'architecture. Le cercle se referme : les facteurs externes (marché, réglementation, technologie) donnent le contexte aux architectures de fondation, et les solutions déployées redeviennent un contexte pour le cycle suivant.
de fondation"] -->|spécialise| A2["Architectures de
systèmes communs"] -->|spécialise| A3["Architectures
sectorielles"] -->|spécialise| A4["Architectures propres
à l'organisation"] end subgraph SOL["Continuum de solutions"] S1["Solutions
de fondation"] -->|spécialise| S2["Solutions de
systèmes communs"] -->|spécialise| S3["Solutions
sectorielles"] -->|spécialise| S4["Solutions propres
à l'organisation"] end EXT["Facteurs externes
normes, marché, réglementation"] --> A1 A4 -.->|généralise| A1 A1 -.->|guide| S1 A4 -.->|guide| S4 S4 -.->|soutient| A4 S4 --> DEP["Solutions déployées
qui redeviennent contexte"] DEP -.-> EXT classDef cExt fill:#ede9e1,stroke:#5f5e5a,color:#1a1a1a classDef cArc fill:#b5651d,stroke:#5f5e5a,color:#f5f2ec classDef cSol fill:#d89253,stroke:#5f5e5a,color:#1a1a1a class EXT,DEP cExt class A1,A2,A3,A4 cArc class S1,S2,S3,S4 cSol
Les actifs qui remplissent le continuum ont deux provenances. Les actifs internes : les livrables des cycles précédents, qu'on a pris soin de ranger dans le dépôt pour cela. Les actifs externes : les modèles de référence d'un secteur, les patrons publiés, les standards du marché. Le continuum sert justement à ne pas les confondre, et à savoir ce qu'on devra adapter en descendant vers le spécifique.
C'est là que les briques du troisième billet retrouvent leur place. Une brique d'architecture générique vit à gauche du continuum, sa version adaptée à l'organisation vit à droite, et la brique de solution qui la réalise vit sur la rangée du bas. Savoir à quel étage on se situe évite deux erreurs symétriques : réinventer ce qu'un étage générique fournissait déjà, et imposer à tout le monde une règle qui ne valait que pour une ligne.
Le continuum ne demande pas « où est cet actif », le dépôt s'en charge. Il demande « à quel point cet actif est à nous », et donc ce qu'il faudra adapter pour le réutiliser.
Scénario B : la Federal Enterprise Architecture Framework v2
Imposer un content framework, un métamodèle commun et un continuum à des dizaines d'organisations qui ne se commandent pas les unes les autres : le gouvernement fédéral américain l'a fait, par écrit, et le document est public.
Le point de départ remonte à 1999, quand le Federal CIO Council publie la première Federal Enterprise Architecture Framework (version 1.1), dans la foulée du Clinger-Cohen Act vu au cinquième billet. Dans les années 2000, l'Office of Management and Budget (OMB) y ajoute des modèles de référence, rassemblés dans le Consolidated Reference Model.
Le 29 janvier 2013, l'OMB publie la Federal Enterprise Architecture Framework Version 2. Le document réorganise l'ensemble autour de six modèles de référence, héritiers du Consolidated Reference Model remanié : les anciens modèles de composants de service et technique laissent place à un modèle applicatif et à un modèle d'infrastructure, et un modèle de sécurité apparaît.
| Modèle de référence | Sigle | Ce qu'il classe |
|---|---|---|
| Performance | PRM | Les objectifs et les mesures : ce que les investissements doivent produire, et comment on le constate |
| Métier | BRM | Les fonctions du gouvernement fédéral, indépendamment des agences qui les exercent |
| Données | DRM | La description, le contexte et le partage des données, pour les découvrir et les échanger entre agences |
| Applications | ARM | Les systèmes, les composants applicatifs et leurs interfaces |
| Infrastructure | IRM | Les plateformes, les réseaux et les installations |
| Sécurité | SRM | Les finalités, les risques et les contrôles de sécurité, rattachés aux cinq autres modèles |
Chaque modèle est une taxonomie hiérarchique. Le modèle métier, par exemple, descend des secteurs de mission aux fonctions puis aux services. Le modèle applicatif va des systèmes aux composants applicatifs puis aux interfaces. Le document présente ces taxonomies comme le vocabulaire commun qui permet aux agences de décrire leurs investissements informatiques dans les mêmes termes, et donc de les comparer.
Projeté sur les quatre notions de ce billet, le dispositif se décompose ainsi. Les six modèles de référence forment le métamodèle commun : des entités typées, à plusieurs niveaux, partagées par toutes les agences. Le document structure aussi l'architecture en six domaines (stratégie, métier, données, applications, infrastructure, sécurité) et liste, pour chacun, les artefacts attendus : c'est un content framework. Il définit des niveaux de portée, de l'international à l'application individuelle en passant par le secteur, l'agence et le segment : c'est le paysage du dépôt. Et il demande à chaque agence de rattacher ses propres architectures aux modèles communs : c'est un continuum, où le niveau fédéral joue le générique et l'agence le spécifique.
Le document ajoute une méthode, la Collaborative Planning Methodology, en cinq étapes : identifier et valider, rechercher et réutiliser, définir et planifier, investir et exécuter, réaliser et mesurer. La deuxième étape consiste justement à chercher ce que d'autres agences ont déjà produit avant de construire. C'est le dépôt et le continuum, pensés pour la réutilisation à l'échelle d'un gouvernement.
Ce billet s'arrête à la structure publiée. Mesurer ce que les agences en ont fait demande d'autres sources, et c'est le travail du Government Accountability Office avec son cadre de maturité, le scénario B du billet suivant.
La FEAF v2 montre à quoi sert un métamodèle commun quand les organisations ne se commandent pas : rendre les architectures comparables et les actifs réutilisables, sans imposer une solution.
Points clés
- Le content framework classe les livrables et les artefacts. Sa structure suit les phases de l'ADM et sert aussi de liste de contrôle.
- Le métamodèle d'entreprise nomme les entités et leurs relations. Il est propre à chaque entreprise, réduit à la finalité de la capacité, et n'impose aucune notation.
- Le dépôt d'architecture tient huit compartiments, du métamodèle au paysage des solutions. Chaque phase de l'ADM y lit et y écrit.
- Le continuum d'entreprise classe les actifs du générique au spécifique, sur deux rangées, architecture et solutions, l'une guidant l'autre.
- La FEAF v2 de l'OMB réunit un métamodèle commun, un content framework et un continuum imposés à toutes les agences fédérales pour rendre leurs architectures comparables.
Dans la série
Palier 3 : Faire rouler les trains. Domaine : Référentiel.
- Précédent : Appliquer l'ADM : itérations, phases concurrentes et compromis
- Suivant : Gouvernance d'architecture : conseil, conformité et capacité
- Vue d'ensemble : Architecture d'entreprise : par où commencer
Pour aller plus loin
- TOGAF 10 et building blocks : le standard et ses briques : la brique d'architecture et la brique de solution, que le continuum situe.
- Gouvernance d'architecture : conseil, conformité et capacité : le conseil qui pilote le dépôt, et le dépôt de gouvernance qu'il alimente.
- TOGAF Standard, 10e édition, Architecture Content, The Open Group : content framework, métamodèle d'entreprise, dépôt et continuum.
- ArchiMate, The Open Group : le langage de modélisation aligné sur le métamodèle TOGAF.
- ISO/IEC/IEEE 42010 : parties prenantes, préoccupations et points de vue, le point de départ de la première approche du métamodèle.
- Office of Management and Budget, « Federal Enterprise Architecture Framework Version 2 », 29 janvier 2013 : document public (PDF), archivé sur le site des archives de la Maison-Blanche.