Gouvernance des données Livre blanc - DoYouBuzz : …€¦ · 2.2 Avec la gouvernance des données, l’intégration fonctionnelle du SI gagne en agilité 37 ... composée d’une

Gouvernance des données – Livre blanc

Philippe Boutet Page 1 sur 63 26/02/2010

Gouvernance des données

Livre blanc



Sommaire

1 Objectifs et principes de gouvernance de la donnée .......................................................... 5 1.1 Introduction à la gouvernance de la donnée ................................................................ 5

1.1.1 Pourquoi une gouvernance de la donnée .............................................................. 5 1.1.2 Qu’est ce que l’activité de gouvernance de la donnée ......................................... 8

1.2 Une sémantique commune à tous les acteurs métier de l'entreprise .......................... 12 1.2.1 Le dictionnaire sémantique commun du Système d’Information ...................... 12 1.2.2 La mise en place du dictionnaire sémantique ..................................................... 13 1.2.3 Les règles de cohérence des données ................................................................. 15 1.2.4 Du dictionnaire sémantique commun au modèle d’entreprise ........................... 15

1.2.5 Le modèle d’entreprise ....................................................................................... 17

1.2.6 Le modèle et ses règles d’intégrité ..................................................................... 18

1.3 La gestion de contenu ................................................................................................ 19 1.3.1 Introduction ........................................................................................................ 19 1.3.2 Définition des contraintes applicables aux informations portées par les objets du

Système d’Information ..................................................................................................... 23 1.3.3 Stratégies d’identification des objets métier ...................................................... 26

1.3.4 Définition des stratégies de prévention contre la création de doublons ............. 28

1.3.5 Définition des stratégies d’identification et de suppression des doublons ......... 29 1.3.6 Mise en œuvre des contraintes d’intégrité dans les processus d’amélioration de

la qualité des données. ...................................................................................................... 31

2 Les activités de gouvernance de la donnée pour la réalisation du système informatique 32 2.1 Un modèle d’entreprise sur lequel s’appuient tous les référentiels, les services et les

flux de l’entreprise ............................................................................................................... 32 2.1.1 Administration du modèle d’entreprise .............................................................. 32

2.1.2 Impacts du modèle d’entreprise sur la définition des interfaces entre applications

34

2.2 Avec la gouvernance des données, l’intégration fonctionnelle du SI gagne en agilité

37 2.2.1 Propager la terminologie commune à l’ensemble des éléments du Système

Informatique ..................................................................................................................... 37 2.2.2 Outiller la propagation de la sémantique portée par le modèle d’entreprise sur

les modèles projets applicatifs .......................................................................................... 41

2.2.3 Propager la sémantique métier commune des modèles applicatifs aux

implémentations physiques .............................................................................................. 42

2.2.4 Impact sur le cycle de vie des projets applicatifs du SI...................................... 44 2.2.5 Nécessité d’avoir au préalable un modèle d’entreprise ...................................... 46

2.3 Gestion des évolutions ............................................................................................... 47 2.4 Diffusion des listes de valeurs et propagation des modifications d’identifiant ......... 48

2.4.1 Diffusion des listes de valeurs ............................................................................ 48

2.4.2 Propagation des modifications d’identifiant ...................................................... 48 2.5 Travaux d’amélioration de la qualité des données .................................................... 48

2.5.1 Audit de l’état des données ................................................................................ 48 2.5.2 Amélioration de l’état des données .................................................................... 49 2.5.3 Amélioration des processus de valorisation des données ................................... 49 2.5.4 Surveillance de la qualité des données ............................................................... 49

3 Synthèse des uses case liés à la mise en œuvre de la gouvernance des données ............. 50

3.1 Mise en place d'un modèle d’entreprise initial .......................................................... 51 3.2 Industrialisation des processus de production utilisant le modèle d’entreprise ......... 53



3.3 Réalisation des logiciels du Système Informatique en conformité avec le modèle

d’entreprise ........................................................................................................................... 54 3.4 Gestion de contenu : Gestion des listes de valeurs .................................................... 55 3.5 Gestion de contenu : Gestion des identifiants ........................................................... 56

3.6 Gestion de contenu : Amélioration initiale de la qualité des données ....................... 57 3.7 Gestion de contenu : Surveillance de la qualité des données .................................... 58

4 Conclusion ........................................................................................................................ 59 5 Glossaire ........................................................................................................................... 60



Remerciements La rédaction de ce document doit beaucoup à l’aide que m’a apporté la société Prima

Solutions et ses consultants.

Prima Solutions a su fournir l’outillage d’excellence qui permet de rendre efficace, productif

et traçable la réalisation de modèles applicatifs conformes à un modèle d’entreprise.

Prima Solutions fournit également un modèle (Prima IBCS™) qui peut être une excellente

base de travail pour la réalisation d’un modèle d’entreprise lorsque cette entreprise exerce des

activités d’assurance.

Les illustrations présentes dans ce document ont été réalisées en s’appuyant souvent sur des

extraits restreints de Prima IBCS™, sur le modeleur UML MagicDraw™ et sur l’outillage

Prima IBCS Tooling™ développé par Prima Solutions. Il apporte des fonctionnalités

complémentaires à MagicDraw ™ importantes pour assurer les activités de gouvernance des

données décrites dans la deuxième partie de ce document.

Contenu du document L’objectif de ce document est d’expliquer ce qu’est la gouvernance des données, de

sensibiliser le lecteur sur son apport dans l’amélioration du fonctionnement de son Système

d’Information, de décrire les activités qui y sont attachées et l’organisation à mettre en place.

Il s’adresse aux cadres responsables du Système d’Information de l’entreprise, informaticiens

ou utilisateurs. Il s’adresse également aux personnes définissant les cadres méthodologiques

et qualité de réalisation du Système d’Information.

Il est structuré en 8 parties :

Les trois premières expliquent ce qu’est la gouvernance des données :

o 1.1 Introduction à la gouvernance des données

o 1.2 Une sémantique commune à tous les acteurs métier de l'entreprise

o 1.3 La gestion de contenu

Les suivantes décrivent les activités de gouvernance des données et leur

fonctionnement

o 2.1 Un modèle d’entreprise sur lequel s’appuient tous les référentiels, les

services et les flux de l’entreprise

o 2.2 L’intégration fonctionnelle du Système Informatique gagne en agilité

o 2.3 Gestion des évolutions

o 2.4 Diffusion des listes de valeurs et propagation des modifications

d’identifiant

o 2.5 Travaux d’amélioration de la qualité des données

Il est complété d’une synthèse des cas d’utilisation liés à la mise en œuvre d’une gouvernance

des données, d’une conclusion et d’un glossaire.

L’auteur du document s’appuie sur plusieurs expériences concrètes de mise en œuvre d’une

activité de gouvernance des données dans le domaine bancaire et dans le domaine assurance.

Ces expériences, menées dans des contextes différents avec différents niveaux d’outillage, lui

ont permis d’acquérir des convictions fortes sur les activités à mettre en place et sur la façon

de les mettre en œuvre (organisation communications et outils nécessaires). Toutefois, il

convient à chaque entreprise de s’approprier les convictions de l’auteur afin de les remodeler

dans le contexte culturel propre à son entreprise.



1 Objectifs et principes de gouvernance des données Ce chapitre a pour objectif de clarifier ce en quoi consiste la gouvernance des données.

1.1 Introduction à la gouvernance des données

Cette première partie a pour objectif d’expliquer pourquoi mettre en place une

gouvernance des données opérationnelle au sein d’une entreprise, son positionnement

dans l’organisation de l’entreprise et de définir ses activités et ses responsabilités.

1.1.1 Pourquoi une gouvernance des données

L’extension des Système d’Information d’entreprise, la multiplication des acteurs métier,

la croissance externe des entreprises, rendent toujours plus complexe la communication

entre les différents acteurs du Système d’Information.

Chaque pan du Système d’Information (ensemble d’applications très connectées du

Système d’Information, d’acteurs de la DSI en charge de ces applications et des

utilisateurs de ces applications) possède son propre vocabulaire, avec déjà des divergences

qui entraînent des surcoûts. Ces divergences sont d’autant plus importantes que la

spécialisation technique des acteurs est forte.

Schéma1 : les acteurs du SI ne se comprennent pas. Par exemple, chacun a sa vision de la

différence qui existe entre un contrat et une proposition ainsi qu’entre un prospect et un

client.



Lorsque les applications d’un pan du Système d’Information doivent communiquer avec

d’autres applications du Système d’Information, les divergences sémantiques deviennent

des gouffres difficiles à combler : vocabulaire différent, granularité des informations

différente, … .

Ce qui a pour conséquence :

Des difficultés d’intégration des applications ;

Une multiplication des fonctionnalités métier proches mais non rapprochables du fait

des divergences sémantiques ;

Un manque d’agilité dans les évolutions du Système d’Information : la compréhension

d’une décision diffère d’un pan du Système d’Information à un autre, puisqu’ils

n’interprètent pas les mêmes termes de la même façon.

Schéma 2: Les applications « Appli1 » et « Appli2 » fournissent des propositions mais

chacune dans une définition sémantique différente.

Manque de cohérence du Système d’Information qui peut aller jusqu’à provoquer un

manque de lisibilité dans la stratégie de l’entreprise et dans son pilotage. Par exemple les

tableaux de bord décisionnels deviennent aléatoires puisque la signification et la

granularité de l’information sont incohérentes.



Pour réduire ces difficultés, les entreprises mettent de plus en plus souvent en place une

activité de gouvernance des données.

Schéma 3: « Tout le monde utilise la même sémantique métier. L’agilité du développement

du Système d’Information s’améliore significativement. »



1.1.2 Qu’est ce que l’activité de gouvernance des données

1.1.2.1 Définition de la gouvernance des données

La gouvernance des données regroupe l’ensemble des activités qui permettent d’obtenir une

synergie des acteurs autour des données de l’entreprise.

Elle définit un vocabulaire sémantique commun, les règles de cohérence entre les données

ainsi que les données de références transverses de l’entreprise. Elle les divulgue, les contrôle

et les administre.

