Comment modéliser la présence de composants techniques dans les flux ?

[j-ova]

Bonjour,

Nous avons commencé à saisir l'ensemble de notre écosystème applicatif dans Mercator, et j'apprécie énormément toutes les fonctionnalités qu'offre l'outil.

Durant nos séances de saisie une question s'est posée à laquelle je n'arrive pas à trouver de solution satisfaisante : comment modéliser la présence de composants qui supportent les flux entre les applications métiers ?

Notre cas d'usage est le suivant :

• Nous avons un flux de données qui part de notre référentiel Articles vers une base de données dans le cloud. Ce flux est exécuté régulièrement par un job Jenkins
• Nous avons également un flux de données qui part de notre référentiel Articles vers notre datawarehouse. Ce flux est exécuté régulièrement par un traitement Talend
• Pour des questions de lisibilité des cartographies, nous souhaitons modéliser le lien direct entre les composants métiers (ie. un lien référentiel->cible au lieu de deux liens référentiel->intermédiaire et intermédiaire->cible)
• Cependant, nous souhaitons quand même pouvoir exploiter la donnée de "quels flux sont portés par quels composants techniques"
  Aujourd'hui nous ajoutons cette information dans la description du flux, mais ce mode de saisi n'est pas très exploitable

Y a-t-il une solution à cette problématique dans le modèle de données actuel ?
Sinon, est-ce qu'une évolution du modèle serait envisageable ? eg. ajouter une box "Composants Intermédiaires" entre la source et la cible d'un flux ?

Merci !

[dbarzin]

Pour l'instant, il n'est pas possible de modéliser les composants qui supportent les flux entre les applications métiers. Il est possible cependant d'utiliser les services ou modules applicatifs comme "Composants Intermédiaires" entre la source et la cible d'un flux.

[j-ova]

J'avais oublié de répondre mais merci pour la suggestion. Les composants intermédiaires étant des applications à part entière (CPE dédié, ...) je ne suis pas à l'aise à l'idée de les modéliser en tant que simples services.

Pour le moment j'ai décidé de modéliser les flux de l'application source à l'application destination, en ajoutant uniquement dans la description du flux si il est soutenu par un composant intermédiaire. Ca facilite la lecture des schémas, et l'info est là même si non structurée.

Les composants intermédiaires sont référencés en tant qu'applications à part entière, mais sans flux déclarés avec les autres applications.

[dbarzin]

J'avais pensé à lier les flux logiques aux flux réseau, mais avec plus de 1 000 flux réseau dans notre organisation, cela devient vite compliqué. Il est important de garder la cartographie simple et claire.

Votre idée de modéliser les flux entre les applications source et destination, tout en mentionnant les composants intermédiaires dans la description, est une bonne solution. Cela rend les schémas plus lisibles tout en conservant les informations importantes.

Référencer les composants intermédiaires comme des applications sans flux déclarés est également une bonne approche. Cela permet de les identifier sans surcharger la cartographie.

Je pense qu'il est important de mettre en place une cartographie simple pour se concentrer sur ce qui est vraiment important.