Partie 5. Urbanisme des SI et architecture d'entreprise

Partie 5 Urbanisme des SI et

 

architecture d'entreprise

 

Chapitre 11. De l'urbanisme des SI à l'Enterprise Architecture

 

OceanofPDF.com

Chapitre 11

 

De l'urbanisme des SI à

 

l'Enterprise Architecture

 

11.1. L'historique de la démarche

d'urbanisation des SI

 

L'urbanisme des systèmes d'information a débuté en France dans la seconde moitié des années 1990. Il y a treize ans environ après de nombreux échecs de refonte complète de SI, il est apparu nécessaire de concevoir une nouvelle approche pour l'adaptation des systèmes d'information des entreprises permettant de les faire évoluer progressivement, en premier lieu selon les exigences métiers plutôt qu'au gré des évolutions technologiques et en concentrant les investissements sur les briques dont la refonte présente le meilleur ratio coût/bénéfice. De manière assez logique, les grandes entreprises dans lesquelles le système d'information est indispensable aux opérations et qui disposaient déjà à l'époque d'un patrimoine SI considérable ont été les premières à ressentir l'impérieuse nécessité de transformer l'approche d'évolution de leurs SI. C'est ainsi que vers 1996, l'idée d'appliquer aux systèmes d'information les principes de l'urbanisme de la cité qui couvait depuis quelque temps a commencé à être expérimentée principalement dans les banques, les assurances et chez les opérateurs de télécommunications. Ainsi, dès 1997 les premières approches structurées sont apparues comme Iteor/urbanisation que j'ai eu l'opportunité développer pour Sema Group. La publication par Jacques Sassoon de « l'urbanisation des systèmes d'information » en 1998 est probablement le premier ouvrage français sur le sujet et pose les bases de la discipline.

L'année 2000 est également un jalon important pour l'urbanisme à la française avec la création du Club Urba-SI (devenu depuis Club Urba EA), club des urbanistes et des architectes de systèmes d'information, à l'initiative d'AXA, de la RATP, de la Lyonnaise des Eaux, de la FNAC et d'Oresys. La vocation de ce Club était et demeure de favoriser les partages d'expériences, les échanges entre praticiens de l'urbanisme des SI et de l'architecture d'entreprise ainsi que de promouvoir la reconnaissance et l'organisation de ces fonctions. En 2008, le Club Urba EA a franchi la barre symbolique des 100 membres de 65 entreprises différentes. La publication de la première édition du présent ouvrage au dernier trimestre 2001 a semble-t-il contribué à asseoir les fondements de l'urbanisme à la française : ce fut le premier ouvrage proposant un cadre assez complet comprenant : un cadre de référence (aujourd'hui communément appelé framework), un méta modèle des concepts, des règles, une architecture fonctionnelle générique type, un processus méthodologique, des intervenants types, le tout illustré par un cas concret. À partir de 2001, les choses s'accélérèrent et les grandes entreprises et administrations commencèrent à s'intéresser de près à l'urbanisme des systèmes d'information et même pour la plupart à le mettre en œuvre. C'est aussi l'époque où la discipline fait son apparition dans les cursus de nos universités et de nos écoles d'ingénieurs. J'ai pour ma part pris la responsabilité du module « urbanisation et architecture technologique des SI » de l'Institut du management de l'information (université de technologie de Compiègne) dès 1999.

Enfin, c'est aussi au début des années 2000 que l'urbanisme des SI devient un véritable centre de profit pour les cabinets de conseil et les sociétés de services informatiques.

Le CIGREF (Club informatique des grandes entreprises françaises) ne pouvait pas manquer de s'intéresser à ce sujet important pour les directeurs des systèmes d'information (DSI) de ses entreprises adhérentes et publia en 2003 un livre blanc intitulé Accroître l'agilité des SI. Il y avait encore à cette époque quelques réfractaires arguant que cette discipline ne concernait ni les administrations pour lesquelles il n'y avait pas d'objectifs de rentabilité économique, ni les industries pour lesquelles

les ERP[1] représentaient la panacée et rendaient inutile tout effort d'urbanisation.

Rapidement pourtant, on vit de grandes administrations urbaniser leurs SI car elles avaient bien des objectifs métiers (pas nécessairement des objectifs de retour sur investissement mais des objectifs d'amélioration du service à l'usager, d'amélioration de l'efficience) et des besoins d'évolution progressive de systèmes d'information devenus si importants qu'une refonte globale n'était plus envisageable. On vit également les entreprises industrielles adopter massivement ces approches. Certes les ERP représentaient souvent une part importante de leurs SI mais pas la totalité. Et l'intégration de ces ERP avec les autres briques du SI (progiciels et applications spécifiques, référentiels…) et dans le cas d'entreprises étendues avec les SI de partenaires justifia la mise œuvre de cette démarche. Les cas de Renault et de Schlumberger pour l'industrie et du Ministère des Finances où encore celui de la CNAM (Caisse nationale d'assurance-maladie) pour les administrations illustrent ce propos.

Depuis, toutes les grandes entreprises et administrations ont une démarche et des moyens dédiés à l'urbanisation même si la maturité, l'angle d'attaque et les moyens consacrés sont bien entendus hétérogènes. Dès 2003, la communauté de pensée des urbanistes a pris conscience du développement outre Atlantique d'une approche appelée Enterprise Architecture qui présentait beaucoup de similitudes. Dès lors, la veille s'organisa et le Club Urba SI et le CIGREF organisèrent des évènements permettant à leurs adhérents de découvrir l'Enterprise Architecture et d'explorer les bénéfices à en tirer.

L'année 2007 a été marquée par deux évènements : la création du CEISAR (Center of excellence for Enterprise Architecture adossé à l'Ecole Centrale de Paris) qui vise à rassembler toutes les bonnes initiatives en vue de former les jeunes ingénieurs et de perfectionner des ingénieurs expérimentés et celle du chapitre français du forum architecture de l'Open Group qui vise quant à lui à promouvoir TOGAF (The Open Group Architecture Framework) et à contribuer à son évolution.

Aujourd'hui, la plupart des entreprises du CAC 4O [2] et des grandes administrations ont une entité dédiée à l'architecture et à l'urbanisme des SI et les entreprises internationales ont souvent commencé à évoluer vers l'Enterprise Architecture afin de s'aligner sur les standards internationaux qui facilitent le déploiement dans toutes les composantes des entreprises. Globalement, les systèmes d'information existants sont tous cartographiés (surtout des points de vue processus métier, fonctionnel et applicatif mais moins systématiquement du point de vue des infrastructures techniques). Le lien entre l'urbanisme et la gouvernance IT existe toujours mais avec des degrés de maturité très divers. Les faiblesses couramment constatées concernent plutôt la cartographie des flux.

