Qu'est-ce que l'architecture d'entreprise ? Définition et domaines

Un réseau qui n'appartient à personne

Un réseau ferré national n'a pas de propriétaire unique. Le gestionnaire d'infrastructure possède les voies et les gares. Les exploitants possèdent les trains, et plusieurs se partagent les mêmes rails. Les régions financent les lignes locales, le ministère fixe les grandes orientations, le régulateur arbitre l'accès au réseau et une autorité de sécurité délivre les homologations.

Aucun de ces acteurs ne commande les autres. Pourtant, quelqu'un doit décider où iront les lignes dans dix ans, quels tronçons on ouvre en premier et à quelle norme tout le monde devra se plier pour qu'un train roule d'un bout à l'autre.

Une organisation de taille moyenne pose exactement le même problème à son système d'information. Les directions métier ont leurs applications, la DSI a ses plateformes, les filiales ont leurs contrats, les fournisseurs ont leurs feuilles de route. Personne ne possède l'ensemble, et l'ensemble doit quand même tenir.

L'architecture d'entreprise est la discipline qui décide, pour un ensemble d'organisations qui ne se commandent pas, quels systèmes elles doivent avoir, comment ils s'articulent et dans quel ordre les changer.

Ce billet pose les quatre notions sur lesquelles toute la série va s'appuyer. Dans l'ordre : ce que TOGAF appelle une entreprise (et ce n'est pas forcément une société), ce que l'ISO 42010 et TOGAF appellent une architecture, à quoi sert la discipline, puis les quatre domaines qui la structurent : métier, données, applications, technologie. Un exemple de bout en bout et un cas réel ferment la marche.

Le cadre de référence est le TOGAF Standard, 10e édition, publié par The Open Group. On le nomme, on renvoie vers lui, on ne le recopie pas.

L'entreprise : un ensemble d'organisations qui partagent des objectifs

Sur Le Chemin de fer, « le réseau » désigne tout à la fois les voies, les gares, les trains, les exploitants et le régulateur. Pas une entité juridique, mais un ensemble d'acteurs qui poursuivent un objectif commun : faire circuler des voyageurs et du fret. C'est ce périmètre-là, et non une raison sociale, que le planificateur doit tenir.

TOGAF prend « entreprise » dans ce sens large. Une entreprise est un ensemble d'organisations qui partagent des objectifs. Le standard la décrit aussi comme le plus haut niveau de description d'une organisation, couvrant l'ensemble de ses missions et de ses fonctions, et s'étendant souvent sur plusieurs organisations.

Trois conséquences pratiques en découlent.

La première : une entreprise peut dépasser la société elle-même. Quand un constructeur, ses sous-traitants de rang un et son réseau de distributeurs partagent un processus de commande et des données de référence, l'architecture doit couvrir les trois. TOGAF parle d'entreprise étendue pour ce périmètre qui inclut partenaires, fournisseurs et clients.

La deuxième : une entreprise peut n'être qu'une partie de la société. Une division, une filiale, un ministère au sein d'un État, une agence au sein d'un ministère : chacun peut être traité comme une entreprise à part entière si ses objectifs, son budget et son autorité de décision le justifient.

La troisième : une même entreprise peut porter plusieurs architectures indépendantes. Comme chaque direction régionale gère ses propres lignes en respectant les normes nationales, une grande organisation découpe son architecture en partitions, chacune avec son équipe et sa gouvernance. C'est le sujet du billet suivant ; retiens ici qu'« une entreprise » ne veut pas dire « une architecture ».

Le choix du périmètre est la première décision d'architecture, avant tout schéma. Trop large, l'équipe n'a aucune autorité réelle sur ce qu'elle décrit. Trop étroit, les problèmes intéressants restent dehors, à la frontière avec le voisin.

Une entreprise, au sens TOGAF, se définit par des objectifs partagés et un périmètre de décision, jamais par un numéro au registre du commerce.

L'architecture : deux définitions, un même noyau

Le tracé des lignes sur la carte n'est qu'une partie de l'affaire. Ce qui fait le réseau, ce sont aussi les règles qui gouvernent son évolution : plus aucun passage à niveau sur ligne nouvelle, un seul système de signalisation pour les futurs corridors, l'électrification systématique. La carte montre l'état ; les règles décident de la suite.

Deux définitions de l'architecture font autorité, et TOGAF retient les deux.

La première vient de la norme ISO/IEC/IEEE 42010, édition 2011, que TOGAF cite telle quelle : l'architecture, ce sont les concepts ou propriétés fondamentaux d'un système dans son environnement, incarnés dans ses éléments, leurs relations, et les principes qui gouvernent sa conception et son évolution. Une révision de la norme est parue en 2022 ; elle en conserve l'esprit.

La seconde est propre à TOGAF : la structure des composants, leurs interrelations, et les principes et lignes directrices qui gouvernent leur conception et leur évolution dans le temps.

Ce que les deux textes ont en commun tient en trois mots : éléments, relations, principes. Les éléments et les relations, n'importe quel schéma les montre. Les principes, non. C'est précisément ce qui sépare une architecture d'un dessin.

Un schéma d'urbanisation du système d'information dit : voilà nos applications, voilà leurs flux. Une architecture ajoute : voilà pourquoi elles sont découpées ainsi, voilà ce qu'on autorise ou refuse quand il faut en ajouter une, voilà la cible vers laquelle on les fait converger. Le schéma est une photographie. L'architecture est la photographie plus le règlement.

Éléments, relations, principes. Si tu peux retirer les principes sans que rien ne change, tu as un schéma, pas une architecture.

Pour un lecteur qui vient du génie logiciel, la définition peut sembler décalée : on y parle d'organisation, de missions, de parties prenantes, rarement de code. C'est voulu. L'ISO 42010 ne définit pas l'architecture d'un logiciel mais celle de n'importe quel système, un ministère compris. TOGAF reprend cette généralité et l'applique à l'entreprise.

À quoi sert une architecture d'entreprise

Personne ne construit un réseau ferré d'un bloc. On a la carte du réseau d'aujourd'hui, on a le schéma 2040 validé par le ministère, et entre les deux une liste de chaînons manquants qu'on comblera tronçon par tronçon, dans un ordre qui dépend des budgets, des urgences et de ce qui doit être prêt avant quoi.

La discipline existe pour tenir ce fil entre l'état actuel, l'état visé et le chemin entre les deux. TOGAF formule la finalité à peu près ainsi : optimiser, à l'échelle de l'entreprise, un héritage souvent fragmenté de processus manuels et automatisés pour en faire un environnement intégré, capable d'absorber le changement et de servir la stratégie.

Derrière cette formule, cinq usages concrets reviennent dans toute organisation qui s'y met sérieusement.

Gérer la complexité et le risque. Un système d'information de taille moyenne compte des centaines d'applications et des milliers de flux. Sans description partagée, chaque projet redécouvre les dépendances en production, au pire moment.

Relier la stratégie à la valeur. Une orientation stratégique (« vendre en direct », « ouvrir un nouveau pays ») ne se traduit pas spontanément en systèmes. L'architecture d'entreprise fait le pont : telle capacité manque, tel système doit évoluer, tel investissement en découle.

Équilibrer transformation et efficacité opérationnelle. Chaque direction veut innover vite sur son périmètre. L'ensemble a besoin de cohérence et de coûts tenus. L'architecture arbitre entre les deux, en disant où l'autonomie locale est acceptable et où elle ne l'est pas.

Gouverner le changement. Décider une fois d'une cible ne suffit pas. Il faut vérifier que les projets y convergent, accepter les écarts justifiés et refuser les autres. Sans ce contrôle, la cible reste un document.

Décrire l'état actuel, l'état futur et l'écart. C'est l'usage le plus terre à terre et le plus utile : savoir ce qu'on a, écrire ce qu'on veut, lister ce qui manque. Tout le reste de la méthode se construit sur ce triptyque.

Une architecture d'entreprise répond à trois questions, dans cet ordre : qu'avons-nous, que voulons-nous, qu'est-ce qui manque. Une organisation qui sait répondre aux trois peut planifier. Les autres réagissent.

Les quatre domaines : métier, données, applications, technologie

Quatre regards se posent sur Le Chemin de fer sans jamais se confondre. L'offre de service, avec ses lignes, ses fréquences et ses exploitants. Les registres, de l'inventaire de l'infrastructure au graphique de circulation. Les postes de commande, la billettique et l'information voyageurs. Et la voie, la caténaire, la signalisation, les dépôts.

TOGAF découpe l'architecture d'entreprise en quatre domaines qui correspondent à ces quatre regards : métier, données, applications, technologie. Les initiales anglaises donnent l'acronyme BDAT (Business, Data, Application, Technology).

L'architecture métier

Elle décrit la stratégie, la gouvernance, l'organisation et les processus clés de l'entreprise. C'est la couche qui parle le langage des directions : ce que l'entreprise fait, pour qui, et comment elle s'organise pour le faire.

On y trouve des capacités métier (« vendre », « livrer », « recouvrer »), des processus et leurs étapes, des chaînes de valeur, des fonctions, des rôles et des unités d'organisation, des objectifs et des indicateurs.

L'architecture des données

Elle décrit la structure des actifs de données logiques et physiques de l'entreprise, et les ressources qui les gèrent. Ce que l'entreprise sait, où elle le stocke, qui en est responsable, comment ça circule.

On y trouve des entités métier (client, commande, facture), des objets de données et leurs attributs, des modèles logiques et physiques, des référentiels de données de référence, des règles de qualité et de propriété.

L'architecture des applications

Elle fournit le plan des applications à déployer, de leurs interactions et de leurs relations avec les processus métier. Elle ne décrit pas le code : elle dit quelles applications existent, ce que chacune fait, et ce qu'elles s'échangent.

On y trouve des applications et des composants applicatifs, des services applicatifs, des interfaces, des flux d'échange, et la matrice qui relie applications et processus.

L'architecture technologique

Elle décrit les capacités logicielles et matérielles nécessaires pour faire tourner les services métier, données et applications. C'est le socle.

On y trouve l'infrastructure, le middleware, les réseaux, les plateformes, les services cloud, les standards techniques retenus et les environnements.

TOGAF regroupe les architectures des données et des applications sous le nom d'architectures des systèmes d'information : elles font l'objet d'une seule phase de la méthode, la phase C. Avec la technologie, elles forment ce qu'on appelle couramment l'architecture IT, par opposition à l'architecture métier qui les surplombe.

Deux préoccupations ne tiennent dans aucune bande : la sécurité et le numérique. Elles traversent les quatre domaines. Un principe de sécurité contraint aussi bien un processus métier qu'un flux de données ou un choix d'hébergement. The Open Group publie des guides de série dédiés qui montrent comment les intégrer à la méthode sans leur inventer un cinquième domaine.

Quatre domaines, une seule architecture. Le découpage sert à organiser le travail et les parties prenantes, pas à produire quatre documents qui s'ignorent.

Un exemple de bout en bout : de la commande à l'encaissement

Suis un seul train, du moment où il apparaît à l'horaire jusqu'à son arrivée : il traverse l'offre de service, les registres, les postes de commande et la voie. Le même exercice sur un processus d'entreprise montre ce que chaque domaine décrit, et pourquoi aucun ne suffit seul.

Prenons le processus le plus répandu qui soit, la commande jusqu'à l'encaissement (Order-to-Cash). Un client commande, l'entreprise livre, facture et encaisse.

Lis le schéma de haut en bas.

Dans le domaine métier, le processus se découpe en quatre étapes rattachées à la capacité « vendre ». Le rôle du vendeur, celui du comptable et l'indicateur de délai de recouvrement s'y rattachent aussi.

Dans le domaine des données, quatre entités portent le processus : le client, la commande, la facture, le paiement. Chaque étape métier crée ou modifie l'une d'elles. Qui est propriétaire de l'entité « client » quand la boutique en ligne, le CRM et l'ERP en ont chacun une copie ? C'est une question d'architecture des données, et elle est rarement tranchée.

Dans le domaine des applications, la boutique en ligne et le CRM prennent la commande, l'ERP la fait livrer, un module de facturation émet la facture, une passerelle de paiement encaisse. Les interfaces entre ces applications font partie de l'architecture au même titre que les applications elles-mêmes.

Dans le domaine technologique, tout cela tourne sur une plateforme cloud, un bus d'intégration, des bases de données et un socle réseau et identité.

Le mérite de l'exercice est de rendre visible ce qu'un seul domaine cache. Vu du métier, « facturer » est une étape. Vu des applications, c'est un module, deux interfaces et un contrat avec un prestataire. Vu de la technologie, c'est une base de données dont la sauvegarde conditionne la clôture comptable. Changer l'étape métier sans regarder les trois autres couches, c'est la définition d'un projet qui dérape.

Un processus se projette sur les quatre domaines à la fois. Si tu ne sais pas le suivre de bout en bout dans chacun, tu ne connais pas encore ton architecture.

Six bénéfices, et à qui ils profitent

Un programme ferroviaire sur dix ans profite à des gens très différents : le ministère qui arbitre entre des régions qui réclament chacune leur ligne, l'exploitant qui planifie son matériel, l'industriel qui répond à un appel d'offres contre une norme connue. L'architecture d'entreprise fonctionne de la même façon : ses bénéfices se répartissent entre des publics qui ne se parlent pas forcément.

The Open Group en liste les principaux dans l'introduction du standard. On peut les regrouper en six.

Les deux dernières tuiles méritent un mot, car on les oublie souvent.

Les achats d'abord. Une architecture écrite donne aux acheteurs des standards contre lesquels consulter : tel format d'échange, telle plateforme d'hébergement, telle exigence d'interface. Les consultations deviennent plus rapides et moins chères, parce que les fournisseurs savent à quoi se conformer et qu'on compare des offres comparables.

L'arbitrage ensuite. Toute organisation reçoit plus de demandes de projets qu'elle ne peut en financer. Sans architecture, l'arbitrage se fait au poids politique du demandeur. Avec, il se fait aussi sur la contribution à la cible : ce projet comble un écart identifié, celui-là en crée un nouveau.

L'architecture d'entreprise ne rapporte rien tant qu'elle reste dans un référentiel. Elle rapporte quand une décision d'achat, d'investissement ou d'arbitrage s'appuie dessus.

Scénario B : le Virtual Case File du FBI

Financé par le Congrès en 2000 et confié à ses industriels en 2001, Trilogy est le programme de modernisation de l'informatique du FBI, en trois volets : les postes de travail, le réseau, et une nouvelle application d'enquête destinée à remplacer l'Automated Case Support, son système de gestion des dossiers vieillissant. Ce troisième volet s'appelle le Virtual Case File (VCF) et son développement est confié à SAIC.

Les attentats du 11 septembre changent les attentes. Le FBI doit partager l'information entre ses bureaux et avec les autres agences. Le périmètre du VCF s'élargit : il ne s'agit plus de moderniser l'existant mais de le remplacer entièrement, et vite.

Le logiciel est livré en décembre 2003. Le FBI estime qu'il ne répond pas à ses exigences. Une année de tentatives de correction suit, puis une version réduite est mise à l'essai début 2005, au bureau de terrain de La Nouvelle-Orléans surtout. En avril 2005, le FBI abandonne le VCF. Le programme Sentinel, confié à un autre industriel, le remplacera des années plus tard. Environ 170 millions de dollars ont été dépensés pour le VCF.

Le Department of Justice Office of the Inspector General publie en février 2005 le rapport d'audit 05-07 sur la gestion du programme Trilogy. Il ne désigne pas un coupable unique. Il liste des causes, et plusieurs relèvent directement du sujet de ce billet :

• des exigences de conception mal définies, qui ont évolué lentement pendant tout le programme ;
• l'absence d'une architecture d'entreprise complète au démarrage de Trilogy, toujours en cours d'élaboration au moment de l'audit ;
• des faiblesses dans la gestion des investissements informatiques et dans la contractualisation ;
• un manque de continuité du management et de supervision, avec une rotation élevée des responsables ;
• un calendrier irréaliste et une intégration insuffisante entre les volets du programme.

L'article d'IEEE Spectrum « Who Killed the Virtual Case File? » (septembre 2005) reconstitue la chronologie à partir d'entretiens et de documents. Il insiste sur deux points qui recoupent l'audit : des spécifications qui changeaient en continu, et le choix d'un basculement en une seule fois depuis l'ancien système plutôt qu'une mise en service progressive.

Relis la deuxième cause de l'audit avec les définitions de ce billet en tête. Sans architecture d'entreprise, le FBI n'avait pas de description partagée de son état actuel, pas de cible stable, donc pas d'écart mesurable. Chaque changement d'exigence redevenait une négociation entre le client et l'industriel, sans référence commune pour la trancher.

Les quatre domaines bougeaient en même temps : nouveaux processus d'enquête, nouvelles données partagées, nouvelle application, nouveau socle technique, sans qu'une architecture ne dise comment les faire tenir ensemble.

Sur Le Chemin de fer, c'est commander les rames et poser la caténaire avant d'avoir arrêté le tracé, puis déplacer le tracé pendant les travaux.

L'audit du DOJ OIG ne dit pas qu'une architecture d'entreprise aurait sauvé le VCF. Il constate que son absence a privé le programme d'un référentiel pour stabiliser ses exigences et gouverner ses changements. C'est exactement l'usage décrit plus haut.

Points clés

• Une entreprise, au sens TOGAF, est un ensemble d'organisations qui partagent des objectifs : elle peut dépasser la société (partenaires, fournisseurs, clients) ou n'en couvrir qu'une division.
• Une architecture, selon l'ISO 42010 comme selon TOGAF, se compose d'éléments, de relations et de principes. Sans les principes, c'est un schéma.
• La discipline sert à décrire l'état actuel, l'état cible et l'écart, puis à gouverner le changement entre les deux.
• Quatre domaines structurent le travail : métier, données, applications, technologie. Les trois derniers forment l'architecture IT ; sécurité et numérique les traversent tous.
• Le Virtual Case File du FBI montre ce qu'il en coûte de lancer un programme de transformation sans architecture d'entreprise : des exigences qui bougent sans référence pour les arbitrer.

Dans la série

Palier 1 : Tracer la ligne. Domaine : Concepts.

• Suivant : Découper une architecture : états, portée, niveaux, partitions
• Vue d'ensemble : Architecture d'entreprise : par où commencer

Pour aller plus loin

• Découper une architecture : états, portée, niveaux, partitions : comment une même entreprise se découpe en plusieurs architectures, et ce qu'on appelle état de référence, cible et transition.
• TOGAF 10 et building blocks : le standard et ses briques : la structure du standard et l'unité de base avec laquelle on décrit les quatre domaines.
• TOGAF Standard, 10e édition (The Open Group) : les définitions d'entreprise, d'architecture et des quatre domaines, consultables en ligne dans la partie « Introduction and Core Concepts ».
• ISO/IEC/IEEE 42010 : la norme de description d'architecture dont TOGAF reprend la définition.
• U.S. Department of Justice, Office of the Inspector General, The Federal Bureau of Investigation's Management of the Trilogy Information Technology Modernization Project, Audit Report 05-07, février 2005.
• IEEE Spectrum, « Who Killed the Virtual Case File? » (septembre 2005) : la chronologie détaillée du programme.