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).
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.
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.
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 ?
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.