Appliquer l'ADM : itérations, phases concurrentes et compromis

Trois passes sur la même ligne

Une ligne nouvelle ne se dessine jamais en une fois. L'autorité d'infrastructure la trace d'abord au crayon sur la carte régionale : un couloir, deux gares, un ordre de grandeur. Puis elle reprend le même tracé en avant-projet, avec les ouvrages d'art et les emprises. Puis en projet détaillé, rail par rail. Trois passes sur le même dossier, et pendant la troisième, le tronçon voisin est déjà en travaux.

L'ADM de TOGAF se pratique comme ça. Le cadran que la série promène depuis le survol de l'ADM donne l'impression d'une roue qui tourne une fois, de A à H, une phase après l'autre. Personne ne l'utilise ainsi, et le TOGAF Standard, publié par The Open Group, consacre une partie entière à la question : « Applying the ADM ».

Trois échelles d'itération coexistent. On itère sur le cycle entier : chaque demande de travaux ouvre un tour complet, et plusieurs tours vivent en parallèle. On itère entre les phases : B, C et D se nourrissent mutuellement, et on revient en arrière quand une exigence bouge. On itère dans une phase : une étape se rejoue au niveau de détail voulu.

À chaque itération, l'équipe redécide quatre choses : la largeur, la profondeur, l'horizon et les actifs qu'elle reprend du dépôt. Le choix dépend des ressources, des compétences disponibles et de la valeur attendue de ce tour-là.

Le cadran, cette fois, n'a pas de tuile active. Le billet parle de la façon de le faire tourner, pas d'une phase.

L'ADM est itératif à trois échelles : sur le cycle entier, entre les phases et dans une phase. Chaque itération choisit sa largeur, sa profondeur, son horizon et ses réemplois.

Le cadran n'est pas une cascade

Personne n'attend que la dernière notice de la ligne soit signée pour lancer les terrassements du premier tronçon. Et personne ne refait l'étude de trafic complète pour déplacer un quai de trente mètres.

Pourquoi itérer ? Parce que les domaines sont interdépendants. Une décision d'architecture applicative change les données à héberger, donc la technologie, donc le coût, donc le périmètre métier qu'on peut se permettre. Une cascade suppose qu'on sait tout au premier passage. L'itération accepte qu'on apprenne en route.

Le standard en tire des règles de pratique courtes. Chaque projet d'architecture a sa finalité, son chemin et sa configuration propres. Il commence toujours en phase A, parce que c'est là qu'on cadre et qu'on fait signer. Il n'entre pas forcément dans toutes les phases. Ses phases et leurs étapes peuvent s'exécuter en parallèle et se répéter au niveau de détail que la demande justifie. Plusieurs phases restent ouvertes en même temps.

La dernière règle dérange souvent les équipes habituées aux jalons. Elle est pourtant la plus utile : elle permet de livrer une feuille de route partielle pendant que la cible technologique se stabilise.

Un projet d'architecture commence toujours en A. Tout le reste, quelles phases, dans quel ordre, combien de fois, se décide d'après la demande de travaux.

Les cinq cycles d'itération

L'autorité d'infrastructure fait tourner plusieurs boucles de nature différente. Elle revoit ses propres méthodes et ses effectifs. Elle étudie des lignes. Elle programme des mises en service. Elle homologue des tronçons et compte des voyageurs. Chaque boucle a son rythme, et aucune n'attend les autres.

Le TOGAF Standard distingue l'itération sur le cycle entier et quatre cycles d'itération ciblés, qu'il pose sur le cadran. Le tour complet traite un paysage d'architecture entier ou l'une de ses partitions, de A à H. Les quatre autres tournent à l'intérieur.

L'itération de capacité couvre le préliminaire et A : créer ou ajuster la capacité d'architecture. L'itération de développement couvre B, C, D et E : produire le contenu. L'itération de planification de transition couvre E et F : la feuille de route, les lots, le plan. L'itération de gouvernance couvre G et H : surveiller la réalisation, mesurer la valeur, absorber le changement.

Posés sur le cadran, les quatre cycles ciblés dessinent des boucles courtes, avec des retours en pointillés.

Crème : capacité. Cuivre : développement. Cuivre clair : planification de transition, E compris. Ardoise : gouvernance. Les pointillés sont les retours : E vers B quand la cible ne converge pas, A vers le préliminaire quand la capacité manque, H vers A pour un nouveau cycle et H vers le préliminaire quand la capacité elle-même doit changer.

Cinq boucles, un seul cadran : le tour complet pose le paysage, les quatre cycles ciblés le raffinent chacun à son rythme.

Itérer sur le cycle entier

