BI – Die alten Regeln gelten nicht mehr

Vor Kurzem veröffentlichte Wayne W. Eckerson (WE) einen Artikel darüber, wie sich die Welt im BI-Umfeld verändert (hat). Er listet einige Erkenntnisse von seiner letzten TDWI-Konferenz und versucht auch dies zu erklären. Ich (SA) versuche einmal, ausgewählte Aussagen wieder zu geben und auf meine Situation zu übersetzen.

  • “There is no need for a dimensional model.”
    • WE: Heutige BI-Werkzeuge sind so gut, dass schlechtes Design kompensiert wird.
    • SA: InfoCubes sind in einen HANA-System nicht mehr notwendig. Bei einer Modellierung in HANA muss man nur bedingt auf Performance achten und Werkzeuge wie Lumira benötigen nichtmal In-Memory sondern nutzen SAP IQ als spaltenbasierte Datenbank um performance durch den Endanwender Millionen von Datensätzen verarbeiten zu können.
  • “There is no need for ETL tools.”
    • WE: nutze Spark für ETL in der Cloud oder in Hadoop-Umgebungen
    • SA: Ebenfalls Lumira hat hier schon gezeigt, wie auch recht komplexe Transformationen sowie die Anbindung an fast beliebige Datenquellen schnell und einfach möglich sind. Mit Agile Data Preparation hat die SAP sogar ein komplett eigenes Werkzeug dafür auf den Markt gebracht.
  • “You don’t need a relational database.”
    • WE: Du kannst alle deine Data Science-Aufgaben ins S3 und mit Spark erledigen.
    • SA: Zumindest meine ersten Erfahrungen mit BO Cloud legen nahe, dass Cloud doch noch die eine oder andere Kinderkrankheit hat. Allerdings garantiert Amazon 99,999999999 % Ausfallsicherheit. Das muss man intern erstmal leisten. Das man für Data Science nicht unbedingt eine relationale Datenbank benötigt, ist aber glaube ich wirklich nichts Neues. Gerade wenn es um unstrukturierte Daten geht und um extrem große Datenmengen sind andere Ansätze gefragt.
  • “Code is not the enemy.”
    • WE:  Schreibe ETL-Code in Spark und verwalte ihn in Git Hub; es ist befreiend
    • SA: Git scheint heute im HANA oder SAP Cloud-Umfeld schon der neue Standard zu sein. In einer superagilen Welt verwundert der Erfolg von Git Hub daher nicht.
  •  “We don’t move data.”
    • WE: Wir bauen logische views in Hadoop für analytische Anwendungsfälle
    • SA: Auch HANA und vor allem S/4HANA setzen auf virtuelle Datenmodelle, welche für analytische Zwecke optimiert sind. Mit Core Data Services wird aktuell von SAP eine neue Grundlage geschaffen, dieses Konzept in der Breite umzusetzen.
  •  “We design from physical to logical, not logical to physical.”
    • WE: Wir laden Rohdaten in das System, dann bauen wir logische views für jeden Anwendungsfall; wir modellieren nicht zuerst.
    • SA: Passt zum vorherigen Punkt und unterstützt und erweitert diesen. In einem S/4HANA liegen die Daten schon vor, jedoch nicht unbedingt für analytische Zwecke. Erst durch das virtuelle Datenmodell bereite ich die „Rohdaten“ auf. In einem NoSQL-System oder Data Lake lege ich Daten ab, wie Sie kommen. In zum Teil völlig verschiedenen Schemata für die Sie ursprünglich gedacht waren. Wie ich diese für die Analyse im Sinne von Data Science benötige, kann ich vorab noch nicht sagen. Dabei kann man jedoch noch gut zu den traditionellen Ansätzen differenzieren, bei denen der Analysezweck im vorhinein recht klar ist (z. B. Analyse von Umsatzdaten nach verschiedenen Dimensionen). Schema-on-Read ist nichts, was der Fachbereich mal nebenher macht, weil er eine Fragestellung beantwortet haben möchte. Und dann gibt es auch noch agile Ansätze wie Data Vault.
  • “We design for secondary use cases, not the primary one, which has a limited shelf life.”
    • WE: Wir laden Daten und speichern diese auf Detailebene, so dass wir diese für neue Einsatzzwecke verwenden können, sobald der Bedarf dafür aufkommt.
    • SA: Die Aggregation von Daten geschieht immer für einen bestimmten Zweck. Information geht dabei verloren. Natürlich sollte es für ein HANA-System in der SAP-Welt kein Problem sein, sehr granulare Daten zu speichern. Jedoch kann dies sehr teuer sein. Mit Ansätzen wie Dynamic Tiering und Nearline Storage hat SAP Ansätze, das zu handhaben. Eine Alternative für BW könnten Ansätze wie SparrowBI sein.
  • “Your data architecture is as important or more than your data model.”
    • WE: Wie die Daten im Dateisystem abgelegt werden ist wichtig. Sonst wird man mit den Daten wenig anfangen können.
    • SA: Themen wie Datenqualität, Metadatenmanagement und Data-Lineage spielen hier eine wichtige Rolle, soll der Data Lake nicht zum Datensumpf werden.
  • “Architecture is way more important when you move to the cloud.”
    • WE: Wenn du deine Cloud nicht richtig konfigurierst, wird es evtl. teurer als gedacht.
    • SA: Mit Cloud-Konzepten herrscht weniger Erfahrung als in der On-Premise-Welt. Die leichte Verfügbarkeit der Ressourcen verführt dazu, erstmal großzügig damit umzugehen. Evtl. muss hier neu und eher elastisch gedacht werden.
  • “Applications are dependent on analytics.”
    • WE: Wir benötigen DevOps um die Entwicklung von Anwendungen und Analytic zu koordinieren.
    • SA: S/4HANA setzt massiv auf Hybrid Transactional Analytical Processing (HTAP) und verbindet immer mehr operative Anwendungen mit analytischen Funktionen.
  • “Either you evolve and change, or die.”
    • WE: Sei offen gegenüber Hadoop, Spark und der Cloud.
    • SA: Das sich SAP gegenüber den Open Source-Technologien wie Hadoop und Spark z. B. im Rahmen von HANA Vora öffnet ist ein wichtiges Zeichen. Bei Cloud versucht sich SAP als Vorreiter und setzt darauf wie auf HANA und zeigt damit auch die Richtung.

