Les architectures orientées services (SOA) sont maintenant tout à fait connues dans des entreprises. Non seulement leurs mérites ont été vantés depuis 5 ans par la presse et de nombreux consultants, mais aussi les premiers retours d'expériences sont maintenant disponibles, et le constat est le suivant : ça marche ! Les promesses de la technologie SOA ont globalement été tenues :
- L'agilité et la reconfiguration de l'intégration
- La compatibilité des protocoles entres les différents vendeurs
- Les performances transactionnelles
- La fiabilité de l'architecture
- L'ouverture et l'évolution vers les nouveaux standards
Tout cela serait pour le mieux dans le meilleur des mondes, si un point essentiel n'avait pas été oublié : Au fait, combien d'applications existantes dans l'entreprise possèdent les points d'entrées nécessaires pour être intégrées dans les architectures SOA ? Et c'est là ou le bât blesse, la majorité des entreprises ont construit leur système d'information sur des architectures et des technologies dites « héritées » qui ne présentent pas ces fameux points d'entrées.
Si l'on retrace l'histoire des systèmes d'informations depuis les années 1970, les entreprises ont été confrontées successivement à toutes ces différentes technologies :
- La grande époque des systèmes centraux dit mainframes (IBM, ou Autres) d'ailleurs toujours au centre des systèmes d'informations des grands comptes à ce jour
- Puis l'arrivées des systèmes départementaux types Minis, Systèmes 36 avec ses successeurs AS/400 iSeries et maintenant i5
- La montée en puissance des systèmes UNIX avec accès utilisateurs par terminaux en mode caractères
- Le règne des architectures client/serveur avec interface utilisateur graphique sous Windows (Et parfois, plus rarement UNIX)
- Bien sur, la déferlante Web Html a été appliquée aux applications en entreprise en Intranet, Extranet et Internet
- Et finalement, les architectures orientées services s'imposent de plus en plus depuis 2002
En y regardant de plus près, seule la dernière génération d'applications conçues après 2002 peut s'intégrer facilement dans les SOA. Que faire des 70% d'applications qui ne possèdent pas ces points d'entrées ? Bien simplement les adapter ou les remplacer, d'où ce périlleux chemin de migration. Le piège à éviter absolument et l'approche « Big Bang » qui consiste à remplacer d'un coup des applications fonctionnellement performantes qui certes présente des lacunes d'intégration, par une nouvelle architecture SOA qui mettra des années à rendre le même service fonctionnel. Toutes les études montrent que le succès des projets basés sur les SOA est fonction de la capacité à réutiliser les acquis logiciels de l'entreprise, et que cette question reste le seul point encore incertain et délicat lors de la mise en œuvre de tels projets.
Etant donné que le remplacement ou le redéveloppement d'applications est un facteur de coût trop important, la tendance actuelle est à l'adaptation des applications existantes pour leur « greffer » les fameuses prises SOA, j'ai nommé les « Web services ». En fonction de la technologie de l'application cible, ce processus peut être plus ou moins compliqué. En résumé, chaque fois que le modèle trois tiers (données, logique métier, présentation) à été respecté lors de la conception de l'application, cette greffe est facile et peut coûteuse. C'est le cas des architectures client/serveur (logique métier exécutée par la base sous forme de triggers par exemple). Par contre, dans tous les autres cas, il sera difficile d'accéder simplement à la couche logique métier car les séparations entre les couches présentation et logique métier n'ont pas été faites lors de la conception des ces applications. C'est le cas des :
- Application mainframes
- Applications AS/400 iSeries
- Applications UNIX non client/serveur
- Applications Web HTML écrites avant l'apparition des SOAs
Or il se trouve que 60% des applications critiques de l'entreprise utilisent les architectures ci-dessus. Le défi pour réussir un projet SOA et bien de pouvoir intégrer ces applications à moindre coût sans remettre en cause les fonctionnalités métiers offertes par ces précieuses applications.Pour cette raison les entreprises, dans leur grande majorité, se tournent vers des outils qui permettent de construire des interfaces SOA sur des applications sans intrusion (modification de code) ou en remplacement de ces applications. Cette technique est souvent décrite comme le « SOA Enablement » par les analystes. Parmi les différents outils disponibles sur le marché, certains spécialistes arrivent maintenant à traiter la « SOAisation » de toutes les applications cibles citées plus haut, mainframe, AS/400 iSeries, UNIX (non client/serveur) et bien sûr l'immense majorité des applications Html disponibles dans l'entreprise ou sur le Web. En conclusion, les architectures SOA respectent leurs promesses à condition que l'existant y soit intégré à moindre coût et sans la moindre déstabilisation fonctionnelle.
Olivier Picciotto, directeur général, Twinsoft.