Chaque lettre de mission du ministère ouvre un dossier de ligne. Deux dossiers avancent en parallèle quand deux lignes se croisent dans la même gare. Et une étude en révèle parfois une autre : impossible de poser le nouveau tronçon sans refaire le nœud ferroviaire voisin, qui n'était pas dans la lettre.

Le tour complet de l'ADM fonctionne pareil. Chaque cycle est borné par une demande de travaux d'architecture : elle le lance, elle fixe son périmètre, et sa sortie modifie ou étend le paysage d'architecture dans le dépôt.

Plusieurs cycles vivent en parallèle, avec des relations entre eux. Un cycle stratégique à cinq ans encadre des cycles de segment plus courts. Un cycle de capacité descend jusqu'au physique sur un périmètre étroit, en s'appuyant sur ce que le cycle de segment a déjà décidé.

Un cycle en déclenche un autre dans deux cas précis. Quand une opportunité identifiée en E exige une architecture plus détaillée que celle que le cycle courant devait produire. Et quand les impacts découverts dépassent la demande de travaux : le cycle courant ne s'étend pas, il émet une nouvelle demande, et un nouveau cycle démarre avec son propre périmètre et son propre sponsor.

Un cycle ne grossit jamais en silence. Ce qui déborde de sa demande de travaux devient une nouvelle demande, donc un nouveau cycle.

L'itération de développement : des phases concurrentes

L'étude de tracé et l'étude de signalisation avancent ensemble, pas l'une après l'autre. Le système de signalisation retenu influe sur la distance entre les gares, qui influe sur le tracé. Les deux bureaux d'études se parlent toutes les semaines, et chacun reprend son plan quand l'autre bouge.

Dans le cycle de développement, B, C et D s'exécutent de façon concurrente pour la même raison : les interrelations entre domaines. Une capacité métier définie en B implique des entités de données et des applications en C, qui imposent des plateformes en D. Si D révèle qu'une plateforme n'entre pas dans le budget, on remonte en C, parfois en B.

On boucle entre les phases jusqu'à converger vers une cible assez détaillée pour être approuvée. Le standard décrit deux chemins. Partir de la référence et déduire la cible, quand l'existant est mal connu et complexe. Partir de la cible et confronter l'existant, quand la stratégie est claire et que l'existant est déjà documenté dans le dépôt.

Et on revient en arrière quand les exigences changent. Une exigence modifiée en D remonte dans la gestion des exigences, qui la redistribue aux phases concernées. Le standard le prévoit, et c'est le fonctionnement normal du cycle.

Converger, c'est faire tourner B, C et D ensemble jusqu'à ce que les trois tiennent debout au même moment, pas finir B avant d'ouvrir C.

L'itération de capacité

Une direction de la planification découvre, au milieu d'une étude, qu'elle ne sait pas chiffrer un tunnel. Elle recrute, se forme ou sous-traite, puis elle reprend l'étude là où elle l'avait laissée.

L'itération de capacité, préliminaire et A, sert exactement à ça. Elle rétablit des aspects de la capacité d'architecture que la phase A a identifiés comme manquants : un point de vue absent de la bibliothèque, un outil de modélisation, un rôle non pourvu, un principe jamais écrit. Sans cette boucle, chaque cycle redécouvre les mêmes trous.

Elle ajuste aussi la capacité après une demande de changement traitée en H. Si l'entreprise change de modèle opérationnel, fusionne deux directions ou externalise une fonction, l'organisation de l'architecture doit suivre : partitions, gouvernance, propriétaires.

Ce cycle est court et discret. Il n'a pas de livrable spectaculaire. C'est pourtant celui qui fait la différence entre une équipe qui apprend et une équipe qui recommence.

La capacité d'architecture n'est pas acquise une fois pour toutes en préliminaire. Chaque phase A et chaque phase H peuvent la renvoyer à l'atelier.

Le flux d'information

Le dossier d'études est moins un planning qu'une connaissance qui se construit : l'esquisse fixe le couloir, l'avant-projet fixe les ouvrages, le projet détaillé fixe les quantités. Chaque étape reprend la précédente et la précise. Si l'avant-projet déplace une gare, l'esquisse se met à jour.

Le TOGAF Standard présente le cadran comme une méthode logique de développement de la connaissance, pas comme un modèle de processus ni une séquence d'activités. Chaque phase existe parce qu'elle produit une sortie essentielle : la vision pour A, les architectures de domaine pour B, C et D, la feuille de route pour E, le plan pour F, les contrats et la conformité pour G, la mesure de la valeur et les demandes de changement pour H.

Chaque phase consomme des entrées, le dépôt, les exigences, les sorties des phases précédentes, et produit des sorties qu'une phase ultérieure peut reprendre telles quelles ou détailler. Le plan de travail réel dépend de la demande : quelles sorties sont attendues, à quel niveau de détail, pour quand.

