Historique des Frameworks d’Architecture d’Entreprise

Il y a 25 ans, une nouvelle discipline est née, qui ne tarda pas à être connue sous le nom de « Architecture d’Entreprise » (AE). Les experts du domaine ont d’abord commencé à s’attaquer à deux grandes problématiques :

La complexité des systèmes: les entreprises consommaient de plus en plus de moyens dans la mise en œuvre des systèmes informatiques ;
L’alignement de l’IT avec le métier: les organisations éprouvaient de grandes difficultés pour maintenir des systèmes IT alignés avec le métier et respectant les contraintes budgétaires.

Le problème de fond à cette époque était bien d’une part l’augmentation des coûts IT et d’autre part une perte de valeur ajoutée pour le métier. Ces difficultés, d’abord identifiées il y a 25 ans, ont aujourd’hui atteint un point de crise. Le coût et la complexité des systèmes informatiques ont augmenté de façon exponentielle, alors que les chances de tirer la valeur réelle de ces systèmes ont considérablement diminuées. Les grandes organisations ne peuvent plus ignorer cette complexité et ces obstacles.

Alors qu’il y a 25 ans, la pratique de l’Architecture d’Entreprise semblait marginale, elle est considérée maintenant comme providentielle !

Une brève histoire de l’architecture d’entreprise

Le domaine de l’Architecture d’Entreprise a réellement débuté en 1987 avec la publication d’un article dans le IBM Systems Journal intitulé «Un cadre pour l’architecture des systèmes d’information», par J.A. Zachman.

Dans ce document, Zachman propose une vision de l’Architecture d’Entreprise qui va guider la discipline pour les 25 années suivantes. Le challenge consistait à gérer la complexité de systèmes de plus en plus distribués.

Comme rappelé par Zachman: « The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems. »

Dès lors, apparait le besoin grandissant de disposer d’une méthode formelle, d’un cadre de représentation (framework en anglais) pour décrire, gérer et maîtriser les systèmes d‘information.

Les principaux frameworks

Beaucoup de cadres d’Architecture d’Entreprise sont apparus depuis ces dernières années. Quels qu’ils soient, on en rencontre 4 grands types :

Les cadres de contenu ou taxonomie (certains vont même jusqu’à parler d’ontologie) : ils décrivent les concepts manipulés du SI (processus, application, …) rangés en catégories (business, technologie, …) et leurs relations.
Les cadres de processus : ces types de méthodes décrivent formellement les activités et les étapes de développement à opérer pour fournir une capacité d’AE.
Les cadres qui sont une combinaison des 2, contenu et process.
Enfin, le seul cadre de ce type, qui n’est ni vraiment un process ou une taxonomie mais qui est décrit comme une pratique, mettant en œuvre des savoir-faire, mais sans suivre un processus particulier ou un modèle de représentation spécifique.

De nos jours, la grande majorité des frameworks utilisés sont les suivants :

Zachman est défini plus précisément comme une taxonomie.
The Open Group Architecture Framework (TOGAF) est à la base une méthode de développement d’architecture mais s’est enrichi d’un framework de contenu depuis la version 9. C’est le framework le plus utilisé à ce jour.
Federal Enterprise Architecture (FEA) peut être considérée comme initialement la méthodologie la plus aboutie (avant la version 9 de TOGAF) puisqu’elle associe process et contenu.
Gartner est le cadre atypique de quatrième type : une pratique, en utilisant des compétences opérationnelles : expérience, formation et relations continues avec ses collègues …« Architecture is a verb, not a noun. »

Comment une organisation doit choisir parmi ces logiques très différentes de l’architecture d’entreprise?

Lors de l’examen de chacune de ces méthodes en profondeur, on est frappé par le fait qu’aucune de ces approches n’est vraiment complète. Chacune a ses forces dans certains domaines et des faiblesses dans d’autres. Pour beaucoup d’entreprises, aucune de ces méthodes ne sera donc une solution idéale.

La description et la comparaison de ces frameworks seront l’objet d’un prochain article.
Figure 1 : historique des principaux frameworks d’AE

L’évolution des cadres

Le pionner, Zachman

La vision de Zachman est une approche holistique de l’architecture, considérant le système comme un tout. Sa logique consiste à répondre explicitement, pour chaque perspective (Business, Technique, …), à une question : qui, quoi, comment, …

