Briques applicatives

Objectif

Après avoir exposé les grands types d’architecture ainsi que les fonctionnalités attendues pour une solution MDM, nous allons évoquer l’intégration et la place du référentiel au sein du SI de l’entreprise.

Cette intégration répond aux principaux objectifs évoqués dans la première partie.

Elle repose aussi sur une intégration étagée afin d’éviter un mode « big-bang » pré-judiciable à la réussite des projets.

La place du référentiel, son interaction avec l’ensemble des couches applicatives du SI et le bon usage de la couche d’intermédiation sont l’objet central de ce chapitre.

7.1 BRIQUES APPLICATIVES

Dans la conception des applications informatiques, on considère cinq grandes couches représentées sur la figure 7.1 :

• accès (portail, B2B…) ;

• intermédiation (EAI, ETL…) nécessaire pour des échanges entre machines ;

• métier (logique applicative construite autour de progiciels, serveurs d’applica-tions, serveurs de données…) ;

Positionner le référentiel

dans le SI

• pilotage (décisionnel, BAM, supervision technique) ;

• transverse (sécurité, annuaire, pilotage).

Figure 7.1— Les cinq grandes couches applicatives

Le schéma de la figure 7.2 présente dans le détail les domaines fonctionnels (regroupement de besoins fonctionnels, comme la gestion de contenu) et les briques fonctionnelles (en général associées à un type de besoin). On voit apparaître un domaine gestion des données, dans lequel on trouve les produits que nous avons déjà évoqués : MDM (Master Data Management) et DQM (Data Quality Management).

L’EII (Entreprise Information Integration) est, quant à lui, cantonné à l’intermédia-tion. Par ailleurs, on note les domaines fonctionnels suivants qui seront abordés dans les architectures présentées :

• Gestion applicative : il s’agit des progiciels métier, mais aussi des briques tech-niques supports ou constituantes d’une solution spécifique (les serveurs Web, les serveurs d’applications qui permettent en particulier de construire des applications transactionnelles et de manière plus générale tout type de traite-ment).

• Échanges et orchestration : il s’agit de la couche d’intermédiation avec les technologies telles que l’EAI (Enterprise Application Integration) pour l’échange de messages à travers un bus, l’ESB (Enterprise Service Bus) pour l’appel aux services Web à travers un bus, l’ETL (Extract Transform Load) pour le chargement en masse de données avec transformations de modèles, le BPM (Business Process Management) pour la définition et l’activation des règles d’enchaînements de traitements (le workflow étant l’enchaînement de tâches réalisées par des humains). Il s’agit aussi des moteurs de règles qui permettent de définir et de modifier les règles d’enchaînements en dehors des applications (mais aussi de coder les algorithmes de règles métier complexes).

• Accès et gestion de contenu : ils constituent la couche d’accès aux informa-tions, en général par les humains mais aussi par les applications notamment via le B2B (Business to Business). Elle permet à la fois de manipuler des

137 7.1 Briques applicatives

données structurées (typiquement stockées dans des SGBD) et des données non structurées (documents aux formats divers rangés dans des fichiers).

Remarque : la gestion de contenu est actuellement peu concernée par les solu-tions MDM (simple gestion de cohérence), mais l’extension de l’EIM (Entre-prise Information Management) aura un impact sur cette sphère. Il peut s’agir par exemple de la réglementation pour un suivi de certificat lié à l’écologie ou à la traçabilité sanitaire et plus tard pour la mise à disposition d’information ciblée non structurée provenant de sources de confiance, tels que les éditeurs de contenus.

Figure 7.2— Les principales briques applicatives

• Pilotage : il englobe la Business Intelligence (BI) ou le décisionnel, le BAM (Business Access Management), le BSM (Business Services Management) et les outils de supervision applicative. La BI permet de construire des tableaux de bord, des rapports d’analyse, des prévisions… Cette brique fonctionnelle est fortement liée à une bonne gestion des données de référence car la qualité des données induit des rapports ou tableaux de bord reflétant réellement l’activité et les performances de l’entreprise. Une politique de bonne mise en œuvre de la BI ne peut pas ignorer deux sujets que nous évoquons largement dans ce

livre : la gouvernance des données (essentielle pour obtenir des données de qualité), la mise en œuvre éventuelle d’outils de gestion de la qualité des données et la gestion adéquate des données de référence. Le BAM, qui permet un reporting sur le bon fonctionnement des processus métier, est plus marginal par rapport à notre propos.

• Sécurité : c’est un sujet important, qui concerne à la fois l’authentification (prouver son identité), l’habilitation (droits pour réaliser des opérations), la confidentialité (chiffrement des données confidentielles si nécessaire), la disponibilité (sauvegardes, reprises après pannes, dispositifs de haute disponi-bilité…). C’est un domaine par ailleurs largement outillé et pris en compte par les DSI des entreprises que nous évoquerons peu dans ce livre.

• Annuaires : on distingue les annuaires de personnes (de type LDAP), les annuaires de services (au sens des services Web) et enfin les annuaires de métadonnées (déjà évoqués et sur lesquels nous reviendrons). Les technolo-gies d’annuaire peuvent être considérées comme des solutions de gestion de certaines données de référence comme, par exemple, les employés d’une société. C’est pourquoi nous les avons évoquées dans les solutions possibles.

Les services Web ne figurent pas sur ce schéma en tant que tels ; ce sont des tech-nologies utilisables en développement pour construire des architectures SOA (voir l’annexe sur ces architectures). De manière très simplifiée, les architectures SOA articulent les applications et le SI plus généralement, autour de services qui sont des entités d’exécution autonomes accessibles via une interface publiée. À noter aussi qu’un progiciel métier (type SIEBEL ou SAP CRM) possède ses propres briques (par exemple, SAP PI est un EAI, SAP Portal un portail) en plus d’une puissante compo-sante métier spécifique généralement bâtie aussi autour d’un serveur Web et d’un serveur d’application.

Conséquemment aux chapitres sur l’architecture fonctionnelle, on notera qu’une solution de gestion de données de référence utilise potentiellement de nombreuses briques applicatives issues du modèle ci-dessus. La mise en œuvre par étapes et une analyse propre des besoins est donc essentielle pour doser l’effort de chaque itération projet et éviter un « big bang » insurmontable.