L'ADM de TOGAF : dix phases, artefacts, livrables, points de vue

De la lettre de mission à la mise en service

Une ligne nouvelle commence toujours par un courrier. Le ministère écrit à l'autorité d'infrastructure : étudiez une liaison entre ces deux villes, voici l'enveloppe, voici l'horizon. Dix ans plus tard, un train commercial roule dessus. Entre les deux, il y a eu un schéma directeur, des études de tracé, un cahier des charges, des lots de travaux, une homologation.

Ces étapes sont les mêmes d'une ligne à l'autre. Et pourtant elles ne se déroulent jamais dans le même ordre strict. Le tracé revient sur la table quand l'enquête publique révèle un riverain oublié. Le cahier des charges se réécrit quand la signalisation change de génération. On avance par passes, pas en cascade.

L'architecture d'entreprise a formalisé exactement ce mouvement. Dans le TOGAF Standard, publié par The Open Group, il s'appelle l'ADM, pour Architecture Development Method. C'est le cœur du standard, et c'est le sujet de ce billet.

On le prend en survol. D'abord les dix phases et ce que chacune produit. Ensuite les notions transverses sans lesquelles la suite de la série ne se lit pas : artefact, livrable et brique d'un côté ; partie prenante, préoccupation, point de vue et vue de l'autre. Les billets suivants détaillent chaque phase ; celui-ci installe la carte.

L'ADM ne dit pas quelle architecture construire. Il dit par quelles étapes passer pour la décider, la faire approuver, la livrer et la faire évoluer, et dans quel ordre revenir dessus.

L'ADM en une page

Sur le réseau, une ligne s'étudie en plusieurs passes : une esquisse pour choisir le corridor, un avant-projet pour fixer le tracé, un projet détaillé pour chiffrer les ouvrages. Chaque passe reprend la précédente avec plus de précision. L'ADM fonctionne pareil.

Le standard le présente comme un processus testé et répétable pour développer des architectures. Il couvre quatre choses : établir le cadre dans lequel on travaille, développer le contenu de l'architecture, gouverner sa réalisation, et accompagner la transition d'un état à l'autre. Le tout s'inscrit dans un cycle itératif, dont la finalité est une transformation contrôlée de l'entreprise.

Il compte dix phases. Une phase préliminaire, qui prépare l'organisation. Huit phases nommées de A à H, qui forment le cycle proprement dit. Et une activité continue, la gestion des exigences, placée au centre parce qu'elle alimente toutes les autres.

Chaque phase est décrite de la même façon : des objectifs, des entrées, une suite d'étapes, des sorties. Le standard précise que ces étapes sont des recommandations. On les adapte à la taille du cycle, à la maturité de l'organisation, aux cadres déjà en place. Un cycle de six semaines sur un seul segment ne déroule pas les mêmes étapes qu'un programme de transformation à cinq ans.

Deux idées à garder avant le détail. L'ADM n'est pas une cascade : on peut ouvrir plusieurs phases en même temps, revenir en arrière, ou ne pas passer par toutes. Et chaque phase produit une sortie qu'une phase ultérieure a le droit de modifier. La vision écrite en A est reprise en B, les écarts de B sont consolidés en E, le plan de F est corrigé en G.

Ce cadran revient dans tous les billets de la série consacrés aux phases, avec la tuile du moment en surbrillance. Ici, aucune tuile n'est active : on regarde la méthode entière.

Le cadran se lit dans le sens horaire, mais il se pratique en spirale : chaque tour affine ce que le tour précédent avait posé.

Les phases une à une

Sur le réseau, le registre des observations de l'enquête publique reste ouvert pendant toute l'étude. Chaque nouvelle demande, chaque contrainte découverte y entre, et chaque étape du projet vient y puiser. C'est le rôle de la tuile centrale du cadran, et c'est pour ça qu'on la décrit en dernier.

Préliminaire

Préparer l'organisation. On décide où l'architecture s'exerce, qui la fait, selon quelles règles. On adapte le cadre TOGAF et les autres cadres de l'entreprise (gestion de projet, gestion des services, gouvernance IT) pour qu'ils s'emboîtent. On pose les principes d'architecture et on choisit les outils. Le résultat est une capacité d'architecture, pas encore une architecture.

A. Vision d'architecture

Ouvrir un cycle. Une demande de travaux arrive ; on fixe la portée du problème et du projet, on identifie les parties prenantes et leurs préoccupations, on confirme les objectifs et les contraintes métier. On écrit une vision de haut niveau de la cible et de sa valeur, puis on fait approuver un énoncé des travaux d'architecture. Sans cette approbation, le cycle ne démarre pas.

B. Architecture métier

