Eine kurze Geschichte

Im Laufe der Jahre hat die Art und Weise, wie Daten angezeigt werden, um uns bei der Präsentation von Informationen zu helfen, viele Namen gehabt: Reporting, Business Intelligence (BI), Datenvisualisierung und so weiter. Basierend auf meiner früheren Erfahrung seit 2001, als ich für ein BI-Plattform-Softwareunternehmen arbeitete und automatisierte Reporting-Tools entwickelte, habe ich die Datenanzeige in sechs Kategorien eingeteilt:

1. Tabellarische Berichterstattung – Zeilen- und Spaltendatenextrakte, Tabellenkalkulationen, oder paginierte Daten auf Papier oder in PDF-Dateien. Daten kommen direkt aus einer Datenbank, einer Ansicht oder werden kopiert, eingefügt und in das Ausgabeanzeigeformat bearbeitet.

2. Pixelgenaue Berichterstattung – Formatierte Berichte wie Finanzberichte, Rechnungen, Belege oder allgemeine Informationsblätter, die Elemente tabellarischer Berichte, Diagramme und Grafiken enthalten können, um Informationen auf statische und strukturierte Weise zu vermitteln.

3. Geführte Analysen – Geführte Analysen sind speziell entwickelte Dashboards, die von BI-Analysten erstellt werden, die für die Erstellung von Datenmodellen und interaktiven Benutzeroberflächen verantwortlich sind. Benutzer nutzen Daten über Diagramme und Grafiken (Visualisierungen genannt), Tabellen und andere Objekte, die in ein benutzerdefiniertes Layout passen.

4. Selfservice-Analyse – Self-Service-Analysen markieren die Demokratisierung des geführten Analyseentwicklungsprozesses für den Endbenutzer. Mit diesen Tools und Plattformen kann der Endbenutzer ein Dashboard von Grund auf neu erstellen, indem er Daten aus mehreren Quellen hinzufügt und Visualisierungen über eine Benutzeroberfläche erstellt, die intelligente Datenaufbereitung und unterstützte Diagrammerstellungsfunktionen nutzt.

5. Eingebettete Analysen – Eingebettete Analysen geben Front-End-Entwicklern die Möglichkeit, mithilfe von HTML 5 und JavaScript robuste und interaktive Visualisierungen mit Code zu generieren und diese direkt in Webseiten und Anwendungen einzufügen.

6. Erweiterte Analysen – Die Zukunft der Analytik war noch nie so rosig. Da die Datenmenge weltweit immer weiter wächst, brauchen wir mehr Hilfe, um an die Informationen und Erkenntnisse zu gelangen, die wichtig sind. Künstliche Intelligenz, maschinelles Lernen, kognitive Analytik, Bots, Konversations-UIs und mehr sind Technologien, die es jedem leichter machen, die Macht der Daten zu nutzen, um sein Leben zu verbessern.

Das Mindeste, was wir von einer Displaytechnologie erwarten können, ist, dass sie keinen Schaden anrichtet.“ – Edward Tufte

Die Herausforderung

Während sich die Datendarstellung (was ich BI nenne) weiterentwickelt und verändert, bleibt ein Problem bestehen. Die Anforderungen an die Tools und Plattformen sind größer als die Funktionen, die sie bieten. BI-Anwender erwarten von diesen Tools mehr als nur „Was ist passiert“- und „Was wäre wenn“-Analysen. Sie möchten eine Anwendung für den gesamten Lebenszyklus, die die Vergangenheit berücksichtigt und sofortige Auswirkungen auf die Zukunft ermöglicht. Das ist das wahre Versprechen, Erkenntnisse in Maßnahmen umzuwandeln, aber über eine einzige Schnittstelle – visuell oder anderweitig. Um diese Anforderung zu erfüllen, müssen BI-Entwickler lernen, wie man programmiert.

Während meiner Erfahrung in BI habe ich mit vielen Analysten gesprochen, die versuchten, allgemeine Anwendungen zu erstellen mit einzige die APIs ihrer BI-Plattform, und es ergab keinen Sinn.

Das Erlernen der BI-spezifischen APIs ist eine schwierige Herausforderung.

Kombiniert man das mit dem Erlernen allgemeiner Programmierung, sind die Investition und der Aufwand letztlich den Gegenwert nicht wert. Deshalb Low-Code ist für BI-Entwickler eine bessere Möglichkeit, vollständige Apps mit Funktionen bereitzustellen, die über BI und Visualisierung hinausgehen. Es ist einfacher und leistungsfähiger, als zu versuchen, mithilfe von BI-APIs zu programmieren oder Tools zu integrieren, die für Vorgänge erforderlich sind, die BI-Tools nicht ausführen (z. B. Zurückschreiben in den BI-Datensatz). Die Ironie besteht darin, dass Anwendungsentwickler versuchen, dasselbe in die entgegengesetzte Richtung zu tun.

