AOS : des architectures très hétérogènes

agrandir la photo

1 - Un point d'entrée unique
Une AOS offre un point d'entrée unique à toutes les applications d'un SI. Elle permet la modification ou le remplacement rapide de l'un des éléments de ce SI, sans impacter l'ensemble. Les services Web, à la base d'une AOS, apportent une réponse adaptée à un besoin particulier. Ils évitent de développer des processus complexes abordant une problématique trop générale.

2 - Un système d'information évolutif
L'architecture orientée services permet de bâtir un nouveau système d'information à partir des éléments existants, en centralisant les processus métier à la base de l'activité de l'entreprise. La mise en place d'une AOS est souvent à l'origine de réductions budgétaires, car elle est plus simple à maintenir et plus souple à faire évoluer que des progiciels monolithiques.

3 - Une mise en ?"uvre complexe
L'entreprise doit se livrer à l'étude de ses processus métier pour les coder ensuite dans l'infrastructure technologique. Cela peut engendrer de considérables frais d'étude et d'intégration. Cette complexité nécessite un transfert de compétences entre l'intégrateur et les équipes internes. Il est nécessaire de former les futurs utilisateurs qui auront à se familiariser avec de nouvelles interfaces clients.

4 - Administration indispensable
La complexité technique d'une architecture orientée services nécessite une plate-forme de supervision réseau ainsi qu'un mécanisme d'administration de services Web, comme en propose, par exemple, AmberPoint. La description du rôle et du mode de fonctionnement de ces services Web est indispensable.

Quelques solutions techniques

agrandir la photo

Retour d'expérience : Stéphane Cresto (SPIR Communication) : ' Les services nous ont fait gagner du temps '

Faire évoluer les blocs fonctionnels

' Suite à un changement de convention collective, nous avons dû complètement modifier le SI de notre filiale Adrexo, chargée de la distribution des journaux. Étaient concernées les applications de vente, de distribution et même de RH, dont les traitements allaient devenir très complexes, explique Stéphane Cresto. Nous avons choisi une approche à base de services métier, développés avec l'architecture.NET de Microsoft. ' Stéphane Cresto et ses équipes ont progressivement bâti une gestion de la distribution des imprimés, un datawarehouse et un portail Web SAP qui communique avec les applications. ' Nous avons délibérément cherché la simplicité. Il nous a fallu développer des services métier et non pas des applications monolithiques car nous savions que nous aurions à redévelopper les pièces qui ne marchaient pas. Il nous fallait des blocs fonctionnels que nous pouvions faire évoluer sans tout changer et suivre au jour le jour. La mise en place de la SOA a imposé certaines contraintes de développement. Chaque service doit bénéficier d'une vue fonctionnelle pour pouvoir être réécrit dans un délai raisonnable. Ils doivent être supervisés continuellement pour réagir vite en cas de perte de performances ou de trop grande consommation de ressources. '

Retour d'expérience : Vincent Bonnet (Pernod Ricard) : ' Nous avons supprimé nos silos applicatifs '

Homogénéiser les processus métier

Pernod a refondu son SI pour bénéficier de processus métier homogènes, partagés par toute l'entreprise. ' Au départ, nous désirions faire communiquer notre nouveau progiciel logistique avec l'application utilisée pour calculer les droits sur les transports d'alcool, explique Vincent Bonnet. Cela nous a donné l'occasion de constater l'état de notre SI, entièrement constitué de silos applicatifs ; nous avions pas moins de six progiciels pour gérer l'ensemble du processus de commande : un pour les stocks, un pour la prise de commande, d'autres encore pour la facturation, les livraisons... ' Ces outils ayant fait leurs preuves, décision est prise de les interfacer au moyen d'une plate-forme centrale. ' Nous avons fait appel à Vistali, un intégrateur qui a commencé par nous faire décrire nos processus métier, notamment ce qu'était pour nous une commande. Puis, nous avons choisi BizTalk, l'EAI de Microsoft, dans lequel l'intégrateur a codé nos méthodes. Faute de connecteurs pour certaines applications anciennes, nous avons imaginé d'autres méthodes de dialogue avec BizTalk, basées par exemple sur des appels à des procédures stockées qui vont chercher les données métier. ' Pour Vincent Bonnet, le nouveau système constitue bien une AOS. ' Les progiciels ne communiquent pas directement entre eux, ils font circuler des processus. Nous pourrons, grâce à BizTalk, ajouter un nouveau progiciel pratiquement sans rien changer au système. Nous avons gagné en souplesse et en productivité. '

Avis d'intégrateur : Marc Boullier (Vistali) : ' Une conception fonctionnelle des échanges applicatifs '

Les AOS sont-elles une évolution des EAI ?
Comme lors de la vague EAI du début 2000, il s'agit d'utiliser une technologie à base de processus pour masquer la complexité de l'architecture applicative. Cependant, à la différence de l'EAI, l'AOS introduit une conception fonctionnelle des échanges. Il ne s'agit plus de discuter avec SAP R/3, mais avec le domaine de la facturation.

L'architecture des EAI a-t-elle évolué ?
Oui. Le moteur central a tendance à disparaître au profit de run-time placés sur les serveurs applicatifs, reliés par un ESB qui prend en charge le routage des messages. Les règles de sécurité, en revanche, comme les métadonnées, doivent être centralisées.

Assiste-t-on à l'arrivée de services vraiment réutilisables ?
Absolument. Il faut cependant respecter les standards XML et Soap. Il y a plus de 78 spécifications sur les services Web. Certaines sont utilisées aujourd'hui par les différents éditeurs du marché. On ne connaît pas leur niveau de maturité, WS-Security commence seulement à s'affirmer. Mieux vaut employer WS-Basic, la première spécification à la base des services Web.