L’architecture d’entreprise : vision métier ou technologique?

Posté le par Yoann Garcia

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

 

11 commentaires sur “L’architecture d’entreprise : vision métier ou technologique?”

  • Clem
    Peut être qu’à chaque fois que l’on détecte un besoin, en se posant la question « Qu’est ce que mon système doit prendre en charge ? » on trouve systématiquement une solution pérenne : Est-ce un processus de production / gestion ? Auquel cas c’est ce processus qui tirent ma réflexion. Est-ce de la visibilité sur mon activité ? Auquel cas ce son les indicateurs de performances tirent ma réflexion. Est-ce de l’information de référence ? Auquel cas c’est effectivement la réalité physique de cette information qui tire ma réflexion. Est-ce les trois ? auquel cas je change mon mode de réflexion et mes solutions en fonction du besoin Penser l’information de référence indépendamment des processus qui l’utilisent et même indépendamment des processus qui la génèrent, effectivement. Par contre, c’est bien la stratégie métiers qui donne le ton (je ne parle pas la du nombre de clic, nous avons tout de même un devoir de conseil :)), je me vois mal demander à Renault s’ils ont l’intention de vendre des pommes. En conception orientée objet, on répond à la problématique que vous abordez en conclusion via de l’héritage, tous les progiciels ne répondent pas à cette problématique. En faire un critère indispensable de choix technologique par philosophie, c’est faire perdre du poids à des besoins plus importants ...
  • Eric Zardi
    En fait on pourrait dire les deux, car une bonne architecture d’entreprise doit permettre des vérifications et des analyses qui vont dans les deux directions, depuis la vision métier jusqu’à la vision technologique et vice-versa. En effet la vision métier, qui est au service de la stratégie de l’entreprise, doit s’assurer qu’elle va disposer des moyens qui seront nécessaires à la bonne mise en œuvre de la stratégie de l’entreprise. En ce sens elle doit vérifier que la technologie sera bien alignée aux besoins, et ce avec des applications et une infrastructure permettant d’assurer le meilleur retour sur investissement. Mais en sens inverse, une vision technologique peut aussi mettre en évidence de nouvelles capacités rendues possibles par les innovations technologiques. Dans ce cas c’est la vision technologique qui peut donc être génératrice de nouveaux modèles économiques pouvant alors être supportés par les progrès qui deviennent disponibles au niveau de l’infrastructure, voire des applications. Par conséquent, l’Architecture d’Entreprise se présente plutôt comme une façon de bien intégrer toutes les visions au sein d’une organisation (métier et technologique entre autres) afin de pouvoir en tirer le meilleur parti de la manière la plus performante possible, et ainsi assurer la compétitivité de l’entreprise en s’appuyant sur les moyens strictement nécessaires à la satisfaction des clients finaux. On décèle même de grandes similitudes avec les objectifs du Lean quand cette approche est adoptée.
  • Clem
    Dans l'approche technologique, à quel niveau de maturité de la réflexion parle-t-on de ROI, de budget et surtout de capacité d'investissement ? Que la technologie donne des idées ou fasse gagner en maturité sur l'expression d'un besoin, je veux bien l'entendre. Mais si, comme exprimé dans cet article, il est proposé d'"altérer" une architecture pour répondre à des besoins hypothétiques qui potentiellement n'apparaîtront jamais, une perte de performance est inévitable. Une orientation de l'IT vers une approche best of breed ne résout elle pas cette problématique ? Il ne s'agit pas de garantir une réponse à des exigences définies via une démarche top-down ou bottom-up, il s'agit d'ajouter un axe, celui de la fonctionnalité, permettant de prendre en charge une typologie de besoin plutôt qu'un besoin présent ou à venir. L'extension de la "capacité" peut alors se faire via des opportunités d'investissement répondants à un besoin immédiat et représentant un patrimoine pour l'avenir. - L'architecture d'entreprise prend elle en compte cet axe ? - Si oui, quelles réponses en matière de technologie propose-t-elle ? Des solutions packagées type progiciel ? Du développement spécifique ? Ou les deux ?
  • Eric Zardi
    L’orientation IT vers une approche best of breed systématique peut entrainer des surcapacités et/ou des surcoûts par rapport aux besoins métier réels et non hypothétiques. Elle est cependant bien sûr possible si elle est souhaitée et voulue en tant que telle au niveau stratégique par toute l’organisation qui est alors consciente de cet investissement, et l’approuve en toute connaissance de cause. Dans ArchiMate 2.0, il a été développé une extension appelée « Motivation Extension ». C’est à ce niveau que peuvent être exprimés les différents besoins qui répondent à la stratégie d’une entreprise ou d’une organisation. On peut y exprimer aussi des contraintes et/ou des principes qui doivent être respectés pour correspondre aux différentes règles (métier ou technologique) que se fixent chaque entreprise. Un principe peut être par exemple (pour reprendre le cas de figure mentionné précédemment) de n’adopter que des solutions qui peuvent disposer d’extension de capacité. Toutes ces descriptions peuvent être complétées par des contraintes et/ou des propriétés diverses telles que coûts, budgets, obsolescences, limites dans le temps, performances, effectifs, etc… Sur la base des analyses de ces différentes informations (objectifs, besoins, contraintes, principes, propriétés,…) les différentes parties de l’entreprise peuvent alors décider en toute connaissance de cause s’il est souhaitable d’investir dans une architecture qui dispose des potentialités ainsi identifiées et évaluées, ou s’il est préférable d’avoir une approche plus ouverte ou flexible permettant l’accueil de fonctionnalités futures nécessaires au support de besoins métier à venir. Comme toutes ces informations sont liées aux différents éléments métier, applicatif, et technologique de l’entreprise, on peut en permanence analyser les impacts de différents choix ou de divers évènements possibles où qu’ils soient sur l’ensemble de la bonne marche de l’entreprise par rapport aux objectifs qu’elle s’est fixée. L’architecture d’entreprise a donc plutôt pour vocation de valider des choix technologiques par rapport aux stratégies des organisations qui la mettent en œuvre. Elle ne se limite pas à décrire toutes les potentialités liées aux architectures réalisées à partir de choix technologiques retenus. Les dernières générations d’outils d’architecture d’entreprise permettent de comparer automatiquement les performances de plusieurs types d’architectures en fonction des critères qui sont importants à la réussite des objectifs visés par les stratégies, de faire aussi différents types d’analyses en fonction des styles de déploiements envisagés (progiciels, développements internes, externalisation/cloud, niveaux de service, sureté, sécurité, services centralisés/décentralisés,…). En fait l’architecture d’entreprise n’empêche pas d’adopter une démarche « best of breed » ni une démarche « Lean » (qui d’ailleurs parfois se rejoignent). L’architecture d’entreprise doit par contre être capable de tout modéliser pour permettre de faire « les meilleurs choix » par rapport à la stratégie et aux objectifs de l’entreprise.
  • Clem
    "L’architecture d’entreprise a donc plutôt pour vocation de valider des choix technologiques par rapport aux stratégies des organisations qui la mettent en œuvre." Voila qui est très clair, ou peut on voir un cas concret ?
  • Eric Zardi
    Notre client, APG Asset Management, est un exemple concret d’une entreprise pour laquelle l’Architecture d’Entreprise permet de supporter la stratégie de leur compagnie notamment par rapport aux évolutions pas toujours prévisibles auxquelles elle se doit de réagir rapidement pour rester compétitive. La vidéo accessible via le lien suivant permet de comprendre facilement en quoi l’Architecture d’Entreprise est positive pour APG: http://www.bizzdesign.fr/outils/architecture-entreprise-togaf/ Un autre exemple est celui de Deutsche Telekom qui est résumé sur la page suivante de l’Open Group qui est en charge de TOGAF (The Open Group Architecture Framework): http://www.opengroup.org/london2011/schweichhart-weber.htm Ces exemples ne sont bien sûr que des échantillons de ce que vous pourrez aussi trouver par vous-même.
  • Yoann
    Je réagis un peu tard à cette discussion sur mon article. En fait, je dirai que si vous semblez en désaccord, je suis plutôt d'accord avec vous :) Le choix d'une technologie est la plupart du temps le fruit d'exigences métiers répondant à une conception court/moyen terme de la manière de réalisée l'activité. C'est à dire outillant le processus existant ou le nouveau processus mis en place. Et c'est tout à fait normal! L'investissement dans une technologie engage souvent sur le long terme, on la conserve au moins 10 ans. Dès lors si on ne se projète pas sur les évolutions envisageables au niveau métier dans les années à venir, le choix technologique (mais aussi toute la conception fonctionnelle qui l'accompagne) faisant sens à court terme peut s'avérer un mauvais choix pour le moyen ou long terme, impliquant de nouveaux investissements et des changements importants qui auraient pu être évités. On est bien là dans la question de la stratégie, mais celle-ci n'est pas toujours claire. La discipline d'Architecture d'Entreprise doit aider à diminuer le risque de voir apparaître des évolutions majeures auxquelles ne saurait pas s'adapter le SI tout en répondant aux exigences immédiates du métier. Comme le dit Eric, s'assurer d'avoir pris en compte les préoccupations de l'ensemble des parties prenantes de l'architecture (comprendre ceux qui sont impactés par le changement) est une méthode qui donne de bons résultats. Une entreprise est un lieu d'interdépendance entre des acteurs métiers ayant des préoccupations, des langages, des objectifs différents. Ne pas prendre en compte ces interdépendances, c'est prendre le risque de concevoir une architecture non pérenne car omettant de répondre à des attentes structurantes qui ne manqueront pas de resurgir. Essentiellement, il s'agit d'échanges d'informations métiers dans le cadre de processus transverses plus ou moins identifiés. Cela peut également concerné des adhérences trop forte à un type d'organisation. Pour faire une bonne Architecture d'Entreprise, il est impératif de prendre en compte plusieurs dimensions, parmi lesquelles, la stratégie métier, l'organisation, les processus, la structure informationnelle de l'entreprise, les services applicatifs et d'infrastructure. Les attentes et la stratégie structurent la vision de la transformation de l'entreprise. L'architecte d'entreprise doit s'assurer de la cohérence de l'ensemble dans la définition de la cible du SI qui permet de donner une trajectoire pour accompagner cette transformation.
  • yoann
    Un ajout sur le sujet du best of breed. Comme Eric, je ne pense pas qu'il y ait de réponse universelle au sujet, un équilibre est à trouver entre le best of breed qui peut être coûteux et surdimmensionné par rapport aux besoins de l'entreprise et le tout intégré qui peut contraindre l'évolution métier. Le choix de solution doit aussi s'établir sur le caractère différenciant du métier pour l'entreprise. Une solution ERP offre des fonctionnalités CRM et PLM intégrées. Si, pour l'entreprise, les métiers demandeurs de telles fonctionnalités ont des besoins "standards", une relative stabilité et une faible valeur dans le business model, alors profiter de cette intégration peut être une bonne stratégie. Le coût de possession du SI sera plus faible. Si par contre ces domaines participent directement à la compétitivité de l'entreprise, sont en évolutions constantes, embarquent des fonctions métiers diverses (Marketing, Callcenter, gestion complexe de la configuration produit) alors une stratégie Best of breed est sans doute possible. Il conviendra de construire l'intégration avec les domaines en interdépendance. Mais la valeur métier sera plus importante. On pourrait aussi ajouter que sur des sujets d'innovations pures le développement interne est tout à fait possible. Mais seule l'analyse architecturale permettra de réellement statuer pour l'un ou l'autre des scénarios. On en revient alors aux méthodes exposées plus haut. Le même constat peut être fait pour une multinationale qui hésiterait entre une certaine centralisation de ces solutions ou une approche locale. Est-il possible d'aligner les différents pays sur des processus métiers, existe-t-il des contraintes réglementaires? L'équilibre devra être trouvé entre la capacité à diminuer les coûts de possession du SI, à homogénéiser les modes de fonctionnement, à faciliter le reporting central et la capacité nécessaire à assurer la performance opérationnelle des pays. Le continuum de TOGAF donne une méthode très intéressante pour aider à classifier les architectures : de l'architecture foundation pouvant s'appliquer à tous les contextes à l'architecture organization specific répondant à un contexte très particulier. Entre les deux des degrés divers de réutilisabilité de l'architecture dans l'entreprise. Là encore l'étude d'architecture doit être menée en prenant en compte toutes les dimensions pour guider le choix. Personne n'a dit que ce serait facile :)
  • Anas
    Merci pour ce rappel des fondamentaux. L’Information a toujours été le cœur du système quelque soit l'échelle, composant logiciel, applications, quartier, lotissements ... et SI. La ressource la plus sensible est l'Information. C'est elle qui assure le fameux alignement du SI sur le métier. C'est la rotule. La technologie n'est qu'un outil, même avec les meilleurs technologies, un SI avec une Information mal gérée et mal modélisée, ne sera pas aligné sur le métier. La conscience des décideur de la sensibilité de cette ressource n'est pas encore de mise. La structuration et la bonne gouvernance de l'Information est une activité reléguée au second plan par nombre de décideurs, à tort, car c'est à ce niveau que se situe le levier le plus important de l'alignement du SI sur le métier.
  • PAURON
    Bonjour, L'architecture d'entreprise, en dehors de toute méthode est une conception qui n'urbanise pas. Elle entreprend, elle a une vision dramatique du genre en fondant son action sur les notion d'infrastructure , de structure et de superstructure. L'homme est au sein du système (Michel Volle), la notion d'outil a disparu, car l'outil c'est le micro service. L'ingénierie d'entreprise vise avec l'architecture d'entreprise de concilier Numérique (le métier appliqué en algorithme 'code is Law' ) à l'Informatique (la science de l'algorithme et de l'electroinformatique, bientôt la mécatronique adjointe à l'intelligence artificielle 'flexibikity in a rigid frame'). Le but étant de mîtriser le momentum imposé par le marché, l'activité, la pénurie ou abondance, bref d'être prêt. @+ Max
  • PAURON
    Bonjour, Celui qui se laisse débordé par les informaticiens, il tombe dans la 'logarchie' : "la logarchie (*) n'a pas pour autant surmonté la question de la fusion qu'elle aime à le faire croire; l'individualisation qui y règne est fictive." in Kathleen Gyssels - Sorciere - Hyvrard Economiste. En effet, noyé dans l'information, l'individu n'existe plus il est la chose qui fusionne, comme l'enfant avec sa mère. Au contraire celui qui trace l'entreprise en creusant son trou dans l'informatique et le numérique, entre dans un monde d'attracteur (in Lahlou - attracteurs cognitifs) qu'il gère avec ses homologues à travers ses blog, ses api et ses algorithmes diffusés dans le web - par exemple - c'est l'archilogie (cf Archilogy - Tru Do Khac ) , pour nous en france notre architecture d'entreprise se découpe comme un tunnel phénoménologique à travers lequel les forces vives de l'entreprise travaille de concert (SaFe-Scrum) à faire émerger sa vision du monde (publique) qui s'impose par sa bienveillance et la conciliation qu'elle opère, opposée au pragmatisme. Exemple : faire usage de robots pour aider des prématurés à grandir dans un utérus artificiel, c'est donner les moyens de contrôle de ce procédé dans l'éthique et la morale, qui trancende l'humain , non pas qui l'asservi - c'est l'archilogisme de l'architecture d'entreprise qui nait sous nos yeux. @+ Max

      • Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha