Présentation

Enterprise Flows Repository est une solution de suivi et de gouvernance des flux des systèmes d’informations. Cette solution permet :

  1. Une centralisation des traces de transport des données,

  2. Un suivi des transports d’information,

  3. Une exploitation pragmatique pour tous les acteurs métier et techniques:

    • Utilisateur d’application,
    • Responsable fonctionnel / d’une ou plusieurs applications,
    • Equipe support de flux,
    • Directeur de Systèmes d’Information,
    • Architecte / Urbaniste.

Enterprise Flows Repository a pour vocation de:

  • offrir une vision fonctionnelle aux échanges dans un Système d’Information,
  • alerter les utilisateurs concernés,
  • faciliter le support technique d’intermédiation applicatif,
  • référencer les flux d’informations,
  • proposer des rapports de gouvernance,
  • centraliser les outils indispensables à l’intermédiation,
  • réinjecter des messages par les acteurs métier (dans la roadmap).

1 - Vision générale

Description des grands principes de la solution.

1.1 - Unique

Une solution unique sur le marché.

Un console de suivi prête à l’emploi

Enterprise Flows Repository est une console de supervision des flux sur étagère.

Aucun module ou complément n’est nécessaire à son fonctionnement. Il est simplement nécessaire de:

  1. lui envoyer des traces de transport,
  2. renseigner l’organisation du SI, son urbanisation.

EFR est agnostique de la technologie, de l’éditeur et de l’architecture en place.

Une réduction de la complexité

Cette solution est unique car elle réduit la complexité en emboitant les notions manipulées dans l’entreprise :

  • des échanges
  • puis des flux
  • puis des médiations

L’utilisation directe de l’urbanisation des architectes

Enterprise Flows Repository met à profit l’urbanisation du système d’information.

La vision rémontée des traces du RUN sont mises en correspondances avec l’ URBANISATION théorique.

Tous les acteurs partagent des visions cohérentes et complémentaires du même système d’information.

Support complet des patterns d’intégration

Enterprise Flows Repository

1.2 - Utile

Une solution utile pour tous les acteurs de l’entreprise.

Pourquoi Enterpise Flows Repository est-il utile ?

Dans les Systèmes d’Information modernes, les échanges d’information sont nombreux. Ils sont pris en charge par des solutions de transports divers (API, ETL, ESB) qui fonctionnent à des rythmes différents (Fichiers, Messages, API, WebServices).

Il souvent impossible pour les acteurs fonctionnels de comprendre les nombreux traitements qui transportent les informations.

Enterprise Flows Repository répond à des questions simples pour les métiers:

  • Ma donnée a-t-elle été transportée ?
  • Dans quel état a terminé le transport ?

Pour répondre à cela, Enterprise Flows Repository analyse, aggrège, relie les traces de ces transports pour les présenter de manière adaptée, simplifiée et synthétisée.

Enterprise Flows Repository réduit la complexité de suivi et de gouvernance des flux.

A qui Enterprise Flows Repository est-il utile ?

Pour les responsables d’applications

Enterprise Flows Repository facilite la suivi fonctionnel par :

  • Un suivi simple des échanges entre son application et les autres,
  • Une visibilité personnalisée et adaptée au périmètre de chacun (1 ou plusieurs applications, un domaine métier, etc.),
  • Des alertes remontées rapidement,
  • Une exposition de la qualité de service des échanges,
  • Une navigation rapide par des filtres efficaces par système, informations métier, etc.

Chaque acteur métier peut suivre, piloter, comprendre les échanges entre ses applications et celles des autres périmètres métier.

Pour les Equipes support des flux

Enterprise Flows Repository facilite la vie aux équipes de support en:

  • Remontant automatiquement les erreurs
  • Ciblant les données métiers impactées
  • Offrant une vision complète des flux ayant participés à un échange
  • Alertant les responsables techniques,
  • Proposant des rapports sur étagère,
  • Reliant les alertes et leur documentation.

EFR réduit les analyses et diagnostiques en contualisant les comportements des médiations.

Pour les Directeurs des Systèmes d’Information

Enterprise Flows Repository garantie la cohérence du RUN avec la vision du Système d’Information avec:

  • La liste exhaustive des échanges et des flux
  • Des rapports sur étagères de synthèse de SLA,
  • La documentation les éléments du système d’Information.

