Les évolutions du SI (2) : SOA… et le monolithe s’effrita!

SOA et monolithe

Les monolithes avaient tout pour réussir… jusqu’à l’arrivée du SOA!

Je revenais dans mon précédent post sur les tendances et enjeux métier qui avaient mené à la création d’applicatifs métier monolithique et à la mise en place des ERP.

Au début des années 2000, un changement s’opère. C’est le début du SOA (Service Oriented Architecture), mais aussi du Cloud. J’étais chez IBM à l’époque et je me souviens à quel point, malgré les efforts de communication, tout le monde (les clients comme les internes) trouvait ces concepts futuristes et incompréhensibles.

Force est de constater que c’était complètement visionnaire et en avance sur son temps. Ça n’a pas pris tout de suite, mais c’est devenu la norme aujourd’hui !

Etape 2 : Le monolithe veut communiquer!

On a vu précédemment (cf. étape #1) que les applications métiers étaient faites d’un seul et unique bloc. Elles répondaient à un périmètre d’activité métier. Or, avec la meilleure volonté du monde, il est très difficile de faire rentrer tous les processus de l’entreprise dans une seule et même application. Même avec un ERP puissant!

C’est ce que l’on retrouve dans les approches « best-of-breed » dans lesquelles, on choisit le meilleur outil possible pour une activité plutôt que d’avoir une seule solution pour tout faire quitte à ne pas bien répondre à 100% des besoins. Elles ont l’avantage de mieux couvrir les attentes, mais imposent aussi certains choix d’architecture.

D’une façon ou d’une autre, certaines activités se retrouvent donc avec leur propre monolithe.

Pourtant, dans une entreprise, les différentes équipes travaillent toutes ensemble (c’est ce que l’ERP avait bien compris!). Une équipe Logistique a son propre système mais travaille avec la production ou les équipes commerciales; une équipe Sinistre dans l’Assurance utilise des contrats, etc… De même, chaque monolithe n’est pas isolé et doit interagir avec les autres.

Alors, les applications se sont progressivement ouvertes…

La première ouverture a été de partager la donnée. On a donc intégré les applications entre elles. C’est l’essor des ETL (Extract Transform Load), des ESB (Enterprise Service Bus), des EAI (Enterprise Application Integration) et autres outils d’intégration.

Tout un outillage indispensable pour faire communiquer un Monolithe avec un autre.

Les limites qui ont mené au SOA

Mais un gros problème de réactivité se pose alors par rapport aux besoins du business.

D’abord, parce que, d’une façon générale, ça prend du temps de faire communiquer les applications ensemble. Il faut comprendre les modèles techniques d’un côté et de l’autre, mais aussi l’utilisation fonctionnelle de la donnée (un client… est-ce la même chose dans les deux applications ?). Ainsi, même avec des outils la mise en œuvre n’est pas immédiate ! Et une fois mis en place, le transfert d’information n’est pas toujours en temps réel. Beaucoup de ces transferts étaient liés à du batch, c’est à dire des traitements certes réguliers mais asynchrones (ex. une fois par jour).

De plus, cela crée des problèmes d’adhérence entre les systèmes. Si je modifie un applicatif (ex la structure technique ou fonctionnelle d’un objet « client »), il faut que je vérifie les impacts ailleurs. Ai-je supprimé une donnée utile ailleurs? Des questions de gouvernance et d’architecture se posent alors.

Ainsi, si le business revoit sa façon de travailler ou met en œuvre un changement stratégique (ex. collaborer avec un partenaire, ou lancer un nouveau produit), il faut « un certain temps » pour réussir à mettre ça en place.

A partir de là, naît l’idée que, pour gagner du temps et s’orienter temps réel, les applications devraient pouvoir « communiquer directement entre elles ». C’est donc une idée assez étonnante énoncée comme cela, mais assez intéressante… Le SOA est né !

Le SOA c’est quoi?

Dans une « Service Oriented Architecture« , une application est « responsable » d’un périmètre de l’activité et doit fournir aux autres, les informations et fonctionnalités associés à ce périmètre.

Ainsi, une application de gestion de stocks, fournit à l’e-commerce, le niveau de stock d’un article sans recourir à une tuyauterie complexe pour transférer des données (qui ne seront peut-être pas suffisamment vite rafraîchies). Du coup, le site d’e-commerce appelle directement l’application de gestion stocks pour un article donné. L’application logistique lui renvoie le niveau de stock de l’article à la volée.

De même, les authentifications et droits d’accès sont désormais gérés dans une seule et même application. Ça évite d’aller les définir un peu partout dans le SI… Une application métier interroge alors le référentiel d’authentification qui lui répond en retour si l’utilisateur peut ou non se connecter.

Ces applications « exposent » des « services.

C’est à dire qu’une fonctionnalité (une portion de leur code) peut être exécutée par une autre application. J’ai une Service S qui permet d’afficher les informations d’un client. Ce Service est accessible à un endroit et d’une façon prédéterminés. Pour appeler ce Service, l’autre application devra par exemple fournir le code du client (ID = 123) pour lequel je veux afficher les données. En retour, l’application qui appelle ce service recevra une réponse normée « Adresse: …; Code Postal: …; etc ».

Et à quoi ça sert de faire communiquer les applications entre elles?

Les avantages d’une approche SOA

D’abord, l’architecture générale du SI est plus nette. Plus besoin de dupliquer la donnée ou même des fonctionnalités Les interfaces « point-à-point » et les systèmes d’échange ne sont plus indispensables pour communiquer! L’architecture d’ensemble donne la responsabilité (données + fonctionnalités) d’un périmètre fonctionnel à une application donnée.

Ensuite, en terme de déploiement et de mise en oeuvre. On mutualise les fonctionnalités! Si on lance une nouvelle application, elle n’aura pas besoin de prévoir les fonctions déjà gérées par d’autres applications. Que ce soit des fonctions techniques (authentification, autorisations,…) ou métier (création, modification de données, de statut…) elle utilisera des fonctions existantes. Sa mise en oeuvre en sera accélérée.

Alors certes des notions d’adhérence entre les applications et de gouvernance générale restent d’actualité. C’est normal et indispensable. Mais cette adhérence est beaucoup plus souple qu’avant. On définit seulement la façon dont les applications appellent une fonction et ce qu’elles reçoivent en retour. Elles sont complètement libres quant à l’utilisation qui est faite de l’information.

En terme de maintenabilité et d’évolutivité, c’est une grande avancée ! Je peux changer une application de fond en comble (techniquement ou fonctionnellement), du moment que les services exposés ne bougent pas, je n’impacte pas les autres applications !

Au final, avec une architecture de type SOA, les premiers éléments de modularité du Système d’information font leur apparition. Les applications ne sont plus isolées et communiquent entre elles. Et qui plus en temps réel… à la volée… quand elles en ont besoin! Je peux dès lors les associer un peu comme des briques de Lego…

Mais bien sûr… on a voulu aller plus loin. L’évolution du SI continue!


Les sujets qui m’intéressent le plus sont Data, Organisation et Temps Réel !

N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!

Andrea

Partager sur twitter
Partager sur linkedin

Vous aimerez aussi ...

Digital Pharma Lab en route pour le médicament du futur!
Performance et Adaptation

Le Digital Pharma Lab accélère la digitalisation de l’industrie pharmaceutique

Après avoir hésité à se lancer dans la transformation digitale, l’industrie pharmaceutique française veut désormais rattraper son retard! Pour y parvenir, elle compte sur son incubateur: le Digital Pharma Lab. Là, les groupes industriels du secteur marchent de concert avec de nouvelles start-up… Et développement de nouvelles idées très innovantes.

Lire plus »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Recevez nos articles

La protection des données nous tient à cœur. Vous pouvez vous désinscrire de ce type de communications à tout moment. Pour plus d'informations, consultez notre politique de confidentialité.

Livre blanc

les problématiques du manager dans un livre blanc
La protection des données nous tient à cœur. Vous pouvez vous désinscrire de ce type de communications à tout moment. Pour plus d'informations, consultez notre politique de confidentialité.

Partagez nos articles

Partager sur linkedin
Partager sur twitter
Partager sur email

Rechercher

une organisation rayonnante

Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considérerons que vous acceptez l’utilisation des cookies. Voir notre Politique de confidentialité.