Discussion :

[Mikael.Ber]

Bonjour à tous et à toutes,

Nous sommes une entreprise spécialisée dans la Business Intelligence et nous aimerions créer un nouveau produit !

Je viens donc solliciter votre avis, car je pense qu’il sera plus que pertinent !

Notre idée est de créer un serveur permettant de réaliser des requêtes paramétrables sur TOUT type de sources de données (database, ERP, application (Excel etc…)) et d’exporter le résultat via un simple lien http (OData, WebQuery, REST, ou GCD).
Ainsi vos bases de données resteront protégées par votre firewall et ne serons pas exposées sur le Cloud.

L’utilisateur final accèdera à ses informations via un portail web en utilisant un lien http ou https pour injecter en temps réel les informations dans son outil (power pivot, excel, power bi, QlikView, etc…).

D’autre part, un serveur SAAS GRATUIT sera disponible afin de créer et publier vos tableaux de bords à partir de tout lien suivant le protocole OData.

Ces liens OData pouvant venir de notre propre logiciel ou de tout autre serveur OData.

Je vous remercie d’avance et n’hésitez pas à donner votre avis!

Cordialement Mikael,

[nuke_y]

Bonjour,

auriez-vous un petit schéma de l'architecture imaginée? Ca me semble flou là.

Ensuite quel est le business model ? Le client installe son serveur et vous paye une licence ? Du SaaS ?

[Mikael.Ber]

Bonjour,

Merci de votre réponse.

En effet le client installe un serveur et paye une licence par serveur et ceci indépendamment du nombre d'utilisateurs. D’autre part le mode SAAS pour les tableaux de bords sera gratuit et pourra être utilisé aussi avec des liens OData, GCD provenant d'applications tierces.

[nuke_y]

Merci,

je comprends l'idée mais là, comme ça, je ne vois pas l'intérêt dans une architecture. Disons que ce qui peut être déterminant c'est
- à quel point utiliser votre outil facilite la vie des utilisateurs, dans ce cas ça veut dire que les utilisateurs font eux-mêmes les requêtes, c'est dangereux
ou
- à quel point votre outil va offrir de la puissance aux développeurs et de la performance, dans ce cas ça veut dire que c'est une couche technique intermédiaire, sans avoir de fonctionnalités détaillées c'est compliqué de se prononcer

Je dirais que le dénominateur commun c'est la performance : si l'outil engendre des gains de performance, il trouvera sa place, sinon... il risque de toujours se heurter à du "fait maison"

[Mikael.Ber]

je ne vois pas l'intérêt dans une architecture

L’intérêt dans une architecture et que plutôt qu’avoir X outils réalisant des requêtes pour chaque support BI. Vous n’en utilisez plus qu’un, et qu’il est facile, aboutit, et complet.

- à quel point utiliser votre outil facilite la vie des utilisateurs, dans ce cas ça veut dire que les utilisateurs font eux-mêmes les requêtes, c'est dangereux

Un responsable peut créer la requête et les utilisateurs vont utiliser un lien webquery, oData ou REX pour alimenter leur application (Excel, QlikView, Power BI, etc…)
Les utilisateurs ne créent donc pas leurs requêtes, elles ont déjà été créées par un responsable et mis à disposition sur un portail web, aucun outil n’a besoin d’être installé sur le poste client. Aucune formation n’est nécessaire car l’utilisateur travaille avec Excel ou tout autre produit de Self-Service BI qu’il connait déjà. Nous agissons donc en tant qu’un Self-Service Data.

à quel point votre outil va offrir de la puissance aux développeurs et de la performance, dans ce cas ça veut dire que c'est une couche technique intermédiaire, sans avoir de fonctionnalités détaillées c'est compliqué de se prononcer

Nous pensons que notre outil va offrir de réels avantages comparés à ceux qu’ils utilisent aujourd’hui car :

-Nous pouvons facilement réaliser une requête qui réalise un « join » sur plusieurs sources de données.
-Notre produit permet de mémoriser le résultat d’une requête provenant de tout type de bases de données directement dans une table de SQL server (ainsi l’utilisateur peut travailler directement sur le résultat et évite ainsi des mauvaises manipulations sans surcharger le serveur de production).
-Les requêtes peuvent contenir des critères dépendant de l’utilisateur ainsi une même requête donnera différents résultats selon l’utilisateur.

[nuke_y]

Il y a 10 ans j'avais commencé des spécifications pour un proxy SQL et ça ressemblait à peu près à ça. Cependant, depuis, des systèmes nouveaux sont apparus: les outils in memory comme Qlikview, Sense et Spotfire qui permettent de croiser de multiples sources de données, les dernières versions de BO ou Cognos qui permettent de croiser plusieurs requêtes dans un même rapport, des outils de Complex Event Processing, de nouvelles technologies de BDD comme SAP HANA ou même le Big Data.

Bref quand vous aurez une version stable, et s'il est possible de la tester, n'hésitez pas à passer par ici pour la présenter. Je serais heureux de l'essayer et de vous faire un retour.

[Mikael.Ber]

C'est vrai qu'il y a déjà des solutions capables de croiser des sources de données mais nous pensons que nous pouvons le faire plus simplement et de façon plus transparente. Comme vous l'avez dit il est difficile de se prononcer sans découvrir les fonctionnalités.

Je vous remercie pour tout, et je me ferai un plaisir de vous présenter notre solution une fois notre phase de BETA terminée (Q2 2016).

Je serai plus que ravie de vous laisser une License de test !

[nuke_y]

Question : que donnez-vous sur des données big data ? Il pourrait y avoir un besoin sur un croisement de big data avec des web services et des données plus traditionnelles

[Mikael.Ber]

Comme notre langage principal d'interrogation c'est le SQL, on peut travailler avec Google Big Query, SAP Hanna, et SQL Server Azure.

D'autre part pour attaquer les web services nous avons brevet qui nous permet d’interroger les web services en langage SQL.

Donc il est tout à fait possible de combiner une requête travaillant par exemple sur Google Big Query, Web services et SQL Server.

[nuke_y]

?

Je parlais de plateformes big data ou assimilées telles que Hadoop, cassandra, Splunk, là-dessus il y aurait de la plus-value à simplifier l'accès aux données.

[Mikael.Ber]

Je comprends, mais hélas on n'en est pas capable aujourd'hui