EFR permet de visualiser les manques et les faiblesses des échanges ou des plateformes sous-jacentes.

Pour les Architectes

Enterprise Flows Repository porte une vision cohérente et pertinente du Système d’Information pour:

  • Localiser un flux dans le SI,
  • Abstraire la complexité,
  • Urbaniser le SI.

Les traces de transports proviennent du RUN. La cartographie provient de l’urbanisation. Enterprise Flows Repository relie ces 2 visions en un ensemble cohérent.

2 - Cas d'usages

Dans quels cadres la solution EFR est-elle mise en oeuvre ?

La mise en oeuvre de la solution Enterpise Flows Repository est multiple. Elle est souple est s’adapte à des cas d’usages technologiques et fonctionnels.

Cas d’usages fonctionnels

Cas d’usages technologiques

Cas d’usages de gouvernance

Cas d’usages de support

2.1 - Gouvernance

Cas d’usages de gouvernance.

2.1.1 - Evaluation de la qualité des échanges

Cas d’usage: Evaluation de la qualité des échanges

Besoins

Problématique

Réponse

2.1.2 - Evaluation de la qualité des flux

Cas d’usage: Evaluation de la qualité des flux

Besoins

Problématique

Réponse

2.2 - Métier

Cas d’usages métier

2.2.1 - Alerte rapide des dysfonctionnements

Cas d’usage: Alerte rapide des dysfonctionnements

Problématique

  • Comment alerter efficacement les référents fonctionnels lors de dysfonctionnement ?
  • Comment identifier les référents ?
  • Comment regrouper des dysfonctionnements entre eux afin de ne pas submerger en erreurs ?
  • Quel est le niveau de l’alerte ?

Besoins

Une alerte est le fait de communiquer sur un dysfonctionnement. Elle doit être envoyée aux destinataires concernés par celui-ci. Dans le cas des échanges, il s’agit des responsables des applications sources et cibles.

Le niveau de l’alerte répond à 2 critères:

  1. La criticité fonctionnelle de l’échange,
  2. La gravité de l’erreur rencontrée.

Réponse

EFR organise sa vision du système d’information suivant des principes d’urbanisation. Ainsi il peut déterminer:

  1. les applications mises en jeu lors d’un échange,
  2. les contacts à solliciter.

EFR regroupe les dysfonctionnements suivant 2 perspectives:

  1. métier pour offrir une vision par le métier (échanges et informations),
  2. applicative pour permettre une compréhension des comportements des applications et de leurs interfaces.

Chaque contact est alors informé 1 seule fois lors de dysfonctionnements. Il n’y a pas d’ effet TSUNAMI lors d’erreurs en masse sur un flux.

Enfin, la criticité de l’alerte est déduite par la définition de l’échange dans la vue métier de l’ urbanisation.

2.2.2 - Prouver le transport d'une information

Cas d’usage: Prouver le transport d’une information

Problématique

  • Comment démontrer le bon transport d’une donnée ?
  • Comment suivre l’avancement du transport ?
  • Comment valider le départ ou l’arrivée à destination ?

Besoins

Lors de la réception de données commercialement sensibles, il est primordial d’être en capacité de démontrer la réception dans le Système d’Information de l’entreprise. Un mécanisme de preuvre est alors nécessaire.

Exemples:

  • Lors de la réception de flux EDI
  • Lors d’échanges intégrés par MESSAGES avec un partenaire.

Réponse

EFR gère tout contenu de traces et leurs états correspondant. Il organise ces traces afin de les regrouper dans des ensembles simples et cohérents. Ces traces peuvent donc servir de preuves de transport entre des partenaires internes ou externes à l’entreprise.

Les partenaires émettent des traces aux étapes clés des traitements comme :

  • émission,
  • réception,

Les étapes internes (envoi, transformation, erreurs) viennent ensuite compléter le cheminement complet afin de permettre le suivi et la preuve de bout en bout.

2.2.3 - Recherches transverses de données transportées

Cas d’usage: Recherches transverses de données transportées

Problématique

  • Quelles sont les données transportées par les échanges ?
  • Comment gérer les perspectives des données dans le SI ?

