Avez-vous essayé de demander a une quinzaine de personnes autour de vous ce que sont les SOA (Service Oriented Architectures). Essayez, vous obtiendrez vraisemblablement une quinzaine de réponse différentes. Fatalement cela mène à quelques incompréhensions relatives aux architectures SOA. Ces dernières sont également soit issues des présentations commerciales, soit d’une mauvaise explication de ces concepts. Voici donc en quelques mot le moyen, j’espère, de venir à bout de quelques unes de ces idées erronées.
Tout d’abord, les SOA ne sont pas un nouveau concept. Pour preuve sur MVS on exposait déjà des modules généralisés il y a 15 ans. Plus généralement cette notion de partage fonctionnel est née dès lors qu’il y a plus d’un ordinateur dans les entreprises.Les appels se sont fait via RPC puis via IPC. Elles ont été ensuite enrichies par des technologies permettant la distribution d’objets métiers tels que COM et CORBA. Les services web ne sont qu’une déclinaison plus récente de ce concept.
Ces web services ne sont par ailleurs pas du tout indispensables à la mise en place d’architectures SOA, même s’ils ont été créés pour en faciliter l’implémentation. Toutes les technologies précitées peuvent y parvenir (COM, CORBA, J2EE…). On peut également y parvenir grâce à l’utilisation de technologies propriétaires.
Par ailleurs, les communication entre les applications d’un réseau d’entreprises n’étant pas une nouveauté, il existe déja des logiciels capables de faire communiquer les différents composants informatique d’une entreprises (les ESB) . Ces derniers, s’ils peuvent bien entendu faire partie d’une SOA ne forment pas une SOA-en-kit. Les ESB ne sont qu’une des solutions techniques qui s’offrent pour construire une SOA. Une telle architecture (nous le verrons dans d’autres article) n’est pas qu’un amas de solutions techniques. Il s’agit plus dune approche permettant la réutilisabilité et l’adéquation de l’outil informatique aux besoins métiers de l’entreprise.
De ce fait les SOA sont et doivent rester éminemment “scalable”, c’est a dire qu’elles doivent permettre aider à mener a bien les augmentations de taille de système d’information des entreprises. Une attention particulière doit donc être portée lors de la phase de découverte/définition des services métiers pour que les briques constitutives du nouveau SI (services métiers) soient adaptées (ni trop grossières, ni trop détaillées). En effet, il faut garder en tête que les architectures informatiques sont au service de la société, et que ces dernières ne doivent pas devenir un poids pour elle ; ce qui serait le cas si ces briques n’étaient pas correctement définies.
De même, tout changement d’architecture doit servir l’entreprise. Bien souvent on se penche sur les SOA pour la réutilisabilité et la flexibilités qu’elles offrent. Ces qualités intrinsèques des SOA serviront généralement votre entreprise, mais il reste important de vérifier auparavant que les coûts de restructuration que leur mise en place va demander en vaudront bien la chandelle (en gros que le ROI sera conséquent).
Post a Comment