Phase D : architecture technologique et technologies émergentes

La signalisation qui change ce qu'une ligne peut écouler

Sur Le Chemin de fer, trois couches portent tout le reste : la voie, la caténaire, la signalisation. Le voyageur ne les regarde pas, l'exploitant ne les possède pas. Ce sont pourtant elles qui fixent combien de trains passent par heure, à quelle vitesse et avec quel tonnage.

Puis une signalisation nouvelle arrive. Le système européen de contrôle des trains, déployé corridor après corridor, permet de rapprocher les circulations sur une voie existante : davantage de trains, sans poser un rail de plus. Aucun exploitant ne l'avait écrit dans sa lettre de mission. L'infrastructure l'a rendu possible, et l'offre de service s'est réorganisée autour.

La phase D de l'ADM a ce double visage. D'un côté, l'architecture technologique est le socle : les composants et les services qui portent les briques métier, données et applications décrites en B et en C. De l'autre, elle est un moteur : une technologie qui mûrit change ce que l'entreprise peut faire avant qu'une direction métier ait pensé à le demander.

Le billet suit le même parcours que les deux précédents. Finalité et objectifs, les étapes (identiques à celles de B et C), les artefacts propres au domaine, puis la partie que le TOGAF Standard met en avant pour cette phase : les technologies émergentes, et les ressources qui évitent de repartir d'une page blanche. En scénario B, la migration de Netflix vers le cloud public, racontée par l'entreprise elle-même.

La phase D répond à une première question : avec quoi faire tourner ce que B et C ont décidé ? Et à une seconde, plus dérangeante : qu'est-ce que la technologie permettrait, que personne n'a encore demandé ?

Vue d'ensemble : ce que la phase D doit produire

Dans le cycle de l'ADM, la phase D ferme le triptyque des architectures de domaine. B a décrit l'offre de service, C les registres et les postes de commande ; D décrit la voie sur laquelle tout cela roule.

Le TOGAF Standard lui donne deux objectifs. Le premier : développer l'architecture technologique cible qui permet de livrer la vision d'architecture et les briques cibles des trois autres domaines au travers de composants et de services technologiques, en respectant l'énoncé des travaux et les préoccupations des parties prenantes. Le second : identifier les composants candidats de la feuille de route, à partir des écarts entre l'architecture technologique de référence et la cible.

Le vocabulaire compte ici. Un service technologique est une capacité technique offerte à une application : exécuter du code, persister des données, acheminer des messages. Un composant technologique logique est la classe de produit qui rend ce service, indépendante du fournisseur : c'est une brique d'architecture. Un composant technologique physique est le produit réellement déployé, avec sa version et son contrat de support : c'est une brique de solution.

La phase ne part pas de rien : elle hérite de tout ce que le cycle a déjà produit, et rend des livrables que E et F consommeront.

Le livrable qui compte le plus n'est pas la liste des produits achetés, mais la liste des services technologiques que les applications attendent, avec, pour chacun, le composant qui le rend.

Les étapes : les mêmes que pour B et C

L'étude d'une ligne passe par les mêmes passes, qu'on travaille le service, l'horaire ou la voie : relever l'existant, dessiner la cible, lister ce qui manque, faire valider. Ce qui change d'un cahier à l'autre, ce sont les plans qu'on produit.

La phase D reprend telles quelles les neuf étapes de B et de C. Le TOGAF Standard insiste sur un point : l'ordre est indicatif, et une architecture technologique s'écrit souvent en plusieurs passes, du modèle de plateforme générique aux spécifications de matériel.

Trois étapes méritent un commentaire propre au domaine technologique.

Décrire la référence est souvent plus facile ici qu'ailleurs : l'inventaire existe déjà, dans la base de gestion de configuration, les contrats de support, la supervision. Le travail consiste à le remonter au niveau du service et du composant logique, parce qu'une liste de serveurs n'est pas une architecture.

Décrire la cible oblige à traduire des exigences non fonctionnelles en choix de plateforme : disponibilité, latence, volume, souveraineté des données, coût d'exploitation. C'est aussi là qu'on tranche entre bâtir, acheter ou louer un service.

Résoudre les impacts sur le paysage pèse plus lourd qu'en B ou C. Une plateforme est partagée : changer de courtier de messages ou de fournisseur cloud touche des segments qui n'ont rien demandé. L'étape existe pour qu'on aille les prévenir avant la revue formelle, pas après.

En phase D, l'analyse d'écarts a une sortie très concrète : la liste des technologies à introduire, à mettre à niveau et à retirer. C'est elle qui nourrit la feuille de route de la phase E.

Les artefacts : le registre de l'infrastructure

Le gestionnaire du réseau tient un registre de l'infrastructure : chaque tronçon, son type de voie, sa caténaire, ses appareils de voie, ses postes, avec la date de pose et l'état. À côté, le schéma de voies du cheminot montre comment tout s'enchaîne. Deux documents, deux usages : savoir ce qu'on a, voir comment ça tient ensemble.

