Les 7 péchés capitaux de la SOA

Certains projets SOA ont déjà suffisamment souffert de leurs erreurs, inutile de s'échouer à nouveau sur les mêmes récifs. Voici décrites 7 erreurs fatales, 7 anti-patterns de démarche SOA qui sont autant de pièges dans lesquels vous ne tomberez pas.

1) SOA furtive : faire la SOA sans le métier

La tentation peut devenir forte, coté DSI, de mettre en place une SOA sans faire participer le métier au projet, voire sans même les informer de la démarche : dans de nombreuses entreprises, la discussion entre les métiers et une informatique décrédibilisée et considérée comme couteuse, est devenue difficile. Un projet de rénovation du SI utilisant les principes de la SOA couronné de succès apporterait plus d'efficacité et de souplesse. Cela restant un projet SI, il peut sembler est inutile d'impliquer les métiers car le seul résultat serait de rendre le projet plus difficile à mener.

Dans la réalité des faits, cette analyse se heurte à deux difficultés : la définition d'une stratégie et le financement. Tout d'abord, un des objectifs majeurs de la SOA est l'alignement du SI sur le métier. L'absence de dialogue rend impossible toute transformation architecturale prenant réellement en compte les attentes concrètes et les jalons du métier.

Ensuite, la SOA implique la mise en place d'une infrastructure, d'outillages et de services partagés et transverses à l'entreprise. Le financement de leur mise en place et surtout celui de leur maintenance en vie courante sont incompatibles avec des modes des fonctionnements et l'allocation de budget basés sur les projets.

Le métier doit donc être impliqué très tôt dans toute initiative SOA, sur les aspects métier, afin de définir une architecture et un plan de mise en oeuvre permettant l'alignement du système d'information et le financement des actions à entreprendre.

2) Simplisme : la SOA, c'est simple et facile

Les concepts de la SOA sont simples à comprendre et l'arrivée à maturité des solutions logicielles supportant ce type d'architecture, fait apparaître la mise en oeuvre come tout aussi simple à qui n'y prend pas garde. Mais ignorer la complexité de la SOA coutera cher en temps et en budget. Le projet n'atteindra pas ses objectifs ; il sera arrêté ou redimensionné à la hausse pour faire face aux difficultés inattendues rencontrées, ce qui est toujours particulièrement onéreux.

Pour bien évaluer l'effort à fournir, l'utilisation d'un modèle de maturité SOA recensant les champs à couvrir et définissant des repères d'avancement sur chacun des axes est une bonne option. Il permet d'obtenir une bonne vision d'ensemble des impacts de la SOA et des sujets à traiter tant dans l'immédiat que dans l'avenir.

3) Prolifération de services : d'abord créer de nombreux services et après faire le tri

Pourquoi ne pas demander aux nouveaux projets d'appliquer une politique « tout service » ? Il paraît aisé de favoriser à postériori la réutilisation des services existants et d'arbitrer entre les éventuels services dupliqués ? Parce que la réutilisabilité ne coule pas de source. Les nombreuses tentatives de capitalisation d'objets réutilisables à partir d'applications existantes nous l'enseignent.

Plus récemment, le manque de supervision des projets à mené plusieurs entreprises à constater la mise en production de 6 à 10 services identiques... à quelques différences près.

Mieux vaut gérer rigoureusement dès le départ le portefeuille de services que de devoir le remettre à plat plus tard.

4) Jeunisme : connaître SOA vaut mieux que connaître l'entreprise

Parce qu'ils ont commencé leur carrière avec les nouvelles technologies, la SOA leur est une évidence. Parce qu'ils sont compétents, les architectes junior conseillent l'entreprise sur l'utilisation de la SOA. Mais ils leur manque l'expérience terrain des processus de l'entreprise, de la gouvernance et des modifications organisationnelles nécessaires à un projet SOA réussi. L'expérience de l'entreprise est aussi nécessaire que la maîtrise des nouvelles technologies et des nouvelles architectures.

Une démarche ayant fait ses preuves est la création d'un centre de compétence SOA (ou d'excellence SOA) ayant pour mission d'orienter les initiatives SOA et de partager la connaissance.

5) Absence d'orientation processus : ne voir l'entreprise que par ce qu'elle produit

Une entreprise peut être regardée au travers d'une vue « produit », focalisée sur les biens et services produits par l'entreprise. Ce type de vision correspond aux organisations en silos et conduit à une architecture qui reflète ce type de structure, avec tous ses inconvénients.

La SOA considère au travers des services les capacités fondamentales de l'entreprise, ce qu'elle fait réellement. Pour identifier ces capacités, une connaissance approfondie du fonctionnement de l'entreprise, c'est-à-dire de ses processus, est indispensable.

Pour supporter l'activité d'une entreprise, la SOA se calque sur son fonctionnement réel et non sur sa la manière dont cette entreprise est organisée, ce qui suppose un approche orientée processus.

6) Amélioration des standards : gagner du temps avec une petite modification

Un des piliers de SOA est l'utilisation de standards, qu'ils soient des normes mondiales tels les WS-* ou des standards utilisés au sein d'une entreprise. Ils sont à la fois une commodité et une contrainte car ils donnent un cadre structurant. En cédant à la facilité, en contournant, dans un cas bien précis par un petit développement non conforme, par une petite modification des standards applicables, le standard devient spécifique. Pas beaucoup, certes, mais cela suffit à complexifier la maintenance et induire des coûts supplémentaires.

Il est nécessaire de faire preuve de rigueur dans l'application des standards et de mettre en place les contrôles de conformité nécessaires.

7) Le Tout SOA : tout migrer vers la SOA

Les architectures orientées services présentent de nombreux avantages parmi lesquels la flexibilité et la réactivité. Il tentant de remplacer tout le vieux système poussiéreux par du neuf. Cela n'est bien entendu ni possible ni souhaitable.
Avoir la vision d'un monde « tout SOA » permet de montrer ce qui peut-être atteint par l'entreprise.

En fonction de l'effort organisationnel et technique à fournir pour migrer un sous-système donné, il est possible de déterminer si un besoin, un enjeu existe réellement. Aucun business case ne justifiera la refonte de deux systèmes qui ne communiquent qu'entre eux simplement pour les orienter service.
Il ne faut de SOA que le juste nécessaire au moment opportun.

Ce catalogue du pire n'est certainement pas exhaustif. Les chausse-trappes sont d'autant plus nombreuses que les chemins commencent seulement à être balisés. Heureusement, la SOA n'est pas une révolution totale, ni dans le fond, ni dans la forme.

Il s'agit avant tout d'architecture, discipline qui n'est pas un terrain inconnu, pas plus que les notions de réutilisation, de composants ou de gouvernance. Cette approche novatrice par de nombreux aspects se nourrit surtout de l'expérience en informatique d'entreprise des 15 dernières années, ce qui rend la démarche crédible et opportune.

Bruno Rizzi et Philippe Ravix