Son approche multi-perspective, décrite à l’origine comme un cadre architectural des systèmes d’information, est finalement renommée pour devenir un cadre d’Architecture d’Entreprise.

Zachman a eu une influence majeure sur l’une des premières tentatives du ministère de la Défense du gouvernement américain, pour créer une Architecture d’Entreprise. Cette tentative a été publiée sous le terme de Cadre Architecture technique pour la gestion de l’information (TAFIM), cadre introduit en 1994.

L’influence des offices gouvernementaux américains

Les promesses de TAFIM de mieux aligner les projets techniques avec les besoins métiers de l’entreprise ont été remarquées par le Congrès américain. Le Congrès a alors adopté en 1996 un projet de loi connu sous le nom Loi Clinger-Cohen, aussi connue comme la loi de réforme de gestion des technologies de l’information, qui a exigé que tous les organismes fédéraux prennent des mesures pour améliorer l’efficacité de leurs investissements informatiques.

En Avril 1998, le Conseil des DSI de toutes les instances gouvernementales majeures a commencé à travailler sur son premier grand projet, le cadre d’architecture d’entreprise fédérale (FEAF). La version 1.1 de ce cadre a été publiée en Septembre 1999.

Figure 2 : liens entre les différents frameworks d’AE

Les premières difficultés apparaissent …

Aucune organisation n’a dépensé plus d’argent pour développer l’Architecture d’Entreprise que le gouvernement des Etats-Unis, pourtant les progrès ont été lents.

En 2004, pas moins de huit ans après la Loi Clinger-Cohen, le constat sur l’adoption de capacités d’Architecture d’Entreprise est plus que mitigé. En 2005, les agences américaines ont été sévèrement réprimandées pour les échecs dans l’adoption des pratiques d’AE.

Le temps de la maturité

Le travail effectué sur TAFIM a été remis à l’Open Group qui l’a transformé et amélioré en une nouvelle norme qui est aujourd’hui connue par son acronyme, TOGAF. C’est le cadre le plus utilisé dans le monde à ce jour. Il jouit de la puissance de l’Open Group pour faciliter son adoption par les organisations.

En 2009 la version la plus aboutie, TOGAF 9, introduit un framework de contenu et développe son framework de capacités.

En 2005, alors que l’OMB (the Office of Management and Budget) devenait la force dominante EA dans le secteur public, une autre organisation prenait de l’ampleur dans le secteur privé, Gartner, une des sociétés les plus influentes spécialisées dans le conseil auprès des CIO. C’est après le rachat de Meta Group, que le groupe Gartner se spécialise dans l’AE pour enfin publier son framework.

Conclusion

Quel que soit le cadre choisi, sa mise en œuvre ne pourra aboutir que s’il existe un réel engagement de l’organisation à transformer son Architecture d’Entreprise. Cet engagement doit être conduit par le plus haut niveau de l’organisation.

La bonne nouvelle est, qu’avec une vraie volonté de changement et d’une méthode adaptée pour guider cette transformation, cette vielle promesse de 25 ans qu’est l’Architecture d’Entreprise est à notre portée.

Cette promesse n’a pas changé: la réduction des coûts informatiques et de la complexité, tout en augmentant la valeur de l’entreprise et l’efficacité ou, pour le dire plus simplement encore, améliorer votre compétitivité dans un monde de plus en plus concurrentiel.

Le prochain article présentera et comparera les principaux cadres d’architecture utilisés ce jour : Zachman ; TOGAF, Gartner et FEA.

Gunther BONNARD, Enterprise Architecture

Bonjour Gunther,