Le TOGAF Standard propose pour la phase D une famille d'artefacts qui joue exactement ces deux rôles.

Trois d'entre eux structurent le travail. Les autres se construisent à partir d'eux.

Le catalogue du portefeuille technologique

C'est le point de départ. Il recense toute la technologie en service dans l'entreprise, en trois catégories : le matériel, les logiciels d'infrastructure (systèmes, bases de données, middleware, outils d'exploitation) et les logiciels applicatifs. Chaque ligne relie un service technologique à son composant logique et à son composant physique.

Son usage dépasse l'architecture : il sert à la gestion des licences, des contrats de support et des fins de vie. Un catalogue tenu par l'exploitation et relu par l'architecture vaut mieux que deux inventaires qui divergent.

La colonne « État » fait tout l'intérêt du tableau : la même ligne logique apparaît deux fois quand la référence et la cible divergent, et l'écart saute aux yeux.

Le diagramme de décomposition de plateforme

Il montre la plateforme technologique qui porte les systèmes d'information : tous les aspects de l'infrastructure, vus d'ensemble. On peut le décliner par domaine fonctionnel pour relier chaque composant applicatif aux composants technologiques qui le portent, avec les détails de spécification utiles : versions, capacités, nombre d'instances.

Ce que le diagramme rend visible, et qu'aucune liste ne montre : deux applications qui dépendent du même composant partagent son cycle de vie, ses pannes et ses fenêtres de mise à jour.

Le diagramme environnements et localisation

Il répond à trois questions : quels sites hébergent quelles applications, quelles technologies sont utilisées à quel endroit, depuis où les utilisateurs interagissent avec les applications. Il montre aussi les environnements de déploiement (développement, recette, production) et où chacun vit.

Un artefact de phase D décrit des services rendus, par quels composants, où, et pour qui. La machine n'est que la dernière colonne.

Les technologies émergentes

Quand la caténaire arrive sur une ligne, personne ne se contente de remplacer les locomotives diesel par des électriques. Les rames accélèrent plus fort, les arrêts se rapprochent, les horaires se resserrent, les correspondances changent. L'étude de trafic d'origine n'avait rien prévu de tout cela ; la technologie a ouvert une offre.

Le TOGAF Standard fait de la phase D le moment où l'architecte regarde ce qui mûrit. L'idée tient en une phrase : faire de la technologie un moteur de changement et une ressource stratégique, plutôt qu'un simple destinataire de demandes de changement venues des métiers.

Concrètement, cela impose de travailler dans deux sens à la fois. Dans le sens descendant, l'architecture technologique répond aux exigences des systèmes d'information : c'est le travail décrit dans les sections précédentes. Dans le sens montant, elle propose : telle technologie permettrait telle capacité métier que personne n'a encore réclamée.

Le standard ajoute un avertissement. L'adoption rapide d'une technologie crée des discontinuités : des compétences qui manquent, un modèle d'exploitation qui ne suit pas, des règles de sécurité et de données écrites pour l'ancien monde. Anticiper, c'est aussi anticiper cela, et l'inscrire dans l'évaluation de la maturité à la transformation vue en phase A.

En pratique, trois dispositifs tiennent ce rôle sans alourdir la phase. Une veille technologique rattachée à la capacité d'architecture, qui alimente le catalogue des standards avec un statut par technologie : en évaluation, standard, en confinement, en retrait. Une architecture candidate, au sens du billet sur les états : un tracé à l'étude que personne n'a encore approuvé, mais qu'on documente comme s'il allait l'être. Et un lien explicite avec la gestion des exigences, pour qu'une opportunité technologique devienne une exigence tracée plutôt qu'un projet mené en douce.

Une technologie émergente qui n'est inscrite nulle part finit toujours par entrer quand même, par la porte de service, sans architecture. Autant lui ouvrir la grande porte et la documenter.

Les ressources : ne pas repartir d'une page blanche

Personne ne redessine l'écartement des rails pour chaque ligne nouvelle. Les fiches internationales fixent les règles communes, les spécifications européennes précisent ce qu'exige un corridor, le gestionnaire ajoute ses règles maison. L'étude de ligne commence par les lire, pas par les réinventer.

La phase D dispose du même continuum, du générique au spécifique. Trois familles de ressources évitent de concevoir ce qui existe déjà.

Deux précisions sur les modèles de The Open Group. Dans la 10e édition, le TRM et le III-RM ne font pas partie du contenu fondamental du standard : The Open Group les publie à part, comme guides de série, dans la TOGAF Library. Et ce sont des taxonomies, pas des cibles : elles servent à vérifier qu'on a pensé à tout.

Un modèle de référence ne te dit pas quoi acheter. Il te dit quelles cases ton architecture doit remplir, et te laisse le choix pour chacune.

Scénario B : Netflix, sept ans pour changer de socle

Le cas vient de l'entreprise elle-même. En février 2016, Netflix publie sur son blog technique « Completing the Netflix Cloud Migration ». Ce qui suit s'en tient à ce que ce billet dit.

