I    Différence entre Infocentre et DataWarehouse

L’infocentre est une collection de données orientées sujet, intégrées, volatiles, actuelles, organisées pour le support d’un processus de décision ponctuel.

Le DataWarehouse est une collection de données orientées sujet, intégrées, non volatiles, historisées, organisées pour le support d’un processus d’aide à la décision.

Ou plus généralement on qualifie d’infocentre une solution décisionnelle dont le modèle de données est très proche d’un modèle de données d’un système opérationnel.

L’infocentre est un outil alors que le Data Warehouse est une architecture.

II  Architecture d’un Système décisionnel

Une prise de décision intègre généralement  quatre modèles  :

1-  Un modèle de données : C’est le DataWarehouse; 

2- Un modèle de connaissance : Ce sont les faits et les règles. Ici c’est le domaine du DataMining (Réseaux de neuronnes, Algorithmes génétiques, Systèmes expert, …);  

3- Un modèle mathématique : C’est le domaine de la modélisation (recherche opérationnelle, programmation linéaire, ..). La variable solution peut être mono critère (C’est–à-dire que l’on recherche une solution optimale) ou multi critère (c’est-à-dire que l’on recherche une solution acceptable). Par définition dans le dernier cas il existe plusieurs solutions;

4- Un modèle de décision : Empirique ? Dépend de l’expérience du décideur

Une architecture minimale contient au moins le modèle de données

Ci-après un schéma résumant l’architecture

Cliquez ici pour télécharger le schéma d'architecture au format pdf

Après avoir raflé la mise sur des marchés entiers, tels que la gestion de contenus, les portails, ou les frameworks de développement, l’open source s’attaque depuis quelques années à une nouvelle gamme d’outils : Décisionnel, avec des solutions qui sont aujourd’hui d’une grande maturité et en progrès rapide.  

Dans cette partie, je décris les deux plateformes décisionnels en open source les plus en vue: Pentaho et SpagoBI

I          Pentaho

Pentaho est une suite logicielle qui permet la distribution de fonctionnalités et documents décisionnels à un grand nombre de personnes par l'intermédiaire d'une application Web ou un portail. Elle permet également l'envoi automatique de documents par email. Pentaho est proposée à la fois en version communautaire sous licence open source et en version professionnelle sous licence commerciale. La version professionnelle est basée sur la version open source à laquelle elle ajoute une meilleure interface utilisateur, la gestion des droits d'accès et la gestion du cycle de vie des documents (développement, test, production, suppression).

1- Composants utilisés

Pentaho intègre la plupart des composants décisionnels open sources existants.

        • Etats : Eclipse BIRT, JasperReports, JFreeReport

        • Graphiques : JFreeChart

        • Analyse : JPivot, Mondrian                          

        • Portail : Jboss Portal

        • Planificateur : Quartz

        • Worfklow : Enhydra Shark

        • ETL : Kettle  

2- Version

La version professionnelle (sous licence commerciale) comporte des fonctionnalités supplémentaires importantes :

         • Administration des actions depuis une interface spécifique

         • Workflow de publication des actions (développement, tests, mise en production)  

         • Audit de l'application 

         • Sécurité au niveau des états

         • Durée de vie des états

         • Stockage des actions en base de données

         • Support des configurations en clusters.

Personnalisation par l'utilisateur. Il peut par exemple choisir le format (HTML ou PDF) d'un état qu'il souhaite recevoir périodiquement.  

3- Prix

• La version « Pentaho Reporting Professional », limitée au fonctions de reporting est facturée 4500 euros par an

• La version « Pentaho BI Suite Professional » est facturée 6000 euros par an. Pentaho propose des partenariats et des certifications.

 Pentaho est une plateforme décisionnelle extrêmement complète. Elle permet non seulement d’utiliser les différents outils décisionnels open source depuis une interface unique, mais elle permet d’étendre et de combiner leurs fonctionnalités grâce à l’utilisation d’un moteur de workflow. La version open source nécessitera cependant de réaliser plusieurs développements avant de pouvoir proposer un portail décisionnel complet utilisable en entreprise.     

 II        SpagoBI

