Le poste de commande et le registre
Sur Le Chemin de fer, deux familles d'outils font rouler les trains sans jamais se confondre. D'un côté les postes de commande, la billettique, l'information voyageurs : ce qui agit, qui ouvre un signal, vend un billet, affiche un retard. De l'autre les registres : le registre de l'infrastructure, les horaires, le graphique de circulation. Ce qui sait.
Un poste de commande qui travaille sur un registre périmé envoie un train sur une voie qu'il croit libre. Un registre impeccable que personne n'exploite est une armoire de papier. L'un sans l'autre ne fait pas rouler un train.
La phase C de l'ADM a exactement cette structure. Le standard TOGAF, publié par The Open Group, l'appelle « architectures des systèmes d'information », au pluriel, parce qu'elle en contient deux : l'architecture des applications (ce qui agit) et l'architecture des données (ce qui sait). Deux chapitres distincts dans le standard, une seule phase dans le cycle.
C'est la deuxième station du palier « Poser les rails ». La phase B a dit quels services l'entreprise doit rendre. La phase C dit avec quels systèmes, et sur quelles informations.
La phase C ne choisit ni un produit ni un serveur. Elle décide quelles applications l'entreprise doit avoir, quelles données elles se partagent, et qui fait autorité sur chacune.
Vue d'ensemble : une phase, deux volets
Le standard donne à la phase C deux objectifs, calqués sur ceux de la phase B. Le premier : développer les architectures cibles des données et des applications qui rendent possibles l'architecture métier et la vision d'architecture, en répondant à l'énoncé des travaux et aux préoccupations des parties prenantes. Le second : identifier les composants candidats de la feuille de route à partir des écarts entre référence et cible.
La phase C ne part donc pas d'une page blanche : elle reçoit une architecture métier approuvée et doit dire quels systèmes d'information la soutiennent, aujourd'hui et dans la cible.
Les deux volets se prennent dans l'un ou l'autre ordre, et le standard ne tranche pas. Les écoles existent. Certaines démarches de planification partent des données, parce qu'elles bougent moins vite que les applications qui les manipulent. D'autres partent du portefeuille applicatif, parce que c'est lui que la direction connaît et finance. Ce qui compte, c'est que les deux convergent avant la revue formelle.
portefeuille, interfaces,
services applicatifs"] DAT["Volet données
entités, composants,
cycle de vie"] APP ---|"l'un ou l'autre en premier"| DAT end B["Phase B
architecture métier approuvée"] --> APP B --> DAT APP --> D["Phase D
architecture technologique"] DAT --> D APP --> E["Phase E
composants candidats
de feuille de route"] DAT --> E classDef volet fill:#b5651d,stroke:#8a4d16,color:#f5f2ec classDef phase fill:#ede9e1,stroke:#8a4d16,color:#1a1a1a class APP,DAT volet class B,D,E phase
Ce qui change d'un volet à l'autre, ce ne sont ni la finalité ni les étapes. Ce sont les artefacts qu'on produit, et les considérations propres à chacun : les modèles de référence sectoriels côté applications ; la gestion, la migration et la gouvernance côté données.
Même finalité et mêmes étapes que la phase B. La différence se joue dans les catalogues, les matrices et les diagrammes qu'on remplit, et dans les questions qu'ils forcent à poser.
Les étapes, les mêmes qu'en phase B
Sur le réseau, l'étude d'une ligne passe par les mêmes passes qu'on dessine le tracé, l'alimentation ou la signalisation. Les phases B, C et D partagent de la même façon une suite de neuf étapes, détaillée dans le billet précédent. Pour chaque volet de la phase C, on les déroule une fois.
| # | Étape | Ce qu'elle produit en phase C |
|---|---|---|
| 1 | Choisir les modèles de référence, les points de vue et les outils | Les modèles sectoriels ou génériques dont on part, la notation retenue |
| 2 | Décrire l'architecture de référence | Le portefeuille applicatif et les entités de données tels qu'ils existent |
| 3 | Décrire l'architecture cible | Les composants applicatifs et de données requis par l'architecture métier |
| 4 | Analyser les écarts | Applications à créer, à retirer, à faire évoluer ; entités manquantes, dupliquées ou sans propriétaire |
| 5 | Définir les composants candidats de la feuille de route | Les lots que la phase E consolidera |
| 6 | Résoudre les impacts sur le paysage d'architecture | Ce que la cible change aux autres architectures du dépôt |
| 7 | Conduire la revue formelle avec les parties prenantes | La preuve que les préoccupations relevées en phase A sont couvertes |
| 8 | Finaliser l'architecture | Briques retenues, standards choisis, justifications écrites |
| 9 | Créer ou mettre à jour le document de définition d'architecture | Les sections données et applications du document ouvert en phase A |
Le tableau sert de rappel, pas de méthode nouvelle. La matrice d'écarts, avec sa ligne « Nouveau » et sa colonne « Éliminé », s'applique telle quelle aux composants applicatifs et aux entités de données.
On ne réinvente pas la démarche à chaque domaine. On change de matière, pas de méthode.
Le volet applications
Les postes de commande, la billettique, l'information voyageurs : sur le réseau, ce sont des systèmes distincts, exploités par des acteurs différents, qui ne tiennent ensemble que parce qu'on sait qui parle à qui, et à propos de quoi. L'architecture des applications fait ce travail pour l'entreprise. Elle définit les composants applicatifs nécessaires pour traiter les données et soutenir le métier, et les interfaces entre eux.
Elle ne décrit pas comment une application est codée, mais quelles applications existent, ce qu'elles font pour le métier, qui les utilise et ce qu'elles échangent.
Les artefacts du volet applications
Le content framework de TOGAF classe les artefacts en trois formes : le catalogue liste, la matrice relie, le diagramme montre. Pour les applications, la liste complète tient dans un tableau.
| Forme | Artefact | La question à laquelle il répond |
|---|---|---|
| Catalogue | Portefeuille applicatif | Quelles applications existent, logiques et physiques ? |
| Catalogue | Interfaces | Quelles applications parlent à quelles autres ? |
| Matrice | Application / organisation | Quelle unité utilise quelle application ? |
| Matrice | Rôle / application | Quel rôle accède à quelle application ? |
| Matrice | Application / fonction | Quelle application soutient quelle fonction métier ? |
| Matrice | Interactions applicatives | Quelle application dépend de quelle autre, et dans quel sens ? |
| Diagramme | Communication applicative | Les flux logiques entre composants, et les entités échangées |
| Diagramme | Applications et localisation des utilisateurs | Qui utilise quoi, depuis où |
| Diagramme | Cas d'utilisation applicatifs | Les interactions acteurs / applications qui comptent pour l'architecture |
| Diagramme | Manageabilité d'entreprise | Comment les applications s'exploitent, se supervisent, se sauvegardent |
| Diagramme | Réalisation processus / application | Quelle application réalise quelle étape de processus |
| Diagramme | Ingénierie logicielle | La structure interne des composants, quand elle contraint l'architecture |
| Diagramme | Migration applicative | Le passage des applications de référence à la cible |
| Diagramme | Distribution logicielle | Où les composants sont déployés |
On ne produit pas les quatorze. La phase A a dit quelles parties prenantes portent quelles préoccupations, et c'est cela qui sélectionne les artefacts à remplir.
Le catalogue du portefeuille, point de départ
Tout commence par la liste. Le catalogue du portefeuille applicatif recense les applications de l'entreprise et distingue le composant logique (la capacité applicative dont le métier a besoin, indépendante de tout produit) du composant physique (le produit, la version, l'instance qui la réalise). Un composant logique peut être réalisé par plusieurs physiques, et c'est souvent là que l'analyse d'écarts commence à parler.
| Composant logique | Composants physiques | Service métier soutenu | Statut cible |
|---|---|---|---|
| Prise de commande | Portail de vente en ligne ; application de saisie en agence | Vendre | Conservé, les deux physiques fusionnés en un seul |
| Gestion des stocks | WMS de l'entrepôt central ; feuille de calcul des agences | Préparer et livrer | Conservé ; la feuille de calcul est éliminée |
| Facturation | Module de facturation du progiciel comptable | Facturer | Conservé |
| Référentiel clients | Aucun : les données clients vivent dans le portail et dans le progiciel | Connaître le client | Nouveau |
Deux colonnes font l'intérêt de l'exercice. « Service métier soutenu » rattache chaque application à la phase B. « Statut cible » prépare la matrice d'écarts : la ligne « Référentiel clients » est un écart de type « Nouveau », la feuille de calcul des agences un écart « Éliminé ».
Le diagramme de communication applicative
C'est le schéma de voies du volet applications. Il montre les composants applicatifs et les interfaces entre eux. Chaque interface peut être associée aux entités de données qu'elle transporte, chaque application au service métier qu'elle soutient. Et il reste logique : une technologie intermédiaire n'y figure que si elle est pertinente pour l'architecture.
Vendre"] -.-> A1 S2["Service métier
Facturer"] -.-> A3 A1["Prise de commande"] -->|"I1 : commande validée
entités Commande, Client"| A2["Gestion des stocks"] A2 -->|"I2 : disponibilité
entité Stock"| A1 A1 -->|"I3 : commande à facturer
entités Commande, Client"| A3["Facturation"] classDef app fill:#b5651d,stroke:#8a4d16,color:#f5f2ec classDef srv fill:#ede9e1,stroke:#8a4d16,color:#1a1a1a class A1,A2,A3 app class S1,S2 srv
Le diagramme répond à une question que ni le catalogue ni les matrices ne posent : si on remplace « Gestion des stocks », quelles interfaces faut-il reconstruire, et quelles entités traversent la frontière ?
La matrice application / organisation
La matrice croise les composants applicatifs logiques et les unités d'organisation. Elle assigne l'usage de chaque application à une unité, fait apparaître les exigences de support que chaque unité porte, et nourrit l'analyse d'écarts : une unité sans application pour un service qu'elle rend, ou deux unités qui en utilisent deux différentes pour le même service.
| Composant logique | Direction commerciale | Logistique | Finance | Service client |
|---|---|---|---|---|
| Prise de commande | Utilise | Consulte | Utilise | |
| Gestion des stocks | Consulte | Utilise | Consulte | |
| Facturation | Utilise | Consulte | ||
| Référentiel clients (cible) | Utilise | Utilise | Utilise |
La dernière ligne montre à elle seule pourquoi le composant est nouveau : trois directions ont besoin de la même vue du client, et aucune application de référence ne la leur donne.
D'où partir : les modèles de référence
Sur le réseau, personne ne réécrit les règles de signalisation pour chaque ligne. Il existe des fiches internationales, des spécifications européennes, puis les règles maison. Le volet applications a ses équivalents, rangés dans le dépôt d'architecture.
Le standard renvoie à trois familles. Les modèles applicatifs génériques par fonction métier, pour le commerce électronique ou la chaîne d'approvisionnement par exemple. Les modèles sectoriels publiés par des consortiums : The Open Group, l'Object Management Group (OMG) et ses groupes de travail par domaine, le TM Forum pour les télécommunications. Enfin le modèle de référence III-RM de The Open Group (Integrated Information Infrastructure Reference Model), qui décrit les catégories de composants applicatifs nécessaires à une circulation de l'information sans frontières entre systèmes (Boundaryless Information Flow).
Les reprendre évite de redécouvrir un découpage qu'un secteur entier a déjà validé. Les adapter reste obligatoire : aucun modèle sectoriel ne connaît l'organisation qu'on a devant soi.
Le portefeuille applicatif n'est pas un inventaire informatique. Chaque ligne se rattache à un service métier, à une unité qui l'utilise et à une décision : conserver, faire évoluer, éliminer ou créer.
Le volet données
Le registre de l'infrastructure dit ce qui est posé sous le ballast ; les horaires disent ce qui doit rouler ; le graphique de circulation dit ce qui roule. Trois registres, et une règle non écrite : chacun a un tenant unique, les autres le consultent. Un second registre de l'infrastructure, tenu par une autre direction, est la garantie que les deux divergeront.
L'architecture des données vise la même discipline. Elle définit les types et les sources de données nécessaires au métier, d'une façon compréhensible par les parties prenantes, complète, cohérente et stable. Ce n'est pas la conception d'une base. C'est la carte de ce que l'entreprise sait, de qui en répond et de la manière dont ça circule.
Les artefacts du volet données
| Forme | Artefact | La question à laquelle il répond |
|---|---|---|
| Catalogue | Entités de données / composants de données | Quelles entités le métier reconnaît, et dans quels composants logiques et physiques elles vivent |
| Matrice | Entité de données / fonction métier | Quelle fonction crée, lit ou met à jour chaque entité, donc qui en est propriétaire |
| Matrice | Application / données | Quelle application accède à quelle entité, et laquelle fait autorité |
| Diagramme | Données conceptuel | Les entités critiques et leurs relations, lisibles par le métier |
| Diagramme | Dissémination des données | Comment les entités logiques sont réalisées par les composants applicatifs, copies et maîtres compris |
| Diagramme | Sécurité des données | Quel acteur peut accéder à quelles données |
| Diagramme | Migration des données | Le flux des données des applications sources vers les cibles |
| Diagramme | Cycle de vie des données | Les états d'une entité, de sa création à sa suppression |
Le diagramme de dissémination mérite une phrase à part : c'est lui qui montre où une entité est répliquée et quel système en détient la référence. Quand deux applications se croient chacune maître de l'entité « Client », c'est ici que ça se voit.
La matrice entité / fonction métier
Les fonctions métier sont les propriétaires naturelles des entités de données : c'est une fonction qui crée une commande, pas une application. La matrice croise les deux et fait apparaître le propriétaire de chaque entité, les besoins d'échange d'information entre fonctions, et les écarts.
| Entité | Vendre | Préparer et livrer | Facturer | Connaître le client |
|---|---|---|---|---|
| Client | Lit, met à jour | Lit | Lit | Crée, met à jour (propriétaire cible) |
| Commande | Crée (propriétaire) | Lit, met à jour | Lit | Lit |
| Produit | Lit | Lit | Lit | |
| Stock | Lit | Crée, met à jour (propriétaire) | ||
| Facture | Crée (propriétaire) | Lit |
Deux signaux d'écart s'y lisent. « Client » est mis à jour par deux fonctions sans que la référence ait désigné un propriétaire : c'est le même écart que le « Référentiel clients » du volet applications, vu depuis les données. « Produit » est lu partout et créé nulle part dans le périmètre : son propriétaire est hors champ, il faudra une interface vers lui.
Trois considérations propres aux données
Le standard attache au volet données trois préoccupations qu'on ne retrouve nulle part ailleurs dans l'ADM. Elles pèsent d'autant plus que la transformation est large.
La gestion des données demande d'abord de nommer les composants applicatifs qui font autorité sur les données maîtres de l'entreprise, puis les standards que toutes les applications adoptent, progiciels achetés compris. Elle demande ensuite de comprendre comment les entités sont utilisées par les fonctions, les processus et les services, et où elles sont créées, stockées, transportées et restituées.
La migration s'impose dès qu'une application de référence est remplacée. Il faut en identifier les exigences, prévoir la transformation et le nettoyage, et s'appuyer sur une définition commune des données pour que la cible n'hérite pas des incohérences de la référence.
La gouvernance vérifie que l'entreprise a de quoi tenir la transformation dans la durée : une structure d'organisation, un système de management, des personnes.
Trois niveaux d'entité dans le métamodèle
Le métamodèle du content framework décrit une donnée à trois niveaux, et la confusion entre eux produit des schémas que personne ne peut utiliser. L'entité de données est le niveau conceptuel : une « chose » que le métier reconnaît, « Client » ou « Commande ». Le composant de données logique regroupe des entités liées et exprime une exigence sur la donnée : où elle est tenue, comment elle circule, qui l'utilise. Le composant de données physique est l'implémentation : la table, le fichier, le flux réellement posés.
propriétaire"] -.-> E E["Entité de données
niveau conceptuel
« Client », reconnue par le métier"] --> L["Composant de données logique
exigence sur la donnée :
au repos, en mouvement, en usage"] L --> P["Composant de données physique
la table, le fichier, le flux
réellement implémentés"] P -.-> A["Composant applicatif
qui fait autorité"] classDef concept fill:#8a4d16,stroke:#8a4d16,color:#f5f2ec classDef logique fill:#b5651d,stroke:#8a4d16,color:#f5f2ec classDef physique fill:#d89253,stroke:#8a4d16,color:#1a1a1a classDef ctx fill:#ede9e1,stroke:#8a4d16,color:#1a1a1a class E concept class L logique class P physique class F,A ctx
La phase C travaille surtout aux deux premiers niveaux. Le physique appartient au projet d'implémentation, que la phase G encadrera.
Au repos, en mouvement, en usage, ouvertes
Les exigences portées par le composant logique se formulent selon l'état de la donnée. Quatre états suffisent à couvrir ce que les diagrammes de sécurité, de dissémination et de cycle de vie doivent dire.
| État | Ce qu'il désigne | Ce que l'architecture en dit |
|---|---|---|
| Au repos | Stockée dans une base, un fichier, une archive, une sauvegarde | Localisation, rétention, protection, système qui fait autorité |
| En mouvement | En transit entre deux composants : interface, message, fichier échangé | Interfaces concernées, format, fréquence, transformation |
| En usage | Chargée en mémoire, affichée, traitée par un acteur ou un composant | Qui y accède, dans quel rôle, pour quelle fonction |
| Ouverte | Publiée vers l'extérieur sous une licence qui en permet la réutilisation | Ce qui peut sortir, à quelle granularité, avec quelle anonymisation |
Une entité de données a un propriétaire, un système qui fait autorité et un cycle de vie. Si l'un des trois manque dans la cible, l'analyse d'écarts a un trou.
Scénario B : la Digital Media Initiative de la BBC
En 2008, la BBC lance la Digital Media Initiative (DMI). L'ambition : supprimer les bandes et donner à toutes les équipes de production une chaîne numérique unique, de la prise de vues à l'archive, accessible depuis le poste de travail. Le programme est d'abord confié à Siemens, puis repris en interne en 2009 après la rupture du contrat.
En mai 2013, le directeur général de la BBC arrête le programme. Le National Audit Office (NAO) publie son rapport en janvier 2014 : la BBC a dépensé 125,9 millions de livres sur la DMI ; déduction faite des 27,5 millions récupérés dans le règlement financier avec Siemens (actifs, trésorerie, crédits de service), le coût net s'établit à 98,4 millions, et la valeur des actifs créés par le programme a été passée en pertes. Le NAO constate que les livrables principaux n'ont pas été fournis, que le programme a été conduit comme un projet technologique sans que la BBC maîtrise le changement des façons de travailler qu'il supposait, et que la direction n'a pas disposé d'une information fiable sur son avancement.
La revue indépendante de PwC, commandée par le BBC Trust et publiée en décembre 2013, va dans le même sens : une gouvernance et un reporting qui n'étaient pas à la hauteur d'un programme de cette taille, une direction qui n'a pas reçu une image fidèle de l'état réel, et des exigences qui n'ont jamais été alignées sur ce dont les équipes de production avaient besoin. Pendant que la DMI avançait, les équipes ont continué à travailler avec leurs outils existants.
Lu avec les artefacts de la phase C, le dossier se décompose en quelques manques.
Côté applications, un catalogue du portefeuille aurait listé les outils de production et d'archive réellement utilisés, site par site, avec leur statut cible. Une matrice application / organisation aurait montré quelles équipes devaient basculer, et avec quelles exigences de support. Le diagramme de localisation des utilisateurs aurait rendu visible ce que la DMI devait couvrir dans chaque centre de production.
Côté données, le cœur de la DMI était un problème d'architecture des données : l'entité « contenu média », son cycle de vie de la captation à l'archive, ses métadonnées, le système qui en fait autorité, et la migration depuis des décennies de bandes. Les trois considérations du volet, gestion, migration et gouvernance, étaient toutes trois au centre du programme.
Et l'étape 7, la revue formelle avec les parties prenantes, est celle dont les deux rapports décrivent l'absence. Des utilisateurs qui gardent leurs anciens outils sont des parties prenantes dont les préoccupations n'ont pas été couvertes, et qui le disent par leurs actes.
Un système d'information cible qui n'est pas rattaché aux services métier, aux unités qui l'utilisent et aux données qu'il doit faire circuler n'est pas une architecture. C'est un projet technologique, et il se juge à la fin sur la seule chose qu'il a produite : sa facture.
Points clés
- La phase C partage la finalité et les neuf étapes de la phase B. Seuls changent les artefacts et les considérations propres aux applications et aux données.
- Deux volets, dans l'un ou l'autre ordre, qui convergent au moment de la revue formelle et de la mise à jour du document de définition d'architecture.
- Côté applications, le catalogue du portefeuille (composants logiques et physiques) ouvre le travail, le diagramme de communication montre les interfaces et les entités qu'elles transportent, la matrice application / organisation dit qui utilise quoi. Les modèles sectoriels et le III-RM évitent de repartir de zéro.
- Côté données, la matrice entité / fonction désigne les propriétaires, et trois questions n'existent que dans ce volet : gestion, migration, gouvernance. Trois niveaux d'entité, de la conceptuelle à la physique, et quatre états : au repos, en mouvement, en usage, ouvertes.
- La Digital Media Initiative de la BBC : 98,4 millions de livres passés en pertes sur un système dont les exigences applicatives et de données n'ont jamais été alignées sur le travail réel des équipes (NAO, 2014).
Dans la série
Palier 2 : Poser les rails. Domaine : Conception.
- Précédent : Phase B : architecture métier et analyse d'écarts
- Suivant : Phase D : architecture technologique et technologies émergentes
- Vue d'ensemble : Architecture d'entreprise : par où commencer
Pour aller plus loin
- Le TOGAF Standard, 10e édition, publié par The Open Group : le document « Architecture Development Method » pour la phase C et ses deux volets, le document « Architecture Content » pour les catalogues, matrices et diagrammes
- La TOGAF Library, où vit le modèle de référence III-RM
- Les modèles sectoriels : le TM Forum pour les télécommunications, l'Object Management Group pour ses standards de modélisation et ses groupes de travail par domaine
- NAO, « Memorandum on the BBC's Digital Media Initiative » (28 janvier 2014), le mémorandum qui chiffre et explique l'arrêt du programme
- PwC, revue indépendante de la Digital Media Initiative commandée par le BBC Trust, décembre 2013 (document public du BBC Trust)
- Phase B : architecture métier et analyse d'écarts, pour les neuf étapes et la mécanique de la matrice d'écarts
- Phase D : architecture technologique et technologies émergentes, pour ce qui porte les composants applicatifs et de données
- L'ADM de TOGAF : dix phases, artefacts, livrables, points de vue, pour la différence entre catalogue, matrice et diagramme