Constats et Problématiques

Le SI Historique embarque des fonctionnalités, des Objets Métiers principaux et des règles de gestion associées.

Les applications du SI Historique sont souvent basées sur des progiciels, dont les montées de version sont coûteuses. Les progiciels, en particulier, ont des difficultés à prendre le rythme des évolutions technologiques.

Dans le même temps, le système d’information se doit d’être de plus en plus communicant. C’est un besoin métier fort que de coupler les applications pour tendre vers une « synchronisation » quasi-temps réel.

De leur côté, les technologies d’échange répondent à des enjeux structurants pour le SI :

  • Permettre des échanges de plus en plus orientés temps réel et de plus en plus nombreux
  • Etre un support à l’agilité du SI, en facilitant et sécurisant le couplage lâche entre les applications
  • Suivre les échanges, pour permettre la supervision de l’activité métier et du SI et maitriser la Qualité de Service
  • Contribuer à faciliter la mise en œuvre d’architectures « scalables »

L’intégration dans un SI moderne des applications historiques passe par l’insertion des technologies d’échanges utilisées par les autres composants du SI, dans l’écosystème de ces applications.

Cela pose toute une série de challenges à relever, parmi lesquels :

  • L’aspect technique « pur » d’intégration d’une nouvelle technologie,
  • La gestion des compétences, sur des technologies différentes,
  • La gestion de la sécurité (déclinée sur le framework DICT) :
  • La performance : Il y a un risque sur l’application qui expose les API ou par l’application qui les utilise
  • La Qualité de Service : la Qualité de Service (QoS) est réduite à celle du composant le plus faible.
  • Le modèle de données : les systèmes historiques imposent leur modèle interne au niveau des échanges.

    Principales évolutions des technologies d’échanges :

    Le SI répond à des enjeux de plus en plus forts, en particulier pour ce qui concerne les technologies d’échange :

    • Permettre des échanges de plus en plus orientés vers le temps réel et de plus en plus nombreux
    • Etre un support à l’agilité du SI, en facilitant et sécurisant le couplage lâche entre les applications
    • Suivre les échanges, pour superviser l’activité du SI et métier et maitriser la Qualité de Service
    • Contribuer à faciliter la mise en œuvre d’architectures « scalables »

    Il y a donc une dualité entre :

    • Un SI Historique, dont le rôle est de garantir le bon fonctionnement des fonctionnalités à moindre coût
    • Des évolutions technologiques dans lesquelles il faut inscrire ces fonctionnalités centrales et critiques.

    Il faut inscrire le SI Historique dans une Politique Industrielle et mutualiser les solutions techniques afin de disposer d’un Catalogue de solutions le plus restreint possible.

    Pour arriver à cela, il est nécessaire de mettre à disposition des architectes et des projets, des Patterns d’architecture, afin, à la fois d’accélérer les phases de conception, et d’homogénéiser le SI dans sa globalité.

    Focus sur quelques Use Cases

    Use Case 1 : Exposition de capacités du SI Historique

    par une API interne (REST, GraphQL)

    Le constat

    L’Application Historique sait exposer ses capacités, mais elle est en retard sur les évolutions technologiques.
    Il y a deux « sous-cas », ici, selon ce qu’on veut exposer au reste du SI :

    • Exposition des données en lecture seule
    • Exposition des traitements proprement dits, et notamment les créations et mises à jour de données, qui intègrent les règles de validation, dont l’Application Historique est généralement seule dépositaire.

    Les pistes identifiées

    Parmi les pistes identifiées, on retiendra celle consistant à mettre en place une brique intermédiaire, entre le SI Historique et le reste du SI.

    S’il y a un besoin de fournir un accès en lecture seule aux données de la brique historique, cela peut passer par la création d’une base de données dédiée, structurée pour optimiser la lecture des données. Celle-ci est alimentée en temps réel depuis l’application historique.

    La modification ou la création de données doit rester dans l’Application Historique, car celle-ci implémente les règles de validation. De plus, si les modifications étaient effectuées vers une autre base de données, il faudrait une synchronisation bidirectionnelle pour les intégrer dans l’Application Historique.

    Le pattern d’architecture proposé

    Dans ce Use Case, la proposition est donc de créer une surcouche d’intermédiation technique. Elle expose la technologie d’échange retenue (REST, GraphQL…), en s’appuyant sur les Services du système historique (SOAP…)

    Cette surcouche doit être exclusivement un composant technique. Il ne faut pas ajouter de complexité organisationnelle ou de gouvernance. A ce titre, elle doit être gérée et pilotée par l’équipe projet qui gère l’application historique.

    Ainsi, au niveau global du SI, le nombre de composants est stable. C’est l’architecture applicative de l’application historique qui évolue. Et la seule chose visible de l’extérieur est l’ajout de cette API.

     

    Le pattern peut être étendu à la gestion des habilitations, avec des protocoles comme OAuth ou OpenID Connect. Cette gestion des habilitations peut être très impactante pour l’Application Historique. L’idée est donc de déporter cette fonction dans la couche d’intermédiation technique, en faisant par exemple appel à l’API en lecture seule pour vérifier les droits d’accès, avant d’autoriser une modification.

    Ceci est potentiellement complexe (en développement et en temps de réponse), et sa mise en œuvre doit être étudiée au cas par cas.

    Les bénéfices

    Cette proposition permet d’exposer les capacités de la brique historique en API (REST, GraphQL…), de minimiser les impacts sur l’Application Historique et de ne pas compliquer la gouvernance du SI. En outre, les appels en lecture (généralement les plus nombreux) sont exécutés sur une brique dédiée, ce qui allège la charge sur l’Application Historique, et permet des performances optimales.

    En outre, ceci peut être une première étape vers un démantèlement progressif de la brique historique.

     

    Use Case 2 : Utilisation par l’Application Historique d’une API REST

    Le constat

    Ce Use Case est le symétrique du Use Case 1. Ici, c’est l’Application Historique qui doit accéder à des APIs existantes. Cet API peut être interne ou externe (exemple : signature électronique en SaaS…).

    L’hypothèse est qu’il y a une barrière technologique : l’Application Historique n’est pas en capacité d’appeler l’API cible.

    Les pistes identifiées

    Le raisonnement est le même que pour le Use Case 1 : l’exigence est de minimiser les impacts sur la brique historique. De même, l’API à appeler est :

    • Soit Externe, typiquement un service en SaaS et c’est au consommateur du service de s’adapter.
    • Soit Interne, typiquement une autre brique du SI, qu’elle soit hébergée onPremise ou dans le Cloud. Cette brique se doit alors de respecter les patterns d’architecture de référence de l’entreprise.

    Comme l’Application Historique ne peut appeler l’API en l’état, il faut faire un intermédiaire. Il y a ici deux solutions :

    • Utiliser les capacités d’intermédiation technique qu’ont la plupart des outils d’API Management
      – Si d’autres applications sont dans le même cas, cela permet une mutualisation
    • Mettre en place une brique d’intermédiation technique dédiée, au sein du projet de l’Application Historique.
      – Ceci évite de complexifier la gouvernance globale, et incite chaque projet à respecter le standard d’échange
      – Ceci évite d’impacter la brique d’API Management pour les besoins d’une seule application.

    Le pattern d’architecture proposé

    L’architecture proposée consiste à mettre en place une intermédiation technique.

    Il y a deux options possibles, qu’il faudra étudier au cas par cas :

    • Mettre l’intermédiation technique sur l’API Management, pour bénéficier des capacités de cette plateforme, et permettre la mutualisation.
    • Mettre l’intermédiation technique au sein du projet de la brique historique.

    Les bénéfices

    Aucune évolution de l’Application Historique, qui reste sur les technologies qu’elle est en capacité de gérer en standard.

    Une brique extérieure (intermédiation technique, ou exposition par l’API Management) est chargée d’adapter le format technique, pour permettre l’appel de l’API cible. Cette brique ne contient aucune règle de gestion, ce qui permet de sécuriser les flux, et de diminuer les coûts de maintenance.

    Use Case 3 : Intégration de l’Application Historique dans une architecture réactive

    Le constat

    Les architectures réactives consistent à utiliser des appels asynchrones, que ce soit en interne d’une application, ou entre applications. Ce type d’interface doit être privilégié pour les nouvelles interfaces. En effet, il présente plusieurs intérêts structurants :

    • Ne pas bloquer de ressources à attendre une réponse d’un système distant.
    • Découpler davantage les systèmes, en Run. En cas de panne d’une partie du SI, les applications qui en consomment les services ne sont pas bloquées, même si elles ne recevront pas de réponse.
    • Permettre une scalabilité maximale : il est très simple d’ajouter des nœuds pour consommer des messages
    • C’est le type d’interface le plus performant

    Il existe une grande variété de solutions techniques : files de messages (AMQP, JMS…), Streaming (Kafka…), Web Sockets (typiquement pour les applications Web), souscriptions de GraphQL…

    Les pistes identifiées

    Les Applications Historiques savent gérer des appels asynchrones, avec un mécanisme bien connu : les échanges de fichiers. Mais c’est à éviter, car plus complexe à sécuriser et à exploiter.

    Ce Use Case se décomposent en deux directions possibles :

    • La requête réactive est émise vers la brique historique
      • On est alors ramené au Use Case 1, et il faudra une brique d’intermédiation pour lire la requête sur la file d’entrée, effectuer l’appel synchrone correspondant vers la brique historique, puis poster la réponse dans la file de réponse.
    • La requête réactive émise par la brique historique: nous considérons les deux sous-cas ci-dessous :
      • La brique historique a besoin de la réponse pour continuer.
        • Il faut alors transformer un appel synchrone en un appel asynchrone. On est ramené au Use Case 2, avec une brique d’intermédiation chargée de cette médiation
      • La brique historique n’a pas besoin de la réponse pour continuer
        • On est typiquement dans un échange asynchrone natif. Il faudra tout de même une intermédiation technique pour déposer le message dans la bonne file (le bon topic…).

     

    Le pattern d’architecture proposé

    Cas des apppels entrants 

    Cas des appels sortants

    Les bénéfices

    L’Application Historique elle-même ne profite pas directement des bienfaits des architectures réactives, puisqu’elle ne sait pas faire d’appels asynchrones nativement. Notamment, en cas de requête/réponse, elle aura une « thread » bloquée à attendre la réponse.

    Mais elle peut s’intégrer avec des applications réactives, notamment pour envoyer ou recevoir des événements métier.

    A contrario, les applications distantes peuvent bénéficier de l’asynchronisme pour leurs appels à l’Application Historique.

    Conclusion

    L’ajout de couche d’intermédiation technique permet de conserver un SI Historique, tout en l’insérant dans un SI en constante mutation.

    Une fois cette intégration avec le reste du SI proprement réalisé, il est alors possible de :

    • Se connecter à des capacités externes, qu’il serait trop compliqué (donc trop cher) de développer dans le SI Legacy
    • Faire bénéficier des capacités de ce SI Legacy au reste du SI, avec les technologies d’échange les plus performantes
    • Démarrer un dé commissionnement progressif du SI Legacy, en évitant les effets big bang