1.1.2.2 L’activité de gouvernance des données dans l’organisation

Pour mettre en place cette activité, il est essentiel de définir une structure commune et

transverse à tous les pans du Système d’Information, composée d’une cellule MOA et d’une

cellule MOE.

La cellule MOA intervient dans l’harmonisation de la sémantique utilisée dans les cahiers des

charges, les plans de tests, les cahiers de recettes et dans les notices d’utilisation des outils

informatiques.

La cellule MOE intervient dans l’harmonisation de la sémantique utilisée dans les documents

de spécification, d’architecture fonctionnelle, dans les documents de conception, dans la

désignation des objets et caractéristiques métiers dans le code et dans les plans de tests.

Les deux cellules interviennent dans l’édiction des règles de cohérence entre les données. Il

s’agit de règles de gestion portant sur l’intégrité fonctionnelle des données.

Schéma 4 : la gouvernance des données crée une synergie entre les acteurs du Système

d’Information.



Les acteurs de cette structure doivent être outillés :

de moyens d’administration de cette sémantique commune,

de moyens d’administration des données de référence transverses,

de moyens de communication permettant de propager la sémantique commune et les

données de référence auprès de tous les acteurs du Système d’Information,

de moyens d’administration des règles d’intégrité des données.

Cette structure doit surtout être dotée du pouvoir lui permettant d’éviter l’introduction de

nouvelles divergences ou la consolidation des divergences existantes.

Elle doit être intégrée dans l’organisme décidant des roadmaps d’évolution du SI. On verra

dans la suite du document que la volonté de convergence sémantique d’une entreprise

infléchit nécessairement le plan d’évolution du Système d’Information.

Par analogie, le pouvoir qui lui est accordé au sein d’une entreprise est similaire à celui qui est

confié à la structure qualité de l’entreprise lorsque celle-ci veut mettre en place une véritable

politique qualité lui permettant de prétendre à des certifications.

1.1.2.3 De quoi est composée l’activité gouvernance des données

L’activité de la gouvernance des données comprend :

La définition d’une sémantique commune à tous les acteurs métier de l’entreprise.

La définition d’un modèle conceptuel métier commun (ci-dessous appelé modèle

d’entreprise) sur lequel s’appuient tous les référentiels, les services et les flux de

l’entreprise. Il contient également les règles d’intégrité des données.

La mise en place d’une stratégie de propagation de l’utilisation du modèle d’entreprise à

l’ensemble des éléments du Système Informatique, afin d’augmenter l’agilité intégrative

fonctionnelle du Système Informatique.

La définition d’une stratégie et la mise en place d’outils permettant de gérer les évolutions

de la sémantique commune et le modèle d’entreprise et les modèles applicatifs qui en

dérivent.

La définition d’une stratégie de gestion de contenu incluant l’administration des données

de référence, l’identification des objets métiers et leurs dédoublonnages, les processus de

contrôle et d’amélioration des données pour s’approcher de l’excellence avec un respect

complet des règles d’intégrité.



Comme le montre le schéma ci-dessous, la gouvernance des données influence l’ensemble des

activités de production du système d’information.

Schéma 5: «Vision simplifiée des principaux uses cases et flux liés à la gouvernance des

données».



La rédaction des documents s’appuie sur le dictionnaire sémantique commun. La MOA

gouvernance des données doit :

D’une part, contrôler que les documents rédigés ont effectivement utilisés la

sémantique commune

D’autre part enrichir le dictionnaire sémantique commun lorsqu’un terme métier

s’avère manquant.

De même les documents doivent respecter les règles de cohérence des données.

La spécification et la réalisation des projets informatiques s’appuient sur le dictionnaire

sémantique commun et le modèle d’entreprise. La MOE gouvernance des données doit :

D’une part contrôler que les documents, modèles et codes respectent le dictionnaire

sémantique commun et le modèle d’entreprise,

D’autre part enrichir le dictionnaire sémantique commun et le modèle d’entreprise

lorsqu’un terme métier ou donnée métier s’avère manquant.

Les spécifications doivent mettre en œuvre le contrôle des règles d’intégrité des données.

Les données de références à administrer sont déterminées par le modèle d’entreprise.

La gestion des identifiants détermine l’identification des instances des concepts métiers

définis dans le modèle d’entreprise.

La gestion du contenu inclut également le contrôle de la qualité du contenu :

Contrôle du respect des stratégies d’identification des objets,

Contrôle de l’adéquation des informations saisies avec la définition sémantique de

l’information,

Contrôle de la complétion des informations sur les objets métiers créés,

Vérification de l’absence de doublons et de la mise en œuvre des moyens nécessaires à

leurs suppressions,

Mise en place des processus de contrôle et d’amélioration des données.

La gestion du contenu est de la responsabilité de l’ensemble des acteurs du Système

d’Information, mais la mise en place des processus inclus dans cette activité et leurs

coordinations sont de la responsabilité de la gouvernance des données.



1.2 Une sémantique commune à tous les acteurs métier de l'entreprise

1.2.1 Le dictionnaire sémantique commun du Système d’Information

La première étape consiste à faire converger la sémantique des acteurs métier de l’entreprise.

L’objectif est d’apporter des réponses à des questions comme :

- Qu’est ce qu’un contrat ?

- Les différents états d’un contrat

- Comment appelle-t-on une personne à laquelle une proposition de contrat a été

envoyée mais qui ne l’a pas encore signée ? Est-ce un client ou un prospect ou … ?

- La notion de client doit elle se limiter à un cadre commercial déterminé ? Si oui, quel

est ce cadre commercial ?

La sémantique commune de l’entreprise doit éclaircir toutes ces interrogations et y apporter

une réponse commune. Lorsque la nature des métiers ne permet pas d’aboutir à une réponse

commune, la définition du terme générique doit se limiter à la partie faisant consensus

commun, tandis qu’une terminologie plus précise sera élaborée pour préciser chaque

différence.

Le dictionnaire commun doit être complet, il ne doit pas se contenter de termes et de

définitions trop approximatives donnant une impression de consensus.

Ce dictionnaire doit être communiqué à l’ensemble des acteurs métiers du Système

d’Information. Les termes retenus doivent être repris avec la sémantique choisie dans

l’ensemble des écrits internes à l’entreprise : cahiers des charges, notes de cadrage, diffusions

d’informations, … . De même les libellés retenus dans les interfaces homme-machine doivent

respecter la terminologie commune.

Exemple : Extrait d’un modèle d’entreprise :

Contract

This class states a contract. A contract is the legal agreement between the

insurance company and the policy owner. In the computer database, a

contract is a partial copy of a product. In a contract, selected options are

specified while product fixed components are omitted.

Contract fiscalDate Date when the contrat is beginning from the fiscal point of view

Contract isContentious Specifies if there is contentious or not on contract.

Contract isFileWatchAlert Flag that indicates something particular about the contract (ex :

contentious...).

Contract regularisationDate Annual date which indicates when the contract is to be regularized

Contract term Contract term expressed in number of months/ years. N.B.: for 'Saving'

products, contract term could have the value 'whole Life'

ContractStatus ContractStatus This class states the status of a contract.

ContractStatus cancellationReason It indicates why the cancellation, or non-renewal is taking place.

ContractStatus cancellationType It identifies the rule to be followed in calculating the earned premium.

ContractStatus Contract status. Values are generally : in force suspended cancelled etc.

ContractStatus statusReason Reason for the las change of status value.

ContractStatus terminationDate Termination date

ContractStatus terminationReason Termination reason

Schéma 6: « Extrait d’un exemple de modèle d’entreprise».



1.2.2 La mise en place du dictionnaire sémantique

La réalisation d’un tel dictionnaire sémantique est laborieuse. Elle nécessite des ressources

importantes et des compétences analytiques fortes ainsi qu’un management ayant autorité

pour pouvoir trancher en cas de divergences entre les métiers ou les organisations sur

certaines définitions sémantiques. Sa réalisation dans le cadre d’un projet de refonte peut

engendrer un effet tunnel important.

Schéma 7: « Planning refonte Système Informatique avec effet tunnel » :

La réalisation d’un modèle d’entreprise dans sa version de base nécessite un travail important

commençant par le recensement de tous les principaux uses cases du Système d’Information à

réaliser et des référentiels existants. Cette phase se poursuit par l’élaboration du modèle

d’entreprise. Cette tâche nécessite la présence d’une équipe importante pluri-compétentes :

compréhension du métier, charisme pour faire converger les MOA métiers, conception UML,

culture technique pour prendre en compte les propositions d’amélioration des MOE, charisme

pour faire converger les MOE.

Cet effort initial peut s’avérer long. De plus, il met le projet en risque budgétaire. Pendant

cette phase initiale, le projet est un centre de coût sans aucun retour concret pour les directions

opérationnelles. La vie de l’entreprise continue, le Système d’Information existant est

constamment modifié et enrichi, créant ainsi un décalage entre les premières fonctionnalités

définies et les attentes des utilisateurs.

Pour éviter cet effet tunnel, l’entreprise pourra s’appuyer soit sur une ou des normes

existantes faisant autorité dans ses métiers, soit sur un produit proposant une sémantique de

référence pour ses métiers incluant déjà ces normes. Lorsqu’un tel produit, correspondant aux

métiers de l’entreprise, existe avec une haute qualité de modélisation, l’effet tunnel est



drastiquement réduit et les gains de productivité sur les phases de conception des applications

sont très sensiblement accrus.

Un dictionnaire sémantique est toujours améliorable. Il faudra donc prévoir une gestion de

versions afin que chaque document faisant référence à ce dictionnaire sémantique puisse

préciser la version qui lui sert de référence.

Schéma 8: « Versions du dictionnaire et référence à une version précise ».

Le choix d’un modèle d’entreprise initial réputé pour faire autorité sur le métier ciblé par le

Système Informatique évite l’effet tunnel et permet de démarrer la refonte du Système

d’Information sur les uses cases les plus prioritaires. La qualité conceptuelle du modèle initial

choisi doit permettre l’ajout des uses cases successifs sans refactoring excessif.



1.2.3 Les règles de cohérence des données