Eckerson schließt mit den Worten „The only constant is change, and now is the time to change! „. Aber Veränderung ist kein Projekt oder etwas, was man jetzt mal angehen sollte. Um konkurrenzfähig zu bleiben muss Veränderung zum integralen Bestandteil der Unternehmenskultur werden.

Self Service BI am Beispiel SAP Lumira – aus IT-Sicht

Lumira ist ein interessantes BI-Werkzeug und im letzten Gartner Magic Quadrant für BI und Analytics Platforms repräsentierte es im Schwerpunkt SAP. Gartner sieht mit dem Schwenk von IT-zentrierter BI hin zu fachbereichszentrierter BI die Vollendung einer seit Jahren andauernden Entwicklung.

In gewisser Weise ist Lumira (aktuell im Release 1.31) sehr mächtig. Kein anderes BI-Werkzeug von SAP bietet vergleichbare Möglichkeiten bei der Akquisition und Transformation von Daten. Auch im Bereich Visualisierung/Explorative Datenanalyse hat Lumira wirklich seine Stärken. Die bisher kommunizierten Arbeitsschritte in Lumira waren je nach Release etwas abweichend: (Hier 2 Alternativen):

  1. Acquire Data / Acquiring Data
  2. Enrich Data / Preparing Data
  3. Build Visualizations / Visualizing Data
  4. Explore Data / Composing Stories
  5. Share with your teammates / Sharing Insights

Gerade der letzte Schritt war stark mit Lumira Cloud verbunden. Da Lumira Cloud wegen SAP BusinessObjects Cloud nicht mehr weiter entwickelt wird, steht diese Option nicht mehr zur Verfügung und man kann seinen Bericht oder seine Story „nur“ noch auf dem Server for Teams oder der SAP BI Plattform sichern.

Natürlich kann man ein Lumira nur bestimmten Key- oder Power-User an die Hand geben kann, um die Sache etwas unter Kontrolle zu halten und nicht für jeden seinen persönlichen Bericht in einem BI-System managen zu müssen. Dieser stellt dann für die Masse der User ein Dokument auf der BI-Plattform zur Verfügung. Dort verfügen die User nur über sehr eingeschränkte Anpassungsmöglichkeiten.

Im Folgenden eine Analyse der einzelnen Schritte in Lumira, deren Bedeutung und einer Bewertung aus IT-Sicht:

SSBI_Lumira

SAP Lumira hat wirklich seine Stärken. Jedoch muss man sich der Grenzen bewusst sein. Wäre in einem Unternehmen die IT entsprechend aufgestellt, so sollten Möglichkeiten wie Lumira nur in Kombination mit klassischen BI-Ansätzen für bestimmte Anwender und Situationen genutzt werden. Das Lumira unter diesem Namen mit Design Studio im Release 2.0 verschmilzt, macht es eher zu einem zukünftigen Werkzeug für Rapid Prototyping, erleichtert jedoch den Übergang in eine IT-gesteuerte Umgebung.