Seit dem Beitritt MendixIch habe jede Woche mehrere Gespräche mit Kunden darüber geführt, wie man mit Low-Code eine Reporting- oder BI-ähnliche Anwendung entwickeln kann, bei der der Endbenutzer eine Reihe der in den oben beschriebenen Kategorien verfügbaren Funktionen ausführen kann. Das Entwicklungsziel ist das gleiche wie das des BI-Entwicklers. Erstellen Sie eine vollständige App, die Informationen sinnvoll vermitteln kann. Tun Sie etwas damit und unterstützen Sie gleichzeitig Aktualisierungen oder Änderungen der Daten. Bieten Sie den Endbenutzern analytische Flexibilität.

Überlegungen zur Verwendung nativer Diagramme in einer Low-Code-Anwendung

Die Grundvoraussetzung für Anwendungsentwickler in Bezug auf Reporting, BI, Analytics usw. ist, das Rad nicht neu zu erfinden. Bleiben Sie bei den Grundlagen und zeigen Sie die Daten an, die dem Endbenutzer helfen, den nächsten Schritt in seiner Erfahrung zu machen. Die Diagramm- und Berichtsfunktionen (über Listenansichten und Datenraster) sind gut geeignet, um aussagekräftige Daten anzuzeigen, die für die Aufgabe relevant sind, die der Benutzer mit der Anwendung erledigen möchte. Der Versuch, alle Daten zur Laufzeit verfügbar zu machen, damit Benutzer tun können, was sie wollen, ist nicht die richtige Lösung. Stellen Sie sich diese drei Einstiegsfragen, wenn Sie versuchen zu entscheiden, was zu tun ist:

1. Welches Problem versuchen Sie für den Benutzer zu lösen?  

Denken Sie über den Anwendungsfall nach und darüber, wie Informationen an den Benutzer übermittelt werden müssen. Wenn der Kunde eine Reihe von Key Performance Indicators (KPIs) auf einer App-Homepage oder irgendwo im gesamten Benutzererlebnis haben möchte, verwenden Sie die Diagramme und Grafiken, die in einer Plattform wie enthalten sind Mendix ist sinnvoll, da Sie schnell und einfach schöne und nützliche Visualisierungen erstellen können. Wenn der Kunde während der Anwendungslaufzeit alle möglichen Self-Service-Funktionen verlangt, ist es an der Zeit, über eine integrierte Plattform nachzudenken, die diese Anforderungen erfüllt.

2. Wie viele Daten sind in Ihrer Anwendung enthalten?

Verfügt die Anwendung über 100 oder 100 Millionen Datenzeilen? Wenn Letzteres zutrifft, ist der Wert der detaillierten Darstellung aller Daten deutlich geringer als die Zeit, die für die Darstellung in der Anwendung benötigt wird. Wenn Sie Apps mit Dashboards und Diagrammen entwerfen, die große Datenmengen enthalten, sollten Sie mit Aggregationen für KPIs, Diagramme und Listenansichten mithilfe von Filtern und bedingter Logik präskriptiv und restriktiv vorgehen. Ihre Benutzer werden es Ihnen danken, wenn Sie ihnen die Zeit bis zur Erkenntnis verkürzen und gleichzeitig den Wert der angezeigten Informationen steigern.

3. Welches Maß an interaktiver Analyse ist erforderlich?

Aufgrund der interaktiven Natur geführter und Selfservice-Analysen haben sich Endbenutzer daran gewöhnt, auf Diagramme und Grafiken zu klicken und diese Aktion einen Filter auf den Datensatz anwenden zu lassen. Die Arbeitsweise mit diesen Tools ändert sich jedoch, und in vielen Fällen besteht die gewünschte Reaktion auf einen Klick oder eine Interaktion darin, eine Aktion auszuführen. Diese Aktionen können ein Drilldown (Wechseln von einer Datenebene zu einer anderen), das Öffnen eines neuen Bildschirms in einer Anwendung, um mehr Details anzuzeigen oder Eingaben anzufordern, oder das Zuweisen eines bestimmten Datensatzes zu einem Workflow oder einer Person, die eine Benachrichtigung oder Warnung auslöst, umfassen. Alle diese Aktivitäten erfordern eine Kombination aus Logik und Visualisierung, um den nächsten Schritt auszuführen, und Low-Code-Plattformen bieten intuitive Möglichkeiten, um die Konfiguration dieser Aktionen zu vereinfachen.

Umgekehrt können Low-Code-Entwickler die Anforderung erhalten, die in den Diagrammen dargestellten Daten zu verknüpfen, was auf einer Analyseplattform einfacher ist. Es ist zwar möglich, eine Gruppe von Diagrammen miteinander zu verbinden, um gemeinsam auf eine Interaktion mit zu reagieren. Mendixist es wichtig, den Aufwand gegen den gewünschten Nutzen, den Wartungsaufwand und den Umfang der Lösung abzuwägen. In vielen Fällen ist die Integration einer Plattform, die speziell für diese Komplexität entwickelt wurde, sinnvoller.

Überlegungen zur Verwendung einer BI-Plattform, die in eine Low-Code-Anwendung eingebettet ist