Besoins

Le métier a besoin de vérifier le transport d’informations au sein des briques du système d’information.

Il convient de rechercher par nature ou par identifiant métier les échanges réalisés.

Exemple:

  • Tous les échanges ayant transportés la facture ABC,
  • Quelle est le dernier système à avoir reçu la commande DEF ?

Réponse

Pour répondre à ce besoin, 3 fonctionnalités sont nécessaires:

  1. la définition d’information purement fonctionnelle,
  2. la capacité à lier des données (techniques ou applicatives) à ces informations,
  3. l’identification des données dans les échanges.
Exemple:
Une commande est transportée sous les noms suivants:
- pour SAP: BLAORD et E1EDK03 suivant les contextes,
- pour Salesforce: order. 
- des raccourcis versionnés tels que ORDER01 et ORDER02

Enterprise Flows Repository y répond pleinement avec:

  1. la prise en compte de:
  • information: notion purement fonctionnelle, dans la vue BUSINESS,
  • donnée: notion applicative, dans la vue APPLICATIONS.
  • alias: synonymes des informations et des alias.
  1. Le marquage des données transportées dans le format interne de la trace

2.2.4 - Suivi de bout en bout

Cas d’usage: Suivi de bout en bout.

Problématique

  • Comment suivre un échange dans le systèmes d’information de bout en bout ?
  • Comment obtenir une vision accessible par les non spécialistes ?

Besoins

Un échange entre le producteur et ses consommateurs passent régulièrement

Réponse

2.3 - Support

Cas d’usages de support.

2.3.1 - Réduction des efforts de support

Cas d’usage: Réduction des efforts de support

Besoins

Problématique

Réponse

2.3.2 - Centralisation de la supervision

Cas d’usage: Centralisation de la supervision

Besoins

Problématique

Réponse

2.4 - Technologique

Cas d’usages technologiques.

2.4.1 - Migration de produits

Cas d’usage: Migration de produits

Besoins

Problématique

Réponse

2.4.2 - Transformation technologique

Cas d’usage: Transformation technologique

Besoins

Problématique

Réponse

2.4.3 - Upgrade de version

Cas d’usage: Upgrade de version

Besoins

Problématique

Réponse

3 - Concepts

Notions principales à comprendre afin d’appréhender les objectifs et la plus value de la solution.

Pour obtenir le résultat présenté dans les fonctionnalités, il convient de prendre connaissance des notions essentielles de Enterprise Flows Repository.

  1. Les notions d’échanges, de flux et de médiations qui permettent aux acteurs d’obtenir une vision cohérente des transports,
  2. La démarche d’urbanisation qui permet le lien entre les échanges, les flux et les médiations,
  3. Les traces qui sont envoyées à EFR par les outils d’intermédiations.

3.1 - Echange, Flux et Médiations

Description d’un échange dans les couches de l’urbanisation.

EFR représente les échanges entre les systèmes. Son objectif peut être résumé à cela. Ces échanges sont représentés pour:

  1. Les métiers
  2. Les acteurs techniques.

De ce fait, leur définition se suppertosent mais sur des axes différents:

  • la vision métier sur la couche “fonctionnelle” (cf. Urbanisation)
  • la vision technique sur la couche “médiations”.

Echange

Un échange est un transfert de données d’un système source vers N systèmes cibles. Il est une vision simplifiée du transport d’information.

La vision fonctionnelle permet de gouverner les échanges d’un point de vue fonctionnel.

Un échange est caractérisé par

  • un système source,
  • un ou plusieurs systèmes cibles,
  • une ou plusieurs informations transportées,
  • un état d’exécution.

Exemple:

Flux

Un flux est le trasnport entre 2 interfaces techniques. Un flux peut être composé, intermédiaire ou direct. Il est souvent utilisé le terme de demi-flux lors de la succession de flux.

Un flux est caractérisé par :

  • Une application source,
  • Une ou plusieurs application cibles,
  • une ou plusieurs données transportées.
  • une technologie de mise en oeuvre
  • une chorégraphie de médiations,
  • un état d’exécution.

Exemple:

Médiation

La mise en oeuvre d’un flux est ensemble de fonctions, de services ou de routes (pour camel par exemple).