Eine mögliche Alternative hieße, dass letztendlich der Fachbereich seine eigene IT aufbaut. Das kann funktionieren, muss aber bewusst vom Unternehmen so gewollt sein. Den dadurch optimiert sich die Abteilung zwar für sich, schafft aber einen Graben zwischen sich und anderen Abteilungen, da Kennzahlen, Information Design und Datenbasis lokal und nicht vergleichbar sind.

Eine andere Alternative wäre, die IT agil bzw. Bi-modal aufzustellen. Wahrscheinlich besteht letztendlich ein großes Problem darin, dass die IT-Abteilungen bzw. BI-Teams selten die Kapazität haben, schnell genug auf Anforderungen/Änderungen zu reagieren. Auch wenn dies wünschenswert wäre, da damit das volle Potential von BI durch technisch ausgereifte Lösungen ausgenutzt werden könnte. Ob sich der Konflikt zwischen „verstehe die Technik“ und „verstehe den User/das Business“ jedoch jemals auflöst ist fraglich. Den die Technik alleine macht noch keine gute Business Intelligence aus.

Das BICC hat seine Erwartungen wohl nicht erfüllt, ist nicht überall realisierbar oder entwickelt sich vielleicht nicht schnell genug weiter. Vielleicht ist es letztendlich doch der letzte Notanker um BI zu retten.

Letztendlich muss hier im Rahmen einer Business-, IT und BI-Strategie hier ein passender Weg für jedes Unternehmen gefunden werden. Vorausgesetzt, solche Strategien sind überhaupt im Unternehmen vorhanden…

SAP BusinessObjects (BO) BI Suite

Die BusinessObjects BI Suite besteht aus einer Reihe von BI-Werkzeugen, welche 2007 von SAP zusammen mit einer Reihe weiterer Werkzeugen übernommen wurden.

Die folgende Übersicht zeigt auch Neuentwicklungen wie Design Studio oder Lumira, welche erst nach der Übernahme von BO entwickelt wurden, um die bestehenden Werkzeuge der BEx-Suite ablösen zu können (Design Studio) oder um neuen Trends wie der agilen Visualisierung (Lumira) entgegen treten zu können.

BO Übersicht

SAP bietet mit den vorhanden Werkzeugen ein großes Spektrum an Möglichkeiten. Jedoch gibt es auch eine große Redundanz an Funktionen und Einsatzzwecken. SAP hat von daher, u. a. auch im Rahmen des Versuchs die angebotene Software für die Kunden einfacher (Simplification) zu machen und klarer zu positionieren, angekündigt, sich auf bestimmte BI-Werkzeuge zu konzentrieren und wichtige Funktionen auf den Ziel-Werkzeugen zu vereinen.

SAP Lumira

SAP Lumira ist ein relativ neues Werkzeug der SAP im Umfeld Business Intelligence. Es fällt in die Kategorie Data Discovery, Agile Visualisierung oder Self Service Visualisierung und zielt direkt auf den Endanwender im Fachbereich.

Mit SAP Lumira Server wurde mittlerweile auch die Möglichkeit geschaffen, SAP Lumira in die BO-Plattform zu integrieren (seit Kurzem auch ohne eine eigene HANA-Datenbank) und gewisse Regeln im Umgang mit dem Werkzeug festzulegen.

SAP Lumira ermöglicht die Analyse und Integration verschiedener Datenquellen, wobei HANA hierfür eine der ersten möglichen Datenquellen war und ein Zugriff auf das SAP BW erst zu einem deutlich späteren Zeitpunkt ermöglicht wurde.

SAP Lumira wird relativ agil und mit kurzen Releasezyklen von zunächst etwa 2 Monaten veröffentlicht. Zuletzt waren es eher 3-4 Monate.

Im Mai 2016 wurde die Konvergenz von SAP Design Studio und SAP Lumira zu voraussichtlich einem Lumira 2.0-Release in Q4/2016 verkündet.

Regelmäßig gibt es im SCN Updates zu den Neuerungen:

SAP Lumira 1.27

SAP Lumira 1.28 (seit 19.08.2015)

SAP Lumira 1.29 (seit 20.11.2015)

SAP Lumira 1.30 (seit 24.03.2016)

SAP Lumira 1.31 (seit 14.06.2016)

SAP Lumira 1.31.1 (seit 12.08.2016?)