Actualités

[22/05/2017] Smile récompensé lors du Hackathon Carrefour !

Smile a remporté le Prix du Code lors du Hackathon Carrefour, organisé ce week-end à Paris !

[18/05/2017] OpenShift, le nouveau livre blanc Smile !

Smile publie aujourd'hui un livre blanc dédié à OpenShift, le PaaS open source orienté DevOps. A télécharger dès maintenant !

[15/05/2017] Smile décroche le label HappyAtWork 2017 !

Pour la 2ème année consécutive, Smile obtient le label HappyAtWork for Starters qui récompense les entreprises où il fait bon débuter sa carrière !

Toutes les actualités picto
       

Vous avez besoin de mettre à jour votre Lecteur Flash Flash 7

Guillemet ouvrant l'actualité des solutions
et des technologies open source Guillemet fermant
picto

MOM, EAI, ESB... Mon SI en a t'il vraiment besoin ?

MOM, ESB, EAI, ces acronymes font aujourd'hui partie du paysage IT. La presse spécialisée en parle, de nombreux éditeurs open source et propriétaires battent le pavé à grand renfort de démonstrations d'utilité et calculs savants de ROI.

L'approche Application

Lorsque l'on construit son SI, les impératifs temporels et budgétaires du projet nous forcent souvent à considérer l'application hors toute démarche de mutualisation au sein du SI. On adopte alors bien souvent une vision centrée sur l'application. Voici alors comment se construit bien souvent le SI :

On commence avec deux applications qui, naturellement, vont être amenées à échanger de l'information. On crée donc un pont spécifique pour les faire communiquer. Puis vient, tout aussi naturellement, une troisième application qui, non moins évidemment, va devoir communiquer avec les deux autres. On crée donc les points qui vont bien. Puis, on ajoute encore des applications, on crée des ponts et on se fait, petit à petit, son petit plat de nouilles, dans lequel aucun être humain normalement constitué n'est capable de maitriser l'ensemble des tenants et aboutissants. Ajoutons une documentation souvent anorexique car sacrifiée sur l'autel des priorités budgétaires, des intervenants qui ne font plus partie de la société. Au final, personne ne connait exactement toutes les ramifications de notre SI, son budget maintenance explose et l'enrichir de nouvelles applications rime alors avec tarifs démesurés, effets tunnels gargantuesques et réactivité dégradée.

L'approche Service

