Accéder à la bonne information, au bon moment et au bon format a toujours été, et reste toujours un enjeu majeur dans les entreprises. Mais voilà, les parcs applicatifs bougent, changent et évoluent vite … de plus en plus vite ! Trop souvent même pour les services informatiques qui n’arrivent plus à suivre le rythme des demandes de changements réclamées par les métiers. Les projets de type décisionnel et transactionnel doivent donc faire face à des demandes continues de changement rapide afin d’être utilisés de manière efficace et fiable, et donc de gagner en crédibilité.
L’enjeu de l’accès aux données
Le débat est posé, les besoins évoluent et les architectures aussi même si elles ne peuvent répondre à toutes les problématiques soumises par les métiers. Prenez un exemple simple : une entreprise industrielle qui possède plusieurs succursales désire consolider ses commandes sur diverses périodes (semaine, mois, année). Les commandes proviennent naturellement de plusieurs progiciels (SAP, Oracle, SGBDR, …). Tout va bien jusque-là : le service informatique met alors en place un système décisionnel pour répondre à cette demande. Le projet se déroule bien et après plusieurs mois la solution BI est déployée conformément aux attentes … mais d’il y a plusieurs mois, justement ! Premier hic : la solution répond-t-elle toujours aux exigences concrètes des métiers ? Bien souvent avant même le « go live » de la solution, déjà des premières demandes de changements sont réclamées par les métiers. Et les premiers conflits MOE/MOA apparaissent. Pire, si les changements sont très structurants, et il faut repartir dans un nouveau mode projet, qui peut durer encore plusieurs semaines voire plusieurs mois !
Les impacts projet
Cette situation est extrêmement frustrante pour tous les intervenants du projet car tous ont l’impression de courir après un train qui est déjà parti, et qu’il est naturellement impossible de rattraper. Il faut donc songer à améliorer la réactivité ces phases de réalisation afin que les besoins métiers soient enfin en adéquation avec ce que peut produire la maîtrise d’œuvre : c’est ce que j’appellerai ici « l’Agile Data Integration ».
La plupart des entreprises ont alors simplifié la couche d’intégration pour complexifier la couche de restitution (plus simple à développer et déployer) en y ajoutant des règles lors de l’affichage par exemple… mais c’est mettre un pansement sur un plâtre car les problèmes liés à la performance ne tardent pas en général à se manifester. Il faut donc bien agir sur la couche d’intégration et se lancer dans l’ « Agile Data Integration ».
Accélérer la phase d’intégration peut se matérialiser par deux axes.
Le premier est de songer à la couche d’accès aux données. La question est alors : comment la simplifier au maximum ? Dans les projets d’intégration de données (de type BI plus particulièrement) on lit et on déplace les sources de données. Or celles-ci peuvent changer et évoluer du point de vue structurel et fonctionnel. Il faut alors revoir – pour prendre en compte les changements – les développements ETL, les tester, les « recetter » et les redéployer ! La solution est donc de créer une couche d’agilité dans le processus d’intégration pour casser la rigidité des développements ETL.
Le second axe est d’impliquer les métiers ou MOA dans la réalisation même des traitements, et pas seulement dans les phases de spécifications. L’idée ici est que ces intervenants qui connaissent les données à récupérer passent moins de temps sur des documents Word et plus dans la manipulation des données, et ce dans un esprit collaboratif entre la MOA et la MOE.
Simplifier la couche d’accès
Simplifier la couche d’accès aux sources de données revient en fait à définir une couche d’accès – mais virtuelle – unique à l’information. Cette couche aura pour rôle de représenter de la manière la plus pragmatique les informations métier telles qu’elles devront être utilisées ultérieurement. Pour cela MOE et (surtout) MOA devront définir ensemble un modèle logique des données. Ce modèle logique devra refléter au mieux les problématiques métiers sans se préoccuper dans un premier temps de la logique d’intégration qu’il faudra mettre en œuvre.
Ce modèle logique deviendra en quelque sorte un contrat de service entre MOA et MOE, une couche intermédiaire qui isolera ensuite la logique d’intégration (dans notre exemple réalisée via l’ETL des sources vers le Data Warehouse) aux données elles-mêmes. Cette couche agira donc comme une sorte de proxy multi-sources et deviendra alors le point d’accès unique à l’information. Notez bien ici qu’il n’est pas question de déplacement des données (comme le fait un ETL) mais d’accès aux données.
Mais comment faire converger l’ensemble des sources de données vers ce modèle logique ? Et bien c’est le rôle de la solution de fédération (ou virtualisation de données). Mais attention, pour être efficace elle devra permettre d’y inclure de la qualité de données ainsi qu’un grand nombre de transformation afin de coller au plus près le modèle logique défini au préalable. En effet dès lors que l’on parle de sources hétérogènes il est logique d’envisager différentes granularités, formats, structures, etc. Il est donc clair que la solution de fédération/virtualisation doit proposer ces fonctionnalités pour être utilisable.
Impliquer MOE et MOA dans un processus collaboratif
Créer une couche de fédération de données permet de simplifier considérablement l’accès aux données et permet aussi, par la même, de mettre en place une couche isolant les développements ETL des données elles-mêmes. Mais pour être efficace il faut que cette couche d’accès soit réalisée conjointement par la MOE et surtout la MOA. Car seules les MOA connaissent les données et bien souvent leur « exclusion » de la réalisation des projets créent des effets tunnels voire pire échouer ces projets ! Il faut donc absolument leur donner la main afin que le modèle logique défini plus haut soit le plus exact possible.
C’est ici que le « l’Agile Data Integration » prend tout son sens car la MOA doit prendre la main sur les données et pouvoir elle-même définir ses « tables/vues logiques » (l’ensemble des tables logiques constituant le modèle logique), analyser les données dans les différentes sources, les consulter et surtout définir ses propres règles métier.
Tous ces éléments, toutes ces manipulations doivent alors pouvoir être récupérées de manière transparente par la MOE pour être utilisées voire enrichies avec de la qualité de données par exemple, pour constituer les tables virtuelles finales. On est donc bien alors dans un processus collaboratif MOE et MOA qui constituent ensemble la couche d’accès aux données. Cette couche pourra être ultérieurement modifiée à la demande, au lieu par exemple de modifier le processus ETL qui suit et ainsi entrer dans un processus projet, chronophage, plus couteux et qui surtout risque une fois déployé de ne plus être d’actualité.
Pourquoi faire de l’Agile Data Integration ?
Pour résumer faire de « l’Agile Data Integration » doit passer par la mise en place d’une couche intermédiaire d’accès aux données. Cette couche propose en fait des services d’accès aux données simple et optimisés qui surtout peuvent être mis en place par la MOA et la MOE conjointement.La solution Informatica Data Services est une réponse simple et complète à toutes les problématiques de type virtualisation de données, mais va aussi bien au-delà en proposant une flexibilité et des possibilités d’optimisation sans équivalent sur le marché. Vous pourrez ainsi créer de manière naturelle ce fameux modèle logique en y apportant toute la richesse des possibilités d’intégration et de qualité de données. Ajoutez à cela une interface dédiée aux MOA pour manipuler simplement et créer/modifier des tables virtuelles sans avoir besoin de connaissances SQL ou autre langage, vous aurez une solution de type Agile qui vous apportera un bénéfice significatif dans la réalisation et la durée de vie de vos projets d’intégration.
Un autre avantage qui découle de la mise en place de cette couche intermédiaire est la facilité de modification et d’évolution des sources de données. En effet dès lors que qu’une demande de changement impliquera l’ajout ou la suppression d’une nouvelle source de données, un changement de version de base de données ou de progiciel, l’impact sera global si l’on est dans un contexte de développement dit « traditionnel ». Dans le cas où l’on aura mis en place la couche de virtualisation/logique on pourra – a contrario – ajouter, modifier et supprimer comme bon nous semble les connectivités en nombre, typologie et version sans jamais impacter toute la chaine d’intégration :
Pour résumer, avec Informatica Data Services entrez dans l’ère de l’ « Agile Data integration » et impliquez plus et mieux les maîtrises d’ouvrage afin de garantir le succès de vos projets.