En parallèle les MOA définissent les règles de gestion qui assurent la cohérence des données

entre-elles.

Exemple : « Tour contrat possède au moins un souscripteur et un apporteur d’affaire, …. . »

1.2.4 Du dictionnaire sémantique commun au modèle d’entreprise

Le dictionnaire sémantique définit une terminologie précise qui s’impose à tous les acteurs

métiers.

Cette terminologie fournit le vocabulaire permettant de décrire et classifier les objets métiers

manipulés dans les processus de l’entreprise: c’est le modèle d’entreprise.

Comme le dictionnaire sémantique, le modèle d’entreprise doit être commun à l’ensemble des

acteurs métier du Système d’Information. Le dictionnaire métier et le modèle d’entreprise

sont très proches. Le modèle d’entreprise structure la terminologie définie dans le

dictionnaire métier, le dictionnaire sémantique donne la définition des termes utilisés dans le

modèle d’entreprise.

Ainsi, il n’est pas nécessaire de maintenir séparément le dictionnaire sémantique et le modèle

d’entreprise. Le dictionnaire sémantique peut être extrait du modèle d’entreprise.



Le modèle d’entreprise décrit les objets métier manipulés dans le Système d’Information.

Schéma 9 : « Modèle d’entreprise (objets du Système d’Information) vers dictionnaire

sémantique commun (obtenu par extraction) ».



1.2.5 Le modèle d’entreprise

Il formalise et structure tous les types de données du métier.

Il est indépendant de toute cible technologique.

Il doit s’appuyer sur un formalisme de modélisation connu et réputé.

Ce formalisme doit permettre de structurer les nombreux types de données du métier en

entités et les entités elles mêmes en paquets, afin d’en faciliter l’accès et la compréhension.

Chaque entité et chaque donnée doivent posséder une définition.

Lorsque le comportement de ces entités est dépendant de leur état, une description du cycle de

vie de l’entité doit être présente.

A chaque fois que cela est possible, il faudra préciser les contraintes applicables à ces

données : valeur minimum, valeur maximum , attribut obligatoire dans une entité, taille

maximum, les identifiants fonctionnels des entités, … .

Actuellement, le formalisme de modélisation le plus adapté pour décrire un tel modèle métier

est « UML ».

En formalisant ce modèle d’entreprise, il faudra prendre garde à définir chaque concept en

s’appuyant sur sa seule réalité sémantique. Il faudra s’abstraire de toute contrainte

d’implémentation.

Un bon modèle d’entreprise doit donc s’appuyer sur des couches de généricité, des patterns

d’analyse, des principes de minimisation des dépendances entre entités du modèle qui

garantissent : une évolutivité du modèle minimisant les risques de refactoring trop important

lors de l’intégration de nouveaux éléments sémantiques au modèle d’entreprise ; une

utilisation de ces modèles compatible avec les bonnes pratiques de conception. Un accent

particulier doit être porté sur la minimisation des dépendances et la précision sémantique.

Les modèles réalisés pourront par exemple s’appuyer sur les patterns proposés par Martin

Fowler dans son livre sur les patterns d’analyse :



Schéma 6: « Extrait d’un exemple de modèle d’entreprise».

1.2.6 Le modèle et ses règles d’intégrité

Les règles d’intégrité doivent compléter la définition des concepts au sein du modèle sous

forme de cardinalités et d’invariants.



1.3 La gestion de contenu

1.3.1 Introduction

Les acteurs métier du Système d’Information manipulent des objets concrets. Le modèle

d’entreprise permet d’obtenir un consensus sur la forme des objets métier. Il reste à obtenir un

consensus sur les valeurs des objets métier.

Ce consensus doit être obtenu au minimum sur l’identification des objets métier et à chaque

fois que cela est possible sur la liste des valeurs que peut prendre une information portée par

un objet métier.

Les processus qui permettent d’améliorer la qualité des données doivent être définis et mis

en place.

1.3.1.1 Consensus sur la liste des valeurs que peut prendre une information

portée par un objet métier

PolicyStatusReference

Active (enforce)

Active - Preliminary Term

Annuitized

Approve - Issue Hold

Approved Tentative Offer

Back Billed

Canceled

Claim pending without policy termination

Conditional Approval

Coverage is "active" but one (or more) of insureds have died

Declined Not Eligible

Disability claim pending without policy termination

Eligible, Issue Pending

Enforce- Attained Age Conversion

Free Look

Fully Paid-Up

Further Information Unobtainable Rejection

…



MaritalStatusReference

Common Law (Defacto)

Divorced

Estranged

Legally Separated

Married

Other

Single

TaxWithholding - Head of Household

TaxWithholding - Married, withholding single.

Unknown

Widowed

Schéma 10: « Du contrat à la liste des états du contrat. De l’adresse à la liste des pays,

des codes postaux. De la personne physique à la liste des civilités. De la personne morale

à la liste des formes juridiques ». Sur les diagrammes ci-dessus, les classes en vert sont

des données de référence partagées. Ce sont des classes dont la liste des instances évolue

peu et est gérée par un administrateur aux ordres de la MOA.

Si la liste des valeurs possibles n’est pas délimitable, il faudra préciser les contraintes qui

peuvent s’appliquer à cette information.



1.3.1.2 Consensus sur l’identification des objets métier

Chaque objet métier du Système d’Information doit être identifiable. Cette identification de

l’objet métier doit être la même dans tout le Système d’Information. La stratégie

d’identification des objets métier doit être étudiée pour chaque classe d’objets métier.

Schéma 11: « Contrat l’identification des contrats. Produit l’identification des

produits». Tous les « agreements » sont identifiés de la même façon : « idNumber »,

comme l’indiaue la balise « id ».

La stratégie choisie doit prévoir les mécanismes permettant d’éviter la présence de doublons :

objets identiques créés plusieurs fois avec des identifiants différents. Elle doit proposer des

mécanismes permettant d’éviter la création de doublons (il n’existe pas de système évitant

définitivement la création de doublons, mais des services ergonomiques de prévention

peuvent limiter leurs créations) et des mécanismes permettant de détecter et supprimer les

doublons existants.



1.3.1.3 Les processus qui permettent d’améliorer la qualité des données

Les systèmes d’information contiennent de part leur histoire des informations de qualités très

variables.

Certaines informations sont peu renseignées, d’autres sont rangées au mauvais endroit (nom à

la place du prénom, sigle à la place de la raison sociale, adresses mal découpées), d’autres

seraient contrôlables n’ont pas été vérifiées, d’autres sont faiblement typées alors que les

nouveaux processus de l’entreprise nécessiteraient qu’elles soient plus fortement typées

(exemple : tranches d’information trop larges), d’autres au contraire ont pu être certifiées. A

cela s’ajoute les problèmes d’incohérence des données (exemple : une même personne

présente dans deux contrats différents possède deux situations familiales différentes).

Il faut gérer cet état du système et mettre en place les processus qui permettent d’améliorer les

données tout au moins celles qui ont la criticité la plus importante, jusqu’à obtenir

progressivement le respect d’un maximum de règles d’intégrité.

1.3.1.4 Synthèse des objectifs à atteindre pour réaliser le consensus sur la

gestion du contenu

Il faudra que la MOA :

- définisse les contraintes applicables aux informations portées par les objets du

Système d’Information, en précisant les contraintes qualités exigées et leurs criticités

et à chaque fois que cela est possible la liste des valeurs possibles,

- définisse pour chaque classe d’objets sa stratégie d’identification,

- définisse les stratégies de prévention contre la création de doublons,

- définisse les stratégies d’identification et de suppression des doublons.

Il faut que les équipes MOE :

- réalisent ou mettent en place des outils en adéquation avec les choix stratégiques

réalisés par la MOA,

- applique sur les projets du Système Informatique, particulièrement sur les référentiels,

les décisions prises par la MOA (contraintes sur les valeurs, stratégie d’identification,

…).

- Mettre en place les outils d’amélioration de la qualité des données et de surveillance



1.3.2 Définition des contraintes applicables aux informations portées par les objets du Système d’Information

Les contraintes exprimées par la MOA sur les informations portées par les objets du Système

d’Information sont en règle générales mises en œuvre concrètement par la MOE, lors de la

réalisation des composants logiciels.

C’est le cas, lorsqu’il s’agit de précisions sur le format des informations ou d’une liste de

valeurs figées pouvant être utilisées dans des algorithmes programmatiques.

Ces listes de valeurs seront dénommées listes de valeurs programmatiques.

Schéma 12: « Exemples de listes de valeurs programmatiques : sexe de la personne, type

de prêt. Dans notre exemple les valeurs de ces deux types sont connues et sont utilisées

dans les algorithmes programmés. ».

Par contre, certaines listes de valeurs nécessitent plus de souplesses. Leur contenu est par

nature amené à évoluer régulièrement durant la vie du Système d’Information.

Les MOA doivent gérer en continu le contenu de ces listes de valeurs. Pour cela, le

Système Informatique doit intégrer des fonctionnalités permettant d’administrer ces listes

de valeurs.



CurrencyTypeReference ADP (Andorran Peseta)

AED (United Arab Emirates Dirham)

AFA (Afghanistan Afghani)

ALL (Albania Lek)

AMD (Armenian Dram)

ANG (Netherlands Antillian Guilder)

AON (Angola New Kwanza)

ARS (Argentine Peso)

ATS (Austria Schilling)

AUD (Australian Dollar)

AWG (Aruban Guilder)

AZM (Azerbaijanian Manat)

BBD (Barbados Dollar)

BDT (Bangladeshian Taka)

BEF (Belgian Franc)

BGL (Bulgarian Lev)

BHD (Bahraini Dinar)

BIF (Burundi Franc)

BMD (Bermuda Dollar)

BND (Brunei Dollar)

BOB (Bolivian Boliviano)

BOV (Bolivian Mvdol)

BRL (Brazilian Real)

BSD (Bahamian Dollar)

BTN (Bhutanian Ngultrum)

BWP (Botswanian Pula)

BYB (Belarussian Ruble)

BZD (Belize Dollar)

CAD (Canadian Dollar)