Depuis si longtemps que l’industrie informatique construit, défait et transformer des méthodes d’industrialisation dans le but d’accroitre ses performances (répondre aux besoins des métiers dans des coûts et risques maitrisés au sein d’un univers technologique à croissante exponentielle), se lancer dans l’histoire de l’architecture d’entreprise est un thème de thèse universitaire sinon une véritable gageure.
Je salue donc cet article qui tente une synthèse courageuse de cette histoire.
Je souhaite néanmoins apporter une remarque.
Comme indiqué dans votre article, les frameworks d’architecture ne sont que, comme leur nom l’indique, des cadres qui permettent de garantir et de s’assurer de la couverture de l’ensemble des sujets qui structurent la problématique des systèmes d’information. En ce sens, on peut en effet les approcher d’une taxonomie.
Ceux proposé comme « les cadres de processus » sont effectivement plus rares c’est-à-dire les « framework » qui propose une taxonomie (un modèle) et un ensemble de tâches avec des produits (un processus). Un de ces cadres est cité en creux dans l’article, il figure en effet dans le schéma de filiation des méthodes mais n’apparait pas dans cette synthèse.
Il s’agit de ne pas oublier l’apport de Capgemini avec l’Integrated Architecture Framework [IAF] qui est utilisé par d’importantes firmes mondiales et est accosté avec TOGAF. IAF propose en effet, une liste de tâche avec des produits en entrée et des produits en sortie. Ces produits sont des « deliverables » c’est-à-dire des documents structurés avec un contenu pré-formaté ou des guidelines assez précis qui permettent d’aller rapidement à l’essentiel.
Je ne fais pas l’apologie de IAF parce que je travaille chez Capgemini, je le pratique finalement assez peu au final mais je sais que les travaux de Capgemini, avec IAF, au sein de l’OpenGroup ont permis d’enrichir le framework TOGAF.

J’en profite pour dire que j’aurai tendance à faire entrer aussi les processus ITIL dans le type de « framework » processus. La production informatique est le parent pauvre des architectes d’entreprise qui, par appétence pour la conception amont ou par méconnaissance du travail laborieux de l’exploitation, oublient souvent cet aspect des systèmes d’information.

Pour finir, une question : quelle est la logique sous-jacente, le paradigme, qui conduit chacun de ces frameworks et qui, au final, modèle les systèmes d’information ?

Cordialement,
Jean-Thomas Stévenin

Répondre

Commentaire

Jean-Thomas Stévenin dit :

13 mai 2015 à 9 h 59 min

Bonjour Gunther,

Depuis si longtemps que l’industrie informatique construit, défait et transformer des méthodes d’industrialisation dans le but d’accroitre ses performances (répondre aux besoins des métiers dans des coûts et risques maitrisés au sein d’un univers technologique à croissante exponentielle), se lancer dans l’histoire de l’architecture d’entreprise est un thème de thèse universitaire sinon une véritable gageure.
Je salue donc cet article qui tente une synthèse courageuse de cette histoire.
Je souhaite néanmoins apporter une remarque.
Comme indiqué dans votre article, les frameworks d’architecture ne sont que, comme leur nom l’indique, des cadres qui permettent de garantir et de s’assurer de la couverture de l’ensemble des sujets qui structurent la problématique des systèmes d’information. En ce sens, on peut en effet les approcher d’une taxonomie.
Ceux proposé comme « les cadres de processus » sont effectivement plus rares c’est-à-dire les « framework » qui propose une taxonomie (un modèle) et un ensemble de tâches avec des produits (un processus). Un de ces cadres est cité en creux dans l’article, il figure en effet dans le schéma de filiation des méthodes mais n’apparait pas dans cette synthèse.
Il s’agit de ne pas oublier l’apport de Capgemini avec l’Integrated Architecture Framework [IAF] qui est utilisé par d’importantes firmes mondiales et est accosté avec TOGAF. IAF propose en effet, une liste de tâche avec des produits en entrée et des produits en sortie. Ces produits sont des « deliverables » c’est-à-dire des documents structurés avec un contenu pré-formaté ou des guidelines assez précis qui permettent d’aller rapidement à l’essentiel.
Je ne fais pas l’apologie de IAF parce que je travaille chez Capgemini, je le pratique finalement assez peu au final mais je sais que les travaux de Capgemini, avec IAF, au sein de l’OpenGroup ont permis d’enrichir le framework TOGAF.

J’en profite pour dire que j’aurai tendance à faire entrer aussi les processus ITIL dans le type de « framework » processus. La production informatique est le parent pauvre des architectes d’entreprise qui, par appétence pour la conception amont ou par méconnaissance du travail laborieux de l’exploitation, oublient souvent cet aspect des systèmes d’information.

Pour finir, une question : quelle est la logique sous-jacente, le paradigme, qui conduit chacun de ces frameworks et qui, au final, modèle les systèmes d’information ?

Cordialement,
Jean-Thomas Stévenin

Répondre