L'enseignement de l'Enterprise Architecture est maintenant intégré dans la plupart des cursus de formation des écoles d'ingénieurs, de commerce et des universités.

 

11.2. L'historique de la démarche

d'Enterprise Architecture

 

Il convient tout d'abord de définir l'Entreprise Architecture. Nous retiendrons ici la définition du Gartner Group : « L'architecture d'entreprise est un processus de transformation de la vision et de la stratégie en changements effectifs dans l'entreprise en créant, communicant et en améliorant les principes clés et les modèles qui décrivent la cible à atteindre pour l'ensemble des ressources de l'entreprise et en rendant possible son évolution ».

Le point de départ de l'Enterprise Architecture se situe en 1987 avec la publication, dans le IBM Systems Journal, d'un article intitulé « A framework for information systems architecture » par John Zachman. J. Zachman a alors écrit : « Pour préserver l'activité de la désintégration, le concept d'une architecture de systèmes d'information devient de moins en moins une option et de plus en plus une nécessité. » Il a présenté un nouveau modèle pour visualiser et communiquer sur les architectures d'entreprises. Zachman définit l'Enterprise Architecture comme un ensemble de représentations pertinentes pour décrire l'entreprise et qui une fois établies constituent la base de référence pour transformer l'entreprise.

Le modèle proposé est une matrice croisant :

des points de vue ou des perspectives pris par les divers acteurs (ce

sont les lignes de la matrice) :

1. Périmètre/Stratège ; 2. Modèle d'Entreprise/Propriétaire ; 3. Modèle du système/Concepteur ; 4. Modèle technologique/Développeur ; 5. Représentation détaillée/Sous-traitant ;

6. Le système lui-même.

avec les concepts de bases pour décrire une architecture (ce sont les

colonnes de la matrice) qui chacun permettent de répondre à une

question :

1. Donnée/Quoi ?

2. Fonction/Comment ? 3. Réseau/Où ?

4. Personne/Qui ?

5. Temps/Quand ?

6. Objectif/Pourquoi ?

Bien que publié en 1987, le Framework de Zachman et l'Enterprise Architecture n'ont réellement décollé aux États-Unis qu'une dizaine d'années plus tard.

Zachman a très fortement influencé les premières tentatives du ministère de la défense Américain pour créer un framework d'Enterprise Architecture. Le résultat baptisé TAFIM (Technical Architecture Framework for Information Management) a été publié en 1994. Il a fallu attendre le Clinger-Cohen Act de 1996 pour voir cette discipline prendre un réel essor. Le Clinger-Cohen Act impose aux administrations fédérales des États-Unis l'élaboration d'une Enterprise IT Architecture (sans Enterprise IT Architecture, pas de budget). Dès lors, toutes les administrations fédérales se lancent dans l'Enterprise Architecture et le framework de Zachman étant bien loin d'offrir un cadre de référence complet, commencent par développer leurs propres cadres. Puis en 1998, le CIO Council commence son travail sur son plus grand projet, le Federal Enterprise Architecture Framework (FEAF), qui deviendra en 2002 le Federal Enterprise Architecture (FEA). En 1998, le travail fait sur TAFIM fut confié à l'Open Group qui l'intégra dans « The Open Group Architecture Framework (TOGAF) ». La fin des années 1990 et le début des années 2000 marquent l'extension de l'approche aux grandes entreprises du secteur privé. Comme en France, après de nombreux échecs de refonte complète de SI, il est apparu nécessaire de concevoir une nouvelle approche pour l'adaptation des systèmes d'information des entreprises permettant de les faire évoluer progressivement, en premier lieu selon les exigences métiers plutôt qu'au gré des évolutions technologiques et en concentrant les investissements sur les briques dont la refonte présente le meilleur ratio coût/bénéfice. Là aussi, comme en France ce sont les secteurs économiques dans lesquels le SI joue le rôle le plus important qui avaient les patrimoines les plus conséquents et donc les plus gros enjeux qui se lancèrent les premiers : banques et institutions financières, opérateurs de télécommunications furent donc les précurseurs.

Les publications sont nombreuses comme « The art of strategic planning for Information Technology » et « Constructing Blueprints for Enterprise IT Architectures » de Bernard Boar.

Enfin, il convient de noter que dans Enterprise Architecture le mot Enterprise ne signifie pas nécessairement toute l'entreprise. Une « Entreprise » est un regroupement d'activités d'entreprise en interaction capable de fonctionner comme une entité indépendante et autonome. On peut donc définir l'architecture d'entreprise d'une ligne métier au sein d'un métier (regroupement de lignes métiers) appartenant lui-même à un groupe multimétiers. On peut par exemple définir l'architecture d'entreprise de la ligne métier assurance dommages d'un métier assurances (regroupant les trois lignes métiers assurance dommages, assurance-vie et assurance santé) d'un même groupe financier.

L'entreprise peut également être vue comme « entreprise étendue », signifiant que le champ d'action d'un effort d'architecture d'entreprise pourrait également inclure des corrélations avec les entités externes comme fournisseurs, partenaires d'affaires et clients.

Aujourd'hui, la plupart des grandes entreprises américaines et toutes les administrations fédérales ont une entité dédiée à l'Enterprise Architecture ou plus précisément à sa partie IT qu'on peut appeler Enterprise IT Architecture.

Globalement, les systèmes d'information existants sont tous cartographiés (surtout des points de vue processus métier, données et applications mais moins systématiquement du point de vue des infrastructures techniques). Le lien entre l'Enterprise Architecture et la gouvernance IT existe toujours mais avec des degrés de maturité très divers.

L'enseignement de l'Enterprise Architecture est intégré dans les cursus de formation des universités.

11.3. Les principaux standards de

l'Enterprise Architecture

 

11.3.1. Introduction

Force est de constater l'existence de nombreuses démarches d'Enterprise Architecture basées sur autant de définitions. Il y a d'abord de très nombreuses approches spécifiques (s'inspirant ou non d'approches publiées) développées par les entreprises pour répondre à leurs propres besoins.

Il faut également y ajouter les approches publiées, elles aussi relativement nombreuses, dont on ne cherchera pas à donner une liste exhaustive. Nous nous bornerons à en citer quelques-unes (source : IFEAD, Institute For Enterprise Architecture Developments) :

Zachman Framework ;

Integrated Architecture Framework (IAF) ;

Extended Enterprise Architecture Framework (E2AF) ;

Enterprise Architecture Planning (EAP) ;

Federal Enterprise Architecture Framework (FEAF) ;

Treasury Enterprise Architecture Framework (TEAF) ;

The Open Group Architecture framework (TOGAF) ;

Joint Technical Architecture (JTA) ;

