S* oriented architecture | Aurélien Pelletier

Comment faire pour passer de cela:
Un système d’information en silo où les applications sont cloissonées les unes des autres et ne communiquent pas ou peu entre elles.

A ceci :
Un système d’information où les applications communiquent abondament entre elles et sont construites en réutilisant des services qui exposent les fonctions de l’entreprise.

La première question à se poser est de savoir si vous avez réellement intérêt à succomber à la mode SOA?
Rappelons qu’une architecture se choisi en fonction d’un besoin et non pas en fonction d’une mode ou des recommandations d’un vendeur de logiciels ou de matériels (voir les deux à la fois).

A quel besoin répond une architecture de style SOA?

Celui de réorganiser dans des délais court l’organisation d’une l’entreprise pour s’adapter rapidement à un environnement en perpétuelle évolution. Donc SOA n’est pas uniquement une mode mais répond bel et bien à un besoin de plus en plus répandu.

Comment SOA répond t-il à ce besoin?

La promesse SOA est le nirvana de l’informatique, notre Saint Graal à tous: la réutilisation! Des générations d’informaticiens se sont cassés les dents sur le problème. Ce coup ci serait-il le bon? Une seule certitude: Une architecture de type SOA coûte plus cher à mettre en place qu’une architecture plus traditionnelle et simple. Le ROI n’est à attendre que sur le moyen/long terme: lorsqu’une nouvelle application sera développée en s’appuyant sur des services déjà existant.
Chacun répondra à ces interrogations selon son contexte. Si vos réponses à ces questions vous confirment dans le choix d’une SOA, quelles sont les conditions du succès?

J’ai vu pas mal de projet aborder la problématique SOA d’un point de vue technique au niveau applicatif. En général on constate que ces projets ne produisent pas des services réutilisables. Pour quelles raisons?

Web services, SOAP, UDDI, EAI, WS-*… La liste des technos que l’on peut introduire sur un projet SOA est longue. En réalité HTTP + XML peuvent suffire pour faire fonctionner une architecture orienté service. Ca ne veut pas dire que les autres technos soient inutiles. Mais là aussi il faut se poser la question de leur utilité et s’assurer que l’équipe de développement les maîtrises avant de les introduire.

Ces problèmes techniques, bien que pouvant être complexes et importants, sont des détails par rapport aux problèmes organisationnels. Bien souvent on décide d’introduire une architecture SOA dans le cadre du développement d’une nouvelle application. L’objectif du projet et de répondre au besoin métier de l’application, l’architecture SOA n’est qu’un moyen. Le projet est porté, financé par une direction métier, les achats par exemple. L’objectif du responsable des achats est d’obtenir au moindre coût et dans les délais les plus courts une application qui va répondre aux besoins de son métier dont le périmètre se limite aux achats. Son objectif n’est pas de financer le développement de services qui pourront être réutilisé par son collègue des ressources humaines. Ces deux objectifs s’opposent, le résultat ne fait aucun doute, au fur et à mesure que le projet avance, que les retards s’accumulent, les principes qui font une SOA sont sacrifiés pour répondre aux impératif immédiat de l’application: adieu le plan d’urbanisation, au revoir l’indépendance des services…

Au final les services produits sont les services de l’application, pas les services de l’entreprise. Cette notion est développée dans ce billet: Intégration d’applications ou intégration ontologique ?

Au lieu d’une approche technique au niveau applicatif il faudrait mieux se concentrer sur une approche fonctionnelle au niveau de l’entreprise. C’est le rôle du(des) homme(s) en rouge sur mon deuxième schéma. Le développement des services doivent être des projets à part entière, ce sont des applications comme les autres, avec leur propre budget et leur responsable métier dont l’objectif sera de produire des services réutilisable par les autres applications. Ces responsables de services ne sont pas rattachés aux achats ou à la production, ils sont transverses à l’entreprise.

C’est à mon avis une condition indispensable pour produire des services réutilisables, ce qui reste l’objectif principale d’une SOA.

On dit souvent qu’une architecture SOA permet d’aligner le système d’information avec les métiers de l’entreprise. Cet alignement est réalisable si les services informatiques font la moitié du chemin et l’organisation de l’entreprise l’autre moitié. On tombe bien sûr tout de suite dans une problématique de conduite du changement.

A défaut d’effectuer ces changements on court le risque de se retrouver avec ce type d’architecture:

Des services qui complexifient le système sans permettre de réelle réutilisation.

A lire aussi:

Réutilisation et mode projet : la contradiction par Dominique Vauquier.