Traits pleins : ce qu'une phase consomme et ce qu'elle produit. Pointillés : ce qui remonte. Les exigences découvertes en B, C ou D retournent au centre du cadran ; les briques réutilisables rejoignent le dépôt ; les demandes de changement de H finissent en nouvelle demande de travaux.

Lis le cadran comme une carte des dépendances entre connaissances, pas comme un diagramme de Gantt.

Spécifier les briques phase après phase

Sur le schéma directeur, la ligne est « voie double électrifiée ». Dans le dossier d'études, c'est « ERTMS niveau 2, caténaire 25 kV ». Dans les lots de travaux, ce sont des kilomètres de rail chez un fournisseur et des armoires de signalisation chez un autre. Même objet, trois niveaux de précision, trois moments.

Les briques d'architecture suivent la même descente. En A, un modèle de haut niveau : les briques sont nommées, pas spécifiées. En B, C et D vient le travail de fond : réutiliser les définitions du dépôt pour décrire la référence, définir les briques requises par la cible avec des catalogues, des matrices et des diagrammes, documenter chaque brique et la justification de sa présence, réutiliser ce qui existe avant d'inventer, choisir les standards applicables, puis publier dans le dépôt les briques que d'autres cycles pourront reprendre.

L'analyse d'écarts classe ensuite chaque brique : conservée, éliminée ou nouvelle. En E, on associe ces écarts aux lots de travail et aux architectures de transition. C'est là que la brique d'architecture rencontre ses briques de solution candidates, celles qu'on va réellement acheter ou construire.

Une brique n'est jamais spécifiée d'un coup. Elle est nommée en A, décrite en B, C et D, classée par l'analyse d'écarts, puis affectée à un lot en E.

Alternatives et compromis

Une ligne nouvelle a toujours plusieurs variantes de tracé : par le tunnel, par le viaduc, par la plaine en contournant la ville. Chacune satisfait certains riverains et en fâche d'autres, coûte plus ou moins, dessert plus ou moins. La concertation ne cherche pas la variante parfaite. Elle cherche celle dont les compromis sont assumés en public.

Le TOGAF Standard est net : il n'existe pas toujours une architecture unique qui satisfait toutes les préoccupations des parties prenantes, au sens que leur donne ISO/IEC/IEEE 42010. Le travail consiste donc à identifier des cibles alternatives, à comprendre ce que chacune rend possible, à nommer les compromis, et à utiliser la présentation des alternatives pour faire sortir les agendas cachés. Une partie prenante qui défend une option sans dire pourquoi se révèle vite quand on la met en face de trois variantes documentées.

La méthode tient en quatre temps. Dériver des critères de décision depuis la vision, les principes d'architecture et les exigences. Construire une alternative par jeu de critères privilégié. Évaluer chaque alternative contre tous les critères, pas seulement les siens. Puis sélectionner une alternative, ou en combiner plusieurs, et consigner la justification dans le document de définition d'architecture.

Les trois alternatives de l'exemple sont volontairement typées. Dans la vraie vie, les jeux de critères viennent des préoccupations recensées en A : la direction financière, la DSI, le métier et le régulateur ne pondèrent pas les mêmes choses, et c'est précisément ce qu'on veut rendre visible.

Trois cibles sur la table, ce n'est pas de l'indécision : c'est le seul moyen de rendre les compromis visibles avant qu'ils ne soient subis.

L'entreprise numérique

Les exploitants vendent aujourd'hui des trajets sur une application plutôt qu'au guichet, et l'information voyageurs change de version tous les mois. Le réseau physique, lui, est le même pour tous. Ce sont les normes communes qui permettent à chaque exploitant d'avancer à son rythme sans que les trains cessent de rouler.

The Open Group définit l'entreprise numérique dans le Digital Practitioner Body of Knowledge : des produits et services créés et livrés numériquement, ou des produits physiques que le client obtient par des moyens numériques. Dans une telle entreprise, les équipes produit livrent en continu, et personne n'attend le prochain tour complet du cadran.

L'architecture d'entreprise y change de posture. Elle ne dessine plus la cible à la place des équipes. Elle leur fournit ce qu'une équipe agile ne peut pas produire seule : la vue de la dette technique à l'échelle de l'entreprise, des standards et des composants réutilisables, une gouvernance de la réutilisation, des choix de simplification, un cadre d'excellence opérationnelle, et l'institutionnalisation des méthodes agiles elles-mêmes.

Les itérations décrites plus haut rendent cette posture possible. Un cycle de développement court, lancé sur une partition étroite, livre une cible utilisable par une équipe produit en quelques semaines. Le tour complet, lui, continue de poser le paysage sur plusieurs années.