Il existe des outils qui permettent de se positionner immédiatement dans la logique de fournir des services au collaborateur. Ceux-ci viennent se positionner entre les applications frontales (affichage de l'information, interfaces de saisie, ergonomie) et les applications d'hébergement de données métier (capture des données, gestion de leur cycle de vie, gestion des droits, logique applicative). Voici un exemple de SI monté en logique service.

On commence avec une application métier. Celle-ci se situe en backoffice et s'expose via des APIs. Sur le Middleware, côté backoffice, on dispose d'interfaces techniques permettant de communiquer avec l'application que l'on connecte aux points d'entrée de l'application (les flêches vertes).

  • Exemple : SELECT (nom_societe, adresse_societe, ...) FROM bdd_CRM.table_client WHERE numero_client=123456

Côté frontoffice, on dispose d'une IHM qui fournit un service à l'utilisateur. Elle se connecte sur le Middleware, côté frontoffice, où l'on dispose d'interfaces fonctionnelles (les flêches bleues)

  • Exemple : Prendre fiche client

Entre les deux, le middleware est chargé de faire le correspondre la fonction métier « Prendre fiche client » à la fonction technique « SELECT ... ». Au passage, on constatera que jamais l'IHM ne sait quoi que ce soit de l'application backoffice qui gère les données qu'elle affiche... Et surtout pas son nom, son éditeur, sa version, …

On peut dès lors ajouter une fonction permettant d'envoyer des données depuis l'IHM vers l'application backoffice. Pas de problème. Il suffit de créer l'interface fonctionnelle qui va bien et de tirer les liens correspondants dans le middleware. Comme il ne s'agit que d'enrichir l'IHM, on ne touche pas aux applications métiers sous-jacents.

En suivant cette logique, on peut tour à tour enrichir le backoffice métier en y ajoutant une application que l'on connecte au middleware. Puis on peut créer des interfaces fonctionnelles pour cette nouvelle application ou enrichir des interfaces fonctionnelles déjà existantes afin qu'elles piochent leurs données dans plusieurs applications. Dans une étape suivante, on peut créer de nouvelles IHM assemblant les interfaces fonctionnelles dont nous disposons. Enfin, cerise sur le gâteau, si une application de backoffice ne nous satisfait plus, on peut la remplacer, il suffit de refaire les liens vers le middleoffice pour garantir la continuité de service de manière transparente.

Du bons sens... mais aussi un design pattern

Un modèle existe depuis des années, qui sous-tend les principes qui viennent d'être cités. Il s'agit du modèle vue contrôleur (MVC). Ce modèle préconise la séparation des couches fonctionnelles selon trois principes :

  • La vue : elle gère l'affichage des informations et les interfaces de saisie. Correspond au frontoffice dans un SI
  • Le backoffice : il gère les données de l'application
  • Le contrôleur : il gère la liaison vue / backoffice en y incluant de la logique métier

Ce Design pattern, très répandu en développement d'application, est devenu aujourd'hui une norme incontournable. Il permet de se placer dans les meilleures conditions d'extensibilité et de personnalisation. On en applique les même principes en design de SI en réalisant un modèle trois tiers séparant la vue et les données par un contrôleur riche.

D'accord, mais quel outil dois-je prendre... et surtout, comment m'y prendre ?

Bien souvent, les décideurs ont peur des mots middleware ou ESB, voyant là de grosses machines synonymes de lenteur, de complexification et de gouffre financier. Il est vrai que bien des projets de refonte de SI basés sur le modèle trois tiers ont pu se solder par des échecs. La plupart du temps, l'ambition affichée est bien trop importante par rapport à la maitrise du périmètre des différents outils. Il est important dans ce genre de projet d'adopter une démarche pragmatique, petit bout par petit bout.

Avoir en tête l'objectif fonctionnel des outils

Chaque outil dispose de ses propres capacités. Voici une description très macroscopique de leur intérêt. Pour plus de détails, je vous conseille la lecture du livre blanc Smile sur les MOM :

 

Adopter une démarche step by step

La couche middleware est par essence complexe. Elle doit rester agnostique de toute solution tout en étant capable de se brancher à toutes ces solutions. Il est donc indispensable d'être très pragmatique dans la mise en œuvre d'un middleware. Croire qu'on peut, dans un seul projet, mettre en place un ESB par lequel toutes les applications vont pouvoir communiquer est tout simplement illusoire. Il y a beaucoup trop d'applications métier et, donc, d'intervenants sur un tel projet pour qu'un consensus entrant dans le moule du modèle trois tiers puisse être trouvé.

Le meilleur conseil que je puisse donner est de garder la tête froide et d'avancer pas à pas. En s'engageant dans la logique du projet pilote, en mettant face à un besoin des moyens adéquats et justement dimensionnés (ie : ne justement pas mettre un ESB pour gérer la bibliothèque photo du CE), on favorise la crédibilisation de l'architecture tout en capitalisant efficacement dans l'optique de l'architecture globale finale.

Et que faire de mes applications qui ne rentrent pas dans le moule ?

Applications ayant leur propre frontend

Nombre d'applications, notamment métier, disposent déjà de leur propre interface utilisateur et ne passent donc pas par le middleoffice pour communiquer avec le backoffice. Aucun problème ! N'essayez surtout pas de tordre l'application pour qu'elle utilise le middleoffice. L'objectif de cette interface n'est pas de pouvoir s'inclure dans une logique globale, mais au contraire, de piloter localement une et unique solution. Ce sera d'ailleurs l'entrée de contribution technique privilégiée de l'application.

En revanche, rien ne nous empêche de relier ses APIs au middleware afin de pouvoir se servir de l'application pour enrichir le pool de données métier. Attention à ne pas tenter de couvrir le périmètre de l'interface utilisateur de l'application par votre propre interface. Vous devez faire un choix. Soit vous contribuez sur l'interface de l'application, soit vous recréez des IHM qui vous sont propres. Mais ne laissez surtout pas deux points d'entrée équivalents dans un SI, c'est le meilleur moyen pour perdre l'utilisateur.

Applications sans APIs / WS

Dans ce cas, il n'y a pas de solution architecturalement propre. Le principe consiste à considérer l'application comme une boite noire et à la couvrir d'une cloche sur laquelle nous pourrons nous connecter.

Qu'est-ce que cette cloche ? Nécessairement quelque chose de spécifique. Un ETL exposant la base de données de l'application en web service ; Une application exposant un AS400... Il n'y a pas de bonnes solutions, seulement des rustines. Ce qui importe, c'est que le dessus de la cloche, partie sur laquelle vous allez vous connecter, soit dans la norme du SI trois tiers.

Patrick Nerden
picto

Commentaires

Soyez la premiere personne à ajouter un commentaire sur cet article.
Ecrire un nouveau commentaire