Migration vers les architectures SOA : pièges et réalités

Les promesses de la SOA ont globalement été tenues : agilité et reconfiguration de l’intégration, compatibilité des protocoles entres vendeurs, performances transactionnelles, fiabilité de l’architecture et ouverture vers les nouveaux standards. Mais la migration n'est pas toujours aisée.

Avec ces promesses tenues, tout serait pour le mieux dans le meilleur des mondes si un point essentiel n'avait été oublié. Car 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 ?

Car c'est bien là où 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ée.

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, Bull 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 sûr, 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çue après 2002 peut s'intégrer facilement dans les SOA. Et donc, que faire des 70 % d'applications qui ne possèdent pas ces points d'entrée ?  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ésentent 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 oeuvre 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 fameuse 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 et 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 est 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, une grande majorité d'entreprises se tournent vers des outils qui permettent de construire des interfaces SOA sur des applications sans intrusion (modification de code) ou 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 fonctionnelles.

Autour du même sujet