Affichage des articles dont le libellé est mashup. Afficher tous les articles
Affichage des articles dont le libellé est mashup. Afficher tous les articles

samedi 31 octobre 2009

Décisionnel vs gestion : définir une application décisionnelle.








Où est la frontière entre une application décisionnelle et une application de gestion? . Qu'est ce qui peut définir une application décisionnelle ?. Voici les questions posées, place aux réponses.

Dans le cadre de mon travail, je suis confronté à ces deux familles d'application et je note une confusion dans leur classification. La question n'est pas anodine car elle conditionne souvent le choix des technologies à utiliser : soit une plateforme décisionnelle, soit un simple framework. Les conséquences ne sont pas neutres.

Les concepts qualifiant le plus souvent le décisionnel sont:

  • La source des données
  • Le caractère multidimensionnel
  • Les restitutions
  • Les simulations
La source des données.

La présence d'une multitude de source de données, hétérogènes n'est pas à lui seul un critère discriminant. Par contre la collecte de type aspiration ('pumping') des données qui seront contrôlées puis injectées dans un entrepôt de données est un élément fondateur d'un système décisionnel. La donnée sera intégrée puis historisée dans un processus qui fournira de la 'traçabilité' sur la donnée. Un vrai entrepôt doit permettre de suivre tout le cycle de vie de la donnée.
Cette notion de 'pumping' s'oppose à la notion de 'mashup' qui elle, n'intègre pas la fonction de prise en charge de la donnée. Dans le décisionnel, la granularité n'est pas la même que dans une application de gestion. Souvent le directeur financier va manipuler des agrégats en Keuros. Dans le même ordre d'idée, le processus d'intégration dans l'entrepôt sera tolérant sur la présence ou le format d'une donnée, alors que pour une application de gestion, la donnée doit etre exactement calibrée et présente.


Le caractère multidimensionnel.
Le cube avec un système OLAP est l'élément clé du décisionnel. Un tel système offre la possibilité de définir des axes d'analyse, à commencer par l'axe temporel
A partir de là, l'analyste pourra explorer son cube dans les dimensions souhaitées.
Un requêteur 'universel' viendra compléter la boite à outil mise à disposition.
C'est l'utilisateur final qui choisit la requête et son domaine et non plus le concepteur de l'application. Tel un peintre qui mélange ses couleurs à partir d'un nuancier: l'entrepôt de données.

Les restitutions.

L'utilisateur final doit pouvoir choisir son format de restitution à partir d'une liste de composant . Cela peut aller du radar en passant par l'histogramme en 3D jusqu'au simple fichier csv.

Un tableau de bord aussi sophistiqué qu'il soit n'est pas le propre d'une application décisionnelle. L'utilisateur doit pouvoir choisir ses indicateurs KPI, le format d'affichage etc.
Une application de statistiques ne relève pas non plus forcement du décisionnel, elle peut etre 'immunable' sans interaction possible.

Les simulations.
Enfin, la simulation est une fonction importante demandée par les décideurs. Comment va évoluer le marché ? , quelles seront les projections dans un an ou deux ?. Il faut pour répondre à ces questions, embarquer dans le système toutes une panoplie d'outil de modélisation mathématiques.


Ainsi le critère de classification repose en grande partie sur le type de l'utilisateur final. Dans le cas du décisionnel ,c'est l'utilisateur qui compose son application, il y aura autant de forme d'application que d'utilisateur. Le nombre d'utilisateur ayant les compétences pour tirer parti d'un système décisionnel est forcement limité.

En conclusion: Les éditeurs du décisionnel cherchent à prendre des parts de marché aux éditeurs traditionnels et réciproquement : voir l'exemple de SAP qui propose du décisionnel dans son ERP. Le parc d'application décisionnelle doit normalement être marginal par rapport à celui des applications de gestion.

vendredi 4 avril 2008

La cuisine du SOA et du Mashup (05/04/2008)

J'ai reçu un article d'olivier Picciotto sur les notions de SOA et de Mashup (alliés ou ennemis) .

Qu'est ce que le SOA : Service Oriented Architecture
En clair (pas plus que ça) : On découpe le système d'information d'une entreprise en composant fonctionnel (ATTENTION pas Technique) . Chaque composant doit être autonome , il a donc :
Une interface publique (pas dans le sens GUI ) et des règles d'accès et de fonctionnement (contrat de service) .

Un composant n'a pas d'interface graphique , il communique avec le reste des composant grâce à des messages . Un utilise le plus souvent le protocole SOAP et le XML pour la partie communication.

On parle souvent d'un fournisseur de service et d'un consommateur de service . On parle aussi de couplage faible (aussi appelé couplage léger ou encore couplage lâche) entre les composants. En effet plus le couplage est faible moins il y aura de contrainte ou d'adhérence etre eux. On pourra ainsi remplacer facilement un composant par un autre . Les composant ne sont pas branchés directement sur un bus applicatif (middleware).

Le mashup : traduit par 'bouillie' , compilation . Est un système qui permet de regrouper , d'agréger plusieurs sources de données en une seule. Exemple: j'ai un réseau social sur facebook , un compte sur myspace un compte mai sur google , je vais pouvoir disposer sur une seule page l'ensemble de ses sources de données . C'est déjà ce qui propose le site français Netvibes. Le marshup est un composant base de ce qu'on appelle le web 2.0 .
Le web 2.0 repose sur :
- L'utilisation d'ajax
- Le partage des programmes et des données
- Les blogs et les flux RSS

Donc SOA et le mashup sont deux notions complémentaires et dans cette approche le service de gestion d'identité et d'authentification (SSO) prend une dimension fédératrice.