Le déclencheur date d'août 2008 : une corruption majeure de base de données empêche pendant trois jours l'expédition des DVD aux abonnés. Netflix en tire une décision d'architecture technologique : s'éloigner des points de défaillance uniques dimensionnés verticalement, comme les bases relationnelles de son centre de données, pour aller vers des systèmes distribués, hautement fiables et dimensionnés horizontalement, dans le cloud. Le fournisseur retenu est Amazon Web Services, choisi d'après le billet pour son échelle et l'étendue de ses services.

La migration s'achève début janvier 2016, quand l'entreprise éteint les derniers éléments de centre de données utilisés par son service de streaming. Sept ans. L'essentiel des systèmes, dont tous les services exposés aux clients, avait basculé avant 2015. Le temps restant a servi à trouver un chemin sûr et durable pour la facturation et pour la gestion des données des clients et des salariés.

Le billet défend un choix qui concerne directement la phase D : ne pas déplacer tel quel. Transporter les systèmes inchangés du centre de données vers le cloud aurait été la voie la plus facile, mais aurait emporté avec eux tous les problèmes et toutes les limites de l'ancien socle.

Netflix a préféré une approche native du cloud, en reconstruisant la quasi-totalité de sa technologie. Passage d'une application monolithique à des centaines de microservices. Modèle de données dénormalisé sur des bases NoSQL. Et un mode de fonctionnement transformé : les validations budgétaires, la coordination centralisée des mises en production et les cycles d'approvisionnement matériel de plusieurs semaines laissent place à la livraison continue et à des équipes autonomes outillées en libre-service.

Les bénéfices rapportés sont ceux d'une architecture cible choisie pour ses propriétés. L'élasticité : des milliers de serveurs virtuels et des pétaoctets de stockage ajoutés en quelques minutes, pour un service qui compte huit fois plus d'abonnés au streaming qu'en 2008 et dont le visionnage a crû de trois ordres de grandeur en huit ans. La disponibilité : un objectif de quatre neuf, dont le cloud a rapproché le service. Le coût : une dépense par démarrage de lecture ramenée, dit le billet, à une fraction de celle du centre de données.

Lu avec les lunettes de la phase D, le cas montre quatre choses. Une brique d'architecture formulée en propriétés (distribué, horizontal, élastique) avant la brique de solution qui la réalise (un fournisseur cloud donné). Une cible atteinte par transitions, service après service, les plus sensibles en dernier. Une technologie émergente, le cloud public de 2008, traitée comme un moteur et non comme la réponse à une demande métier. Et la discontinuité annoncée par le standard, assumée ici jusqu'au bout : changer de socle a voulu dire changer d'organisation, de compétences et de manière de livrer.

Netflix a défini une architecture technologique cible par ses propriétés, puis a accepté que l'atteindre prenne sept ans et change tout le reste. C'est la phase D poussée jusqu'à ses conséquences.

Points clés

• La phase D produit l'architecture technologique de référence et cible : les services technologiques que les applications attendent, les composants logiques qui les rendent, les composants physiques qui les réalisent, et les composants candidats de la feuille de route.
• Les neuf étapes sont celles de B et C ; en D, décrire la référence s'appuie sur l'inventaire d'exploitation, décrire la cible traduit les exigences non fonctionnelles, et résoudre les impacts sur le paysage pèse plus lourd parce qu'une plateforme est partagée.
• Trois artefacts structurent le travail : le catalogue du portefeuille technologique (point de départ), le diagramme de décomposition de plateforme (qui dépend de quoi) et le diagramme environnements et localisation (quoi, où, pour qui).
• La technologie est un moteur autant qu'un socle : anticiper, innover, capter, piloter, en sachant que l'adoption rapide crée des discontinuités à inscrire dans la maturité à la transformation.
• Netflix, de 2008 à 2016, illustre une cible définie par ses propriétés, atteinte par transitions, en choisissant de reconstruire plutôt que de déplacer.

Dans la série

Palier 2 : Poser les rails. Domaine : Conception.

• Précédent : Phase C : architectures des données et des applications
• Suivant : Phase E : opportunités, solutions, risques et feuille de route
• Vue d'ensemble : Architecture d'entreprise : par où commencer

Pour aller plus loin

• Le TOGAF Standard, 10e édition, publié par The Open Group : la phase D dans le document ADM, les artefacts technologiques dans le document Architecture Content
• La TOGAF Library, où The Open Group publie désormais le TRM et le III-RM
• Netflix TechBlog, « Completing the Netflix Cloud Migration » (février 2016), la source unique du scénario B
• Phase C : architectures des données et des applications, pour les briques que la phase D doit porter
• Phase E : opportunités, solutions, risques et feuille de route, où les écarts de B, C et D deviennent des lots de travail
• Découper une architecture : états, portée, niveaux, partitions, pour l'architecture candidate évoquée plus haut
• TOGAF 10 et building blocks : le standard et ses briques, pour la distinction entre brique d'architecture et brique de solution