Une brève histoire

Au fil des ans, la manière dont les données ont été affichées pour nous aider à présenter les informations a porté de nombreux noms : reporting, business intelligence (BI), visualisation de données, etc. Sur la base de mon expérience antérieure, depuis 2001, en travaillant pour une société de logiciels de plateforme BI et en développant des outils de reporting automatisés, j'ai classé l'affichage des données en six catégories :

1. Rapports tabulaires – Extractions de données en lignes et en colonnes, feuilles de calcul, ou des données paginées sur papier ou PDF. Les données proviennent directement d'une base de données, d'une vue ou sont copiées, collées et manipulées dans un format d'affichage de sortie.

2. Des rapports au pixel près – Rapports formatés tels que des états financiers, des factures, des notes d’honoraires ou des relevés d’informations générales qui peuvent inclure des éléments de rapports tabulaires, de diagrammes et de graphiques pour transmettre des informations de manière statique et structurée.

3. Analyses guidées – Les analyses guidées sont des tableaux de bord spécialement conçus, créés par des analystes BI chargés de créer des modèles de données et des interfaces utilisateur interactives. Les utilisateurs consomment des données via des graphiques et des diagrammes (appelés visualisations), des tableaux et d'autres objets adaptés à une mise en page personnalisée.

4. Analyse en libre-service – L’analyse en libre-service marque la démocratisation du processus de développement d’analyses guidées pour l’utilisateur final. Grâce à ces outils et plateformes, l’utilisateur final est en mesure de créer un tableau de bord à partir de zéro en ajoutant des données provenant de plusieurs sources et en créant des visualisations à partir d’une interface utilisateur utilisant des fonctionnalités de préparation intelligente des données et de création de graphiques assistée.

5. Analyses intégrées – Les analyses intégrées offrent aux développeurs front-end la possibilité d’utiliser HTML 5 et JavaScript pour générer des visualisations robustes et interactives avec du code et les placer directement dans des pages Web et des applications.

6. Analyses avancées – L’avenir de l’analytique n’a jamais été aussi prometteur. La quantité de données dans le monde ne cesse de croître, et nous avons besoin de davantage d’aide pour obtenir les informations et les connaissances qui comptent. L’intelligence artificielle, l’apprentissage automatique, l’analyse cognitive, les robots, les interfaces utilisateur conversationnelles et bien d’autres technologies permettent à chacun d’exploiter plus facilement la puissance des données pour améliorer sa vie.

Le minimum que nous devrions espérer avec toute technologie d’affichage est qu’elle ne fasse aucun mal ». – Edward Tufte

La Problématique

L'affichage des données (ce que j'appelle BI) continue d'évoluer et de changer, mais un problème demeure. Les exigences envers les outils et les plateformes sont plus importantes que les capacités qu'ils offrent. Les consommateurs de BI attendent de ces outils plus qu'une analyse « ce qui s'est passé » et « et si ? ». Ils veulent une application de cycle de vie complet qui tienne compte de l'historique et permet un impact immédiat sur l'avenir. C'est la véritable promesse d'une compréhension de l'action, mais à partir d'une interface unique, visuelle ou autre. Afin de répondre à cette exigence, les développeurs de BI doivent apprendre à coder.

Au cours de mon expérience de travail dans le domaine de la BI, j'ai parlé à de nombreux analystes essayant de créer des applications à usage général en utilisant uniquement les API de leur plateforme BI, et cela n'avait aucun sens.

Le défi d’apprendre les API spécifiques à la BI est difficile.