Ces médiations réalisent des transformations protocolaires, des routages, des publcations, des enrichissements, etc. lors du traitement des messages.

Chaque médiation est caractérisée par:

  • une interface source
  • une ou plusieurs interfaces cibles,
  • un code,
  • un état d’exécution.

Ce sont les médiations qui génèrent des traces à destination de EFR.

3.2 - Urbanisation

Organisation et structuration générale.

Visions urbanisés du Système d’Information

‘Enterprise Flows Repository’ respecte l’organisation mise en place lors des travaux d’urbanisation.

Bien que les éléments soient volontairement simplifiés, on retrouve les “couches” traditionnelles:

  1. Entreprise
  2. Fonctionnel ou Métier
  3. Application
  4. Infrastructure

Lors de l’analyse de ces travaux, il est très difficile de décrire les notions de flux, d’interfaces voir de médiation applicative.

Bien qu’indispensable à la gouvernance et à la modélisation du Système d’Information, l’urbanisation est limitée sur la partie d’interconnexion entre les applications.

La particularité et la plus-value de EFR est d’avoir “ajoutée” une couche intermédiaire dite de “médiations”. Ainsi cette couche porte la définition des éléments plus fins et spécifiques à l’interconnection des applications.

Pour EFR, les couches manipulées plus fines et plus opérationnelles avec :

  1. Entreprise
  2. Processus (spécifique)
  3. Fonctionnel
  4. Applications
  5. Médiations (spécifique)
  6. Déploiement (spécifique)
  7. Infrastructure

Modélisation

Il est nécessaire de définir les concepts du Système d’information au sein de EFR afin que celui-ci puisse corréler les traces qui lui sont envoyées.

Utiliser EFR implique donc une part de modélisation.

Manipulation par API

Toutes les couches d’urbanisation de EFR sont exposées sous la forme d’API.

Les usages transverses et connexes sont alors possibles lors de:

  • l’urbanisation avec des outils spécialisés (MEGA OPEX, Ardoq, LeanIX etc)
  • l’intégration continue

La collaboration avec les écosystèmes existants est facilitée par les API.

3.3 - Trace

Collecte des traces de transport de données.

EFR est une solution qui analyse, aggrège et adapte des traces produites lors des transferts de données.

La portabilité de cette trace garantie que EFR n’est pas dépendant d’un éditeur.

EFR reçoit indépendamment des traces des plateformes d’interconnexion comme les API Management, Gateway, Micro-Services, ESB, ETL, Scripts, etc.

Pour compléter les visions, les outils comme les ERP peuvent aussi envoyer des traces de transport.

Contenu

Une trace indique le transport d’un message dont un contexte logiciel et infrastructure.

Chaque trace porte:

  • le message
    • le corps au format texte
    • les entêtes
  • le transport
    • la date de production
    • l’état au moment
  • la médiation qui a pris en charge
  • le contexte métier
    • les données transportées
  • l’infrastructure

Format

Le format respecte le standard API:

  • JSON

Exemple

  {
    "state": "success",
    "message": {
      "created": "2022-05-30",
      "correlationId": "abcd-efgh-ijkl-mnop",
      "headers": [
        {
          "name": "EnteteA",
          "value": "123"
        }
      ],
      "body": "Texte transporté."
    },
    "route": {
      "name": "ServiceABC",
      "id": "serviceA-123",
      "step": "Lecture du message",
      "description": "Message de ..."
    },
    "business": [
      {
        "name": "COMMANDE",
        "value": "1234"
      }
    ],
    "infrastructure": {
      "instance": "GatewayAPI-abc",
      "hostname": "gateway1",
      "datacenter": "paris"
    }
  }

4 - Fonctionnalités

Fonctionnalités

Fonctionnalités principales

Le coeur fonctionnel est basé sur la necéssité de proposer de la visibilité aux utilisateurs dits “métier”.

Tout est organisé afin de proposer un accès adapté à cette population d’utilisateurs. Les fonctionnalités sont :

  1. Comprendre l’état d’un échange et son dysfonctionnement,
  2. Alerter les utilisateurs “métiers” des dysfonctionements lors des échanges de données,
  3. Rechercher les échanges suivant les informations manipulées ou les systèmes émetteurs.

