Il y a 16 ans -
Temps de lecture 10 minutes
Mise en œuvre d’une SOA : Les clés du succès
La mise en œuvre d’une architecture orientée services (SOA) est un bien vaste chantier. Elle impacte toutes les composantes du SI (Système d’Information) et doit impliquer tous les acteurs de la DSI et même au-delà. De plus, elle suppose une profonde mutation des façons de penser et de concevoir le SI.
Autour de cette problématique titanesque, la question de la bonne approche pour la mise en place d’une SOA a donné lieu à bien des écrits et des théories chacune sous tendant des positions souvent trop dogmatiques.
Les différentes approches
Les clés du succès
Les différentes approches
En premier lieu, la polémique a rapidement enflé sur le thème « Top Down contre Bottom Up ». Un débat bien trop manichéen dans lequel certains ont vu le combat des puristes contre les pragmatiques, des générateurs de valeurs contre les gestionnaires (« cost savers ») ou encore des évangélistes métiers contre les architectes techniques. Cette opposition stérile tend à disparaitre mais elle a laissé des traces et ressurgit encore régulièrement sous des formes diverses [1].
Une fois cette première « guerre de religion » apaisée, on a vu fleurir pléthore d’approches hybrides proposant une troisième voix. Parmi ces approches, on retiendra l’approche Middle Out et l’approche Outside In (Aussi appelé Meet In The Middle) qui là encore ont chacune leurs partisans.
Top Down
Le point de départ de cette approche est le suivant : puisque l’objectif de la mise en œuvre d’une SOA est d’aligner le SI sur le métier de l’entreprise, c’est en toute logique qu’elle doit partir de la définition (ou de la formalisation) des processus métiers pour descendre ensuite au travers des différentes strates du SI afin de définir les services nécessaires à la réalisation de ces processus (en commençant par la définition des services de plus au niveau, c’est-à-dire offrant le plus de valeur ajoutée métier).
Cette approche représente la voie royale :
- Elle permet de piloter la SOA par les besoins métiers.
- Elle minimise la redondance de services.
Elle n’est cependant que rarement possible car :
- Elle signifie une refonte de tout ou partie du SI, jugée bien souvent trop coûteuse et trop risquée.
- Elle rend difficile l’adhésion à la démarche des équipes MOE (Maîtrise d’œuvre).
Bottom Up
A l’inverse, cette approche prône une phase de conception ascendante. Une analyse de l’existant (cartographie applicative) permet de déterminer les fonctions existantes du SI. Ainsi cartographiées, il est possible d’identifier les fonctions du SI qui sont éligibles au rang de service. Une fois ces fonctions mises en mode service, elles sont exploitables au sein de services à forte valeur ajoutée et / ou de processus métiers.
Cette approche peut séduire par plusieurs aspects :
- Elle contraint à réaliser une cartographie du SI qui, si elle est tenue à jour et publiée, facilitera la réutilisation de services.
- Le coup du ticket d’entrée peut paraître moins élevé que pour une démarche Top Down.
Elle présente cependant des travers rédhibitoires :
- Elle bloque le pilotage de la SOA par les besoins métiers.
- Elle ne favorise pas la mise en place d’un effort transverse : elle ne permet pas de sortir de la « culture projet ». En effet, les services émergeants de cette approche restent très fortement couplés à leur application d’origine.
- Elle rend très difficile la justification de l’investissement auprès du métier, qui n’en verra les bénéfices qu’une fois les services auront été rendus exploitables au sein de processus métiers.
Enfin, cette approche se limite à une mise en mode service de fonctions existantes sur le SI. C’est présupposer que cet existant suffit à réaliser le métier de l’entreprise. Quel est dans ce cas la pertinence de la mise en place d’une SOA pour aligner le SI sur le métier ?
Outside In (Meet In The Middle)
Cette approche préconise de mener en parallèle :
- Un chantier Top Down pour définir les processus métiers et les services de plus haut niveau nécessaires à leur réalisation.
- Un chantier Bottom Up afin de cartographier l’existant applicatif dont dispose l’entreprise pour supporter les services métiers à forte valeur ajoutée.
Une fois ces deux chantiers en phase finale, commence la délicate étape de l’accostage. Son objectif est de « réconcilier » les résultats des deux approches afin de déterminer comment seront réalisés les processus métiers. Il faut, pour cela, croiser les besoins en services (exprimés par le chantier Top Down) et le patrimoine applicatif (cartographié par le chantier Bottom Up).
De part sa nature, cette approche réunit les bénéfices des approches Top Down et Bottom Up. Elle permet de piloter la SOA par les besoins métiers tout en facilitant la réutilisation de services et la capitalisation sur l’existant.
Mais elle cumule également les travers des deux approches, notamment en induisant un très fort risque d’effet tunnel.
En effet, le point critique de cette démarche est l’étape d’accostage. C’est d’elle seule que dépend la réussite ou l’échec de la mise en œuvre d’une SOA. D’un côté, elle doit intervenir (et aboutir) suffisamment tôt pour éviter un décalage entre les résultats des chantiers préliminaires et la réalité opérationnelle (Nouveaux besoins métier / Cartographie obsolète). D’un autre côté, elle ne doit pas démarrer trop tôt afin de ne pas parasiter les chantiers Top Down et Bottom Up et de se baser sur des résultats suffisamment étoffés.
Le bon déroulement de l’étape d’accostage passe donc par une coordination étroite des chantiers Top Down et Bottom Up très en amont de sa réalisation.
Middle Out
Cette approche peut être introduite par la phrase « BPM et SOA sont les deux faces de la même pièce ». Assertion qui fait référence à un autre débat stérile ayant fait couler beaucoup d’encre et qui rappelle qu’il est impossible de dissocier la définition des processus métiers de l’établissement du catalogue de services.
Par opposition à l’approche Outside In, cette méthode propose de commencer « In the middle », c’est-à-dire là où le métier et les IT parlent le même langage (ou en tout cas presque). Elle s’attaque donc d’emblée à ce qui reste un des principaux freins à l’adoption des SOA au sein des DSI françaises : La compréhension du métier de l’entreprise par les maîtrises d’œuvre et inversement, la compréhension des contraintes IT par les maîtrises d’ouvrage.
Une fois les différentes parties d’accord sur un premier socle de services « métiers » nécessaires :
- La maîtrise d’ouvrage engage un chantier Middle Up pour spécifier les processus métiers.
- La maîtrise d’œuvre engage un chantier Middle Down pour spécifier le socle de services de plus bas niveau permettant la réalisation des services métiers.
Cette approche fait donc la part belle au dialogue entre métier et IT et pose la compréhension mutuelle comme pré-requis à la mise en œuvre d’une SOA.
Elle limite par contre le pilotage de la SOA par les besoins métiers, puisque le point de départ est l’identification des services métiers nécessaires et non la définition des processus réalisant le métier de l’entreprise.
Les clés du succès
Il n’existe pas de recette miracle pour la mise en œuvre d’une architecture orientée services (SOA). Il est illusoire de croire que l’application d’une des approches présentées plus haut garantisse sa réussite. Comme souvent, la réponse adéquate dépend, pour beaucoup, du contexte de l’entreprise : ses besoins, ses moyens, ses ambitions, son existant (organisationnel et méthodologique), …
Même s’il ne sert à rien de réinventer la roue, il est donc primordial de savoir décliner et adapter les différentes approches (ou combinaison d’approches) possibles dans le contexte de mise œuvre.
Il est également important de garder à l’esprit que l’approche choisie doit garantir la prise en compte du changement. En effet, la mise en œuvre d’une SOA étant un chantier de longue haleine, il y a fort à parier que les besoins métiers changeront en cours de route. C’est le premier pas vers l’agilité du SI et l’alignement de l’IT sur le métier.
Toutefois, quelle que soit l’approche choisie (et déclinée), la mise en place d’une architecture orientée services (SOA) ne peut pas aboutir si :
- Elle n’est pas traitée comme un projet transverse.
- Elle n’est pas pensée en termes métier.
- Elle ne s’accompagne pas d’un travail d’évangélisation visant à changer les façons de penser et de concevoir le SI.
Un projet transverse
La mise en place d’une SOA est un effort (une initiative) qui doit être mené de façon transverse. Elle ne peut pas être traitée projet par projet. Elle passe par un projet de gouvernance, mené par une équipe transverse. On ne parle pas ici d’un projet de réalisation qui engendrera du logiciel, mais d’un projet de pilotage.
Pour réussir la mise en place d’une SOA, il faut étendre la « culture projet » (pour autant que cette dernière ne soit pas complètement pervertie). En effet, même si le projet reste le seul cadre performant pour la construction d’une solution logicielle, il limite automatiquement, dès sa définition, le champ d’analyse. Il est utopique de demander à un responsable de projet d’étendre ces analyses au-delà du champ de son projet.
Cela ne veut pas dire qu’il faut abandonner le projet comme unité de production de logiciel. Cela veut dire qu’on ne peut plus mener la construction du SI par une simple juxtaposition de projets : Le SI doit devenir plus que la somme des applications qui le composent.
Un des moyens de garantir la transversalité du chantier est de mettre sur pied une équipe SOA dédiée en charge de le coordonner. Cette équipe doit regrouper des représentants et experts de chaque population impliquée :
- Maîtrises d’ouvrage métier : Expert métier.
- Maîtrises d’ouvrage SI : Architecte fonctionnel.
- Maîtrises d’œuvres : Architecte technique / logiciel.
- Exploitation.
Penser métier
La mise en place d’une SOA doit être pensée en termes de besoin métiers et pas en terme de besoins techniques : la construction d’une architecture IT doit se baser sur la problématique métier qu’elle tend à résoudre (ou sur le(s) service(s) métier(s) qu’elle essaie de rendre).
Evangéliser
La mise en place d’une SOA implique une mutation profonde des façons de penser et de travailler. Comme pour l’agilité, il ne suffit pas d’appliquer la culture SOA lors de la définition des architectures IT ou de la réalisation d’une application, mais il faut savoir l’étendre à l’ensemble des composantes d’une organisation.
Il faut commencer à sensibiliser les acteurs le plus tôt possible afin que cette mutation aboutisse et se face en douceur. L’évangélisation est de la responsabilité de l’équipe de coordination SOA.
Savoir itérer
Comme l’explique Manuel Eveno dans son billet « Quel type de projet pour démarrer une SOA ?« :
« […] Plutôt que de mettre en place, en une fois, toutes les briques de la SOA et d’introduire trop de changements, il est souvent préférable d’adopter une approche incrémentale. »
Il est donc bénéfique d’aborder la mise en œuvre d’une SOA via une approche par projets agiles.
On remarque qu’en planifiant cette mise en œuvre par itérations verticales (qui traversent toutes les couches du SI) sur des périmètres fonctionnels restreints, en y intégrant progressivement les évolutions des couches supportant les processus, chaque itération est pilotée par un besoin métier et les mutations du SI sont introduites progressivement.
—
[1] « SOA : méthode vs pragmatisme, mauvais débat » par Olivier Rafal.
Commentaire