Lorsque nous réalisons la cartographie du système d'informations nous pouvons décrire plusieurs couches :
- La couche des applications : elle représente les applications qui sont utilisées dans le système d'information, telles que les systèmes de gestion de contenu, les applications de gestion de la relation client (CRM), les applications de gestion de la chaîne d'approvisionnement, etc. Elle peut inclure des informations sur les fonctions des applications, les interfaces d'application et les protocoles de communication.
- La couche des données : Cette couche représente les données stockées dans le système d'information, telles que les données clients, les données financières, les données de production, etc. Elle peut inclure des informations sur les bases de données, les fichiers de données, les entrepôts de données et les services de gestion de données.
- La couche des infrastructures : Cette couche représente les composants matériels et logiciels qui sont nécessaires pour faire fonctionner le système d'information, tels que les serveurs, les ordinateurs, les réseaux, les dispositifs de stockage, les logiciels de virtualisation, etc. Elle peut inclure des informations sur les configurations matérielles et logicielles, les connexions réseau, les protocoles de sécurité, etc.
- La couche des processus métier : Cette couche représente les processus métier et les flux de travail qui sont soutenus par le système d'information. Elle peut inclure des informations sur les activités, les rôles, les responsabilités, les règles de gestion, les indicateurs de performance, etc.
Cette recette s'addresse à la couche des applications.
Comment représenter cette cartographie
Le module usage permet de restituer toutes les utilisations de données, c'est pourquoi il contient l'objet "Application".
Vous pourrez grâce à cet objet Applications :
- disposer d'une fiche "objet" dédiée pour décrire les applications
- Pour les applications de type reporting, lister tous les rapports
- Pouvoir le relier
- aux données gérées grâces aux liens avec le glossaire
- A sa ou ses sources de données (module dictionnaire)
- Aux flux d'alimentation (module traitements)
Attention : les Applications peuvent être liés à des technologies ou même être alimentées par le connecteur. Dans ce cas il n'est pas pertinent de créer un niveau racine "applications" qui contiendrait toutes les applications. En effet :
- La technologie est héritée de l'objet racine : ainsi vous ne pourriez avoir qu'une technologie pour tous les enfants
- Le connecteur remonte les informations en s'appuyant sur le path. En ajoutant un niveau racine, le path sera différent et donc le connecteur ne pourra plus lier l'application listée dans le catalogue à celle qu'il souhaite décrire.
Décrire les applications
L'intérêt de disposer d'une fiche objet dédiée réside notamment dans la capacité à disposer d'attributs spécifiques. Voici une liste non exhaustive des attributs qu'il peut être intéressant d'utiliser pour décrire une application :
- Description : pour cela vous pouvez utiliser
- Identification : il existe souvent un code interne pour identifier les applications. Un attribut peut être dédié à cela.
- Owner
- Liste des entités utilisatrices
- Type de technologie : client lourd, web, etc.
- URL d'accès
- Type d’application : développement interne, logiciel, progiciel,
- Volume d’utilisateurs et profils : à noter que pour cet attribut il peut être intéressant d'utiliser les attributs de type série temporelles afin de mesurer les éventuelles progressions.
Créer les ilots applicatifs
Afin de faciliter la compréhension de tous, il est souvent intéressant de créer des ilots applicatifs. Par exemple en précisant les applications liées à tel ou tel domaine métier.
Comme décrit plus haut il peut être pénalisant d'utiliser les hiérarchies. La meilleure solution est alors d'utiliser des vues filtrées basées sur les attributs décrivant les fiches objets. Par exemple :
- Les applications de tel ou tel domaine métier
- Les applications contenant des données personnelles
- Les applications hébergées sur tel serveur
Ce fonctionnement présente plusieurs autres avantages :
- Ces vues filtrées sont partageables et facilement accessible via la recherche
- Elles peuvent être positionnées en vue par défaut du module usage
Un second fonctionnement, est d'utilisé la notion de domaine pour décrire vos quartiers et vos ilôts. Vous pourrez ainsi
- Disposer d'une fiche dédiée permettant de décrire l'utilisation
- Disposer d'un objet chapeau facilement appelable depuis n'importe quel objet de DataGalaxy
- Faire surfacer facilement l'information sur les fiches objets grâce aux attributs raccourcis.
Représenter les ilots applicatifs
Une fois que les applications auront été dument décrites il peut être très intéressant de représenter les liens sur un diagramme libre. Ainsi vous disposerez d'une vision des différents liens unissant vos applications. Vous pouvez également utiliser les couleurs disponibles pour représenter les ilots applicatifs.
Prochaines étapes
Comme nous l'avons vu plus haut, une cartographie des applications prendra tout son sens dans DataGalaxy notamment car il est possible de la lier
- Aux données fonctionnelles utilisées
- Aux éventuelles couches techniques : sources et autres flux.
Pour aller plus loin, cette cartographie peut bien sur être liée aux processus métiers. Il sera ainsi possible de comprendre quand cette application est utilisée et dans quel contexte.