Fonctionnalités secondaires

  1. Alerter les référents techniques de dysfonctionnements sur les interfaces et les flux,
  2. La capacité à organiser et structurer les environnements (Production, Qualification, etc.)
  3. Le chiffrement des contenus.
  4. Le respect des chorégraphies de médiations dans les flux,
  5. Le support de patterns complexes flux API et Messages.
  6. La gestion des tables de transcodification.

4.1 - Alerte des applications

Alerter les référents techniques lors de dysfonctionnement.

La détection d’alerte

Enterprise Flows Repository détecte les alertes sur la couche dite “médiation” et “application”.

La détection est dynamique. Les rejeux viennent modifier les états et adapter les alertes en conséquence.

La présentation pour les équipes techniques

Une information simple et compréhensible est présentée aux référents techniques afin de:

  • visualiser quel flux est en erreur,
  • lister les données concernées (Commande, Bon de Livraison, etc)
  • Mettre en évidence les erreurs relevées.

La sélection des bons interlocuteurs

Les responsables des applications sont automatiquement alertés par mail.

Les référents sont informés au plus tôt.

4.2 - Alerte fonctionnelle

Alerter les référents fonctionnels lors de dysfonctionnement.

La détection d’alerte

Enterprise Flows Repository détecte les alertes sur la couche dite “fonctionnelle”.

La détection est dynamique. Les rejeux viennent modifier les états et adapter les alertes en conséquence.

La présentation pour les métier

Une information simple et compréhensible est présentée aux référents métier afin de:

  • visualiser quel échange est en erreur,
  • lister les informations concernées (Commande, Bon de Livraison, etc)
  • Mettre en évidence les erreurs relevées.

La sélection des bons interlocuteurs

Les responsables des applications sont automatiquement alertés par mail.

Les référents sont informés au plus tôt.

4.3 - Tables de transcodification

Externaliser les tables de transcodification des médiations.

Qu’est-ce qu’une transcodification ?

Une transcodification est le fait de transformer un contenu en fonction de sa destination.

Par exemple, lors de la manipulation des contenants, il est nécessaire de pouvoir calculer une valeur depuis un contenant vers un autre.

Un carton a une dimension de 10x30x40.
Celui-ci peut contenir au maximum 5kg.
Son contenu est de 5 litres.

Une palette de 120x120x10 pèse 2 kg.
Celle-ci peut porter au maximum 1000 kg et 1025 litres.

Seulement 50 cartons peuvent être déposés sur la palette.

La table de correspondance est alors la suivante:

Clécartonkglitrepalette
carton15550
kg510.975
litre51.0251025
palette100010251

Un outils pour les fonctionnels

Ces données sont PUREMENT fonctionnelles.

Elles n’ont pas vocation à être déployées dans les médiations API, ESB ou ETL.

Enterprise Flows Repository propose :

  • une interface de gestion aisée
  • un accès complet par API (pour les médiations).

Les transcodifications réduit les développements spécifiques et accélère la propagation des changements en offrant un outils complet.

4.4 - Suivi des échanges

Suivi des transports d’information du point de vue fonctionel.

Une recherche efficace

Les échanges sont accessibles par des recherches, soit:

  • temporelles
  • critères multiples

Des critères multiples

La recherche est possible par:

  1. des intervales de temps,
  2. les informations transportées,
  3. les systèmes sources et cibles.

4.5 - Suivi des flux

Collecte des traces reçues par Enterprise Flows Repository.

Une recherche efficace

Les flux sont accessibles par des recherches, soit:

  • temporelles
  • critères multiples

Des critères multiples

La recherche est possible par:

  1. des intervales de temps,
  2. les données transportées,
  3. les applications sources et cibles.

L’exemple ci-dessus illuste les API exposées au sein d’une API Gateway.

4.6 - Vision du RUN

Consultation de l’exécution des traces provenant du RUN.

Cette vision n’est pas théorique. Elle est calculée depuis les traces du RUN !

Une organisation en couche

Dans cette vision de l’exécution du RUN, EFR organise 3 blocs pour le même transport.

  1. La vision de l’échange

  1. La vision des flux

  1. La vision des médiations

Mise en avant des erreurs

Les erreurs relevées sont mises en avant lors de la sélection des flux ou des médiations.