Ajoutez à cela la nécessité d'apprendre le codage général, et au final, l'investissement et les efforts ne valent pas la valeur obtenue. C'est pourquoi Low-code est un meilleur moyen pour les développeurs BI de fournir des applications complètes avec des fonctionnalités allant au-delà de la BI et de la visualisation. C'est plus simple et plus puissant que d'essayer de coder à l'aide d'API BI ou d'intégrer des outils nécessaires pour effectuer des opérations que les outils BI ne permettent pas (par exemple, réécrire dans l'ensemble de données BI). L'ironie est que les développeurs d'applications essaient de faire la même chose dans la direction opposée.

Depuis l'adhésion MendixJ'ai eu plusieurs conversations par semaine avec des clients sur l'utilisation du low-code pour développer une application de reporting ou de type BI, où l'utilisateur final peut exécuter un certain nombre de fonctions disponibles dans les catégories décrites ci-dessus. L'objectif de développement est le même que celui du développeur BI. Créer une application complète qui offre la capacité de transmettre des informations de manière significative ; faire quelque chose avec elle tout en prenant en charge les mises à jour ou les modifications des données ; offrir aux utilisateurs finaux une flexibilité analytique.

Considérations relatives à l'utilisation de graphiques natifs dans une application low-code

Le principe de base pour les développeurs d'applications en matière de reporting, de BI, d'analyse, etc., est de ne pas réinventer la roue. Tenez-vous-en aux principes de base et affichez les données qui aideront l'utilisateur final à passer à l'étape suivante de son expérience. Les fonctionnalités de création de graphiques et de rapports (via des vues de liste et des grilles de données) sont parfaites pour afficher des données significatives en rapport avec la tâche que l'utilisateur souhaite accomplir avec l'application. Essayer de mettre à disposition toutes les données au moment de l'exécution pour que les utilisateurs puissent faire ce qu'ils veulent n'est pas la bonne solution. Pensez à vous poser ces trois questions de départ lorsque vous essayez de décider quoi faire :

1. Quel est le problème que vous essayez de résoudre pour l’utilisateur ?  

Pensez au cas d'utilisation et à la manière dont les informations doivent être transmises à l'utilisateur. Si le client souhaite disposer d'un ensemble d'indicateurs de performance clés (KPI) sur la page d'accueil d'une application ou à un endroit quelconque de l'expérience utilisateur, utilisez les tableaux et graphiques inclus dans une plateforme comme Mendix Cela a du sens, car vous pouvez créer rapidement et facilement des visuels attrayants et utiles. Si le client demande toutes sortes de fonctionnalités en libre-service pendant l'exécution de l'application, il est temps d'envisager une plateforme intégrée qui réponde à cette exigence.

2. Quelle est la quantité de données contenues dans votre application ?

L'application contient-elle 100 lignes de données ou 100 millions de lignes de données ? Dans ce dernier cas, la présentation détaillée de toutes ces données génère beaucoup moins de valeur que le temps nécessaire à leur rendu dans l'application. Lorsque vous concevez des applications avec des tableaux de bord et des graphiques contenant des volumes de données importants, soyez prescriptif et restrictif avec des agrégations pour les indicateurs clés de performance, les graphiques et les vues de liste à l'aide de filtres et d'une logique conditionnelle. Vos utilisateurs vous remercieront d'avoir raccourci leur temps d'analyse tout en augmentant la valeur de ce qui est affiché.

3. Quel niveau d’analyse interactive est requis ?

En raison de la nature interactive des analyses guidées et en libre-service, les utilisateurs finaux se sont habitués à cliquer sur des graphiques et des diagrammes pour appliquer un filtre à l'ensemble de données. Cependant, les méthodes de travail avec ces outils évoluent et, dans de nombreux cas, la réponse souhaitée à un clic ou à une interaction consiste à effectuer une action. Ces actions peuvent inclure une exploration en profondeur (passer d'une couche de données à une autre), l'ouverture d'un nouvel écran dans une application pour afficher plus de détails ou solliciter une saisie, ou l'attribution d'un enregistrement spécifique à un flux de travail ou à une personne déclenchant une notification ou une alerte. Toutes ces activités nécessitent une logique combinée à l'aspect visuel pour passer à l'étape suivante, et les plateformes low-code offrent des moyens intuitifs pour faciliter la configuration de ces actions.

À l’inverse, les développeurs low-code peuvent être amenés à devoir connecter les données présentées dans les graphiques, ce qui est plus facile à faire sur une plateforme d’analyse. Bien qu’il soit possible de connecter un groupe de graphiques ensemble pour répondre à l’unisson à une interaction avec Mendix, il est important de peser l'effort par rapport aux avantages souhaités, à la maintenance et à l'échelle de la solution. Dans de nombreux cas, l'intégration d'une plateforme spécialement conçue pour gérer ce niveau de complexité est plus judicieuse.

Considérations relatives à l'utilisation d'une plateforme BI intégrée dans une application low-code