Décrire comment l'entreprise doit fonctionner pour réaliser la vision : capacités, processus, organisation, information au sens métier. On documente l'architecture de référence (ce qui existe) et l'architecture cible, puis on fait l'analyse d'écarts entre les deux. Les écarts deviennent des candidats pour la feuille de route.

C. Architectures des systèmes d'information

Même mouvement, sur deux volets : les données et les applications. Quelles entités d'information, qui en fait autorité, quelles applications les traitent, quelles interfaces les relient. Référence, cible, écarts, dans un ordre ou dans l'autre selon ce qui structure le plus le cycle.

D. Architecture technologique

Le dernier domaine : les composants et services technologiques qui portent les trois autres. Plateformes, réseau, middleware, infrastructure, cloud. Référence, cible, écarts. C'est aussi la phase où l'on regarde les technologies émergentes comme un moteur de changement, et non seulement comme une réponse à des demandes.

E. Opportunités et solutions

Passer de la cible à la manière d'y aller. On consolide les écarts des phases B, C et D, on les groupe en lots de travail, on vérifie les dépendances, on identifie les véhicules de livraison : projets, programmes, acquisitions. Si tout ne peut pas être livré d'un coup, on définit des architectures de transition. La sortie est une première feuille de route complète.

F. Planification de la migration

Transformer la feuille de route en plan daté et financé. Coût, valeur et risque de chaque lot ; ordre de priorité ; coordination avec le portefeuille de changement de l'entreprise. Le plan d'implémentation et de migration est finalisé, le document de définition d'architecture mis à jour. C'est ici que la direction dit oui, ou non.

G. Gouvernance de l'implémentation

Ici, les architectes ne produisent pas d'architecture : ils surveillent celle que d'autres construisent. Contrats d'architecture avec les équipes d'implémentation, revues de conformité, arbitrage quand la solution s'écarte de la cible. Les projets se terminent, la cible est ajustée si les faits l'imposent.

H. Gestion du changement d'architecture

Garder l'architecture vivante une fois livrée. On mesure si la valeur promise arrive, on reçoit les demandes de changement, on décide de leur sort : un ajustement courant, une ré-architecture partielle, ou un nouveau cycle complet. Ce dernier cas renvoie en phase A.

Gestion des exigences

Au centre, en continu. Chaque phase identifie des exigences, en découvre de nouvelles, en invalide d'autres. Le processus les enregistre, évalue leur impact sur les phases déjà passées, et met le dépôt à jour. Ce sont les phases qui décident ; la gestion des exigences garantit qu'elles décident toutes à partir du même état.

Les phases B, C et D répondent à la même question (référence, cible, écart) pour un domaine différent. Ce qui change entre elles, ce sont les artefacts qu'on y produit.

Artefacts, livrables, briques

Le dossier d'études d'une ligne tient en plusieurs classeurs : des listes d'ouvrages, des tableaux croisant tronçons et contraintes, des plans. Ce dossier est signé par l'autorité qui le reçoit, puis versé aux archives techniques. Sur chaque plan, une mention comme « voie double électrifiée » désigne un composant standard, qu'un fournisseur réalisera ensuite avec ses rails et sa caténaire.

Trois niveaux, donc : la pièce élémentaire, le dossier qui les assemble et qu'on signe, et la chose que les pièces décrivent. TOGAF les nomme artefact, livrable et brique.

L'artefact

Un artefact est un produit de travail qui décrit un aspect de l'architecture. Le standard en distingue trois formes. Le catalogue est une liste : les acteurs, les applications, les standards technologiques. La matrice montre des relations : quelle application sert quelle fonction métier, quel rôle accède à quelle donnée. Le diagramme est une image : un processus, une chaîne d'interfaces, une répartition par site.

La forme n'est pas un détail de présentation. Un catalogue sert à vérifier qu'on n'a rien oublié, une matrice à trouver les trous et les doublons, un diagramme à faire comprendre. Trois préoccupations différentes, et on y revient dans la section suivante.

Le livrable

Un livrable est un produit de travail spécifié à l'avance, puis revu, approuvé et signé par les parties prenantes. C'est souvent un document : la vision d'architecture, l'énoncé des travaux, le document de définition d'architecture, le plan de migration. Il représente la sortie d'un projet d'architecture. Une fois le projet terminé, il est archivé, ou versé au dépôt d'architecture comme modèle de référence, standard ou photographie du paysage à un instant donné.

Un livrable contient des artefacts. Le document de définition d'architecture, par exemple, rassemble les catalogues, matrices et diagrammes des quatre domaines. Et ces artefacts décrivent des briques.

La brique