Dans l'entreprise numérique, l'architecture ne précède pas la livraison. Elle tourne à côté, en cycles courts, et nourrit les équipes en standards et en briques réutilisables.

Scénario B : le Guardian quitte MongoDB

En novembre 2018, l'équipe d'ingénierie du Guardian a publié « Bye bye Mongo, Hello Postgres », le récit de la migration de son outil de rédaction, Composer, de MongoDB vers PostgreSQL. Au sens strict, ce n'est pas un programme d'architecture d'entreprise, mais la méthode des compromis et l'itération y sont visibles ligne à ligne, ce qui en fait un bon cas d'école.

Le point de départ, tel que l'article le raconte : Composer stockait ses contenus dans MongoDB, hébergé par le journal sur ses propres instances AWS. L'outil de gestion commercial censé simplifier l'exploitation n'a pas tenu cette promesse, et l'équipe passait trop de temps à administrer la base plutôt qu'à produire des outils éditoriaux. L'objectif est devenu clair : une base gérée par le fournisseur, pour ne plus exploiter d'instances.

Les critères d'abord, tels que l'article les liste : le moins d'administration de base possible, le chiffrement au repos, un chemin de migration réaliste depuis Mongo. Puis les alternatives. DynamoDB, la base gérée du fournisseur cloud déjà utilisé, était la candidate naturelle ; elle a été écartée parce qu'à l'époque elle ne proposait pas le chiffrement au repos, et l'équipe raconte avoir attendu cette fonctionnalité pendant des mois avant de renoncer. PostgreSQL sur Amazon RDS l'a emporté, avec le type jsonb pour conserver les documents tels quels et limiter les changements au modèle de données.

L'itération ensuite. Le plan publié tient en quelques étapes : créer la nouvelle base ; écrire une nouvelle API qui parle à Postgres ; placer devant les deux API un proxy qui envoie chaque requête aux deux, répond avec la base principale et journalise les écarts ; migrer les contenus avec un script ; basculer la principale sur Postgres ; éteindre Mongo. Chaque écart journalisé par le proxy renvoyait l'équipe à l'API ou au script, puis on rejouait. Tant que le proxy tournait, les deux bases recevaient les mêmes requêtes et le choix de la base principale tenait à une configuration modifiable à chaud : la porte de sortie est restée ouverte jusqu'à l'extinction de Mongo.

Projeté sur le cadran : des critères tirés des exigences, une alternative par jeu de critères, un compromis nommé (garder un modèle documentaire, mais dans une base relationnelle), une architecture de transition en double écriture, et des itérations de développement qui n'ont jamais attendu que tout soit parfait pour avancer. Tout ce qui précède vient du billet de l'équipe ; je n'y ajoute rien.

Le Guardian n'a pas cherché « la meilleure base ». Il a écrit ses critères, mis ses options en face, nommé le compromis et gardé une porte de sortie jusqu'à l'extinction de l'ancienne base.

Points clés

• L'ADM est itératif à trois échelles : sur le cycle entier, entre les phases et dans une phase. Chaque itération redécide largeur, profondeur, horizon et réemplois.
• Un projet commence toujours en A, n'entre pas forcément dans toutes les phases, et peut garder plusieurs phases ouvertes en même temps.
• Quatre cycles ciblés (capacité, développement, planification de transition, gouvernance) tournent à l'intérieur du tour complet, chacun à son rythme.
• Les briques se précisent phase après phase : nommées en A, décrites en B, C et D, classées par l'analyse d'écarts, affectées aux lots en E.
• Quand aucune cible ne satisfait tout le monde, on dérive des critères, on construit des alternatives et on nomme les compromis avant de choisir.

Dans la série

Palier 3 : Faire rouler les trains. Domaine : Pilotage.

• Précédent : Phase H et gestion des exigences : piloter le changement
• Suivant : Le référentiel d'architecture : métamodèle, dépôt, continuum
• Vue d'ensemble : Architecture d'entreprise : par où commencer

Pour aller plus loin

• L'ADM de TOGAF : dix phases, artefacts, livrables, points de vue, pour le survol des phases et le vocabulaire que ce billet réutilise sans le redéfinir.
• Phase H et gestion des exigences : piloter le changement, pour le détail de ce qui remonte au centre du cadran et de la demande de changement.
• TOGAF Standard, 10e édition, partie « Applying the ADM », publié par The Open Group : les cycles d'itération, le flux d'information et les alternatives dans le texte de référence.
• Digital Practitioner Body of Knowledge, The Open Group, pour la définition de l'entreprise numérique.
• ISO/IEC/IEEE 42010, pour les notions de partie prenante et de préoccupation sur lesquelles repose la méthode des compromis.
• The Guardian, « Bye bye Mongo, Hello Postgres » (novembre 2018), le récit complet de la migration résumée dans le scénario B.