CHF (Swiss Franc)

CLF (Unidades De Formento)

CLP (Chilean Peso)

CNY (China Yuan Renminbi)

…

Schéma 13 « Exemple de liste de valeurs non programmatique : la liste des devises. Cette liste

change à travers le temps. Les algorithmes programmés peuvent utiliser certaines valeurs

identifiées par les éléments de cette liste, comme le taux de change, mais ils ne se réfèrent

jamais directement à une des valeurs de cette liste. »

Il est à noter que même les listes de valeurs dites programmatiques doivent faire l’objet d’une

administration afin de définir la forme prise par la valeur dans les interfaces homme machine,

en fonction du contexte dans lequel s’exécute l’interface homme machine.

Par exemple, un libellé peut être associé à chaque valeur. Pour une même valeur, ce libellé

peut être différent en fonction de la langue utilisée par l’utilisateur.



Un outillage d’administration des listes de valeurs doit être fourni à la MOA. Cet

outillage doit permettre la création d’une nouvelle valeur en précisant la date effective à partir

de laquelle la nouvelle valeur devient active. Il doit permettre la désactivation de certaines

valeurs à partir d’une certaine date. Il doit également proposer des services plus avancés

comme la substitution à une date donnée d’une valeur de la liste par une autre.

Code désignation Début Fin Code

remplaçant

ZOL Zorgland 1/1/2008 30/6/2008 ZGL

ZGL Zorgland 1/7/2008

ZOL Zorguelande 1/8/2008 30/08/2008 ZGL

Schéma 14: « Exemple de substitution d’une valeur de référence par une autre :

Un nouveau pays, le Zorgland, est créé le 1/1/2008 mais n’a pas encore de code iso officiel.

En attendant les gestionnaires décident de le coder ZOL. Le 1er

juillet le code officiel est

déclaré. le code doit devenir « ZGL ». Toutes les applications qui référençaient le

Zorgland en utilisant le code ZOL doivent modifier leurs références en remplaçant « ZOL »

par « ZGL ». Le 1/8/2008, un service a besoin de créer un processus lié au Zorgland. Mal

renseigné, ce service crée un doublon avec un autre code et une désignation erronée : « ZOL /

Zorguelande ». Fin août, un utilisateur plus avisé (ou un programme de dédoublage), détecte

l’erreur. le code ZOL doit être désactivé et remplacé par le code « ZGL ». Ce

remplacement sera appliqué le 1/09/2008.



1.3.3 Stratégies d’identification des objets métier

Une attention particulière sera apportée à l’identification des objets métier. Dans un

Système d’Information, il est préférable que pour une classe d’objets métier, un seul

système soit responsable d’attribuer une identification des objets métier de cette classe. Ce

système est qualifié de système maître pour les objets de cette classe. La désignation du

système maître potentiel est de la responsabilité des personnes en charge de l’urbanisation

du Système d’Information.

Schéma 15: « Schéma d’architecture avec système maître d’identification des produits ».

Lorsque, pour un type d’objet métier, il n’est pas possible de définir de système maître, il

faut au minimum qu’une stratégie commune d’attribution d’identifiants pour les objets

de cette classe soit élaborée et mise en œuvre dans chacun des systèmes créant des objets

métier de cette classe.



Schéma 16: « Schéma d’architecture sans système maître d’identification des produits ».

On évite la création d’homonymes via une stratégie qui consiste à préfixer l’identifiant de

chaque produit. Ce mécanisme ne fonctionne que si la frontière entre les systèmes

produisant des produits est clairement identifiée.

La stratégie choisie doit bien sûr éviter la création d’homonymes : objets différents ayant

le même identifiant.

Quelque soit la stratégie choisie et les précautions prises, l’absence de système maître de

la donnée reste un risque pour un système d’information. Il va nuire à la capacité de

détection des doublons, va complexifier les chaînes avals en particulier lorsqu’elles

doivent agréger les données.

Par exemple dans l’exemple ci-dessous, l’absence de système maître a engendré la

création de deux produits décès accident de la route similaire mais difficiles rapprocher.

La conséquence sera que le pilotage se fera comme si il existait deux produits différents ce

qui faussera la réalité concrète des résultats commerciaux de ces produits.



Schéma 17: « Schéma avec homonymes : deux produits différents ayant le même

identifiant ».

1.3.4 Définition des stratégies de prévention contre la création de doublons

La stratégie de prévention contre la création de doublons est en général spécifique à

chaque type d’objet. Elle peut s’appuyer sur des outils de rapprochement ou de recherche.

La stratégie la plus communément utilisée consiste à proposer une liste limitée des objets

les plus ressemblants au fur et à mesure que l’utilisateur renseigne les informations sur le

nouvel objet qu’il est en train de créer. Lorsque l’utilisateur découvre, dans la liste des

ressemblants, l’objet qu’il est en train de vouloir créer, l’ergonomie de son application

doit lui permettre d’abandonner sa création et de continuer le processus en cours en

utilisant l’objet préexistant qu’il vient d’identifier.



Schéma 18: « Fenêtre de création d’un tiers avec liste de semblables pour éviter la

création d’un doublon ». La liste est triée selon le coefficient de ressemblance.

1.3.5 Définition des stratégies d’identification et de suppression des doublons

La stratégie d’identification des doublons est également spécifique à chaque type d’objet.

Elle peut s’appuyer sur des outils de rapprochement ou de recherche.

La stratégie de suppression des doublons met en œuvre des processus complexes

spécifiques à chaque type d’objet. En effet la suppression d’un doublon doit se propager à

l’ensemble des objets métier qui référencent le doublon supprimé.



Schéma 19: « Dédoublonage d’un produit impact sur les contrats qui référençaient le

produit dédoublé »

Ces processus doivent faire l’objet de sous-projets à part entière menés par la MOA et la

MOE. Ils nécessitent la mise en ouvre d’un outillage souvent spécifique et d’une grande

robustesse. Une mauvaise propagation de l’information de substitution d’un objet en

double par un autre peut avoir des conséquences dramatiques sur l’intégrité du Système

d’Information.

Produit: Décès accident de la route Id: VieIARD003

Contrat 100345 Produit: VieIARD003 Client: 45612






Produit: Décès accident de la route Id: Vie108

Produit: Décès accident de la route Id: IARD106

Contrat 100345 Produit: Vie108 Client: 45612



Contrat 87698 Produit: IARD106 Client: 54238





1.3.6 Mise en œuvre des contraintes d’intégrité dans les processus d’amélioration de la qualité des données.

L’amélioration de la qualité des données doit commencer par une analyse de l’état des

données. La réalisation d’un audit des données du système, mettant en exergue pour chaque

donnée :

Sa criticité en désignant les processus que l’absence de qualité de cette donnée peut

faire échouer. On précisera le coût engendré par l’échec de ces processus.

L’état de cette donnée dans les systèmes maîtres de cette donnée et dans ceux qui n’en

possèdent qu’une copie mise à jour à partir d’un ou plusieurs systèmes maîtres.

Lorsque l’état de la donnée est insuffisant par rapport à sa criticité, une analyse des

processus qui ont provoqués cet état de fait est nécessaire.

Cet audit s’appuie sur les règles de cohérence et d’intégrité.

Cet audit permet d’élaborer une cartographie de la qualité des données du système et des

coûts induits par la « non qualité ».

Pour améliorer l’état du système des processus doivent être mis en place qui vont permettre

d’améliorer les données tout au moins celles qui ont la criticité la plus importante, jusqu’à

obtenir progressivement le respect d’un maximum de règles d’intégrité.

Cet état des données dans le système peut être du à un endettement du système existant mais

également à des processus existants insuffisamment exigeants en termes de qualité de données

(partenaires n’ayant pas les mêmes contraintes).

Lorsque cela est possible, les processus défaillants doivent être améliorés pour que les

nouvelles données respectent les contraintes d’intégrité voulues. Lorsqu’il n’est pas possible

d’améliorer les processus défaillants, alors si l’exigence qualité de la donnée est critique, il

faut mettre en place un processus correctif et adapter l’organisation pour qu’elle puisse le

traiter (workflow).

De même pour l’endettement existant, certaines données peuvent être améliorées au moyen de

processus qualités automatisés. D’autres données ne peuvent être améliorées que par des

processus correctifs semi-automatiques voir manuels qui ne seront mis en œuvre que si la

criticité de la donnée est haute.

Toutes ces activités doivent être complétées par des processus de surveillance de la qualité

des données avec des mécanismes d’alerte lorsque la qualité des données ne respecte pas la

contrainte minimale exigée.



2 Les activités de gouvernance des données pour la réalisation du système informatique

Dans le chapitre précédent, la gouvernance des données a été définie, ses responsabilités

précisées et son intérêt dans le Système d’information mis en exergue.

Les chapitres suivants approfondissent les activités liées à la gouvernance des données liées à

la réalisation du système informatique.

2.1 Un modèle d’entreprise sur lequel s’appuient tous les référentiels, les services et les flux de l’entreprise

Schéma 20: « Modèle d’entreprise (modèle pivot) au centre de la définition des autres

composants du Système Informatique ».

2.1.1 Administration du modèle d’entreprise

Le modèle sémantique métier doit être administré par une cellule ayant de fortes

compétences synthétiques et analytiques.

Afin de s’assurer que la sémantique métier commune est correctement utilisée, le modèle

d’entreprise doit servir de modèle de données de référence pour la définition des interfaces

des applications.

Il est donc préférable qu’il soit administré par une cellule issue de la MOE, mais en

coopération continue avec la cellule de gouvernance des données issue de la MOA.

Un outillage de modélisation doit recevoir ce modèle d’entreprise. Il doit s’appuyer sur un

langage permettant d’exprimer une sémantique précise. Le langage retenu doit être le plus

reconnu et le plus répandu possible. Dans l’état de l’art actuel, le langage de modélisation

le plus adapté est « UML ».



L’outillage de modélisation doit permettre de gérer des versions de modèle et être ouvert

vers l’extérieur afin de pouvoir extraire les éléments de communication nécessaires :

- dictionnaire sémantique commun,