Department of Defence Technical Reference Model (DoD TRM) ;

Technical Architecture Framework For Information Management

(TAFIM) ;

Computer Integrated Manufacturing Open System Architecture

(CIMOSA).

Nous allons nous limiter ici à la présentation du framework de Zachman (le plus ancien) et de TOGAF qui constitue l'un des grands standards et qui est certainement le plus complet. Pour plus d'information sur les autres framework le site l'IFEAD (www.enterprise-architecture.info/) constitue un excellent point d'entrée.

 

11.3.2. Le framework de Zachman Comme évoqué dans l'historique de la démarche d'Enterprise Architecture, John Zachman a proposé le framework qui porte désormais son nom en 1987 dans le IBM Systems Journal. Le framework de Zachman propose une approche de représentation de l'architecture d'une entreprise, qu'il organise suivant différents points de vue et selon différents concepts.

La puissance de cette représentation se trouve dans la segmentation des différentes ressources de l'entreprise selon les différents points de vue nécessaires et selon le spectre des différentes problématiques de tout projet de l'entreprise. Le framework est représenté ci-après (source ZIFA : the Zachman Institute for Framework Advancement's. WWW.ZIFA.COM)

 

Fig. 11.1

 

Les lignes de cette matrice correspondent aux points de vue (perspectives) pris par les divers acteurs de la construction d'une architecture d'entreprise :

le point de vue du stratège : Périmètre (Contexte) : Cette ligne décrit

les modèles, l'architecture et les représentations qui correspondent aux

limites de l'« entreprise » considérée. L'entreprise peut être l'entreprise

tout entière ou un sous-ensemble de celle-ci comme par exemple une

ligne métier ;

le point de vue du propriétaire : Modèle d'Entreprise (Conceptuel) :

Cette ligne décrit les éléments clés du périmètre étudié : processus

métier, objets métier… ;

le point de vue du concepteur : Modèle du système (Logique) : Cette

ligne décrit les modèles, l'architecture et les représentations utilisés par

les ingénieurs, architectes et toutes personnes qui doivent arbitrer entre

les besoins et ce qu'il est techniquement possible de faire ;

le point de vue du développeur : Modèle technologique (Physique) :

Cette ligne décrit les modèles, l'architecture et les représentations

utilisées par les techniciens, les ingénieurs et les contractants qui

développent le système ;

le point de vue des sous-traitants : Représentation détaillée

(Intégration) : Cette partie décrit les différents éléments inclus dans le

produit final (ex. : composants logiciels). Pour les développeurs de

logiciel, cette partie correspond à l'intégration de modules ou de

composants en provenance de l'extérieur ;

le système lui-même : Cette partie représente la réelle mise en œuvre

des éléments, c'est l'existant dans toute sa complexité.

Les colonnes de la matrice correspondent aux concepts de bases pour décrire une architecture et aux différentes questions que se posent toutes les parties prenantes :

Quoi ? (Donnée) : En quoi est-ce fait ? C'est la composition du produit.

Dans le cas d'un logiciel, il s'agit des données ;

Comment ? (Fonction) : Comment ça fonctionne ? Cette colonne

correspond au fonctionnement et à la transformation du produit ;

Où ? (Réseau) : Où sont les éléments les uns par rapport aux autres ?

Cette colonne s'intéresse à l'emplacement et aux connexions du

produit ;

Qui ? (Personne) : Qui fait quoi ? Cette colonne correspond au

personnel, aux manuels, aux procédures qui leur sont utiles pour faire

leurs tâches ;

Quand ? (Temps) : Quand se produisent les choses ? Cette colonne

concerne les cycles de vie, les durées et les programmes qui sont

utilisés pour contrôler l'activité ;

Pourquoi ? (Objectif) : Pourquoi les événements arrivent-ils ? Cette

colonne correspond aux objectifs, plans et règles qui guident

l'organisation.

Chaque cellule de la matrice décrit une architecture, un modèle, une représentation ou une description qu'une organisation peut documenter. Il est possible et John Zachman insiste beaucoup là-dessus, de décrire chaque cellule indépendamment des autres, mais il existe des liens entre les cellules. En effet, chaque ligne décrit un point de vue et chaque colonne est basée sur le même type d'élément (donnée, fonction, réseau, personne, temps, objectif). Les cellules d'une même colonne sont donc liées entre-elles et représentent des points de vue plus ou moins détaillés d'un même type d'éléments.

Enfin, chaque composant d'architecture ne figure que dans une cellule et une seule.

Le framework de Zachman est bien loin d'une solution complète pour l'architecture d'entreprise : le framework indique ce qu'il faut modéliser pour produire une image riche de l'entreprise et de son écosystème. En revanche, il ne donne pas :

de métamodèle des concepts ;

ni même de conseils méthodologiques que ce soit pour élaborer les

modèles, les exploiter et les gérer de façon efficace ou encore pour

bâtir une architecture qui réponde le mieux aux besoins métier de

l'entreprise. Certes, depuis la publication du framework, Zachman a

apporté les éléments d'une démarche de construction mais celle-ci est

loin d'avoir la notoriété du framework et ne fait nullement référence.

À l'absence de métamodèle et de processus méthodologique bien documentés s'ajoute l'absence d'outil spécifique et de guide pour adapter le cadre aux particularités d'une entreprise.

Certes, des processus méthodologiques ou des outils simples existent pour être utilisés conjointement avec le framework de Zachman, mais :

ils ne sont généralement pas définis pour se conformer au cadre de

Zachman ;

ils n'indiquent pas comment procéder à une adaptation au contexte

spécifique d'une entreprise.

En fait, Le framework de Zachman est à l'architecture d'entreprise ce qu'est la classification périodique des éléments à la chimie : cela donne les listes des briques élémentaires permettant de décrire une entreprise mais il ne faut pas en attendre plus.

Le framework de Zachman peut donc constituer un point de départ d'un cadre de référence d'architecture d'entreprise mais doit impérativement être complété par d'autres briques. Malgré cela, le framework a inspiré de très nombreux travaux sur ces sujets, et est utilisé assez systématiquement en référence.

 

11.3.3. The Open Group Architecture

Framework (TOGAF)

 

L'Open Group et TOGAF

L'Open Group est un consortium industriel neutre vis-à-vis des fournisseurs et des technologies.

L'Open Group travaille avec des clients, des fournisseurs, des consortiums et d'autres organismes proposant des normes. Son rôle est de :

capter, comprendre et aborder les besoins courants et émergents,

établir des politiques et partager les « best practices » ;

faciliter l'interopérabilité, développer le consensus, élaborer et intégrer

des spécifications et des technologies Open Source ;

offrir un ensemble complet de services pour accroître l'efficacité

opérationnelle ;

faire fonctionner le premier service de certification, comprenant la

certification UNIX.

L'Open Group a plus de 15 ans d'expérience dans le développement et le fonctionnement des programmes de certification et a une vaste expérience pour développer et faciliter l'adoption de suites de tests pour valider la conformité à un standard ouvert ou à une spécification. L'Architecture Forum de l'Open Group compte aujourd'hui 166 membres dans le monde.

La première version de TOGAF a été publiée en 1995 à l'instigation d'acteurs membres de l'Open Group Architecture Forum. Depuis cette date, des versions de TOGAF ont été régulièrement publiées (la version actuelle est la version 9.0 de février 2009) et mises à disposition par l'Open Group. TOGAF est une méthode, largement reconnue et utilisée ainsi qu'un ensemble d'outils pour concevoir, planifier, implémenter et gouverner une architecture d'entreprise.

En effet, parmi l'ensemble des frameworks publiés, seul TOGAF inclut une méthode standard, qui, de plus, est indépendante des outils et technologies et peut être utilisée avec d'autres frameworks. Par conséquent, cette méthode ne prescrit aucun livrable obligatoire : les architectes peuvent utiliser les livrables décrits dans TOGAF ou d'autres livrables associés à d'autres frameworks.

TOGAF n'a pas pour ambition d'entrer en concurrence avec d'autres frameworks mais, au contraire, de proposer une méthode qui peut s'adapter à tout autre framework

Ce n'est pas un cadre d'architecture d'entreprise prêt à l'emploi mais plutôt une base de départ pour que chaque entreprise puisse construire son propre cadre.

 

Le framework

Le framework proposé par TOGAF pour l'Enterprise Architecture identifie quatre couches :

architecture métier : elle décrit la stratégie métier et les processus

métiers supportant les objectifs ;

architecture des données : elle décrit la structure des stockages de

données logiques et physiques et les ressources de gestion des

données ;

architecture applicative : elle décrit comment les applications sont

construites et leurs interactions, leurs relations avec les processus cœur

de métier de l'organisation ;

architecture technique : elle décrit l'infrastructure, le middleware, les

réseaux, les communications, les traitements, les standards etc.

supportant le déploiement des services métier, données et applications.

L'ensemble constitué des couches données et application est aussi appelé Information architecture.

TOGAF repose sur trois piliers :

« l'Architecture Development Method (ADM) » : c'est la méthode

de construction d'une architecture d'entreprise. C'est probablement le

pilier le plus important de TOGAF ;

« l'Enterprise Continuum » : c'est un référentiel à compléter de

modèles d'architecture du marché ou développés dans l'entreprise et

qui peuvent être utilisés comme point de départ pour bâtir une

architecture. TOGAF ne propose nativement que deux modèles

génériques de référence : TOGAF Foundation Architecture et

Integrated Information Infrastructure Reference Model (III-RM) ;

« Resource Base » : c'est un ensemble de guides, de modèles, d'outils,

de méthodes… pour aider l'architecte à utiliser ADM.

Nous allons tout d'abord présenter le cœur de TOGAF à savoir l'ADM.

 

L'« Architecture Development Method (ADM) »

La démarche ADM est constituée de huit phases principales et d'une phase préliminaire comme l'illustre la figure 11.2.

 

Fig. 11.2

 

Chacune des phases est divisée en étapes.

Les livrables sont générés tout au long du processus, mais le livrable d'une phase peut être modifié dans une phase ultérieure.

Les points clés d'ADM sont :

ADM est une démarche itérative, tout au long du processus, entre les

phases et à l'intérieur d'une phase ;

pour chaque itération, une décision doit être prise sur :

le périmètre couvert ;

le niveau de détail ;

l'horizon visé, y compris le nombre et la portée des jalons intermédiaires ;

les éléments d'architecture existants de l'Enterprise Continuum, déjà créés dans les itérations précédentes ou existantes dans l'entreprise ;

ces décisions doivent être prises sur la base d'une évaluation pratique des ressources et des compétences disponibles et sur la valeur attendue pour l'entreprise de la démarche d'architecture ; en tant que méthode générique, ADM est prévue pour être utilisée dans des contextes très variés, et peut donc être adaptée à des besoins spécifiques.

ADM est une méthode générique pour le développement des architectures, conçue pour traiter la plupart des besoins quel que soit le contexte de l'entreprise. Cependant, il est généralement indispensable d'adapter ADM pour répondre à des besoins spécifiques. En effet :

l'ordre des phases est, dans une certaine mesure, dépendant de la

maturité de la discipline d'architecture dans l'entreprise concernée ;

le framework utilisé n'est pas nécessairement celui proposé par

TOGAF ne serait-ce que pour capitaliser sur un éventuel framework

d'entreprise antérieur à l'introduction de TOGAF. Or, les phases B, C et

D sont directement alignées sur le framework proposé par TOGAF.

L'utilisation d'un autre framework avec des couches différentes

nécessite une adaptation d'ADM ;

La coordination d'ADM avec d'autres démarches d'entreprise

importantes pour le modèle de gouvernance (gestion des risques,

planification budgétaire, développement de systèmes…) nécessite elle

aussi des adaptations ;

L'ADM est probablement une démarche trop lourde pour les PME qu'il

convient d'adapter sur le plan du niveau des ressources requises.

Les principaux concepts utilisés par ADM

Les trois concepts suivants sont importants : les composants d'architecture, les vues

et points de vue et les principes d'architecture.

Les composants d'architecture (« buildings blocks ») sont constitués d'un ensemble

de fonctionnalités répondant à des besoins métier, possédant des interfaces publiées

pour accéder aux fonctionnalités d'autres building blocks et à la fois réutilisables et bien

spécifiés.

Les vues et points de vue (« views et viewpoints »). Un même modèle de

représentation d'une architecture est toujours trop complexe pour être compris par

toutes les parties prenantes, d'où la nécessité pour l'architecte de choisir et de

développer différentes représentations qui fournissent une description de l'architecture

d'un système. C'est la notion de vue et de point de vue.

Un point de vue est l'angle sous lequel l'architecte va élaborer une représentation de

l'architecture. Une vue est le résultat de la représentation obtenue à partir d'un point de

vue donné.

Les couches du framework constituent le premier niveau de découpage de

l'architecture en points de vue.

Les principes d'architecture (généralement entre 10 et 20) sont des règles qui doivent

guider l'élaboration d'une architecture. TOGAF distingue d'une part les principes relatifs

à l'élaboration de l'architecture, son développement et sa maintenance et d'autre part les

principes relatifs à la mise en œuvre de l'architecture. Ces principes sont à établir par

l'entreprise, TOGAF n'en proposant aucun.

 

Les principaux éléments de la gouvernance de

l'architecture d'entreprise prônée par TOGAF

La gouvernance TOGAF s'appuie sur les éléments suivants :

• Architecture Board : organe transverse de niveau Direction et responsable de :

– la cohérence entre les sous architectures ;

– l'identification des éléments réutilisables ;

– la flexibilité de l'Enterprise Architecture ;

– la conformité de l'architecture ;

– l'amélioration du niveau de maturité de la discipline de l'architecture dans

l'organisation ;

• des revues de conformité de l'architecture afin de :

– relever, dès que possible, les non-conformités dans les projets ;

– s'assurer de l'application des meilleures pratiques ;

– fournir une vue d'ensemble de la conformité aux standards de l'entreprise ;

– identifier les points sur lesquels les standards eux-mêmes peuvent avoir besoin d'être

modifiés ;

– identifier les services qui sont actuellement spécifiques à une application mais

pourraient être fournis comme partie de l'infrastructure de l'entreprise ;

• des contrats d'architecture : ces contrats peuvent prendre différentes formes mais

permettent d'établir une vue commune et claire pour toutes les parties prenantes des

objectifs, du périmètre, des livrables de leurs niveaux de détail avant d'enclencher des

travaux d'architecture.

 

11.4. Les différences entre les deux écoles

de pensée

 

Toute comparaison entre les deux écoles de pensée nécessite d'abord de poser les références pour l'une et pour l'autre.

Nous allons pour cette comparaison prendre le présent ouvrage comme référence de l'école de pensée française de l'urbanisation des systèmes d'information et TOGAF (version 9) comme représentant de l'école de pensée anglo-saxonne de l'Enterprise Architecture. La comparaison porte sur les axes suivants :

le framework et le modèle des concepts ;

les règles d'urbanisme/d'Enterprise Architecture ;

la démarche méthodologique ;

les modèles de référence ;

le déploiement.

 

11.4.1. Le framework et le modèle des

concepts

Chacune des deux écoles propose un framework à quatre niveaux :

objectifs métiers comme point d'entrée puis les quatre niveaux

suivants : architecture métier, architecture fonctionnelle, architecture

applicative et architecture technique pour l'urbanisme à la française ;

architecture métier, architecture des données, architecture des

applications et architecture technique pour TOGAF.

On notera les principales différences suivantes :

l'existence d'un niveau architecture fonctionnelle dans le modèle de

l'urbanisme à la française, alors que TOGAF ne le fait pas apparaître

explicitement ;

l'existence d'un niveau Architecture des données dans TOGAF, alors

que le modèle d'urbanisme des SI ne le fait pas apparaître

explicitement.

Cela dit, lorsque l'on étudie plus en détail les deux démarches, on s'aperçoit que ces différences ne sont pas aussi tranchées.

 

Absence d'un niveau Architecture Fonctionnelle dans TOGAF

Le niveau Architecture Métier de TOGAF, fait mention des fonctions métier. Ainsi, d'une façon plus explicite, la Phase B de l'Architecture Development Method (ADM) « identifie et définit les fonctions métier ». C'est une étape détaillée et récurrente qui implique la décomposition des fonctions essentielles en sous fonctions.

De plus, cette modélisation des fonctions métier fait partie des résultats de la phase B d'ADM pour le niveau Architecture Métier : l'architecture métier cible définit notamment les processus métier, les fonctions métier, les services métier (aux clients internes et externes).

 

Absence d'un niveau Architecture des données dans l'urbanisation des SI

Les informations et les données sont prises en compte dans les niveaux architecture métier et architecture fonctionnelle du modèle d'urbanisme. En revanche, la décomposition du POS (« Plan d'occupation des Sols ») fonctionnel en zones met en évidence une zone gisement de données et une zone référentiels elle-même décomposée en un quartier « référentiel de données » et en un quartier « référentiel de règles ». Ces zones et quartiers se retrouvent ensuite dans l'architecture applicative. Donc au final, les différences entre les deux frameworks existent mais sont moins importantes qu'on pourrait le croire en première analyse. En revanche, TOGAF version 9 ne définit pas de méta modèle des concepts (il faut toutefois noter que les concepts dont définis) en complément du framework alors que dans le présent ouvrage figure un méta modèle simplifié des concepts. Certes, ce méta modèle n'est pas un véritable méta modèle d'où le qualificatif « simplifié » puisque seuls les concepts essentiels sont présentés et les cardinalités des relations ne sont pas indiquées. Mais il constitue une base de départ structurante pour établir un méta modèle détaillé exécutable dans un outil. TOGAF ne définit pas de métamodèle ni de métamodèle simplifié probablement car son objectif est de ne pas aller trop loin de manière à pouvoir être adapté et adaptable à tout framework et tout méta modèle. La philosophie de TOGAF n'est pas de fournir un cadre spécifique prêt à l'emploi mais plutôt un cadre générique pouvant être adapté le plus largement possible de manière à viser une audience très large.

 