Spago BI est une plate forme décisionnelle développée par la société italienne Engineering Ingegneria Informatica. Cette plate-forme est uniquement distribuée sous licence open source. Il n'y a donc pas de fonctionnalités volontairement absentes et réservée pour une version commerciale comme c'est le cas pour Pentaho.

1- Composants utilisés

SpagoBI utilise plusieurs composants décisionnels open source :  

         • Etats : JasperReports, BIRT

         • Analyse : Mondrian, JPivot

         • Data-mining : Weka

         • Portail : eXo platform   

La fonctionnalité de création de requêtes SQL (Query By Example) est développée spécifiquement par SpagoBI.  

Les indicateurs dynamiques des tableaux de bord sont des composants flash, générés avec la plate-forme Open Laszlo.  

SpagoBI est une plateforme décisionnelle complète. Elle ne permettra pas de créer des documents aussi complexes que ceux pouvant être générés par le système de workflow de Pentaho, mais elle a l’immense avantage de proposer une interface utilisateur bien plus riche, qui ne nécessite pas de développements spécifiques avant de pouvoir être utilisée. Le portail eXo platform utilise maintenant SpagoBI pour présenter les statistiques d’accès et d’utilisation des portlets dans l’interface d’administration.

Dans cet article, je présente les deux scénarii de déploiement d'une solution décisionnelle. Bien entendu ces scénarii n'engagent que moi.

Axiomes :

- « On n’achète pas un DataWareHouse, on le construit » : Bill Inmon. 

- Un DataWareHouse, un vrai, se justifie par la satisfaction d’un besoin horizontal.

I- Scénario 1 : DataWareHouse « Global »

Ici le DataWareHouse (rigoureusement la zone de données principales) contiendra potentiellement tous les lots (« verticaux » et « horizontaux ») 

I-1       Avantages

-          Centralisation des données

-          Possibilité de brancher un programme de DataMining (le volume et la centralisation des données peuvent justifier ce branchement) afin de détecter des corrélations cachées entre les données 

I-2       Limites et contraintes 

- Le DataWareHouse peut rapidement devenir inconsistant. En effet, il ne suffit pas d’aligner des lots « verticaux » les uns à côtés des autres pour obtenir un lot « horizontal » cohérent;

- Risque de collision entre les objets « horizontaux » et « verticaux » si la frontière n’est pas clairement définie;

- Difficultés liée à la maintenance et à l’administration. En effet étant donné que plusieurs domaines fonctionnels et que les deux visions « verticale » et « horizontale » cohabitent, une maintenance et une administration efficaces nécessiterons une bonne compréhension de plusieurs domaines fonctionnels et de plusieurs visions. Ce qui énorme en terme de charge; 

- Besoin important en ressources machines (disques, RAM , CPU, …). En effet dans un DataWareHouse « global », le volume de données est de l’ordre du téra octet ----à Nécessité de mettre en place de véritables architectures de bases de données dédiées décisionnelle (Teradata , Netezza, …)

I-3       Remarques :

Ce déploiement peut convenir :

-          Aux organisations qui n’ont pas beaucoup d’applications verticales  

-          Aux organisations qui ont un ERP qui couvre l’essentiel des domaines fonctionnels

-        Aux organisations dont les besoins en indicateurs et métriques ne font pas intervenir plusieurs domaines fonctionnels

Ici le DataWareHouse (rigoureusement la zone de données principales) contiendra uniquement des lots susceptibles d’intervenir dans la satisfaction d’une problématique ou d’un besoin « horizontal ». Les besoins « verticaux » étant alors comblés par des DataMarts dédiées 

II-1     Avantages

-          Architecture distribuée

-          Possibilités de brancher un programme de DataMining (le volume et la centralisation des données peuvent justifier ce branchement) afin de détecter des corrélations cachées entre les données

II-2     Limites et contraintes  

- Suivi de la cohérence

- Possibilité d’organiser les données décisionnelles par groupe fonctionnel (peut aussi être vu comme un avantage).

- Nécessité de mettre en place une véritable architecture de bases de données dédiées décisionnelle (Teradata , Netezza, …) en cas de grosse volumétrie

II-3     Remarques :

Ce déploiement peut convenir :

-          Aux organisations qui ont beaucoup d’applications verticales

-          Aux organisations qui n’ont pas un ERP qui couvre l’essentiel des domaines fonctionnels