Conception des services SOA

Le thème

L’état de la plupart des systèmes informatiques a de quoi préoccuper. Presque tous ces systèmes présentent un taux de redondance effarant. En ce qui concerne le couplage interne, ce n’est pas tellement qu’il soit élevé, mais il est peu connu, insuffisamment documenté, et il constitue une cause de rigidité et de risque.

Par ailleurs, les systèmes d’aujourd’hui ne sont pas des îlots fonctionnant de façon autonome. Ils sont plongés dans un environnement, et doivent interagir avec d’autres systèmes. L’interopérabilité rejoint des enjeux stratégiques pour les entreprises, puisqu’elles s’insèrent dans des chaînes de valeur complexes, impliquant des fédérations d’entreprises. Il ne suffit donc plus de concevoir un système informatique séparé : notre approche se doit d’être multi-système.

Bien comprise, l’approche SOA (service oriented architecture) fournit les principes pour restructurer correctement les systèmes informatiques. Elle remédie à la redondance, et donne les moyens pour maîtriser le couplage à l’échelle du système. Elle doit aboutir à l’exposition de services hautement réutilisables, à la fois à l’intérieur du système et vers l’extérieur. Elle assure ainsi l’interopérabilité.

La promesse SOA :

  • élimination de la redondance, donc réduction du volume du système informatique, donc diminution des coûts et des risques ;
  • augmentation de l’agilité du système technique (par réduction du volume et adoption de dispositifs d’agilité), ce qui contribue à l’agilité de l’entreprise ;
  • interopérabilité par partage d’un langage commun et exposition de services intelligents, ce qui facilite la mise en place de chaînes de valeur complexes (fusions-acquisitions opérationnalisées, convergence, partenariats…).

 

Cette “promesse SOA” concerne directement les décideurs. Elle répond à une partie de leurs préoccupations. Encore faut-il qu’ils en prennent conscience. Une vraie transformation informatique dans l’esprit de SOA réclame une forte vision et la continuité des efforts sur le moyen terme. L’horizon est de l’ordre de trois ans pour produire une transformation significative du système. En conséquence, l’engagement des décideurs est essentiel pour réunir les conditions de succès d’une SOA.

Un autre facteur de succès que l’on aurait tort de négliger est celui de la méthode. Comment trouver les “bons” services, qui soient autre chose que de simples accesseurs ? Comment structurer le système pour évacuer la redondance et assurer les performances ? Comment spécifier rigoureusement les services ? Quel est le chemin pour arriver à un vrai langage pivot, un format d’échange qui pourra être adopté par les différents systèmes en jeu ? etc. Au fil des expériences, ces questions ont reçu des réponses en termes de procédés. Notamment, les projets doivent mobiliser des compétences de conception logique. C’est la discipline traitée dans cette rubrique (voir aussi : Architecture logique).

Nos prestations

  • Pour la préparation des compétences de conception : Formation “SOA, conception d’une architecture de services”.
  • Définition et accompagnement de programme de transformation IT.
  • Conception logique (production des spécifications détaillées des services jusqu’aux algorithmes, modèles logiques de données, modèles logiques des échanges).
  • Conception des tests.

Nos expériences

Nos atouts

Par la force des choses, Dominique Vauquier a été amené à mettre au point les procédés de conception nécessaires à l’approche SOA. En cela, il a été aidé par des experts, dans toutes les dimensions de ce sujet : stratégique, technique, méthodologique. Citons, notamment, Jean-Michel Detavernier (DSI SMABTP) et Pierre Bonnet (Orchestra Networks), avec lesquels il a publié l’ouvrage “Le Système d’information durables, la refonte progressive du SI avec SOA.

Il est aussi l’auteur de :

  • la méthode “Praxeme pour SOA”, version 1 du Guide de l’aspect logique ;
  • les supports de la formation à la version 1  (co-investissement de la SMABTP et d’Unilog) ;
  • plusieurs articles dont “Quatre idées fortes sur SOA“, à destination des décideurs informatiques.

Il pratique et enseigne la version 2 de “Praxeme pour SOA”, appuyée sur la notation UML 2 et tirant parti des nombreuses expériences partagées au sein du Praxeme Institute (April, Europcar, Volvo Group…). La version 2 précise les règles de dérivation des modèles métier, et détaille les procédés de conception logique, dans les trois facettes : services, données, échanges.

<<

Les commentaires sont fermés