J'entends souvent la question suivante : L'architecture d'entreprise (EA) doit-elle être centrée sur la vision Métier ou Technologique ?

On parle aujourd'hui de plus en plus régulièrement d'architecture Business et on réalise facilement l'amalgame avec l'EA.

L'architecture Business n'est qu'un domaine de l'architecture d'entreprise qui, pour reprendre la définition donnée par TOGAF, en comporte quatre (Business, data, application, technology). Elle adresse la stratégie Business, l'organisation, les Business process clés et les interactions entre ces éléments. L'architecture d'entreprise adresse également la couche technologique permettant de supporter l'architecture Business.

La notion de capacité (capability) que l'on retrouve dans TOGAF est ici intéressante : Une capacité est définie comme une compétence qu'une organisation, une personne, un système possède. Je souhaite mettre en oeuvre la comptabilité de mon entreprise pour gérer mon bilan et mon compte de résultat, traiter mes factures. Je dois donc mettre une organisation de personnes en place réalisant des tâches (ponctuelles, réglementées, récurrentes), interagissant entre elles  ainsi qu'avec des fournisseurs et des clients. J'ai donc, dans le but de mettre en place cette capacité Business, conçu une architecture Business. Celle-ci est-elle suffisante ? Tout dépend de l'aptitude de cette architecture à réaliser les travaux qui lui sont confiés, les traitements de l'information. Si ma capacité a en charge la comptabilité d'un groupe international de plusieurs milliers de personnes traitant avec un nombre important de clients et de fournisseurs, de combien de personnes ai-je besoin pour mener à bien ma mission en temps et en heure? Comment ces ressources affectent-t-elles la rentabilité de l'entreprise ?

Si l'impact est important, on arrivera sans doute à la conclusion que l'architecture Business n'est pas suffisante à elle seule pour répondre à la mission de la capacité. Il est alors nécessaire de supporter cette architecture en faisant appel à la technologie. Elle induit cependant une complexité supplémentaire liée à la traduction de l'organisation et des activités business en besoins de traitements d'informations par des logiciels et du matériel technique.

L’architecture d’entreprise repose sur l’analyse transverse des composantes horizontales (au sens domaines de l'entreprise : métiers, support) et verticales (au sens couches d'architecture : processus métiers, services applicatifs, infrastructure) d’une entreprise dans le but de décloisonner les domaines pour faire émerger les processus transverses, de mieux gérer la complexité liée à une organisation et à ses besoins.