- pont vers les outils d’administration des données de référence,

- exposition des modèles pour l’ensemble des acteurs du Système d’Information.

Schéma 21: « Des outils d’extraction permettent à l’ensemble des acteurs du Système

d’Information de consulter le dictionnaire sémantique commun et le modèle d’entreprise en

ligne.

L’outil d’administration des références est également alimenté par un outil d’extraction, afin

que les données de référence soient toujours maintenues en cohérence avec le modèle

d’entreprise.



2.1.2 Impacts du modèle d’entreprise sur la définition des interfaces entre applications

Dans une stratégie d’intégration par les flux, pour minimiser les coûts d’intégration, l’analyse

des échanges entre applications se fait par demi-flux.

Schéma 22: «Avantage de l’intégration par les demi-flux».



Si un ensemble d’applications A, B, C, D et E communiquent ensemble sur un sujet S, plutôt

que d’étudier chaque flux A B, AC, AD, AE, BC, BD, BE, CD, CE et

DE, on étudie les flux de ASi, BSi, CSi, DSi et ESi où Si est un système

d’intégration traitant des échanges sur le sujet S.

La sémantique des flux traités par Si s’appuie sur un modèle qui sera nommé MSi ci-dessous.

Il sert de référence pour faire des échanges de données sur le sujet S. Il doit respecter le

modèle d’entreprise. Les nouvelles applications et les nouveaux flux devront implémenter

leurs échanges en instanciant le modèle MSi.

Que signifie « le modèle MSi doit respecter le modèle d’entreprise» ?

Les noms des classes représentant les objets métier dans le modèle MSi doivent être

identiques à ceux du modèle d’entreprise. Cette identité de nommage doit être respectée

également pour les attributs et les rôles. Les cardinalités définies dans le modèle MSi doivent

être compatibles avec celles du modèle d’entreprise (les cardinalités possibles du modèle MSi

doivent être un sous-ensemble des cardinalités possibles du modèle d’entreprise).

Le modèle MSi supporte des différences par rapport au modèle d’entreprise (simplifications,

dé-normalisations). Par contre, aucune nouvelle terminologie sémantique métier ne doit y être

ajoutée sans qu’elle fasse l’objet d’une évolution du modèle d’entreprise, sous le contrôle des

cellules qui en ont la responsabilité.

Extrait du modèle sémantique traitant du sujet S



Fabrication par mapping du modèle MSi relatif à la modélisation normalisée des flux traitant

du sujet S, sur les concepts modélisant S dans le modèle d’entreprise.

Résultat : le modèle MSi modélisé en conformité avec la sémantique du modèle d’entreprise

Schéma 23 : « Exemple de modèle MSi conforme au modèle d’entreprise».

La même logique doit s’appliquer à la modélisation des paramètres des services exposés par

les applications.



2.2 Avec la gouvernance des données, l’intégration fonctionnelle du SI gagne en agilité

L’intégration est souvent une phase délicate et lourde pendant laquelle sont mises

progressivement en exergue les différences de compréhension du système cible par chacune

des équipes. En particulier, il faut souvent attendre l’intégration pour s’apercevoir que les

équipes n’ont pas mis la même définition derrière le même intitulé d’une donnée.

Les impacts sont alors importants puisque les développements concernés sont fortement

avancés.

La phase d’intégration est sans doute celle qui est la moins apte à être qualifiée d’agile.

L’utilisation d’un modèle d’entreprise va limiter les d’incompréhension entre les équipes

projets et donc supprimer un des principaux risques de dysfonctionnement des intégrations.

La phase d’intégration devient alors nettement plus simple et peut devenir beaucoup plus

agile. Elle s’intègre beaucoup plus facilement au cycle itératif des projets dits « agile ».

2.2.1 Propager la terminologie commune à l’ensemble des éléments du Système Informatique

L’étape ultérieure consiste à propager la terminologie commune sur l’ensemble des éléments

qui font le Système Informatique. Il faut donc profiter d’opportunités comme le

développement de nouvelles applications, ou les refontes d’applications existantes, pour

propager la sémantique commune jusqu’aux noms des entités manipulées dans le code

programmatique, jusqu’aux schémas physiques des bases de données, jusqu’aux noms des

données manipulées dans les jeux de tests. Cela est essentiel pour une compréhension

mutuelle entre tous les acteurs du Système d’Information, pour éviter les dérives techniques

sur l’utilisation des données du Système d’Information et pour faciliter les interactions entre

les équipes des différentes applications et de fait faciliter l’intégration des applications dans le

Système Informatique.



Schéma 24: « Exemple de modèle applicatif projet issu du modèle d’entreprise».



Les trois figures ci-dessus montrent comment un modèle applicatif est conçu. Après avoir

identifié les classes du modèle d’entreprise utiles à la réalisation du modèle applicatif

commun, un modèle est créé en copiant les propriétés issues du modèle d’entreprise.

Dans la première figue on peut voir la correspondance entre les classes du modèle applicatif

(à droite de la figue en jaune claire) et celle du modèle d’entreprise (à gauche en brun clair).

La figue du dessous zoome sur les éléments du modèle d’entreprise utilisés. La figure

suivante zoome sur le modèle applicatif résultant.

Dans le modèle applicatif résultant certaines simplifications ont été réalisées en supprimant

les classes « CoreBusinnessRole » et « ProfessionnalServiceProvider » de l’arbre d’héritage

entre « LossAdjuster » et « Role ».

Une fois le modèle applicatif métier réalisé, il peut être à nouveau décliné en modèle de base

de données.



Schéma 25 et 26: «Schéma montrant la déduction d’un modèle logique de base de

données issu du modèle applicatif métier »

Ces deux schémas montrent comment un modèle de base de données a été réalisé à partir du

modèle applicatif métier. La première figure montre la correspondance entre les classes du

modèle applicatif métier et les tables de la base de données. La seconde figure zoome sur les

tables de la base de données.

Cet exemple montre que la terminologie du modèle d’entreprise est conservée par transitivité

jusqu’au modèle de la base de donnée.

Pour que ces opérations puissent être réalisées efficacement, il est essentiel de les outiller. Ce

sera le sujet du chapitre suivant.



2.2.2 Outiller la propagation de la sémantique portée par le modèle d’entreprise sur les modèles projets applicatifs

Le modèle d’entreprise étant fait pour supporter la sémantique de tous les métiers du Système

d’Information, il est d’une richesse bien supérieure au besoin de chaque application, chaque

flux et chaque service.

Pour que cette sémantique commune puisse être propagée à chaque application, chaque flux et

chaque service, il est essentiel de mettre en place un outillage qui permette de modéliser

chaque application, chaque flux et chaque service en reprenant les éléments du modèle

d’entreprise qui intéressent l’application, le flux ou le service modélisé.

Schéma 27: « Outil ViewMapper de création d’un modèle par extraction d’un modèle

existant ».

Un outil doit permettre aux concepteurs des modèles applicatifs des modèles de base de

données, des modèles d’échange, …, de concevoir leur propre modèle en piochant les

éléments de leur modèle dans le modèle d’entreprise.

Les noms, les définitions, les descriptions et toutes les précisions (taille, valeur minimale,

valeur maximale,…) présentent dans le modèle d’entreprise doivent être transportées dans la

copie réalisée dans le modèle applicatif.

Schéma 28: « Exemple de modèle résultant suite à l’utilisation du view mapper..»

Il est important que chaque élément du modèle applicatif projet conserve un lien vers les

éléments sémantiques du modèle d’entreprise dont il est originaire afin de gérer les impacts

des éventuelles évolutions du modèle d’entreprise.



La mise en œuvre d’une telle approche contraint la structure conceptuelle du modèle

d’entreprise à une obligation d’exigence qualitative très élevée. En particulier, il doit intégrer

des contraintes afin que les modèles projets applicatifs issus de ce modèle d’entreprise

puissent appliquer les bonnes pratiques de conception d’une application sans diverger de la

sémantique imposée par le modèle d’entreprise.

2.2.3 Propager la sémantique métier commune des modèles applicatifs aux implémentations physiques

Pour que la sémantique métier commune soit réellement la base permettant d’améliorer les

échanges entre équipes et de mieux intégrer les applications, il faut que cette sémantique

métier commune devienne une réalité concrète sur chaque constituant physique du Système

informatique.

Ainsi les noms des tables et colonnes des bases de données, les noms des classes, des

attributs, des paramètres de services, dans le code d’implémentation des logiciels, les noms

des balises ou des déclarations de variables dans les fichiers d’échange doivent tous être

conformes à la sémantique métier commune.

Le modèle applicatif qui a été conçu à partir du modèle d’entreprise doit à son tour être

propagé à la réalisation des composants physiques du système.

Cela peut être réalisé de deux façons :

Chaque développeur traduit le modèle applicatif dans un langage d’implémentation

spécifique à sa cible

un outil de génération produit automatique dans le langage d’implémentation cible des

éléments conformes au modèle applicatif. Il s’agit alors d’une approche de type MDA.

2.2.3.1 Traduction manuelle des modèles par les développeurs

Cette approche laisse une plus grande flexibilité au développeur dans l’interprétation qu’il

peut faire du modèle. Elle s’appuie sur la qualité du travail du développeur.

Elle nécessite la mise en place de contrôles de conformité. Ces contrôles sont couteux et

nécessitent des contrôleurs multi-compétences : connaissances des cibles techniques et du


La maintenance évolutive de l’application risque de se faire au niveau programmatique et

d’éloigner l’implémentation de l’application de la sémantique métier commune et donc de

compliquer les futurs intégration de cette application dans le système informatique.

2.2.3.2 Utilisation d’approche MDA et d’un outillage adapté

Le MDA est une pratique qui consiste à déduire d’un modèle conceptuel la structure de

développement des éléments physiques de l’application : structure du code, structure de la

base de données, … .

Pour être efficace et productive, cette déduction est en générale automatisée par des outils

appelés générateurs.



Comme expliqué ci-dessus, une approche MDA automatisée permet de s’assurer que les

éléments physiques d’une application respectent la sémantique exprimée dans le modèle.