Es gibt viele Gründe, Reporting- und BI-Plattformen in Low-Code-Anwendungen zu integrieren. Zunächst einmal hat Ihr Unternehmen beträchtlich in BI investiert und Sie sollten davon profitieren. Transaktionsbasierte Systeme in Anwendungen sind nicht darauf ausgelegt, die Analyseanforderungen zu erfüllen, die BI-Plattformen mit ihren proprietären Daten-Engines erfüllen. Daher bietet BI eindeutig Vorteile, wenn Ihre Benutzer Daten aufteilen und analysieren müssen. Darüber hinaus verfügen sowohl BI-Plattformen als auch Low-Code-Anwendungsplattformen über frei zugängliche APIs, um die Kommunikation auf den verschiedenen Ebenen ihrer jeweiligen Stacks zu erleichtern. Dies erleichtert die Erstellung von Hooks auf der BI-Seite und wiederverwendbaren Komponenten auf der Low-Code-Seite, um die Leistungsfähigkeit beider Technologien zu kombinieren. Hier sind einige Fragen, die Sie berücksichtigen sollten, wenn Sie versuchen, Business Intelligence und Analytics in Anwendungen einzubetten.

1. Stammen die Daten aus mehreren Quellen?

Sowohl Low-Code-Plattformen als auch BI-Plattformen verfügen über robuste ETL-, Datenverarbeitungs- und Transformationsfunktionen. Hier sind einige Dinge, über die Sie nachdenken sollten:

• Wenn eine Plattform die Datenzusammenführung durchführt und bereitstellen kann, was die andere benötigt, lohnt sich der Aufwand zur Neuerstellung im anderen System möglicherweise nicht.
• Wenn eine Entscheidung darüber getroffen werden muss, welche Plattform für die Datenzusammenführung verwendet werden soll, wählen Sie die Plattform, bei der die Personen, die die Daten am besten verstehen, auch das Tool am besten verstehen. Das Tolle heutzutage ist, dass sowohl Low-Code- als auch BI-Plattformen über die APIs verfügen, um miteinander zu kommunizieren.
• Vermeiden Sie die Verarbeitung von Daten auf beiden Plattformen, um den Anwendungsfall zu unterstützen. Dies birgt Risiken für die Datenqualität und erschwert die Erkennung potenzieller Berechnungsfehler oder die durchgehende Nachverfolgung der Datenherkunft.

2. Benötigen Endbenutzer Self-Service-Funktionen, um die Datenfelder auszuwählen, die sie in einem Raster anzeigen oder ausgeben möchten, oder um zur Laufzeit Visualisierungen mit den zugrunde liegenden Daten zu erstellen?

Wenn meine vorherigen Aussagen nicht klar genug sind, nicht Erstellen Sie Self-Service-Berichts- und Analysetools mit jeder beliebigen Anwendungsentwicklungsplattform, es sei denn, Ihr Ziel ist es, das nächste großartige Tool zu entwickeln. Es gibt viele Optionen auf dem Markt, die eine oder mehrere der von mir beschriebenen Kategorien erfüllen können, und viele bieten die Möglichkeit, die Lösung als White Label zu kennzeichnen, damit die Kunden denken, es sei Ihre eigene. Sparen Sie Zeit und Geld und verhindern Sie ein Burnout der Entwickler.

3. Müssen in BI-Plattformen abgeleitete Metriken Ereignisse auslösen, Anwendungslogik aufrufen, in zugrunde liegende Datenquellen schreiben und die BI-Visualisierungen aktualisieren?

In der heutigen BI-Welt müssen Sie sich Ihren Weg zur Lösung programmieren, um über die Analyse hinaus innerhalb derselben Plattform zur Aktion zu gelangen. Dies kann für erfahrene Softwareentwickler zeitaufwändig und für BI-Analysten, die versuchen, das Problem zu lösen, ein No-Go sein. Low-Code-Anwendungsentwicklungsplattformen machen es jedem leicht, robuste Anwendungen mit visueller Logik zu erstellen (denken Sie an Visio, aber die Abläufe werden in Aktionen umgesetzt), um die Interaktion der Benutzeroberfläche zu steuern und Back-End-Aktivitäten zu verarbeiten. Die Kombination von Low-Code mit eingebetteter Analytik, die an eine BI-Plattform gebunden ist, bietet das Beste aus beiden Welten. Sie können die Konnektivität und Interaktivität nutzen, die die Analytikplattform bietet, und eine Low-Code-Plattform verwenden, um die Datenverarbeitung und Betriebslogik des Anwendungslebenszyklus zu handhaben.

Es besteht kein Zweifel an der Konvergenz dieser beiden Technologien. Da die Nachfrage nach Anwendungen wächst, wächst auch die Nachfrage nach der Interpretation und Präsentation der von ihnen generierten Daten noch schneller. Low-Code-Plattformen sind in der Lage, eine Reihe von Anwendungsfällen für Berichte und Diagramme zu bewältigen. Da die Zeitspanne von der Erkenntnis über die Aktion bis zur Überprüfung und wieder zurück immer kürzer wird, müssen anspruchsvollere Lösungen in Betracht gezogen werden, die Analysen und Low-Code nutzen, um das Beste aus beiden Welten zu vereinen.