Imp Soa 1
Imp Soa 1
Imp Soa 1
LIVRE BLANC
A PROPOS DE L’AUTEUR
Cyrille Devaux,
Directeur chez Aubay Management
Titulaire d’un DESS en Intelligence artificielle, reconnaissance des formes et robotique, et d’un Executive MBA (HEC),
Cyrille Devaux est le plus globe-trotter des experts en technologies et systèmes d’information Aubay.
Après une adolescence passée à Abidjan (Côte d’Ivoire), Cyrille Devaux fait ses études supérieures à l’Université Paul
Sabatier de Toulouse et part ensuite effectuer son service militaire civil pendant 2 ans à l’Ecole Nationale des Sciences
de l’Informatique à Tunis (Tunisie).
Cyrille Devaux débute sa carrière en 1992 au Centre de Maquettage des Systèmes d’Information et de Communication
de la DGA (Délégation Générale pour l’Armement) pour le compte de Cap Gemini. En 1995, il rejoint Marben et part en
mission chez TELMEX au Mexique. De retour en France, il occupe successivement les fonctions de consultant ou chef
de projet chez EDF, Bouygues, Neuf Telecom, AXA ou encore IBM.
C’est chez Marben, devenu Sligos puis Atos, qu’il rencontre Christian Aubert (plus tard, fondateur du Groupe Aubay),
Christophe Andrieux (Directeur Général Délégué de Aubay France) et François Hisquin. En 1998, en collaboration avec
ce dernier, et fort de son expérience dans le conseil et le service client, dans les secteurs aussi divers que l’industrie, la
défense, les télécoms, la banque et l’assurance, il crée OCTO Technology, cabinet spécialisée dans l’architecture de
systèmes d’information.
En 1999, il part ouvrir et diriger l’agence espagnole d’OCTO à Madrid jusqu’au rachat du cabinet par le Groupe Aubay,
qu’il rejoint en 2002, en qualité de Directeur Technique.
A 42 ans, Cyrille Devaux occupe le poste de Directeur au sein de Aubay Management, département spécialisé dans le
conseil.
Aubay est une société de conseil en technologies et intégration de systèmes d’informations, réseaux et télécoms
fondée en 1997. La société dispose de plus de 2000 collaborateurs répartis dans 6 pays (France, Belgique,
Luxembourg, Italie, Espagne et Portugal). En 2007, Aubay a réalisé un chiffre d’affaires de 155,3 millions d’euros et
une marge opérationnelle de 9,5%.
Les informations contenues dans ce document représentent le point de vue actuel de Aubay sur les sujets exposés, à la date de publication. Dans la mesure où les éditeurs cités doivent s’adapter aux conditions
changeantes du marché, Aubay ne peut pas garantir l’exactitude des informations présentées après la date de publication.
Les noms de produits ou de sociétés dans ce document peuvent être les marques déposées de leurs propriétaires respectifs.
1 INTRODUCTION ........................................................................................................................................................5
2 URBANISATION & SOA, LE COUPLE GAGNANT POUR UN SI AGILE ................................................................6
2.1 Urbanisation du SI ...............................................................................................................................................6
2.2 Principes directeurs de l’urbanisation ..................................................................................................................8
2.3 Règles d’or de l’urbanisation ...............................................................................................................................8
3 LA DEMARCHE SOA .............................................................................................................................................. 12
3.1 Concept de service............................................................................................................................................ 12
3.2 Fiche signalétique d’un service ......................................................................................................................... 14
3.3 Contrat de service ............................................................................................................................................. 14
3.4 Un exemple de modèle SOA ............................................................................................................................. 15
3.5 Typologie de services........................................................................................................................................ 16
3.5.1 Service Applicatif (ou Use Case)................................................................................................................ 16
3.5.2 Service Fonctionnel.................................................................................................................................... 17
3.5.3 Service Entité (ou Service C.R.U.D.).......................................................................................................... 17
3.5.4 Service Transverse (ou d’Infrastructure) .................................................................................................... 18
3.5.5 Service Host ............................................................................................................................................... 18
3.6 Identification des services ................................................................................................................................. 18
3.7 Référentiel des services .................................................................................................................................... 21
4 BONNES PRATIQUES ............................................................................................................................................ 24
4.1 Gestion des versions et variantes ..................................................................................................................... 24
4.2 Gestion des libellés ........................................................................................................................................... 25
4.3 Gestion des transactions ................................................................................................................................... 27
4.4 Gestion des données de références.................................................................................................................. 28
4.4.1 Définition d’un référentiel............................................................................................................................ 29
4.4.2 Principaux types de référentiel ................................................................................................................... 30
4.4.3 Métadonnées d’un référentiel ..................................................................................................................... 30
4.4.4 Services d’accès aux référentiels............................................................................................................... 31
4.5 Gestion des valorisations par défaut ................................................................................................................. 34
4.6 Gestion des exceptions ..................................................................................................................................... 35
4.7 Gestion de la sécurité........................................................................................................................................ 36
4.8 Utilisation d’un bus de service ........................................................................................................................... 38
4.9 Préconisations d’organisation............................................................................................................................ 40
5 CONCLUSION ......................................................................................................................................................... 41
6 REFERENCES ......................................................................................................................................................... 43
7 GLOSSAIRE ............................................................................................................................................................ 44
La capacité d’une entreprise à faire évoluer son système d’information pour faire face aux changements qu’elle rencontrera
(fusion, acquisition ou cession d’activités...) constitue une des clefs de sa compétitivité.
Contribuant à cette capacité d’alignement du Système d’Information avec les métiers de l’entreprise, l’urbanisation utilise la
cartographie comme principal outil support de son activité. Elle permet d’une part de réaliser l’inventaire du patrimoine de
l’entreprise et, d’autre part, de mesurer les analyses d’impact du système cible, et ceci sur les plans métier, fonctionnel,
technique, voire organisationnel.
Par ailleurs, l'évolution récente des technologies de l'information et le développement rapide des services sur le Web ont
impulsé de nouvelles approches qui permettent de mettre en place des architectures d’entreprise plus souples, plus
évolutives, et plus aptes à satisfaire les besoins d'agilité de l'entreprise.
Dans ce contexte, les objectifs des départements « Architecture – Urbanisation - Méthode » de la plupart des grandes
entreprises visent aujourd’hui à rationaliser et rendre plus modulaire leur patrimoine applicatif pour gagner en flexibilité et
1
répondre plus rapidement aux sollicitations des Métiers ou de la réglementation en vigueur .
Le présent ouvrage s’inscrit dans cette démarche de progrès puisqu’il propose d’identifier et de formaliser quelques règles
d’urbanisme et il exposera un certain nombre de bonnes pratiques d’une démarche d’Architecture Orientée Service (SOA).
Il est le fruit de l’expérience des consultants Aubay qui interviennent régulièrement sur des missions de conseil en stratégie
2.
technologique pour le compte de nos grands clients
1
SOX, Bale II, LOLF…
2
AGF, Société Générale, GMF…
Répondre à ces questions revient en fait à définir certaines règles d’urbanisation du SI et à clarifier les principes
architecturaux pour le développement des nouvelles applications.
Le métier d'architecte technique (ou de système informatique) existe depuis longtemps. Celui d'urbaniste, parfois
nommé architecte d’entreprise (ou de système d’information), est en revanche beaucoup plus récent. Urbaniste et
architecte sont aujourd'hui deux métiers complémentaires dont les rôles sont fondamentaux dans la conception,
l'implantation et l’évolution de systèmes durables. Ensembles, l’architecte et l’urbaniste disposent d’une vision globale à
la fois des processus, des informations et de leurs interdépendances.
A ces deux fonctions, il convient d’ajouter celle d'administrateur de référentiel de données dont l’objet est d'assurer une
définition précise des règles de gestion et un propriétaire unique (dans le sens objet du principe) à chaque information
manipulée par l’organisation. Voir à ce sujet le chapitre 4.4 de ce document.
2.1 Urbanisation du SI
Urbanisation du SI : Action de structurer de façon cohérente et modulaire le SI en définissant les niveaux de
représentation, en répartissant les éléments et les responsabilités qui y sont liées par niveaux, et en définissant les
règles communes ou spécifiques.
la désimbrication des systèmes, des différents métiers puis des différentes activités de façon à éviter
l’enchevêtrement des applications informatiques correspondantes. Ce découplage a pour contrepartie la mise en
3
place de référentiels communs .
4
la recherche du juste équilibre entre subsidiarité et mutualisation, la difficulté de cet exercice est de placer la
responsabilité du système au plus près du terrain pour rendre l’entreprise plus réactive tout en réalisant des
économies d’échelle et en garantissant la cohérence de l’ensemble.
La cartographie du SI
La cartographie considère en général quatre visions du système d'information :
• la vision métier qui décrit les processus ou activités que le SI doit supporter,
• la vision fonctionnelle qui décrit les fonctions du SI permettant de représenter les processus,
• la vision applicative décrivant l'ensemble des éléments applicatifs du SI,
• la vision technique décrivant l'architecture technique (matériels, logiciels et technologies utilisés).
Cartographie métier
Les systèmes d’information doivent être cartographiés du point de vue métier :
• Les objets manipulés sont des processus, acteurs, rôle, objets métiers
• L’exploitation des cartographies métiers se fait au travers :
o des études d'impacts (par exemple, lors d’une fusion d’activité ou lors de l’éclatement d'activités)
o des études d’optimisation des processus (par l’analyse des points sensibles des processus).
Cette vue définit par conséquent des domaines et les processus métiers qui relient ces domaines par des flots de
données. Ces informations doivent être transposables d’une entreprise à une autre.
Cartographie fonctionnelle
Les systèmes d’information doivent être cartographiés du point de vue fonctionnel :
• Les objets manipulés sont des domaines d’activité, des domaines de responsabilité,
• Le découpage doit s’effectuer autour d’invariants métiers (objets métiers, fonctions …),
• Les échanges doivent être identifiés entre domaines fonctionnels,
• Des référentiels communs doivent être identifiés autour des objets ou données métiers.
Cette vue représente la mise en œuvre particulière du métier dans l’entreprise mais doit restée découplée des solutions
techniques de mise en œuvre informatique.
Cartographie applicative
Les systèmes informatiques doivent être cartographiés du point de vue applicatif (ou logiciel) :
• Les objets manipulés sont des applications, des composants logiciels, des bases de données…
• On y identifie les modes de communication entre composants (synchrone/asynchrone, MOM/fichier/DB/http,...),
• On y précise les outils communs (ex : modules communs de gestion des logs, des traces, des statistiques…)
• On précise les standards techniques (choix) et les règles de gestion concernant les plateformes logicielles (ex :
distinguer l’environnement de développement de celui de production).
La vue applicative est la partie automatisée du SI. Elle va décrire les solutions technologiques retenues pour réaliser
certaines fonctionnalités du SI
Cartographie technique
Les systèmes d’information doivent être cartographiés du point de vue technique (ou matériel) :
• Les objets manipulés sont du matériel (serveurs…), du câblage, des bâtiments, etc.…
• On y précise les règles de gestion des plates-formes (i.e. une seule plate-forme pour N applications ou N plates-
formes pour une application ; plate-forme 24x7…)
• On précise les règles de dimensionnement des tuyaux, les contraintes d’exploitation, de sécurité.
3
Un chapitre entier sera consacré à ce point majeur d’une architecture d’Entreprise.
4
Subsidiarité : Le principe de subsidiarité est une maxime politique selon laquelle la responsabilité d'une action publique doit être allouée à la plus petite entité
capable de résoudre le problème d'elle-même. C'est donc le souci de veiller à ne pas faire à un niveau élevé ce qui peut l'être avec autant d'efficacité à une
échelle plus faible.
Encapsulation
Le bloc est seul propriétaire de ses données et de ses traitements.
Ses données sont masquées pour les autres blocs, un bloc ne peut donc accéder aux données d'un autre bloc qu'en
faisant appel aux services que propose celui-ci.
Mutualisation
Partager les éléments du SI qui peuvent être utilisés par plusieurs blocs :
- Par la mise en œuvre de référentiels d’objets,
- Par le déploiement d’une infrastructure d’échange (EAI ou ESB),
- Par la mise en œuvre progressive d’une approche orientée « service » (SOA).
Echanges contrôlés
A la frontière de chaque bloc, les échanges avec l'extérieur se font au moyen d'interfaces publiques et éventuellement
par l'intermédiaire d'une infrastructure fédératrice (annuaire).
Chaque bloc produit des résultats et des rapports avec un format standard sans présumer des destinataires.
Chaque interface est gérée par version pour prendre en compte le cycle de vie des blocs et de l’infrastructure de
communication.
5
On distribue ainsi les systèmes applicatifs dans les zones :
de présentation/acquisition (couche de front office ou commerciaux),
de traitements métiers (couche de back office ou de gestion),
d'échange et diffusion (couche middleware),
de gestion des référentiels,
de fonctions support à l’entreprise (SI Financier, SI Ressources Humaines), de pilotage et de reporting.
Par exemple, un système ne devrait pas cumuler des préoccupations commerciales (simulations de devis, règles de gestion
simplifiées) et des préoccupations administratives (caractéristiques contractuelles des contrats, règles de gestion
rigoureuses). Autre exemple, une application ne doit pas gérer à la fois des contrats et assurer la production de statistiques
d'aide à la décision (qui est la vocation d'un système de pilotage).
Gains attendus
Eviter la redondance fonctionnelle
Meilleure évolutivité du Système d’Information (limitation de l'imbrication des traitements)
Pilotage plus simple de l’évolution du système d’information par une vision d’ensemble urbanisée permettant
d’appréhender plus rapidement l’impact d’une évolution fonctionnelle ou technologique, de localiser les zones de
progrès, par exemple, grâce à des métriques calculées à partir de la cartographie.
Gains attendus
Réduction de la diversité du patrimoine applicatif
Réduction des coûts
5
On définit un SA comme étant le regroupement de fonctions métiers au sein d’une même entité informatique
Une bonne gestion des flux est particulièrement importante pour la cohérence du SI et elle doit respecter un certain nombre
de principes :
Tous les flux doivent être identifiés (donc inscrits dans la cartographie),
Tout flux doit être préférentiellement basé sur un échange asynchrone de type Message,
Tout SA échange avec l’extérieur via une couche d’abstraction normalisée et documenté,
Tous les flux doivent être gérés par un unique outil central (type bus de communication inter-applicatifs).
Gains attendus
Fiabilité et cohérence des échanges de données,
Pilotage et traçabilité des événements,
Analyse statistiques des flux,
Sécurisation de la mise en production des nouvelles versions d’échanges,
Un référentiel ne contient que des informations de référence. Une information de référence est principalement caractérisée
par son partage entre plusieurs systèmes applicatifs et par un fort accès consultatif. Un référentiel peut aussi concerner les
données communes de nomenclature (paramètres applicatifs).
Pour chaque référentiel, il est nécessaire de bien identifier sa localisation et de développer une architecture d'échange
(normalisée et indépendante) d'informations entre les applications pour permettre la circulation des informations présentes
dans les référentiels.
Gains attendus
Vision commune des informations de référence de l’entreprise, évitant ainsi aux applications toute divergence ou
désynchronisation sémantique sur une donnée,
Mutualisation des infrastructures de gestion des tables communes.
Mesure d’avancement
Une démarche d’Urbanisation est un projet de longue haleine. Il s’agit donc de bien mesurer au fur et à mesure des mois qui
passent l’avancement de cette démarche de progrès ! A cette fin, le Club Urba a formalisé un outil de suivi de l’avancement
au travers le calcul d’un indice d’avancement.
Graphiquement, il se représente ainsi :
L’architecture SOA favorise la réutilisation fonctionnelle au travers de l’approche service. Cette approche est un modèle
d'interaction applicative mettant en œuvre des composants logiciels avec une forte cohérence interne et des couplages
externes « lâches ». Elle permet en outre de contractualiser la mise à disposition des grandes fonctions métier de l’entreprise
et induit une mise à disposition homogène de ces fonctions. De plus cette approche permet d’envisager de manière uniforme
la mise en place de fonctions communes comme l’administration, l’exploitation, la sécurité, etc.
Le service est de préférence autonome, favorisant ainsi le couplage faible entre services.
Il implique de gérer un contexte d’appel transmis mais non mémorisé (service « sans état »).
Il fonctionne en toute transparence, fournissant des informations sur son exécution, ses performances…
6
La composante « Interface » est une description des Entrées / Sorties pour l’ensemble des méthodes du service (voir le
chapitre sur le contrat de service).
L’implémentation représente la réponse codée à la fourniture des fonctionnalités exposées par l’interface. Elle peut être de
diverses natures car, étant masquée aux utilisateurs du service, le choix d’une technique de mise en œuvre (technologies
Web Service ou EJB ou connexion directe JDBC…) n’a en principe pas d’impact sur son exécution (à part un impact de
performance mais qui est alors explicitement indiqué dans le contrat de service).
L’aspect Mapping est une couche technique (optionnelle) de mise en relation entre deux éléments de natures distincts (ex :
objet java coté Service & structure à plat coté host, éventuellement au travers de l’utilisation d’un outil type hibernate).
Les bouchons sont nécessaires pour les phases de tests et font partie intégrante des éléments logiciels du service.
6
On utilisera indifféremment le terme « Service » pour désigner le composant ou l’une de ses opérations.
Politique de sécurité
- Authentification du demandeur
- Gestion des droits d’accès
- Cryptage des informations
Politique de robustesse
- Présence d’un Secours, mode dégradé/différé, reprise
Politique de performance
- Réactivité du service
- Seuils d’alerte, statistiques périodiques
7
Repository de Service (WSRR chez IBM, MEGA V2007…)
8
Utile pour l’analyse d’impact d’une modification apportée sur un service.
Syntaxe :
Le Service Applicatif permet de mettre en œuvre la logique applicative d’une application telle qu’elle a été identifiée par les
cas d’utilisation ou les processus métiers. Ce service est fortement lié à la logique de l’application qui a nécessité sa
création ; en général, il n’est donc pas réutilisable, hors du contexte de l’application. Le service applicatif active des règles de
gestion qui vont conduire, dans le contexte de l’application, à la modification d’une grappe d’objets métier.
9
Au sens UML du terme.
Le Service Fonctionnel permet d’exposer des traitements métiers identifiés comme réutilisables dans des contextes variables
(ex: calcul de devis). Le service fonctionnel travaille sur des objets métiers et fait donc appel à des services Entité ou
Transverse. Dans le cas de l’exposition d’un service Host de haut niveau (et correspondant fonctionnellement à un SF), on
s’oblige à créer un SE de passage (prise en compte de la gestion du mapping…).
La Valeur Ajoutée du SF réside dans ses caractéristiques particulières (mais arbitraire car dépendant du modèle SOA que
l’on décide d’établir) :
Le SF peut faire appel à des services plus élémentaires ou externes (partenaires). C’est la notion d’orchestration.
Le SF représente la couche logicielle où seront prises en compte la gestion de la sécurité, des règles métiers
déportées (ex : calculs globaux sur des listes) ou encore des libellés (voir plus loin dans le paragraphe).
10
3.5.3 Service Entité (ou Service C.R.U.D.)
Ce type de service permet de faire la transition entre le monde des référentiels de données et le monde de l’application. Il
s’agit de transformer des données provenant d’horizons hétérogènes en objets métier utilisables par les applications mettant
10
Signifie « Create – Research – Update – Destruction » (les 4 opérations élémentaires sur un objet)
Concernant l’opération de recherche, il est intéressant de raisonner en « niveau de profondeur » sur l’objet métier retourné.
En effet, un objet métier est généralement lié à d’autres objets (« Clients » avec « contrats », « contrat » avec
« sinistres »…). Se pose alors la question de savoir quelle « grappe » d’objet voulait en pratique l’utilisateur qui demande un
objet… Veut-il simplement l’objet métier racine ou veut-il un ensemble plus large d’objets, tous reliés à l’objet racine, origine
de la requête ? Pour répondre à ces différents cas, il est d’usage de paramétrer les requêtes de recherche avec un type (ou
scénario) de recherche. Ainsi, selon le scénario précisé, la requête retournera l’objet métier seul ou un ensemble d’objet
selon une profondeur donnée sur la grappe d’objet. Bien évidemment, le programmeur du composant CRUD installera des
contrôles afin d’éviter qu’une requête mal définie tente de ramener « l’ensemble du SI »…
Un Service Transverse offre des services dont la problématique n’est pas uniquement métier. Un service transverse peut
éventuellement être client d’autres services transverses mais cette dépendance est peu souhaitable.
Exemples de Services transverses :
Service de log
Service de gestion du Contexte Utilisateur
Service de gestion des libellés…
11
Il est possible de disposer d’un serveur d’applications sur le HOST, facilitant ainsi la communication avec l’extérieur du Host.
12
On notera l’effort particulier de IBM dans la formalisation d’une méthode d’identification des services. La méthode SOMA.
SOMA : Méthode d’origine IBM, est un support méthodologique à l’alignement d’une “business architecture” et d’une
architecture orientée service par une analyse combinée “top-down” (business driven, process based) et “bottom-up”
(réutilisation des systèmes existants ou en projet).
Le “Domain decomposition” est une analyse de processus métier. Elle répond donc aux règles de l’analyse de
processus. Le souci principal est d’obtenir une analyse appropriée à la décomposition en services par l’application des
principes suivants :
• Identifier l’événement métier déclencheur.
• N’utiliser que des termes métier (sans lien avec les applications ni la technologie).
Reste à savoir à quel niveau de décomposition s’arrêter ? Suivre la “Rule of thumb 3 levels” mais d’autres critères
peuvent s’ajouter :
• Tâche unitaire.
• Issue d’un acteur unique d’une organisation unique.
• Complétude nécessaire pour aborder la tâche suivante.
• Contient au moins une interaction avec le système d’information.
• Éventuellement transactionnelle.
A la fin de cette phase, chaque tâche devient un service candidat pour ajout dans le portefeuille des services candidats.
Goal Service Modeling consiste à identifier les objectifs Métier portés par le ou les processus (ex : Améliorer une
productivité, un chiffre d’affaire, une qualité de service, la qualité d’information…). Dans cette phase, vont être
recherchés les services qui permettent d’informer de l’atteinte de ces objectifs :
• Recherche de l’existence de services cohérents avec les objectifs.
• Identifier les indicateurs clé de performance (KPI) : quelle est l’information nécessaire à un manager responsable du
processus pour valider l’atteinte des objectifs ?
• Définir les services qui vont permettre d’obtenir cette information.
La troisième étape, celle relevant des Décisions d’implémentation, ne constituent pas un processus simple. Ces
décisions reposent sur les savoirs faire de l’architecte, sur la base des éléments recueillis lors des phases précédentes.
SOMA ne propose pas de démarche particulière à ce niveau.
L’identification pertinente des services est un critère important pour la bonne qualité du SI global. Cependant, vu la grande
quantité de services possibles pour les SI des grandes entreprises, il n’est pas envisageable de créer autant de composants
(au sens du composant logiciel autonome et déployé sur un serveur) que de services qui auront été identifiés. Il s’agira donc,
dans un second temps de réflexion, de regrouper les services au sein de composants. Les services sont alors appelés
« Opérations » du composant qui par extension, peut parfois prendre le nom de service… Assez naturellement, la politique
de regroupement consistera à regrouper au sein d’un même composant les services traitant des mêmes entités (ou objets)
métiers mais il pourra éventuellement être tenu compte d’autres critères de regroupement comme les contraintes liées au
contrat de service (regroupement des opérations à fort besoin de disponibilité au sein d’un même composant versus
opérations non critiques).
Le référentiel doit également contenir la description des contrats de service, le détail des opérations (au format WSDL par
exemple), la liste des applications utilisant le service et une vision des données (sous forme de Diagramme de classe) des
objets manipulés.
Publication et découverte
• Définitions et descriptions des services
• Liens entre services et dépendances
• Définition du cycle de vie des services
• Définition des policies par service
Enrichissement
• Gestion dynamique des informations par les runtimes WPS, WMB, WESB, WAS…
• Sélection du endpoint d’un service
• Gestion de la disponibilité des services
• Gestion des policies
• Notification des changements
• Sécurité des informations transmises
Gestion
• Gère la relation entre services, les dépendances, les redondances
• Classification de services en groupes métiers
• Gestion des policies
• Gestion des changements des services
• Gestion des versions
• Analyse d’impact
Cependant, le présent document traitera plus particulièrement de celles en relation avec l’étape d’intégration car ce sont des
problématique d’architecture habituellement rencontrées quelque soit le contexte client ou environnement technique :
gestion des versions et des variantes,
gestion des libellés,
gestion des transactions,
gestion des données de références,
gestion des valeurs par défaut,
gestion des exceptions,
gestion de la sécurité,
gestion des flux et échanges,
préconisation d’organisation.
Les réponses apportées ici sont à resituer dans le modèle d’architecture exemple décrit dans le paragraphe §3.4.
Quatre scénarios d’implémentation d’une gestion normalisée des libellés ont été étudiés dans l’architecture de référence
SOA (voir figure 7). On suppose ici la mise en place d’un référentiel des libellés au sein d’une base dédiée mais
éventuellement esclave du référentiel géré sur le Host. On suppose également que le Host, garant des règles et données
métiers, ait la capacité à retourner le code du libellé et non pas le libellé lui-même.
Ces trois premières solutions ne sont pas optimales dans la mesure où le libellé et son code circule inutilement sur une
partie de la chaîne de transmission. Le libellé n’est véritablement utile en bout de chaîne.
Ce dernier scénario est le plus optimisé. Il permet de retarder la conversion du code en libellé le plus tard possible. Il est
cependant intéressant de pouvoir gérer quelques libellés par défaut (par exemple, libellé court, libellé long) dès l’origine de la
chaîne afin de ne pas obliger systématiquement l’application à demander le libellé correspondant à un code, quand le libellé
souhaité est des plus standards.
Réplication. Les libellés sont gérés dans le HOST (par définition de son rôle centralisateur et garant des référentiels),
il faut donc mettre en place un mécanisme de réplications (avec quelle fréquence ?) entre le référentiel des libellés
HOST et la base répliquée locale.
Contenu du référentiel. Le contenu en lui-même et la structure du référentiel doit être étudié précisément.
- Combien attribuer de libellés pour une clef donnée ? (Libellé court, libellé long, libellé commercial, etc…)
- Comment constituer la clef de recherche unique pour un libellé donné ? (est-ce un simple code, une combinaison
entre plusieurs valeurs telles qu’entité, type d’IHM, longueur souhaité du libellé, profil de l’utilisateur, canal de
diffusion…)
Notons enfin que l’administration centralisée des libellés peut représenter une tâche non négligeable dans la mesure où il
peut exister autant de libellés que d’applications pour une valeur donnée, surtout si le mécanisme mis en place autorise (et
cela est souhaitable) l’extension des valeurs de libellés par les applications elles-mêmes.
Une possibilité à court terme rejoint les principes souvent utilisés aujourd’hui, à savoir reléguer la transaction au niveau du
HOST (proposer un SH qui gère les traitements transactionnels à son niveau, sous CICS). Cela impose le développement
d’un module particulier (SE chapeau) en rupture de conformité avec le modèle SOA retenu.
Ce regroupement d’entités et de traitements distincts sous le même module HOST n’est évidemment pas une solution
pérenne. Il est cependant possible, quoique coûteux, de coder des transactions inverses. Dans ce cas, le retour arrière est
géré par le SF qui, en cas de problème sur l’une des requêtes, lance les requêtes inverses des premières qui se sont
déroulées sans problème.
La disponibilité de la donnée en premier lieu. Où la trouver ? Dans quelle base de données ? Et comment y
accéder ?
La consistance : X dit blanc, Y dit noir. A se conforme à telle nomenclature, B à telle autre. Qui a tort, qui a raison ?
La stratification organisationnelle, voire la concurrence pure et simple de services, aboutit souvent à du doublonnage
de données de référence et donc à de l’incohérence.
La pertinence : la forme, la fraîcheur doivent être adaptées aux usages des consommateurs. Pour une même
donnée, les besoins sont souvent différents selon les consommateurs.
La sécurité : fiabilité de l’émetteur, confidentialité de l’échange… la sécurité de la donnée peut devenir un vrai enjeu.
Ces problèmes se posent de manière plus aiguë dans le cas des « bases de données référentielles ». L’existence de
plusieurs bases de données relatives à un même ensemble d’information se heurte, plus ou moins tôt et avec plus ou moins
d’acuité, à un ensemble de problèmes critiques, dont les principaux sont :
Conflit d’identité. Le même objet possède des identités différentes selon les sources de données.
Par exemple, le client X est identifié par la clé X1 dans un référentiel et X2 dans un autre.
Conflit de schémas. Le même concept est modélisé de manière différente
Par exemple, le client est modélisé par le champ « customer » d’un coté, et par les deux champs « nom » et « prénom
» par ailleurs.
Conflit sémantique. Le même terme est interprété de manières différentes.
Par exemple, un « compte » est un compte courant bancaire dans une application et un identifiant utilisateur
permettant de gérer la sécurité des accès pour une autre.
Conflit de valeur. Le même objet a des valeurs différentes selon les sources.
La balance d’un compte courant apparaît différente suivant les bases dans lesquelles on le consulte.
Redondance de valeur. Le même concept est dupliqué dans plusieurs applications indépendantes.
Par exemple, le tarif catalogue des produits est représenté par N bases avec des recoupements sur certaines
catégories de produits.
Plus grande complexité du SI à assurer la sécurité, en ce qui concerne les habilitations.
Dans une configuration de redondance de valeur, le cas classique est d’interdire l’accès à une donnée dans telle base
en oubliant d’en interdire l’accès dans telle autre.
Plus grande complexité du SI à assurer les mises à jour.
Dans une configuration de redondance de valeur, nécessité de mettre à jour toutes les bases ou fichiers contenant
cette donnée via des passerelles compliquées entre les différentes sources de données.
Le besoin de référentiel provient donc de cette situation où plusieurs ensembles de données coexistent et où leur multiplicité
pose des problèmes de cohérence.
La gestion de la qualité des données est stratégique et elle peut reposer sur une démarche spécifique type « MDM »
s’articulant autour de trois axes :
1 - Organisation : mettre en place une cellule dédiée à la gestion des données, ayant une fonction transverse dans
l’entreprise. Son rôle est d’assurer la gestion des données et la bonne application des processus dans le temps.
2 - Processus : définir des processus métier qui garantissent la disponibilité, l’exactitude, la cohérence, l’auditabilité et la
sécurité de toutes les données de références de l’entreprise.
3 - Outil : Déployer une solution informatique robuste, capable de supporter les processus.
Parmi les outils, SAP NetWeaver Master Data Management vous permet de stocker, d'enrichir et de consolider les
données de base, tout en assurant leur distribution homogène à toutes les applications et à tous les systèmes de votre
environnement informatique. SAP NetWeaver Master Data Management devient ainsi le pivot qui permet de fournir aux
applications client de toute l'entreprise des informations cohérentes et homogènes.
Les référentiels contenant des données de production (on dit aussi données « vivantes »). Ces référentiels se
décomposent eux-mêmes en deux sous ensembles :
- Les référentiels contenant des informations élémentaires : les plus courants concernent les tiers (clients,
fournisseurs…), les contrats, les produits….
- Les référentiels contenant des informations de synthèse servant à la consolidation ou à l’obtention d’une
vision globale sur tel ou tel domaine d’activité.
Les référentiels contenant des données de type nomenclature (on dit aussi données « mortes »). Par rapport au
précédent groupe, leurs caractéristiques sont une plus grande stabilité des informations qu’ils contiennent et la
possibilité d’anticiper leur mise à jour qui n’intervient pas de façon aussi aléatoire. On les appelle aussi « tables de
référence ». Ils peuvent eux-mêmes se structurer en deux sous groupes :
- Référentiels d’origine interne à l’entreprise. Ce sont, par exemple, les référentiels des types de clients, des
types de fournisseurs ou type de pièces documentaires jointes…
- Référentiels d’origine externe à l’entreprise. Ce sont, par exemple, des référentiels devises, pays, taux,
calendriers…
Ces deux types ne sont pas équivalents : les données de type nomenclature constituent un « environnement » préalable,
nécessaire à la bonne exécution des traitements de production. Mais c’est surtout la fréquence de mise à jour qui est
discriminante pour établir cette typologie, ainsi que la fréquence de consultation de la donnée.
Caractéristiques Signification
Que signifie cette donnée ? A quoi sert-elle ? (Ex : que signifie CA d’un client)
Toute information identifiée comme information de référence doit obligatoirement faire l'objet
d'une définition explicite permettant notamment :
Sémantique d'apporter une vision claire et précise du contour de cette information de référence
(aucune ambiguïté ne doit exister sur les limites et le contenu de cette information de
référence),
une adhésion de tous les « consommateurs » sur la définition et le contour qu'elle porte
(partage de la définition).
D’où vient-elle ? Où, par qui et quand a-t-elle été créée et mise à jour ?
Origine
(Ex : le CA provient directement des applications de vente des produits)
Qui en a besoin ?
Destination
(Ex : le CA est « consommé » par l’application de calcul des rétributions des agents)
Règles de calcul Comment la calcule-t-on ? (Ex : le CA d’un client)
Règles d’agrégation Quel est le périmètre de consolidation ? (Ex : le CA par semaine, mois, an)
Stockage, format Où et comment l’information est-elle stockée ? Son format ? (Ex : CA en euros HT )
Quelle est la personne responsable de cette donnée ?
Propriétaire Tout référentiel doit avoir un propriétaire désigné explicitement. Pour identifier le propriétaire d'un
référentiel, le principe de "primo-créateur" est à privilégier, à savoir que le propriétaire est au plus
proche de la création de l'information de référence.
Date de disponibilité et Quelle est la date de mise à disposition de la nouvelle valeur de cette donnée ?
période de validité des (Ex : CA hebdo mise à disposition le lundi matin 7h00, taux de valorisation interne le 2 janvier de
données chaque année…)
Soit portés dans les applications prenant en charge des fonctions du SI,
Soit présents dans des applications dédiées à la gestion de référentiels.
Pour chaque référentiel, il est nécessaire de bien identifier sa localisation physique et de développer une architecture
d'échange (normalisé et indépendant) d'informations entre les applications pour permettre la circulation des informations
présentes dans les référentiels.
Lorsque le nombre de consommateurs et de producteurs est important, les contraintes techniques des échanges deviennent
prépondérantes. Certains acteurs du SI vont alors se spécialiser dans la distribution de la donnée, c’est-à-dire dans la
gestion de la localisation des acteurs et l’orchestration des échanges de manière optimale.
Pour des raisons techniques (par exemple, pour des raisons de type de plates-formes technologiques ou de performances
d’accès), on peut envisager de dupliquer un référentiel. Il faudra simplement prendre garde à distinguer le référentiel maître
de ses clones techniques dans les procédures de mises à jour et autres traitements de gestion.
Dans notre architecture SOA de référence (voir paragraphe 3.4), ces considérations donneraient les propositions
suivantes :
On voit que cette solution est très proche techniquement de celle retenue pour gérer les libellés. Il y a matière à capitaliser
sur les développements et les charges d’exploitation.
Référentiels et progiciels
La présence de progiciels au sein du SI est très structurante car les progiciels constituent des standards de fait avec
lesquels il faut composer, même pour la gestion des référentiels de données de l’entreprise.
Dans ce cas et en ce qui concerne les référentiels, le rôle de l’urbaniste sera d’assurer la coexistence des référentiels
propres à l’entreprise et ceux que le progiciel héberge dans une logique fonctionnelle parfois différente. Par exemple, le
client au sens du module Fi-Co du progiciel SAP ne porte pas la même sémantique de celui du référentiel client dans le
réseau d’agence.
Si un référentiel préexiste à la mise en place du progiciel, le problème du choix du progiciel à retenir se pose ainsi :
• Asservir le progiciel, pour les données de référence, au référentiel interne existant et garantir la correspondance à
tout instant entre les deux référentiels,
• Remplacer le référentiel existant par le progiciel (sous réserve de l’adéquation du modèle de données et des
fonctions de service du progiciel à un rôle de référentiel).
S’il n’y a pas de référentiel préexistant à la mise en place du progiciel, alors cette mise en place constitue, a priori, une
opportunité naturelle pour créer le référentiel. Dans ce cas, la démarche de choix du progiciel pourra intégrer les
contraintes propres aux besoins sur le référentiel, en plus des besoins métiers à couvrir par le progiciel.
Quatre scénarios d’implémentation d’une gestion normalisée des valeurs par défaut ont été étudiés dans l’architecture de
référence SOA (voir figure 7). On suppose ici la mise en place d’un référentiel des valeurs par défaut au sein d’une base
dédiée mais éventuellement esclave du référentiel géré sur le Host.
13
http://www.assurland.com/
Ce dernier scénario semble le plus optimisé. Sa solution technique se rapproche de celles choisies pour la gestion des
libellés et pour la gestion des valeurs de référence. Dans tous ces cas, il s’agit en effet de donner à l’application la possibilité
d’appeler un service en charge des conversions (d’un code vers un libellé, d’une valeur pour un code…).
Toutes les solutions « classiques » de sécurisation (d’un site web par exemple) peuvent se retrouver ici (sécurité par le
réseau, sécurité via les protocoles, systèmes externes d’authentification…). Cependant, la situation dans une architecture
SOA peut parfois être plus complexe, du fait de la composition des applications composites, de la multiplicité des
fournisseurs (internes, externes), etc.
Nous nous intéressons ici plus particulièrement aux fonctionnalités d’authentification et d’habilitation. Nous n’aborderons pas,
en revanche, les architectures de sécurité autour des problématiques de SSO, de gestion des certificats ou encore de la
signature électronique.
Concrètement, les points auxquels il faut pouvoir répondre est : Comment implémenter les principes de sécurité.
D’authentification ? (s’assurer que la personne connectée est bien celle qu’elle prétend être). Cela passe le plus
souvent par une phase de login (vérification du couple « User / Pwd », éventuellement couplée avec un SSO).
D’habilitation ? (s’assurer que la personne connectée ait bien les droits pour faire ce qu’elle désire). Cela passe par
la gestion d’un ensemble d’éléments caractérisant l’utilisateur (profil applicatif au sein d’un annuaire LDAP par
exemple) qui autorise ou interdit l’appel.
Les aspects « intégrité » des messages, « non répudiation » des traitements, et de « confidentialité » (via un cryptage par
exemple) sont ici exclus de notre analyse.
WS-Security)
SOAP
Dans le cas où les échanges entre partenaires sont nombreux (nombreux liens entre services appartenant
indifféremment à l’un des partenaires en réseau), il est souhaitable de mettre en place une extension de ces
mécanismes élémentaires vers une gestion plus globale de fédération d’identité (voir les spécifications Liberty ou
WS-Federation). Cette fédération d’identité facilite les échanges en faisant l’économie de répliquer les serveurs
d’identités (annuaires LDAP) entre partenaires.
Aujourd’hui, les outils d’EAI sont entrés en concurrence avec l’ESB (Enterprise Services Bus) qui, comme son nom l’indique,
se propose de mettre à disposition de l’entreprise des services partagés sur un bus.
Un modèle connu consiste à suivre chaque service au moyen d’un agent de supervision (type JMX ou WMI). De cette
façon, chaque interaction avec le service (appel au service, retour d’appel, arrêt, démarrage) est tracé et les informations
de log peuvent être remontées vers une console de supervision centrale (par exemple : Tivoli, HP OpenView…)
La supervision SAM repose donc sur l’utilisation d’indicateurs résumant les mesures prises de manières unitaires sur
l’ensemble des services. La difficulté se situe alors dans le choix des bons indicateurs métiers ou techniques et il est
important de les implémenter de la façon la moins intrusive possible.
BAM (Business Activity Monitoring) : la supervision des processus métiers
La supervision des Processus métiers peut être vue comme le prolongement du SAM dans la mesure où les activités du
processus métier reposent sur l’exécution de services SOA. Les outils de BAM se baseront donc sur les fonctions
offertes par le SAM pour supporter la supervision de l’état des instances de processus (quelle étape, quel état, quel
délai ?), la création de statistiques et d’historiques (combien d’appels de services pour combien d’instances déclenchées,
dans quels délais … ?).
La finalité de ce cabinet d’urbanisme (composé d’urbanistes et d’architectes) serait de maintenir le système d’information
dans la trajectoire établie et réviser périodiquement la cible et le plan de migration. Le cabinet d’urbanisme aurait
typiquement pour missions « régaliennes » de :
Piloter le plan d’urbanisation
• Lorsque nécessaire, une mise à jour du plan d’urbanisation peut être décidée. Ce type de situation se
produit lorsqu’un facteur amène à réviser la stratégie de manière significative (fusion, acquisition,
nouveaux métiers…). l faut alors en déduire les mesures de réalignement du S.I. cible et de la trajectoire
de convergence.
Créer, maintenir et publier le référentiel documentaire d’urbanisation
• Les différentes cartographies constituent un actif précieux pour l’entreprise, permettant notamment des
analyses d’impacts rapides et fiables et la formation rapide de nouveaux intervenants sur le système
d’information.
Conseiller maître d’ouvrage et maître d’œuvre
• Avec les maîtrises d’ouvrage, l’urbaniste joue un rôle de conseil et d’expertise. Il les aide à voir la valeur
ajoutée métier de leurs besoins fonctionnels, à cadrer ces derniers par rapport au schéma stratégique mis
en place par l’entreprise et à les classifier.
Les enjeux des SI modernes reposent définitivement sur la maîtrise de plusieurs composantes :
La maîtrise des métiers, des produits, des marchés : les SI doivent jouer un rôle majeur dans la mise en œuvre de la
stratégie métier de l’entreprise, dans sa conquête d’avantages concurrentiels et dans sa politique de différentiation.
La maîtrise du temps : les SI doivent être réactifs - sans sacrifier la vision à plus long terme et sans nuire à la
cohérence et à la qualité de service rendu aux directions opérationnelles.
La maîtrise des coûts : les SI doivent contribuer à la maîtrise globale des coûts (processus, organisation, ressources).
Ils doivent eux-mêmes être conçus et fonctionner en respectant ces efforts d’économie.
La maîtrise des risques : qu’il s’agisse des risques financiers, opérationnels ou technologiques, les SI doivent aider à
les identifier, à les mesurer et à les contrôler.
La maîtrise des technologies : sans céder aux effets de mode, il s’agit d’une part de se prémunir contre les risques
d’obsolescence et d’autre part de tirer profit des évolutions technologiques pour offrir un service différentiant et de
qualité.
SOA, nouvelle architecture du SI qui met l’accent sur la réutilisation, la standardisation des interfaces et la flexibilité, peut
clairement aider à atteindre ces objectifs.
Ses apports sont multiples :
L’implémentation privilégiée d’une SOA reste les Web Services. Cependant, si les Web Services sont souvent une approche
intéressante, ils ne sont pas forcément adaptés à toutes les situations (notamment si besoin de transaction globale ou de
performance critique). En ce qui concerne leur mise en œuvre, il faut être vigilant sur la définition des services (règles
d’identification des services à mettre en œuvre et surtout partage de l’information entre les membres des équipes projet). Par
ailleurs, la gestion des transactions et de la sécurité restent, à ce jour, incomplètes, même si les spécifications du W3C
avancent sur ce sujet. Enfin, la mise en place de services externes (via des partenaires) nécessite une infrastructure lourde
pour pouvoir supporter les contraintes de monitoring ou de sécurité.
En complément d’une approche SOA et au delà du seul système d’information, la démarche d’urbanisation fournit au
management les moyens pour modéliser leur vision d’avenir de l’entreprise et faire partager cette vision à l’ensemble des
acteurs de l’entreprise.
SA Service Applicatif
SAM Service Activity Monitoring
SE Service Entité
SF Service Fonctionnel
SH Service Host
SOA Services Oriented Architecture
SOX Sarbanes-Oxley
ST Service Transverse (ou Technique)
WSDL Web Services Description Language