Elle réduit donc le coût de contrôle en limitant ces contrôles au modèle applicatif métier.

L’approche MDA apporte un autre axe d’intérêt pour la mise en place d’un modèle

d’entreprise : l’axe productivité.

La rapidité de réalisation d’un modèle projet, alliée à la capacité de production d’éléments

issus du modèle, permet de compléter l’axe qualité par un axe productivité en inscrivant le

modèle d’entreprise dans la chaîne de production des développements.

Schéma 31: « Principes du MDA.».

Toutefois, pour inclure complètement le modèle d’entreprise dans la chaîne de productivité

logicielle, il est indispensable de le compléter par un outillage performant permettant de

construire efficacement le modèle projet applicatif en s’appuyant sur le modèle d’entreprise.



2.2.4 Impact sur le cycle de vie des projets applicatifs du SI

Conséquence d’une telle approche sur le cycle de vie de développement des applications du

Système Informatique :

Les cahiers des charges, les spécifications des processus métiers, les maquettes

d’interface homme/machine et les cas de tests sont exprimés en utilisant un lexique de

référence issu du modèle d’entreprise. les risques d’incompréhension entre les

différents acteurs des projets (MOA, MOE) sont diminués

La phase de conception de l’application gagne en agilité. La réalisation d’une bonne

conception d’une application, permettant de définir une structure conceptuelle forte et

stable limitant les risques de refactoring trop larges, nécessite la prise en compte de la

globalité des besoins y compris le potentiel évolutif de l’application. Elle se traduit en

gestion de projet par un effet tunnel peu compatible avec la volonté de plus en plus

affirmée des décideurs de réaliser les projets sur la base d’un cycle court.

La conception d’un modèle applicatif en s’appuyant sur un modèle d’entreprise de

qualité, permet de rendre agile cette phase de conception tout en garantissant une

qualité de modélisation limitant les risques de refactoring trop importants.



Schéma 30: « Comparaison entre un cycle de vie en cascade avec effet tunnel sur la

conception du modèle et sur la phase d’intégration avec un cycle plus court : conception

beaucoup plus courte, intégration plus courte, réutilisation des cas de tests ».

Les modèles conceptuels des applications seront globalement de meilleure qualité, ce

qui aura un impact positif sur la qualité du code.



L’équipe ayant en charge l’administration du modèle d’entreprise doit être mise à

contribution sur l’ensemble des tâches mettant en œuvre le modèle d’entreprise :

o Rendre le modèle d’entreprise plus accessible en aidant les équipes projet

(MOE et MOA) à accéder à l’information disponible dans le modèle. Sa

richesse peut devenir un handicap en compliquant l’accessibilité à la bonne

information. Cet obstacle peut être facilement levé avec l’aide d’une équipe

spécialisée.

o Vérifier que chaque élément du Système Informatique respecte la sémantique

métier commune du cahier des charges jusqu’au code réalisé par le

développeur.

Pour cela, une validation du respect du modèle d’entreprise doit être ajoutée

dans les points de contrôle qualité. Ils doivent devenir obligatoires pour que

l’élément contrôlé puisse obtenir la qualification de « validé ».

Ce contrôle peut s’avérer fastidieux et donc coûteux surtout lors du contrôle

des éléments techniques (lignes de codes, schémas de base de données) qui

nécessitent la double compétence, expertise du modèle d’entreprise et expertise

technique.

Une approche MDA permet de limiter les vérifications à effectuer (voir plus

loin).

o Effectuer les évolutions du modèle d’entreprise, lorsqu’un acteur du Système

d’Information a besoin de disposer d’un élément sémantique métier non défini.

Autres conséquences importantes :

o une réduction des coûts de projet sur les phases de conception, de

développement et d’intégration ;

o une flexibilité dans la composition des équipes. Lors du passage d’une équipe à

une autre, l’utilisation d’une sémantique commune facilite l’intégration d’un

membre pour peu qu’il provienne d’une équipe projet mettant en œuvre le


2.2.5 Nécessité d’avoir au préalable un modèle d’entreprise

La contrepartie aux avantages cités ci-dessus est l’existence préalable d’un modèle

d’entreprise suffisamment complet et d’un bon niveau d’exigence qualité.

La réalisation d’un tel modèle va nécessiter la mobilisation durant une longue période d’une

équipe regroupant différentes expertises :

expertises sur les métiers de l’entreprise (MOA et MOE)

expertises en modélisation

Pour limiter l’impact d’une phase initiale couteuse, il peut être préférable pour l’entreprise de

s’inspirer d’un modèle préexistant traitant déjà des métiers de l’entreprise et respectant un

certain nombre de normes.

Dans le choix d’un tel modèle, une attention particulière devra être portée à la qualité du

modèle.



2.3 Gestion des évolutions

Du point de vue production de logiciels, le modèle d’entreprise, les modèles projets

applicatifs, les générateurs, ainsi que les éléments physiques développés font alors partie

intégrante de la chaîne de production. Ils doivent donc être intégrés à la gestion de

configuration du Système Informatique.

Du point de vue gestion d’une sémantique métier commune à l’ensemble du SI, il est

important qu’il y ait le moins de divergences possible entre la sémantique utilisée par les

applications, les flux et les services.

Or le modèle d’entreprise va s’enrichir au fur et à mesure de la mise en place de nouvelles

fonctionnalités dans le Système d’Information. Certaines parties de ce modèle peuvent même

être légèrement refactorées. Il faut alors remettre à niveau les flux, services et applications qui

utilisent des éléments sémantiques modifiés.

Les évolutions du modèle d’entreprise sont donc contraintes par une obligation de

compatibilité ascendante. Lorsque cette compatibilité ascendante ne peut pas être respectée

les éléments du modèle d’entreprise qui ne doivent plus être utilisés doivent être qualifiés de

dépréciés.

Il est essentiel que l’outillage du modèle d’entreprise puisse fournir l’impact d’une

modification du modèle sur les modèles projets applicatifs. La connaissance de ces impacts

doit permettre à l’équipe administrant le modèle d’entreprise de planifier les évolutions des

modèles de flux, de services et d’applications qui permettront d’intégrer la nouvelle version

du modèle d’entreprise.

Cette gestion est encore plus importante lorsque l’impact porte sur un élément de modèle

qualifié de « déprécié ».



2.4 Diffusion des listes de valeurs et propagation des modifications d’identifiant

2.4.1 Diffusion des listes de valeurs

Les listes de valeurs doivent être à la disposition de l’ensemble des composants logiciels et en

particulier des composants de front office qui doivent présenter ces listes de valeurs aux

utilisateurs dans des listes de sélection, et des composants traitant des intégrations entre demi-

flux et qui doivent réaliser les transcodages.

La diffusion des ces listes doit pouvoir se faire en fonctionnement 24h/24h / 7j/7j et en temps

réel. Il est donc préférable de s’appuyer une solution technique qui assure cette diffusion au fil

de l’eau.

2.4.2 Propagation des modifications d’identifiant

Il est nécessaire que l’ensemble des composants qui référencent l’objet dont l’identification a

été modifiée soient informés de cette modification, y compris s’il s’agit de composants

externes au Système Informatique (B to B, B to C).

Il faut donc prévoir :

Un mécanisme de propagation au fil de l’eau de type abonnement / consommateur qui

assure la propagation sans perte de l’événement et s’assure de la consommation de

l’événement.

Un mécanisme qui retourne l’information sur le changement d’identification lorsque

l’objet est invoqué dans un service via son identifiant périmé.

2.5 Travaux d’amélioration de la qualité des données

La synergie et la cohérence des travaux d’amélioration de la qualité des données doivent être

assurées par l’équipe de gouvernance des données.

2.5.1 Audit de l’état des données

La définition de la criticité des données doit être menée par les équipes métiers qui

supervisent les processus.

La criticité des données permet de prioriser les audits à réaliser sur les données.

L’audit de la qualité des données doit être mené sur l’ensemble des applications qui possèdent

ces données en vérifiant le respect des règles d’intégrité édictées dans le modèle d’entreprise,

administré par l’équipe de gouvernance des données.

Les raisons de la « non qualité » des données critiques doivent être recensées.



2.5.2 Amélioration de l’état des données

La gouvernance des données décident avec les responsables métiers des actions correctrices à

mettre en place :

Corrections automatiques par des programmes ;

Achat de référentiel de données qui peuvent aider à la correction des données

(référentiels postaux, … ) ;

Corrections semi-automatiques, voir manuelles en mettant en place l’organisation et

les workflows qui permettent l’exécution des processus correctifs nécessitant des

interventions humaines ;

2.5.3 Amélioration des processus de valorisation des données

Lorsque l’état des données est du à la qualité insuffisante d’un processus en place, la

gouvernance des données et les équipes métiers doivent rechercher les solutions

d’amélioration du processus afin que les données critiques qu’il alimente respectent les

contraintes d’intégrité énoncées dans le modèle d’entreprise.

Les solutions ne sont pas toujours automatisables. Par exemple, un partenaire ayant peu de

moyens communique ses données avec une qualité en dessous des exigences nécessaires. Il se

peut que la seule solution soit de mettre en place un workflow de contrôle et correction des

données envoyées avant qu’elles soient injectées dans le Système d’information.

2.5.4 Surveillance de la qualité des données

Des indicateurs doivent être mis en place afin de surveiller la qualité des données les plus

critiques. Dès qu’une donnée critique est valorisée sans respecter les contraintes de qualité

attendues, une alerte doit être levée auprès d’une part du superviseur du processus qui a

constitué la donnée, d’autre part auprès de la gouvernance des données.

Si des actions correctrices sont déjà cataloguées, alors elles doivent être exécutées.

Si ce n’est pas le cas, une action correctrice doit être menée par le maître des données.

L’équipe de gouvernance des données doit s’assurer que les actions nécessaires ont été

menées à bien et que l’anomalie a bien été corrigée.



3 Synthèse des uses case liés à la mise en œuvre de la gouvernance des données

La mise en place d’une gouvernance des données commence par la mise en place d’un modèle

d’entreprise. Il s’agit d’un ensemble d’activités dont l’objectif est l’initialisation et