Il existe de nombreuses raisons d'intégrer des plateformes de reporting et de BI dans des applications low-code. Pour commencer, votre organisation a réalisé un investissement considérable dans la BI et vous devez en tirer parti. Les systèmes basés sur les transactions dans les applications ne sont pas conçus pour gérer les exigences d'analyse auxquelles les plateformes BI répondent à l'aide de leurs moteurs de données propriétaires. La BI présente donc un avantage certain lorsque vos utilisateurs doivent découper et analyser les données. En outre, les plateformes BI et les plateformes d'application low-code ont toutes deux des API exposées pour faciliter la communication aux différentes couches de leurs piles respectives. Cela facilite la création de hooks côté BI et de composants réutilisables côté low-code pour combiner la puissance des deux technologies. Voici quelques questions à prendre en compte lorsque vous essayez d'intégrer la business intelligence et l'analytique dans les applications.

1. Les données proviennent-elles de plusieurs sources ?

Les plateformes low-code et les plateformes BI disposent toutes deux de solides capacités d'ETL, de traitement des données et de transformation. Voici quelques éléments à prendre en compte :

• Si une plateforme effectue le mélange des données et peut fournir ce dont l’autre a besoin, le niveau d’effort nécessaire pour le recréer dans l’autre système peut ne pas en valoir la peine.
• Si vous devez décider quelle plateforme utiliser pour le mélange de données, choisissez celle pour laquelle les personnes qui comprennent le mieux les données peuvent également comprendre l'outil le mieux. L'avantage de nos jours est que les plateformes low-code et BI disposent toutes deux d'API pour communiquer entre elles.
• Évitez de traiter les données sur les deux plateformes pour prendre en charge le cas d'utilisation. Cela introduit des risques liés à la qualité des données et rend plus difficile la détection d'erreurs potentielles dans les calculs ou le suivi de la lignée des données de bout en bout.

2. Les utilisateurs finaux ont-ils besoin de fonctionnalités en libre-service pour sélectionner les champs de données qu’ils souhaitent afficher dans une grille, une sortie ou pour créer des visualisations pendant l’exécution avec les données sous-jacentes ?

Si mes déclarations précédentes ne sont pas suffisamment claires, ne voulez pas Créez des outils de reporting et d'analyse en libre-service avec n'importe quelle plateforme de développement d'applications, à moins que votre objectif ne soit de créer le prochain grand outil. Il existe de nombreuses options sur le marché qui peuvent satisfaire une ou plusieurs des catégories que j'ai décrites, et beaucoup d'entre elles proposent des options permettant de mettre en marque blanche la solution afin que les clients pensent qu'il s'agit de la vôtre. Gagnez du temps et de l'argent et évitez l'épuisement des développeurs.

3. Les métriques dérivées des plateformes BI doivent-elles déclencher des événements, appeler la logique d'application, écrire dans les sources de données sous-jacentes et actualiser les visualisations BI ?

Dans le monde de la BI d'aujourd'hui, pour passer de l'analyse à l'action au sein de la même plateforme, il faut coder pour trouver la solution. Cela peut prendre du temps pour les développeurs de logiciels expérimentés et ne pas être une solution pour les analystes BI qui tentent de résoudre le problème. Les plateformes de développement d'applications low-code permettent à tout un chacun de créer facilement des applications robustes en utilisant une logique visuelle (pensez à Visio, mais les flux sont interprétés en action) pour piloter l'interaction de l'interface utilisateur et traiter les activités back-end. L'association du low-code à l'analyse intégrée liée à une plateforme BI offre le meilleur des deux mondes. Vous pouvez tirer parti de la connectivité et de l'interactivité fournies par la plateforme d'analyse et utiliser une plateforme low-code pour gérer le traitement des données et la logique opérationnelle du cycle de vie de l'application.

Il ne fait aucun doute que ces deux technologies convergent. À mesure que la demande d’applications augmente, la demande d’interprétation et de présentation des données qu’elles génèrent augmente encore plus rapidement. Les plateformes low-code sont capables de gérer un certain nombre de cas d’utilisation de reporting et de création de graphiques. Comme le temps nécessaire pour passer de la compréhension à l’action, puis à la révision et ainsi de suite devient de plus en plus court, des solutions plus sophistiquées exploitant l’analyse et le low-code doivent être envisagées pour offrir le meilleur des deux mondes.