11.4.2. Les règles d'urbanisme et

d'Enterprise Architecture

Dans le présent ouvrage figurent des règles d'urbanisme et des règles de bonne pratique (44 au total) proposées pour les différents niveaux du framework.

Celles-ci sont bien entendu à adapter au sein de chaque entreprise mais constituent un point de départ appréciable.

En revanche TOGAF ne propose pas de contenu sur ce point même si le contenant est prévu dans le 3e pilier de TOGAF la resource base.

 

11.4.3. La démarche méthodologique

Les deux écoles proposent un processus méthodologique pour le développement d'architecture d'entreprise, mais aucune des deux n'aborde le processus de développement de systèmes il est vrai déjà largement adressé depuis des décennies. Cependant, afin de réellement faire progresser l'urbanisme des SI au sein d'une entreprise, il faut combiner l'approche globale de l'architecture d'entreprise avec l'approche projets car c'est au fil des projets que le système d'information va progressivement mettre en œuvre les principes et les règles d'architecture d'entreprise et peu à peu converger vers la cible. Mais pour adresser ce point, il s'agit de faire les mises à jour ciblées nécessaires dans la démarche de conduite de projets de chaque entreprise beaucoup plus de créer une N e méthode de développement de systèmes. C'est la raison pour laquelle cette dimension n'est pas traitée dans le présent ouvrage et on peut imaginer qu'un raisonnement similaire a conduit l'Open Group à la même conclusion quant à TOGAF et à sa couverture.