Une brique d'architecture (ABB) décrit une capacité requise, indépendamment de la façon dont on la réalise. Une brique de solution (SBB) est la réalisation concrète : le progiciel, le service, le composant acheté ou développé. Le billet précédent a détaillé la distinction ; ici on retient la chaîne complète.

Brouillon et approuvé

Tant qu'un livrable circule entre architectes, c'est un brouillon : on le rature, on le réorganise, on le redécoupe. Le jour où les parties prenantes le signent, il change de statut. Il devient la base sur laquelle un sponsor engage un budget, une équipe lance un projet, un contrat se rédige.

Approuvé ne veut pas dire figé. Le livrable approuvé change encore, mais par un chemin explicite : une demande de changement, une évaluation d'impact, une nouvelle approbation. La différence entre les deux statuts, c'est la trace que laisse chaque modification.

Un artefact décrit, un livrable engage, une brique se construit. Confondre les trois conduit à signer des diagrammes ou à construire des documents.

Parties prenantes, préoccupations, points de vue, vues

Le voyageur regarde la carte des lignes, avec les correspondances. Le cheminot lit le schéma de voies, avec chaque aiguillage numéroté. Le planificateur travaille sur le graphique de circulation, où chaque train est une droite dans un repère temps-distance. Trois cartes du même réseau, et aucune ne servirait aux deux autres.

TOGAF reprend ici le vocabulaire d'ISO/IEC/IEEE 42010, la norme internationale sur la description d'architecture. Quatre termes, dans l'ordre où ils s'enchaînent.

Partie prenante et préoccupation

Une partie prenante est un individu, une équipe, une organisation, ou une catégorie de ceux-ci, qui a un intérêt dans le système. Sur le réseau : le voyageur, le chargeur, le riverain, l'élu, l'exploitant. Côté entreprise : le directeur financier, la DSI, l'équipe de production, le régulateur, le client final.

Une préoccupation est cet intérêt, formulé. Elle peut porter sur n'importe quel aspect du système : son fonctionnement, son développement, son exploitation, sa performance, sa sécurité, son coût, sa capacité à évoluer. Une même partie prenante en porte plusieurs. Une même préoccupation est souvent partagée par plusieurs parties prenantes.

Les préoccupations ont une propriété qui compte pour toute la suite : elles sont la racine des exigences. On ne part pas d'une liste d'exigences tombée du ciel. On part de qui est concerné, de ce qui l'inquiète, et on décompose jusqu'à des énoncés vérifiables. Une exigence qu'on ne peut rattacher à aucune préoccupation est la première à interroger.

Point de vue et vue

Un point de vue est la spécification des conventions pour un type de vue : ce qu'elle montre, pour quelles préoccupations, avec quelle notation, à quel niveau de détail. Le point de vue est générique. « Schéma de voies » est un point de vue : on peut en dresser un pour n'importe quelle gare du réseau, avec les mêmes symboles.

Une vue est la représentation du système depuis un ensemble de préoccupations liées. Elle est spécifique : le schéma de voies de cette gare-là. Toute vue a un point de vue, au moins implicite. Quand on dessine un diagramme sans avoir dit pour qui ni selon quelles conventions, le point de vue existe quand même, dans la tête de l'auteur, et personne d'autre ne peut le vérifier.

Parce qu'ils sont génériques, les points de vue se rangent dans une bibliothèque, au sein du dépôt d'architecture, et se réutilisent de cycle en cycle. Les vues appartiennent à l'architecture pour laquelle elles ont été produites.

Le lien avec la section précédente : les artefacts sont la matière des vues. Un catalogue, une matrice et deux diagrammes assemblés pour répondre aux préoccupations du directeur financier forment une vue. Le choix de ces artefacts, de leur notation et de leur niveau de détail, c'est le point de vue.

Une vue qui ne répond à la préoccupation de personne est un dessin. Avant de produire un artefact, demande-toi quelle partie prenante le lira et ce qu'elle y cherchera.

Scénario B : la paie de Queensland Health

Quittons le réseau ferré. En mars 2010, Queensland Health, le ministère de la santé de l'État du Queensland en Australie, met en service un nouveau système de paie pour ses agents, payés toutes les deux semaines. Le système remplace une application ancienne dont le support arrivait à son terme. Il repose sur SAP pour la paie et sur Workbrain pour les horaires et l'interprétation des conventions collectives, le tout intégré par IBM sous contrat avec CorpTech, l'unité de services partagés de l'État.

Dès les premières paies, des milliers d'agents sont payés en retard, trop, pas assez, ou pas du tout. Le système doit être tenu à bout de bras par des renforts massifs de gestionnaires de paie, pendant des années.