l’industrialisation du modèle d’entreprise :

Mise en place d'un modèle conceptuel métier commun initial

Industrialisation des processus de production utilisant le modèle d’entreprise

Une fois la mise en place terminée, le modèle d’entreprise devient l’élément sur lequel

s’appuie l’ensemble des réalisations de logiciels : use case « Réalisation des logiciels du

Système Informatique en conformité avec le modèle d’entreprise ».

En parallèle aux activités de mise en place et de maintenance du modèle d’entreprise, il faut

assurer les activités liées à la gestion de contenu :

Gestion de contenu : Gestion des listes de valeurs

Gestion de contenu : Gestion des identifiants



3.1 Mise en place d'un modèle d’entreprise initial



Les premières activités permettent de définir sur quoi s’appuiera le modèle d’entreprise. Pour

cela il faut :

Recenser les métiers de l’entreprise

En déduire les domaines fonctionnels du Système d’Information (Tiers, souscription,

instruments financiers, …)

Définir les normes et standards que devra respecter le modèle d’entreprise (adresses

respectant la norme UPU, …)

Rédiger un cahier des charges définissant précisément les attendus du modèle

d’entreprise idéal.

Il faut ensuite rechercher soit en interne soit sur le marché le ou les modèles à

acquérir.

Une fois ce choix réalisé il faut fabriquer la première version du modèle d’entreprise:

union et homogénéisation des modèles choisis, nettoyage des éléments de ces modèles

qui ne sont pas dans le sujet ciblé du Système d’Information.

Pour terminer cette initialisation, il faut définir pour chaque type d’objet métier sa

stratégie d’identification et l’injecter dans le modèle.



3.2 Industrialisation des processus de production utilisant le modèle d’entreprise

IL faut, en complément à l’initialisation d’une première version du modèle d’entreprise,

entreprendre le choix et la mise en place d’outils permettant son industrialisation :

Choix et mise en place d’un modeleur UML,

Choix et mise en place d’outils de passage du modèle d’entreprise au modèle

applicatif,

Choix et mise en place d’un outil permettant de gérer des versions de modèles,

Définir et déployer un processus permettant de gérer et tracer les demandes

d’évolution du modèle d’entreprise ainsi que leurs réalisations,

De plus, à chaque fois qu’une évolution réalisée sur le modèle d’entreprise peut avoir

un impact sur les projets qui utilisent les éléments modifiés, il faut pouvoir avertir ces

projets et planifier avec eux les évolutions nécessaires. Il faut donc avoir un outil

permettant de gérer finement les impacts des évolutions du modèle (connaissance pour

chaque élément du modèle des projets qui les référencent).



3.3 Réalisation des logiciels du Système Informatique en conformité avec le modèle d’entreprise

Au fur et à mesure de la réalisation des composants du Système Informatique, le modèle

d’entreprise évolue.

Les projets demandent des évolutions qui sont réalisées par les équipes de gouvernance des

données puis livrées aux équipes projets.

Les projets utilisent le modèle d’entreprise pour réaliser leurs modèles applicatifs et le lien

entre les composants développés par les projets et le modèle d’entreprise est réalisé en

générant les éléments du code qui le rendent conforme au modèle d’entreprise.

En parallèle, au fur et à mesure des évolutions réalisées, le dictionnaire sémantique commun

du Système d’Information doit être régénéré afin de rester complet et cohérent avec le modèle

d’entreprise.



3.4 Gestion de contenu : Gestion des listes de valeurs

Les listes de valeurs sont administrées par des outils spécifiques. Toutefois, le modèle

d’entreprise définit les types de données dont les instances doivent être administrées par ce

type d’outil.

Cette liste doit donc être maintenue cohérente entre le modèle d’entreprise et l’outil

d’administration.

Par ailleurs, il sera certainement nécessaire d’assurer des transcodifications entre les nouvelles

listes de valeurs et celles qui étaient utilisées sur des applications préalablement existantes.

Ces transcodifications doivent également être administrées.



3.5 Gestion de contenu : Gestion des identifiants

A chaque fois qu’un nouvel objet est créé il doit être identifiable. Son identification lui est

attribuée sous le contrôle du système maître de ce type de données.

Afin d’éviter la création de doublons, il est nécessaire que le système maître fournisse un

service permettant de connaître les objets métier ressemblants en prenant en compte les

informations saisies par l’utilisateur dans le processus de création.

Il peut arriver, pour raisons techniques ou fonctionnelles (suppression d’un doublon), qu’un

objet métier change d’identifiant ; il faut alors prévenir l’ensemble des composants logiciels

qui référencent cet objet métier.



3.6 Gestion de contenu : Amélioration initiale de la qualité des données

Les processus sont audités afin de déterminer la criticité des données

Les données les plus critiques sont auditées.

Si leur qualité est problématique, des actions correctives sont mises en place en fonction de

l’origine du problème :

Correction des processus d’alimentation des données

Mise en place de processus correctifs complémentaires lorsque les processus

d’alimentation des données ne peuvent pas être suffisamment améliorés

Correction effective des données erronées



3.7 Gestion de contenu : Surveillance de la qualité des données

La qualité des données critiques est mise sous surveillance. Lorsqu’une donnée

critique ne respecte pas les critères qualité exigés, une alerte est émise.

Une tache de correction de la donnée est alors déclenchée.



4 Conclusion

L’acte de mise en place d’une gouvernance des données dans le Système d’Information d’une

entreprise est un acte fort, comparable à la mise en place d’un plan assurance qualité.

Il concerne toutes les phases du cycle de vie du Système d’Information et tous les acteurs du

Système d’Information.

Il impacte le processus d’évolution du Système d’Information mais également l’organisation

des acteurs et des circuits décisionnels du Système d’Information.

Une cellule de gouvernance des données doit être mise en place. Son pouvoir doit être

similaire à celui de la cellule assurance qualité.

Sa mise en place nécessite une forte volonté émanant de la direction de l’entreprise. Cette

volonté doit être clairement communiquée à l’emble des acteurs du Système d’Information.

Sa réussite passe par la mise en place d’un outillage complet comprenant :

Un support de modélisation pour définir et faire évoluer le modèle d’entreprise.

L’outil doit savoir gérer les différentes versions du modèle.

Un outillage de réalisation et maintenance des modèles applicatifs projets par

extraction du modèle d’entreprise. Cet outil doit savoir gérer les versions du modèle

applicatif projet, conserver les liens de cohérence entre les modèles projets applicatifs

et le modèle d’entreprise.

Un outillage d’extraction du dictionnaire sémantique commun à partir du modèle

d’entreprise.

Des outils de communication permettant de propager la connaissance contenue dans le

dictionnaire sémantique commun et dans le modèle d’entreprise

Un outillage d’administration des données de référence fortement lié au modèle

d’entreprise

Un modèle d’entreprise initial traitant des principaux sujets fonctionnels métiers du

Système d’Information. L’existence préalable d’un modèle initial le plus complet

possible et d’un haut niveau de qualité permet d’augmenter l’agilité du Système

d’Information.

L’ajout du MDA en complément à un processus de gouvernance des données, complète

l’intérêt d’une telle approche en minimisant les coûts de contrôle et en augmentant la

productivité et l’agilité des développements.

Tout cela doit être complété par un cursus de formation portant sur le langage de modélisation

utilisé, le contenu du modèle d’entreprise, les outils utilisés et les processus organisationnels

liés à la gouvernance des données.



5 Glossaire

Terme Définition

acteurs du Système d’Information

Ensemble des personnes ou systèmes intervenant soit dans le développement du Système Informatique et de ses évolutions, soit dans le fonctionnement quotidien du Système d’Information.

acteurs métier Ensemble des personnes qui utilisent le Système d’Information pour réaliser leur métier.

agilité intégrative fonctionnelle du Système Informatique

Les phases d'intégration dans la construction d'un système sont souvent les plus lourdes et les plus délicates. L'utilisation d'un modèle d’entreprise facilite l'intégration fonctionnelle entre les composants du Système Informatique. Elle permet ainsi de raccourcir le cycle entre deux itérations du système d'information et facilite l'ajout de nouvelles fonctionnalités. D'où la terminologie: agilité intégrative du Système Informatique.

approche MDA