Les figures 11.3 et 11.4 représentent les processus méthodologiques respectivement définis par ce livre et par TOGAF.

Fig. 11.3

 

 

Fig. 11.4

 

Une première différence apparaît : le cœur du processus méthodologique proposé par cet ouvrage est d'abord découpé selon l'axe existant/cible (phase « d'analyse de l'existant » et phase de « définition de la stratégie » c'est-à-dire de la cible) et de manière secondaire selon les quatre niveaux du cadre de référence. Autrement dit, le processus suggère de travailler sur tous les niveaux du cadre de référence pour dresser la cartographie et le bilan de l'existant puis de nouveau de travailler sur tous les niveaux du cadre de référence pour définir la cible. À l'inverse, le cœur du processus de l'ADM (Architecture Development Method) proposé par TOGAF est d'abord découpé selon les niveaux du cadre de référence (phase B « Business Architecture », phase C « Information system architectures », phase D « technology architecture ») et de manière secondaire selon l'axe existant/cible. Autrement dit, le processus suggère de travailler successivement sur chacun des niveaux du cadre de référence en traitant pour chacun d'eux l'existant et la cible. Les résultats de chaque phase contiennent une architecture cible, une architecture existante et une analyse d'écarts systématique entre les deux. Cette approche conduit TOGAF à privilégier des cycles courts d'évolution de l'urbanisme, dans lesquelles la comparaison systématique Existant/Cible est un élément clé.

L'urbanisme peut, bien sûr, s'appliquer également aux cycles courts, mais l'absence de comparaison systématique Existant/Cible permet d'entreprendre des évolutions à plus long terme, qui ne seront pas bridées par l'état actuel.

Cela dit, si la représentation schématique de l'ADM de TOGAF vise à faire apparaître visuellement la notion d'itération, celle-ci est également prônée dans cet ouvrage. Le chapitre 9 présente en effet les phases une à une de manière très séquentielle. Mais l'étude de cas au chapitre 4.9 « Construction de la solution méthodologique » permet d'expliquer que le cycle de vie de chaque projet de développement d'une architecture d'entreprise doit faire l'objet d'un choix des briques méthodologiques (celles présentées au chapitre 9) et du cycle de vie adapté à la situation. Il ne recommande pas d'itérer sur l'analyse de l'existant mais le recommande systématiquement pour la définition de la cible. ADM développe, de façon plus détaillée, les travaux sur la Technology Architecture. En effet, la phase D, « Technology Architecture » de la démarche ADM de TOGAF a constitué le point de départ de TOGAF. Les autres phases d'ADM ont été développées par la suite pour enrichir le champ de TOGAF. On peut également penser qu'au-delà des origines mêmes de TOGAF, un facteur culturel a pu jouer pour que les approches d'Enterprise Architecture développées outre atlantique soient plus ancrées sur les technologies alors que l'école de pensée française est plus conceptuelle donc plus éloignée des considérations technologiques. Enfin, nous ne reviendrons pas sur la place accordée aux données car ce sujet a déjà été abordé dans la partie « le framework et le méta modèle des concepts ».

 

11.4.4. Les modèles de référence

Ni l'Architecture Development Method de TOGAF, ni le présent ouvrage ne fournissent beaucoup de contenu de ce point de vue. Il est vrai que ce n'est pas la vocation de cet ouvrage et probablement pas non plus celle de TOGAF. Les modèles de références sont souvent liés à des secteurs économiques (même s'il peut y avoir des exceptions notamment pour des modèles techniques ou des modèles transversaux). Cela dit, on pourrait espérer que les membres de l'OPEN GROUP organisent la capitalisation et définissent peu à peu des modèles de référence autrement dit que les membres partagent une partie de leurs « enterprise continuum » respectifs. Cependant nous proposons tout de même dans cet ouvrage une architecture fonctionnelle générique, découpage fonctionnel de tout SI en un certain nombre de zones et de quartiers qui a l'avantage de sa généricité puisqu'il est indépendant de tout secteur économique et qui en a aussi l'inconvénient puisque pour une entreprise donnée, il n'y a pas assez de contenu. Enfin, TOGAF propose tout de même :

TOGAF Foundation Architecture :

Integrated Information Infrastructure Reference model (III-RM).

Les entreprises devront donc dans ce domaine chercher ailleurs car ce type de modèle existe comme par exemple eTOM (Enhanced Telecom Operation Map) pour les opérateurs de télécommunications.

 

11.4.5. Le déploiement

L'approche de l'urbanisme à la française telle que présentée dans ce livre mais aussi telle que définie et promue par le Club Urba EA notamment avec ses publications (Pratiques de l'urbanisme des systèmes d'information. Publibook 2003 et Urbanisme et gouvernance des SI. Dunod 2006) et par le CIGREF partenaire du Club Urba EA sur l'architecture d'entreprise est très largement déployée en France et constitue la référence de fait. TOGAF a une position beaucoup moins hégémonique dans le monde anglo-saxon où la concurrence est beaucoup plus fournie. Cependant TOGAF est un standard international de fait arrivant dans le top 3 des approches publiées selon l'Institute For Enterprise Architecture Developments (IFEAD). L'Architecture Forum de l'Open Group compte aujourd'hui 166 sociétés ou organismes membres.

TOGAF est en anglais et bénéficie donc d'un avantage concurrentiel important par rapport aux différentes publications concernant l'urbanisme à la française. Certes le présent ouvrage est traduit en langue anglaise (The Enterprise Architecture IT Project – The urbanisation paradigm, Kogan Page Science 2003) mais c'est une exception et s'il fait référence en France, ce n'est pas le cas aux États-Unis.

De plus, l'enquête menée en 2008 par le Club Urba EA montre un intérêt croissant des entreprises françaises pour TOGAF qui arrive largement en tête des cadres de référence d'Enterprise Architecture publiés auxquels elles se sont intéressées ou envisagent de le faire prochainement. Il ne s'agit probablement pas pour elles de faire table rase du passé et du savoir-faire acquis au fil du temps mais d'évoluer progressivement vers TOGAF en tirant parti du meilleur des deux écoles de pensée et en capitalisant sur les investissements passés.

 

11.5. La réalité de la mise en œuvre des

deux approches

 

11.5.1. La réalité de la mise en œuvre en

France

En France, l'observatoire de l'urbanisation du Club Urba EA publie depuis trois ans maintenant un livrable qui donne une bonne vue de la mise en œuvre réelle de l'architecture d'entreprise et de l'urbanisme des SI. La mise en œuvre des démarches d'urbanisation remonte à :

12 ou 13 ans pour les « pionniers » (vaque de la deuxième partie des

années 1990) ;

8 ou 9 ans pour les « early adopters » (vague de 2000) ;

et moins de 5 ans pour beaucoup d'entreprises (vague de 2003).

Toutes ces démarches concernent les très grandes et grandes entreprises, plus rarement les PME (ou alors elles communiquent peu sur ce sujet). La plupart des entreprises du CAC4O (donc tous secteurs économiques confondus) et des grandes administrations ont une entité (le plus souvent pilotée par la DSI) dédiée à l'architecture et à l'urbanisme et les entreprises internationales ont souvent commencé à évoluer vers l'Enterprise Architecture afin de s'aligner sur les standards internationaux qui facilitent le déploiement dans toutes les composantes des entreprises. Force est de constater que la mise en œuvre ne couvre que la partie SI de l'Enterprise Architecture. Les points remarquables sont les suivants :

la connaissance des objectifs métiers (ce point ayant beaucoup

progressé depuis 2 ans environ) est généralement bonne ;

la cartographie des SI existants est réalisée tout au moins pour ce qui

concerne les processus, l'architecture fonctionnelle et l'architecture

applicative, la cartographie des infrastructures techniques étant quant à

elle largement en retrait. L'une des caractéristiques de l'approche à la

française est d'ailleurs le manque de lien suffisamment formalisé entre

les dimensions fonctionnelle et applicative et la dimension technique.

De ce point de vue, la démarche française reste peut-être un peu trop

conceptuelle en ne se souciant pas assez des réalités à prendre en

compte dans l'implémentation physique ;

les échanges interapplicatifs demeurent insuffisamment formalisés ;

le partage des référentiels et la mise en œuvre et le partage des services

communs sont encore peu développés ;

la communication et la formation sont encore à développer.

L'enseignement de l'Enterprise Architecture est maintenant intégré dans la plupart des cursus de formation des écoles d'ingénieurs, de commerce et des universités.

Le métier est maintenant reconnu et valorisé même si son insertion dans un cursus de carrière reste à inventer pour la plupart des entreprises (75 % selon l'enquête réalisée par le Club Urba-EA en 2008). Le pilotage de l'urbanisation reste l'apanage des sociétés les plus matures. C'est donc encore un axe de progrès.

Les missions dévolues à l'entité Enterprise Architecture couvrent communément :

la définition du cadre méthodologique ;

la cartographie des SI et sa diffusion ;

la mise sous contrôle des référentiels de données et de services ;

la mise sous contrôle échanges interapplicatifs ;

la définition du cadre d'évolution du SI (cible globale et trajectoire de

migration) ;

l'accompagnement des projets ;

la communication et la formation ;

la contribution à la gouvernance de l'IT (ce rôle est cité comme l'un

des rôles dévolu à l'architecture d'entreprise par seulement 55 % des

entreprises selon l'enquête réalisée par le Club Urba-EA en 2008).

 

11.5.2. La réalité de la mise en œuvre aux

États-Unis

On constate tout d'abord une grande diversité des cadres méthodologiques utilisés comme l'illustre la figure suivante qui a été élaborée à partir d'une étude réalisée en 2005 par l'Institute For Enterprise Architecture Developments (IFEAD), intitulée Trends in Enterprise Architecture 2005 – How are organizations progressing ?) Les résultats de l'étude sont basés sur 79 réponses d'entreprises à un

questionnaire, dont 37 % en Amérique du Nord et 21 % en Europe.[3]

Fig. 11.5

 

Le schéma de la figure 11.5 montre que Zachman (qui rappelons-le n'offre pas un cadre complet pour l'architecture d'entreprise) arrive en tête devant les approches spécifiques. Ensuite, FEAF (Federal Enterprise Architecture Framework), TOGAF (The Open Group Architecture Framework) et DoD (Department of Defense) se dégagent puis l'audience des autres approches est assez émiettée

Aujourd'hui, la plupart des grandes entreprises américaines et toutes les administrations fédérales ont une entité dédiée à l'Enterprise Architecture. Globalement les systèmes d'information existants sont tous cartographiés (surtout des points de vue processus métier, données et applications mais moins systématiquement du point de vue des infrastructures techniques). Le lien entre l'Enterprise Architecture et la gouvernance IT existe toujours mais avec des degrés de maturité très divers.

L'enseignement de l'Enterprise Architecture est intégré les cursus de formation des universités.

Différents métiers comme celui d'enterprise architect, de process architect de solution architect ou encore de technical architect sont maintenant reconnus et valorisés.

Le pilotage de l'urbanisation reste l'apanage des sociétés les plus matures. C'est donc encore un axe de progrès.

Les missions dévolues à l'entité Enterprise Architecture semblent assez similaires à ce qu'on trouve en France.

 

11.5.3. Les enseignements

Plusieurs enseignements sont à tirer de ce survol des différences entre l'école de pensée américaine « Entreprise Architecture » et la française « l'approche d'urbanisme du système d'information ». En particulier trois constats s'imposent.

D'une manière générale, le premier constat est que les démarches anglo-saxonnes d'Enterprise Architecture abordent un périmètre a priori plus large que le système d'information, vers le métier d'une part, vers les composants techniques d'autre part. Mais elles sont souvent pratiquées seulement sur le périmètre « IT » du système d'information comme le confirment les experts américains.

De plus, elles traduisent une véritable ambition d'architecte, où tout devrait être décrit dans le détail. Par exemple, pour John Zachman, chaque case de son framework (il y en a 36) doit faire l'objet d'une description détaillée. Cela illustre bien que le courant de pensée anglo-saxon se situe dans une logique industrielle de description systématique et détaillée de tous les aspects de l'architecture (à l'image des plans d'un avion qui sont exhaustifs et détaillés afin de permettre à chaque intervenant dans la conception, la construction ou la maintenance d'y trouver les informations dont il a besoin). Bien entendu, les mêmes experts savent bien que pour un système d'information et encore plus pour une entreprise, il est relativement irréaliste de penser tout décrire dans le moindre détail et qu'il faut donc faire des choix tant en termes d'exhaustivité du périmètre que de niveau de détail. Mais la logique demeure et conduit à des projets de mise en œuvre de l'Enterprise Architecture sans commune mesure avec ce qu'on peut voir en France. Un second constat sur la réalité de la mise en œuvre aux États-Unis est une mise en œuvre industrielle, systématique au prix de moyens importants.

De son côté, l'approche française d'urbanisme des systèmes d'Information est largement centrée sur l'articulation Business-SI et décrit un cadre d'ensemble, qui introduit une cohérence transversale sur les éléments clés du système d'information.

En outre, elle consacre l'importance du principe de subsidiarité qui ne cherche pas à tout décrire. Les projets d'urbanisation de systèmes d'information sont donc des projets sensiblement plus légers que ceux menés au États-Unis dont le périmètre et le niveau de détail font l'objet d'une définition très fine et alignée sur les enjeux et les objectifs de chaque projet. Sur ce plan, la réalité de la mise en œuvre en France est une mise en œuvre sur-mesure reposant sur un cadre théorique solide et relativement économe en moyens. Par ailleurs, et ce sera notre troisième constat, la mise en œuvre de l'approche française concerne essentiellement le système d'information et d'ailleurs la stratégie métier et l'organisation globale de l'entreprise sont présentées dans cet ouvrage comme un élément en entrée de l'approche plutôt que comme un élément interne.

Du côté de l'approche anglo-saxonne il y a un décalage entre l'ambition théorique affichée par l'architecture d'entreprise et la mise en œuvre réelle qui sauf quelques très rares exceptions (selon les propos d'éminents experts américains) se limite au système d'information et donc à se qu'on commence à appeler « l'Enterprise IT Architecture ». En conclusion, si notre premier constat est que le périmètre de l'Enterprise Architecture est plus large que celui de l'urbanisme des SI, notre troisième constat indique que la mise en œuvre réelle est dans les deux cas similaire et circonscrite au système d'information.

Finalement :

• Enterprise IT Architecture = urbanisme des SI

et

• Enterprise Architecture = urbanisme de l'entreprise

 

11.6. La convergence des deux écoles de

pensée

 

« Comment refaire ou moderniser son système d'information, comment profiter à bon escient des avancées technologiques sans faire table rase du passé, dans des limites de coûts maîtrisés tout cela en maintenant son fonctionnement et la qualité de service pendant les travaux ? » tel est le challenge auquel l'urbaniste de systèmes d'information ou l'architecte d'entreprise sont confrontés en permanence.

L'urbaniste de systèmes d'information et l'architecte d'entreprise sont confrontés au même challenge et les deux écoles de pensée ont été conçues pour répondre aux mêmes enjeux de l'entreprise et donc de son SI. À ce stade, il est important de préciser ces enjeux. Il s'agit de :

l'éclairage de la décision stratégique : L'Architecture d'Entreprise

doit fournir les éléments de coûts, délais et risques qui éclairent la

décision ;

la maîtrise des métiers, des produits et des marchés : les SI doivent

jouer un rôle majeur dans la mise en œuvre par chaque métier de sa

stratégie. En particulier, les SI sont déterminants dans la conquête

d'avantages concurrentiels et la politique de différentiation ;

l'agilité : Les SI doivent être réactifs sans sacrifier la vision à plus long

terme et sans nuire à la cohérence et à la qualité de service. Le « Time

to market » est la maîtrise du temps qui s'écoule entre l'émission d'une

idée par les métiers de l'entreprise et sa mise en œuvre opérationnelle,

dans une perspective durable ;

l'interopérabilité : Il s'agit d'avoir une représentation de l'entreprise

qui permette d'exposer l'interopérabilité pour assurer des coopérations

intra et inter niveaux. L'interopérabilité nécessite l'adoption et le

respect de règles et de standards ;

la maîtrise de la qualité  : les SI doivent répondre aux exigences de

satisfaction des tiers (client externe ou interne, partenaire…) sans

basculer dans la sur qualité. Piloter la qualité du SI : L'optimisation

poussée des systèmes informatiques entraîne une exigence toujours

plus forte en termes de besoins (notamment sécurité, standards,

règles…) ;

la maîtrise de la complexité  : L'entreprise est complexe et le SI doit

aider à maîtriser cette complexité : être en permanence capable de

savoir quels besoins métiers couvre le SI et comment il les couvre.

Avoir une valeur correcte du SI au regard de l'entreprise. Offrir une

vision globale qui associe processus métier et Système d'information.

Il faut être efficace dans la conception de l'Architecture d'Entreprise,

l'organiser et maîtriser sa cohérence dans son ensemble ;

la maîtrise de l'adéquation ressources/objectifs : l'Architecture

d'Entreprise doit contribuer à la gestion du portefeuille de projets. Les

SI doivent contribuer à la maîtrise globale des coûts de l'entreprise

(processus, organisation, ressources) et à l'efficacité de la dépense. Ils

doivent eux-mêmes être conçus et fonctionner en respectant ces efforts

d'économie et d'adéquation entre ressources et objectifs ;

la maîtrise des risques, du contrôle interne et de la conformité  :

qu'il s'agisse des risques financiers, opérationnels ou technologiques,

les SI doivent aider à les identifier, à les mesurer et à les contrôler.

L'architecture d'entreprise doit également aider à respecter les

principes de contrôle interne et de conformité ;

la maîtrise des évolutions technologiques  : sans céder aux effets de

mode, il s'agit d'une part de se prémunir contre les risques

d'obsolescence et d'autre part de tirer profit des évolutions

technologiques pour offrir un service différentiant et de qualité.

Le monde anglo-saxon, pour faire face aux mêmes enjeux que ceux visés par l'urbanisme des SI, a développé un « courant de pensée » appelé l'Enterprise Architecture.

L'Enterprise Architecture est une approche « top-down » et « bottom-up » s'appuyant sur une démarche de modélisation globale des ressources de l'entreprise.

Le périmètre de l'architecture d'entreprise inclut les acteurs, objectifs, organisations, processus, procédures, fonctions, applications, éléments d'infrastructure technique et leurs relations entre eux et avec le monde extérieur. Les architectes d'entreprise définissent des solutions complètes et cohérentes qui adressent les objectifs métiers de l'entreprise et supportent la gouvernance nécessaire à leur implémentation. En fait, le Framework de Zachman présenté au paragraphe 11.3.2 rend bien compte du périmètre de l'architecture d'entreprise. En théorie l'architecture d'entreprise couvre un périmètre et une ambition plus large que l'urbanisme des systèmes d'information. Mais la réalité est que la mise en œuvre de l'architecture d'entreprise est presque toujours réduite à la partie IT et donc les pratiques réelles d'architecture d'entreprise sont tout à fait comparables aux pratiques d'urbanisation des systèmes d'information.

Plusieurs années d'urbanisation des systèmes d'information en ont montré les apports potentiels mais aussi les défis. Pour concrétiser et pérenniser ces démarches et leurs bénéfices, il est maintenant nécessaire de les placer dans un cadre de coopération plus large. C'est l'intérêt de l'Architecture d'Entreprise.

Il nous faut donc maintenant adopter le niveau d'ambition affiché par l'architecture d'entreprise et le concrétiser dans les pratiques réelles. C'est par conséquent probablement le bon moment pour :

fusionner l'approche d'urbanisation de systèmes d'information à

la française et l'approche d'architecture d'entreprise anglo-

saxonne en prenant le meilleur de chaque école de pensée ;

capitaliser sur un premier standard international comme TOGAF,

pour participer à son amélioration et à sa promotion et pour

définir les nouveaux standards manquants.

 

Architecture d'entreprise

Pour passer de l'Enterprise IT Architecture à l'Enterprise Architecture, le défi majeur est certainement la mobilisation des acteurs. L'architecture d'entreprise doit en effet réunir tous les acteurs et tous les processus de l'entreprise.

 

OceanofPDF.com