En décembre 2012, le gouvernement du Queensland crée une commission d'enquête, la Queensland Health Payroll System Commission of Inquiry, présidée par Richard Chesterman. Son rapport est remis le 31 juillet 2013. Il est public, et c'est la source de ce qui suit.

Ce que la commission a constaté

La portée n'a jamais été fixée. Le rapport décrit un périmètre défini de manière inadéquate au contrat, puis modifié en cours de route, sans qu'une version stable des exigences métier ait été arrêtée. Les règles de paie de Queensland Health, issues de plusieurs conventions et accords, n'avaient pas été recensées de manière complète au moment de la signature.

Les parties prenantes n'ont pas été identifiées comme il aurait fallu. Le rapport décrit une complexité des règles de paie sous-estimée par toutes les parties, et un métier insuffisamment associé à la définition de ce que le système devait faire. Les agents qui calculent la paie, les cadres qui valident les feuilles de temps, les personnels dont les primes dépendent de règles locales : leurs préoccupations n'ont pas structuré la conception.

La gouvernance était éclatée. Trois organisations se partageaient la responsabilité : l'État via CorpTech, Queensland Health, et l'intégrateur. Le rapport décrit des lignes de décision floues, des tests d'acceptation inachevés au moment de la mise en service, et une décision de bascule prise alors que des défauts connus n'étaient pas corrigés.

Côté chiffres, on s'en tient à ce que le rapport établit ou reprend : un contrat initial d'environ 6,19 millions de dollars australiens pour le volet paie, et une estimation issue d'une revue de KPMG de 2012 situant le coût total du système, correctifs et exploitation compris, à environ 1,25 milliard de dollars australiens sur huit ans. Le commissaire écrit que ce remplacement doit prendre place au premier rang des échecs de l'administration publique du pays, et qu'il en est peut-être le pire.

Lecture avec le cadran

Relis les trois constats avec le cadran sous les yeux. Pas de portée stable ni d'énoncé des travaux approuvé : la phase A n'a pas joué son rôle. Des exigences jamais arrêtées : la tuile centrale était vide. Des parties prenantes et des préoccupations non recensées : aucune vue n'a été produite pour ceux qui allaient vivre avec le système. Une gouvernance à trois têtes sans méthode partagée : les phases F et G, qui décident de la bascule et surveillent la conformité, n'avaient pas d'instance pour trancher.

On n'a pas besoin d'un cadre pour lire ces constats. Mais chacun nomme un trou précis dans ce que l'ADM demande de produire et de faire approuver avant d'avancer.

Un programme sans portée approuvée, sans exigences gérées et sans parties prenantes identifiées n'a pas « raté sa méthode ». Il n'en avait pas.

Points clés

• L'ADM est le cœur du TOGAF Standard : dix phases (préliminaire, A à H, gestion des exigences au centre), chacune décrite par des objectifs, des entrées, des étapes et des sorties, à adapter au contexte.
• Le cycle n'est pas une cascade : plusieurs phases peuvent être ouvertes en même temps, et chaque sortie peut être reprise par une phase ultérieure.
• Un artefact (catalogue, matrice, diagramme) décrit un aspect de l'architecture ; un livrable est spécifié, revu, approuvé et signé ; il contient des artefacts qui décrivent des briques.
• Les préoccupations des parties prenantes sont la racine des exigences ; le point de vue est générique et réutilisable, la vue est spécifique à l'architecture et toujours associée à un point de vue, même implicite.
• La paie de Queensland Health (2010) montre ce qu'il advient d'un programme sans portée stable, sans exigences gérées et sans parties prenantes identifiées : la commission d'enquête de 2013 en détaille chaque manque.

Dans la série

Palier 1 : Tracer la ligne. Domaine : Concepts.

• Précédent : TOGAF 10 et building blocks : le standard et ses briques
• Suivant : Phase préliminaire : la capacité d'architecture et ses principes
• Vue d'ensemble : Architecture d'entreprise : par où commencer

Pour aller plus loin

• Le TOGAF Standard, 10e édition, publié en ligne par The Open Group : la partie Architecture Development Method pour les phases, la partie Architecture Content pour artefacts, livrables et briques
• The Open Group, page TOGAF, l'éditeur du standard
• ISO/IEC/IEEE 42010, la norme sur la description d'architecture dont TOGAF reprend partie prenante, préoccupation, point de vue et vue
• Queensland Health Payroll System Commission of Inquiry, rapport remis le 31 juillet 2013 (Richard Chesterman, commissaire), document public du gouvernement du Queensland
• Phase préliminaire : la capacité d'architecture et ses principes, la première tuile du cadran en détail
• Appliquer l'ADM : itérations, phases concurrentes et compromis, pour la façon dont le cadran se pratique vraiment