Les Architectures Orientées Services (SOA) répondent à un modèle d'interaction applicative particulier, mettant en oeuvre des composants logiciels simples et autonomes appelés « services ». Cette approche permet de décomposer l’expression d’un besoin métier en un ensemble de fonctions basiques au niveau du système d’information. Elle invite également à cesser de construire la vie de l'entreprise autour d'applications rigides et monolithiques, traditionnellement réparties en silos fonctionnels. À contrario, elle favorise une architecture logicielle souple et modulaire, organisée en « services ». Ces derniers sont partageables entre les différents domaines de l’entreprise, et donc réutilisables dans le cadre de l'implémentation de processus métiers transverses.
Adopter une démarche SOA n’est pas trivial. Afin d'adresser les nombreuses problématiques inhérentes à ce type d’architecture, il est nécessaire de spécifier et de mettre en application un dispositif de contrôle et de surveillance adapté, à même d’encadrer et de limiter les nombreux impacts induits par l’approche SOA.
Toutefois, encore faut-il veiller à garantir les bénéfices liés à la SOA comme le premier d’entre eux : l’amélioration de la compétitivité de l’entreprise en favorisant l'alignement entre le métier et l'IT, et en accélérant le « Time to Market ». Et cela nécessite plus que jamais une vigilance accrue, car il s’agit de ne pas rigidifier le système plus que de raison. Un résultat totalement contraire à la philosophie même de SOA, sensé procurer souplesse et flexibilité au SI.
Alors, faut-il contrôler malgré tout ? Assurément ! Mais en veillant à ne pas entraver l'agilité de l'architecture du SI, ni celle de son organisation. Entre contrôle et flexibilité, l’entreprise doit trouver son point d’équilibre.
Aujourd'hui, beaucoup d'entreprises adoptent (ou ont adopté) une démarche SOA avec pour objectif premier de gagner en agilité. Objectif : supporter au mieux et au plus vite l’expression de nouveaux besoins métiers. En effet, la mise à disposition rapide sur le marché et à destination des clients de nouveaux produits et de services à forte valeur ajoutée est devenue le nerf de la guerre.
Avec un peu de recul, on constate toutefois que les nombreuses initiatives engagées n'ont pas toutes été couronnées du même succès. Ainsi, s'il est en général assez aisé de « toucher du doigt » les bénéfices tant attendus de la SOA lors de l'élaboration d'un projet pilote (modularité de l’architecture, réutilisation de composants, rationalisation du SI...), l'exercice s'avère bien plus complexe et périlleux lorsqu'il s'agit de déployer et mettre en oeuvre des projets typés « SOA » à grande échelle, traversant les différents silos fonctionnels et organisationnels de l'entreprise.
Dès lors, les nouveaux défis introduits par les architectures SOA sont bien plus nombreux, et particulièrement difficiles à appréhender : quelle stratégie de financement mettre en place pour des services transverses et partagés, destinés à être utilisés par différentes entités de l’entreprise ? Qui doit en assumer la propriété et, par conséquent, la responsabilité ? Comment prioriser le développement des services au regard du portefeuille de projets et de leurs roadmaps ? Comment garantir la qualité de leur développement, ainsi que leur performance et leur bon fonctionnement à l’exécution ?
Il ne s’agit là que de quelques exemples, la liste exhaustive des problématiques s’avérant fort longue.
Pour apporter une réponse à ces problématiques spécifiques aux architectures de services, il est primordial de se doter d'un dispositif permettant de cadrer la démarche globale. La Gouvernance SOA est une discipline incontournable visant à accompagner et à sécuriser le déploiement d'une SOA de bout en bout, via l’identification, la spécification et la mise en oeuvre de processus, de bonnes pratiques et de principes directeurs spécifiques aux architectures de services.
La Gouvernance SOA constitue un levier majeur de la rationalisation du SI :
Elle favorise également la réduction des coûts du département informatique :
En outre, elle contribue à l’amélioration de la disponibilité et de la fiabilité des applications, et offre une nouvelle agilité à l'entreprise en permettant de réduire les délais nécessaires entre l'expression des besoins par les métiers, et leur mise en oeuvre au sein du SI.
La Gouvernance SOA, concept sibyllin s’il en est, prend corps et s’applique concrètement via l’identification, la formalisation, la mise en oeuvre et la supervision d’un régime (ou programme) de Gouvernance. Pour être réellement efficace, ce dispositif se doit d’être contextuel et adapté à l’entreprise qui initie la démarche SOA, en tenant compte de ses processus existants et de son organisation interne.
Dans la majorité des cas, ce nouveau régime de gouvernance ne se construit pas à partir de la page blanche.
En effet, afin d’éviter certaines zones de recouvrements avec des dispositifs existants et déjà en place, la gouvernance SOA doit être appréhendée non pas comme une nouvelle discipline, mais comme une extension et une particularisation de celles déjà bien connues que sont la Gouvernance Informatique (aussi appelée Gouvernance IT – avec certains frameworks connus tels que Cobit), et l’Architecture d’Entreprise (EA – avec certains frameworks connus tels que TOGAF). La gouvernance SOA permet alors d’apporter un cadre pour les nouvelles activités spécifiques à la mise en oeuvre des Architectures de Services, et non couvertes par les disciplines déjà en place dans l’entreprise.
La gouvernance SOA recouvre un périmètre d’application très large, qui présente deux dimensions majeures : la stratégie et l’opérationnel.
Sur l’axe stratégique, le programme de gouvernance SOA doit proposer un cadre pour la gestion de portefeuilles de solutions SOA (aussi connues sous le nom d’applications composites) et la gestion de portefeuilles de services. Pour cela, il apporte des éléments de réponses sur les différentes problématiques stratégiques : l’identification (des solutions éligibles au paradigme SOA, et des services candidats à la réutilisation), le financement (qui paye pour la réalisation de fonctionnalités transverses et partagées ?), la planification, la priorisation, la propriété et la responsabilité, etc.
Sur l’axe opérationnel, il est nécessaire de contrôler et de sécuriser les trois temps forts de l’existence des solutions SOA et des services. A savoir : la phase de fabrication (« Design-Time »), la phase de déploiement (« Deploy-Time ») et la phase d’exécution (« Run-Time »). Cela nécessite la mise en place de processus spécifiques de gestion des cycles de vie pour les solutions SOA et pour les services, à même d’adresser les problématiques relatives à chacune des trois grandes étapes précitées.
Sur chacun des deux axes, qu’il s’agisse des services ou des solutions SOA, le programme de Gouvernance SOA doit considérer les trois piliers fondamentaux d’un dispositif classique de gouvernance que sont :
Un programme de gouvernance SOA doit donc préconiser la mise en place de processus adaptés aux particularités d’une démarche SOA, d’un ensemble de directives de contrôle (aussi appelées « principes directeurs », ou « politiques »), permettant d’encadrer et de sécuriser à la fois la fabrication et l’exécution des services (on parle alors de « Design-Time Policies » et de « Run-Time Policies »), ainsi qu’une organisation cible qui soit à même de supporter l’ensemble du dispositif méthodologique et technologique proposé.
Prendre appui sur une méthode éprouvée
Construire un dispositif de gouvernance ne s’improvise pas. Cela requiert une démarche méthodologique claire et structurée, associée à une approche itérative et incrémentale. Un nouveau dispositif de gouvernance peut effectivement entraîner de nombreux impacts sur les axes méthodologiques et organisationnels de la branche informatique, en introduisant par exemple de nouveaux processus de gestion, ou en donnant naissance à de nouvelles cellules organisationnelles transverses (centres de compétences, cellule de gouvernance…).
La gouvernance SOA ne doit en aucun cas être déployée via une approche de type « big-bang ». On veillera plutôt à procéder par vagues de déploiement successives, avec pour chaque itération : une phase d'identification, une phase d'implémentation, une phase de mise en oeuvre, puis une phase de supervision du dispositif cible.
Ainsi il est de coutume d’identifier les objectifs que l’on se fixe en termes de gouvernance, d’analyser les écarts avec le dispositif existant, de planifier un plan de transformation et de transition adapté, d’implémenter le dispositif cible sur le plan technologique, méthodologique et organisationnel. Enfin, il s’agit de mettre en place des métriques et des indicateurs de suivi permettant d’évaluer l’atteinte des objectifs initialement fixés.
Partager |
|
![]() Eric Vendeville,
Eric Vendeville accompagne de grands comptes dans leur stratégie de déploiement de la Gouvernance SOA. Il maîtrise la méthode et les outils relatifs au sujet de la Gouvernance SOA. Il intervient le plus souvent sur des cadrages méthodologiques et des cadrages d'architecture. Il traite des architectures orientées services (SOA) dans leur ensemble depuis plus de six ans à présent. |