Chaque erreur est identifiée et caractérisée pour faciliter le support en cas de dysfonctionnement.

Un accès aux traces

EFR est agnostique aux outils et aux éditeurs.

Responsabiliser EFR permet d’uniformiser le suivi de toutes les plateformes d’interconnexion du Système d’Information.

5 - Architecture

Vision technique de Enterprise Flows Repository

Principes

5.1 - Collecte des traces

Suivi des transports d’information du point de vue technique.

Collecte centralisée

Les traces sont sauvegardées dans des indexes Elasticsearch. Leur format est complet.

Elles sont accessibles et disponibles pour des analyses complémentaires ou du reporting Kibana à façon.

Collecte uniformisée

EFR est agnostique aux outils et aux éditeurs.

Responsabiliser EFR permet d’uniformiser le suivi de toutes les plateformes d’interconnexion du Système d’Information.

5.2 - Organisation par environnement

Répartition des flux dans des espaces dédié à chaque environnement d’exécution.

Des environnements dédiés

Chaque environnement d’exécution est séparé. Les suivi et les reporting sont spécifiques à chaque environnement.

L’utilisateur choisi un environnement à son entrée dans EFR.

Urbanisation commune

L’urbanisation n’est pas spécifique aux environnements. Il est donc commun et partagé.

Il n’est pas nécessaire de dupliquer ou propager des informations d’urbanisation d’environnement à environnement.

5.3 - Chiffrement des messages

Le chiffrement des messages est anticipé ou délégué à EFR.

Chiffrement des contenus

Le chiffrement des corps des traces des messages (partie body) est délégué aux modules spécialisés:

EFR délègue le chiffrement à des services fortement sécurisé.

Chaque Client pilote sa gestion des clées de chiffrement.

Chiffrement initié par EFR

Lors de leur arrivée dans EFR, certains messages peuvent être chiffrés.

En fonction de la définition des flux, EFR chiffre automatiquement le corps avant sauvegarde dans le puit des traces.

Chiffrement piloté par les collecteurs Client.

Avant l’envoi à EFR, un agent demande le chiffrement des corps des messages.

EFR reçoit un corps de message déjà chiffré.

Piloté par l’urbanisation

Le chiffrement est activé lors de la sélection de caractéristiques sur le flux.

Chaque flux “sensible” reste confidentiel.

Les corps des traces sont stockées chiffrés en fonction de l’urbanisation.

5.4 - Plateforme isolée

Ressources dédiées à chaque client.

Isolation des ressources

Chaque client est isolé dans un réseau spécifique avec ses ressources correspondant à la capacité choisie.

Chaque solution EFR est déployée dans un projet Google Cloud différent.

Les ressources dédiées sont

  • les réseaux:
    • firewall
    • load-balancer
    • nat
  • le cluster Kubernetes:
    • espaces de stockage
    • serveurs utilisés
  • les bases de données
  • les configuration de chiffrement.

Personnalisation

Gestion du changement

La gestion du changement sur la solution EFR est réalisée en collaboration.

Les opérations de maintenance sont partagées et choisies en connaissance des contraintes du client.

Personnalisation des environnements

Chaque environnement peut utiliser des ressources matérielles dédiées.

En cas de besoin d’environnement hors-production à forte capacité, celui-ci peut-être adapté afin d’offrir une forte elasticité.

Chaque environnement (Production, Qualification, etc) est personnalisable.

Sécurisation des réseaux

Sécurisation en entrée

L’offre EFR inclue la mise en place d’un VPN avec chaque client.

Le VPN renforce la sécurisation des données transportées entre le client et l’environnement dédié EFR.

Sécurisation en sortie

Un module NAT, Network Adress Translation, simplifie la gestion des IP sortantes.

La restriction des flux de EFR vers le réseau client est facilité.

5.5 - Gestion des identités

Gestion des identités dans un module dédié.

Centralisation des identités

Les identités sont centralisées et gérées dans la solution Keycloak.

Cette solution garantie la gestion centrale et unique des identitées.

Interconnexion avec les fournisseurs externes

Keyclaok offre des interconnexions avec les principaux fournisseurs du marché:

  • Microsoft Azure Directory
  • Google Account
  • GitHub
  • etc.