MDA (pour l'Anglais Model Driven Architecture) est une démarche de réalisation de logiciel, proposée et soutenue par l'OMG. C'est une variante particulière de l'ingénierie dirigée par les modèles (IDM, ou MDE pour l'Anglais Model Driven Engineering).

Cellule MOA

Ensembles de personnes responsables devant la direction MOA de la gouvernance des données. Elle intervient dans l’harmonisation de la sémantique utilisée dans les cahiers des charges, les plans de tests, les cahiers de recettes et dans les notices d’utilisation des outils informatiques.

Cellule MOE

Ensembles de personnes responsables devant la direction MOE de la gouvernance des données. Elle intervient dans l’harmonisation de la sémantique utilisée dans les documents de spécification, d’architecture fonctionnelle, dans les documents de conception, dans la désignation des objets et caractéristiques métiers dans le code et dans les plans de tests.

chaîne de production Ensemble d'actions plus ou moins outillées à réaliser pour produire un composant exécutable du SI utilisable en production par les utilisateurs

coefficient de ressemblance

Entre deux ensembles de données, il existe une possibilité que ces deux ensembles de données représentent le même objet réel. Plus les données se ressemblent, plus la probabilité que cet événement soit vrai augmente. Le coefficient de ressemblance indique la probabilité que cet événement soit vrai.

Compatibilité ascendante

Indique qu'il est possible de déployer une nouvelle version d'un composant ou d'un outil sans impacter ceux qui utilisaient la version précédente.

couches de généricité

Ensembles d'éléments conçus pour être utilisés dans un nombre important de cas y compris dans des nouveaux cas non encore spécifiés. L'utilisation de couche générique ne signifie pas qu'il n'y a aucun travail à effectuer pour définir des cas de fonctionnement concrets. Par contre ces travaux sont facilités par cette couche de généricité.

cycle de vie des projets

Succession de phases ayant un objectif précis permettant d'amener un projet informatique en production

déduction d’un modèle logique de base de données

Dans le cadre d'une approche MDA, le modèle logique de la base de donnée est déduit du modèle d’entreprise qui lui est indépendant de la plateforme cible.

demi-flux

Dans la mise en place d'un échange de flux via une plateforme d'échange, le raisonnement par demi-flux permet de limiter le nombre de formats d'échange à traiter. Le demi-flux représente le flux échangé entre la plate-forme d'échange et un système émetteur ou récepteur. Ce demi-flux se définit sans connaître le système opposé récepteur ou émetteur du flux.



dépréciation

Lorsque dans une interface ou dans un système, une donnée déjà utilisée devient caduque, il y a alors rupture de la compatibilité ascendante. Pour éviter un impact bloquant sur les composants du Système Informatique qui utilisent cette donnée, celle-ci est maintenue dans l'interface ou dans le système pendant un temps limité. Son statut de donnée caduque est marqué par sa qualification de donnée dépréciée. Le même principe s'applique à des services.

dictionnaire sémantique commun du Système d’Information

Ensemble des termes métier utilisés pour décrire les objets manipulés par les acteurs métiers. La base d'une activité de gouvernance des données est de faire en sorte que ces termes soient partagés par tous les acteurs du Système d’Information

données de référence transverses

Ensemble des valeurs que peuvent prendre certaines informations du Système d’Information. Lorsque les valeurs possibles d'une information sont limitées et partagées par l'ensemble des acteurs du Système d’Information, celles-ci doivent être gérées et administrées en commun.

doublons

Objet métier réel, représenté involontairement (en dehors de contraintes techniques connues) par plusieurs instances dans le Système d’Information sous des identifiants différents. Les doublons sont des risques majeurs de disfonctionnement des processus d'entreprise et doivent donc être éradiqués des Systèmes d’Information. La gouvernance des données se doit de piloter l’éradication des doublons.

effet tunnel

Nom donné à un ensemble de tâches réalisées sur un projet et qui ne permettent pas aux commanditaires du projet d'en avoir une vision rassurante tant du point de vue complétude des tâches que du point de vue adéquation des décisions avec l'objectif final.

Équipe gouvernance des données

Ensemble des personnes qui assurent les activités de gouvernance des données

évolutions de la sémantique commune

Un Système d’Information n'est jamais terminé. Les métiers de l'entreprise se modernisent, s'élargissent, … . Le dictionnaire sémantique commun est donc amené à évoluer. Toutefois, pour éviter que ces évolutions soient anarchiques, des procédures doivent être mises en place. Ces procédures doivent permettre à l'équipe de gouvernance des données d'assurer les évolutions en cohérence avec le dictionnaire sémantique existant.

évolutions modèles entreprise

Un Système d’Information n'est jamais terminé. Les métiers de l'entreprise se modernisent, s'élargissent, … . Le modèle d’entreprise est donc amené à évoluer. Toutefois, pour éviter que ces évolutions soient anarchiques des procédures doivent être mises en place. Ces procédures doivent permettre à l'équipe de gouvernance des données d'assurer les évolutions en cohérence avec l'existant.

générateurs Outil permettant d'extraire d'un modèle du code qui servira de base au développement des éléments physiques du Système Informatique.

gestion de configuration du Système Informatique.

Gestion des versions de tous les éléments participant au développement du Système Informatique ainsi que de leurs dépendances. Parmi ces éléments se trouvent, les modèles, les générateurs, les codes des logiciels, les cas de tests, les outils de développement et de tests, les frameworks, ... .

gouvernance des données

La gouvernance des données regroupe l’ensemble des activités qui permettent d’obtenir une synergie des acteurs autour des données de l’entreprise. Elle définit un vocabulaire sémantique commun ainsi que les données de références de l’entreprise. Elle les divulgue, les contrôle et les administre.

identification des objets métiers

Chaque objet métier doit pouvoir être nommé de façon unique dans le Système d’Information. Cette dénomination doit être commune pour tous les acteurs du Système d’Information. Cette dénomination est appelée "identification". C'est un élément essentiel de la gouvernance des données.

interface des applications

Ensemble de services offerts par une application à ses utilisateurs (autres applications ou composants). Un service se définit par son nom, ses paramètres d'entrée / sortie et la spécification du service rendu (contrat de service).

Lexique de référence Ensemble de mots constituants le vocabulaire sémantique à utiliser dans



tous les documents relatant des sujets liés au fonctionnel.

liste de valeurs non programmatique

Liste de valeurs stables non utilisées dans des algorithmes programmatiques ==> La liste des valeurs peut évoluer sans devoir faire évoluer les logiciels.

liste de valeurs programmatique

Liste de valeurs figées pouvant être utilisées dans des algorithmes programmatiques.

Mapping

Action consistant à faire correspondre des éléments d'un modèle avec ceux d'un autre modèle. Le mapping est utilisé pour construire le modèle d'un composant logiciel ou d'un flux à partir du modèle d’entreprise,, en gardant la trace des correspondances entre les éléments des deux modèles.

modèle d’entreprise

Modèle conceptuel partagé par l'ensemble des acteurs du Système d’Information. Ce modèle ne doit représenter que la sémantique métier du Système d’Information. Il sera ensuite décliné en différents modèles propres à chaque composant ou flux du Système Informatique. Ceux-ci prendront en considération des éléments propres à leurs environnements cibles. Il est également appelé modèle d’entreprise.

modèles projets applicatifs

modèles spécifiques à un composant ou à un flux du Système Informatique. Ce modèle est conçu en s'appuyant sur le modèle d’entreprise

pan du Système d’Information

Ensemble, d’applications très connectées du Système d’Information, d’acteurs de la DSI en charge de ces applications et des utilisateurs de ces applications. Les systèmes ont souvent été construits verticalement pour répondre à la mise en place d'un métier avec un back-office, un middle-office et un front office consacrés à un métier. De ce fait l'intégration entre ces systèmes n'est pas innée et nécessite des efforts qui peuvent être très importants. Les nouveaux systèmes essaient au moins au niveau des front-office de rompre cette verticalité afin de flexibiliser les organisations, de faciliter l'intégration entre les métiers de l'entreprise et d'améliorer la qualité de l'information permettant de piloter l'entreprise.

patterns d’analyse

Formes (structures ou motifs) de modélisation appliquées systématiquement pour résoudre les mêmes problèmes de modélisation. L'utilisation de patterns d'analyse assure une homogénéité du modèle d’entreprise et une qualité dans sa structuration lui garantissant une forte capacité d'évolutivité.

propagation de l’information de substitution d’un objet

Pour des raisons techniques ou fonctionnelles (par exemple la suppression d'un doublon), il peut arriver qu'un objet change d'identifiant. Cet objet est référencé sur l'ensemble du système par l'ancien identifiant. La modification de l'identifiant doit donc être propagée à l'ensemble des éléments du système qui référencent cet objet. Les solutions techniques mises en place doivent assurer pendant une certaine période le référencement de l'objet par les deux identifiants (l'ancien et le nouveau).

refactoring Opération de maintenance d'un modèle ou d'un code informatique. Elle consiste à retravailler le modèle ou le code afin d'y insérer de nouvelles fonctionnalités ou d'améliorer ou corriger les fonctionnalités existantes.

roadmap d’évolution du Système d’Information

Grandes étapes datées des livraisons des évolutions du Système d’Information

SI Système d'information d'une entreprise. Regroupe l'ensemble des activités et fonctions manuelles ou automatiques qui permettent de produire et faire évoluer l'information manipulée dans les métiers de l'entreprise.

sujet du flux

Dans un système d'information bien architecturé, les échanges d'information entre les composants sont structurés par sujet. Un sujet représente un type d'objet du Système d’Information y compris les informations qui le complètent. Il est fortement déconseillé d'échanger dans un même flux des informations portant sur des sujets différents, les cycles de vie des objets sous-jacents à chaque sujet pouvant être différents et du coup engendrer une multiplication couteuse des échanges.



système maître

Le système maître d'un type de donnée est le système qui sert de référence pour les objets de ce type. Au minimum, il doit fournir les services suivants: - il assure l'identification des objets de ce type (il attribue les identifiants aux nouveaux objets créés) - il est responsable de fournir l'image valide la plus récente de ces objets - il doit contrôler les évolutions effectuées sur ces objets afin d'éviter leur corruption (non respect de règles d'intégrité).

terminologie commune Ensemble de termes dont la définition est partagée par tout le monde.

UML

UML (en anglais Unified Modeling Language, « langage de modélisation unifié ») est un langage graphique de modélisation des données et des traitements. C'est une formalisation très aboutie et non-propriétaire de la modélisation objet utilisée en génie logiciel. Sa définition et ses évolutions se font sous l'égide de l'OMG.

Prima IBCS est un produit de la société Prima-Solutions. C’est un modèle d’assurance orienté-objet: il couvre les principaux domaines fonctionnels de l’assurance (vie, dommages, réassurance, en individuel et collectif). Il est employé par des douzaines de clients comme base pour des projets allant de la souscription de contrats à la gestion des sinistres. Prima IBCS™ a été adopté par ACORD comme base de construction du modèle d’information ACORD.

Prima IBCS Tooling: ensemble d’outils qui facilitent les activités de gouvernance des données.

Des outils de productivité permettant de créer facilement des modèles projet à partir du modèle de référence. Ces outils garantissent la traçabilité entre les modèles et préservent l’intégrité et la cohérence des modèles à travers les cycles d’itération.

Un outil de génération de code automatisant la création de composants techniques en vue de l’implémentation des projets.

Prima Solutions : Editeur de solutions logiciel pour le secteur de l’assurance.

Voir :http://www.prima-solutions.com.

MagicDraw : Modeleur UML édité par l’entreprise « No Magic ». voir : http://www.nomagic.com.

http://www.prima-solutions.com/

http://www.nomagic.com/

Documents

Gouvernance des données Livre blanc - DoYouBuzz : …€¦ · 2.2 Avec la gouvernance des données, l’intégration fonctionnelle du SI gagne en agilité 37 ... composée d’une