Le but de l'EA est d'accompagner l'entreprise dans ces changements, d'en maîtriser les impacts, de les faciliter. Elle permet à l'entreprise de construire ses capacités et d'assurer leurs interdépendances. Ces changements interviennent au niveau Métier (changement d'organisation, de processus, changement de marché...) et bien sûr au niveau Technologique (obsolescence, innovation...). Les architectures Métier et Technologique sont par nature des architectures sans cesse remises en cause. Je souhaite externaliser ma capacité RH, je fusionne avec une autre entreprise et je souhaite homogénéiser mes process et mes systèmes d'information, rationaliser mon infrastructure pour réduire mes coûts de possession.

Comment mesurer les impacts de ces besoins sur mes architectures en place et comment les maîtriser ? Sur quelle "constante" de l'entreprise s'appuyer pour faciliter mes changements d'architecture ?

Une bonne architecture d'entreprise est centrée sur ce qui fait fonctionner le Business et ce que traite la Technologie : l'Information. C'est la maîtrise de l'Information, de sa transformation, de son cycle de vie, de son échange qui permet à une entreprise d'opérer efficacement ses changements. Si j'absorbe une entreprise, comment l'intégrer à mon SI ? Qu'implique le lancement d'un nouveau produit ? Mes applications peuvent-elles supporter un changement d'organisation ? Comment puis-je améliorer la collaboration entre la comptabilité et le commerce pour confronter les visions réelles et prévisionnelles des résultats de l'entreprise ?

Tout est dans la compétence à gérer l'Information en adéquation avec sa valeur pour l'entreprise. Ces informations ne se retrouvent pas uniquement dans le SI. Il est donc utile de dépasser l'analyse SI et de l'enrichir de la vision métier dans le but de déceler de nouvelles opportunités. Mon service juridique n'est pas informatisé, je ne retrouve pas mes contrats dans le SI, ils me seraient utiles pour identifier mes clients.

L'Architecture d'Entreprise doit donc accompagner le choix Technologique ayant pour but de maîtriser l'Information et son utilisation pour répondre aux exigences Métier.

Le choix d'une technologie reposera sur différentes exigences : fonctionnalités attendues, capacité d'exploitation, coûts de mise en oeuvre, coûts de possession...Ces exigences sont bien souvent liées à des process et une organisation existant ou accompagnent leurs mises en place. En cas de changement d'organisation dans l'entreprise par exemple, ces exigences peuvent évoluer. Si la solution mise en oeuvre ne repose que sur ces exigences, elle doit faire l'objet d'une refonte majeure.

Ajoutons maintenant des exigences liées aux informations que je souhaite traiter ou sur lesquelles j'identifie une opportunité future de traitement. J'ouvre le champ d'analyse pour élaborer ma solution.

Si j'externalise la capacité RH de mon entreprise en choisissant un hébergement SaaS dans le but de réduire les coûts, à quelles difficultés puis-je m'attendre? Les fonctionnalités attendues sont le traitement des recrutements et des départs, la gestion des formations, la gestion des carrières, le relevé des activités, le calcul de la paye, les déclarations réglementaires et sociales...

Pour autant, cela ne signifie pas que mon SIRH sera coupé du reste de mon SI. Le calcul de paye implique par exemple des écritures comptables dans mes SI comptabilité. Si je souhaite mener une politique de gestion d'identité dans mon entreprise, j'ai besoin d'un référentiel de ressources humaines. Mon SIRH échangera donc des informations. Les difficultés interviendront si l'entreprise est dans l'incapacité de mettre en oeuvre efficacement ces échanges par manque de maîtrise de l'information (souvent liée à l'hétérogénéité de celle-ci dans les domaines métiers et SI). On passera alors pas des transformations multiples pour interconnecter les systèmes, difficiles à maintenir, complexifiant l'architecture et diminuant les bénéfices de la politique d'externalisation. Et si j'ai construit ma solution RH hier pour ne traiter que les employés de l'entreprise mais que je souhaite demain pouvoir traiter les contractuels, ai-je conçu mon modèle de données pour qu'il réponde à cette nouvelle exigence ?

Il convient de bien mesurer ces efforts dans ce travail d'analyse car on peut se perdre dans un puits sans fond.

Mon expérience me montre qu'en ajoutant quelques attributs à une information (entre 5 et 10 selon la complexité) ou en modifiant leur nature, on simplifie le système d'information.

Un employé et un contractuel sont deux informations métiers différentes. Si je m'arrête à cette affirmation, je proposerai sans doute deux solutions distincts pour traiter ces informations. Ainsi, pour un système RH dédié aux employés, les fonctions ou services qui le compose seront sans doute fortement influencés par l'information "employé". Si je souhaite dans une évolution future traiter l'information "contractuel", l'aptitude du système à traiter cette nouvelle information sera moindre et le refactoring nécessaire important. En revanche, si je construis mon système initial pour qu'il traite l'information "ressource RH", je me place à un niveau d'abstraction supérieur, mon système possédera une capacité à gérer les dérivés "employé" ou "contractuel". Je pourrai ainsi prévoir de traiter dans un premier temps l'information "employé" mais ne me fermerait pas de porte pour traiter ultérieurement l'information "contractuel".

Amazon lorsqu'a été lancée sa plateforme d'achat en ligne ne proposait que des livres. Mais la plateforme n'a pas été conçue pour la vente en ligne de livre. Il ne s'agissait que du produit jugé le plus mature pour le démarrage de l'activité. L'idée dès le départ était d'être en capacité de vendre des "produits" au sens large. Les capacités business et systèmes dont s'est dotée l'entreprise ont été pensés dans le but de supporter cette stratégie.

Aligner la stratégie IT sur la stratégie Métier, c'est avant tout comprendre la valeur de l'Information Métier et comment celle-ci doit-être représentée et traitée dans le SI pour en tirer le meilleur avantage concurrentiel. L'Information est le pivot de l'architecture d'entreprise.

En savoir plus:

Les organismes autour de l'EA

• l’Enterprise Architecture Research Forum (EARF)
• L’Open Group (TOGAF, Archimate)
• Le Centre d’Excellence en Architecture d’Entreprise (CEISAR)

Articles et études sur l'EA

• Gartner : une étude sur les 10 pièges pour l’architecture d’entreprise (2009)
• Article autour d'une étude du Forrester : Architectes d’entreprise : snobés mais tenaces (2010)
• Session USI sur le positionnement stratégique des cellules d’architecture transverse (2008)