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.

Advertisements

DSAG Technologietage – Was man für BI & Analytics mitnehmen kann

Am 21. Und 22.02.2017 waren in Mannheim die DSAG Technologietage. Das Motto lautete – „Change = Chance: Heute ist morgen schon gestern“.

Leider war ich nicht vor Ort, analysiere jedoch gerne mal die Folien, um zu sehen, was sich im Bereich BW/BI/BO/Analytics und angrenzenden Bereichen bei der SAP so tut. Gerne bekomme ich auf dem Blog auch Feedback und Ergänzungen von Teilnehmern.

Die SAP HANA Cloud Platform (HCP), hier auch als SAP Cloud Platform beschrieben, scheint aktuell das große Ding zu sein. In der Keynote von SAP CIO Thomas Saueressig nimmt diese ganz klar die führende Rolle als Plattform für die Digitale Transformation ein.

Bei der HCP wird Analytics und Business Intelligence ganz klar als fundamentales Element der Digitalisierung (Machine Learning, Real-time Analytics) sowie der Digitalen Transformation (Zusammenspiel von Business process und Business intelligence) dargestellt. Die HCP soll dabei Mission Critical Data analysieren und visualisieren. Und wenn Data richtig Big wird, wird einfach HANA Vora angeflanscht.

Auch werden auf Basis der HCP einige Machine Learning Services, sogenannte Intelligent Enterprise Applications vorgestellt:

  • Resumee Matching
  • Cash Application Intelligence
  • Ticket Intelligence

Die Referenz fehlt, es dürfte aber ganz klar das seit kurzem verfügbare SAP Clea sein.

Auf den BW/4HANA-Folien werden aktuell 4.000+ BW on HANA-Kunden von insgesamt 16.000+ dargestellt. 8.000+ auf Release 7.3/7.4. Fast der Versuch zu sagen, das 7.5-Kunden ja sowieso auf HANA gehen, was nach meiner Erfahrung ganz klar nicht unbedingt der Fall ist. Nun wenn ich vergleiche, dann sind in den letzten 1 ¼ Jahren 1.500 BW-Kunden on HANA gegangen oder haben so gestartet. Bei 1.000 Neukunden in der Zeit ist hier sicherlich ein großer Teil zu sehen, die direkt on HANA starten. Also SAP, 12.000 Kunden voraus bis 2025!

Ansonsten haben die Folien von Roland Kramer und Gordon Witzel nichts wirklich Neues zu BW/4HANA gebracht. Aber bei so einer Veranstaltung muss man vielleicht auch erst alle nochmal abholen.

Ulrich Christ und Jürgen Haupt haben eine schlanke und dynamische Modellierung mit BW/4HANA und BW powered by HANA vorgestellt. Dabei ging es ziemlich ins Detail zu den flexiblen Möglichkeiten über einen CompositeProvider mit Hilfe von Associations und transitiven Attributen neue Stammdaten über alle LSA++-Layer zu integrieren. Ähnliches wurde bereits vor etwa einem Jahr in einem First Guidance-Paper vorgestellt.

Detlef Wassermuth stellt den aktuellen Stand der Planungs-Werkzeuge von SAP vor. Dabei wird BPC klar als Schwerpunkt dargestellt und die Möglichkeiten zwischen Embedded und Standard Model diskutiert. Aber auch hier nicht wirklich Neues.

Jie Deng und Alexander Peter stellten den aktuellen Stand zu Lumira 2.0 sowie Analysis Office vor. Bzgl. Analysis wurden kurz die Neuerungen von Release 2.4 vorgestellt und die Roadmap, was kommen soll. Hierzu gab es jedoch auch bereits diverse Webinare. Genauso bei Lumira. Auch hier wurden nach meinem Gefühl keine wesentlichen Neuheiten gezeigt, die man nicht bereits hätte kennen können. Allerdings gab es eine Demo und Live habe ich jetzt selbst auch noch nicht viel gesehen.

Von Abassin Sadiq und Larissa Naujoks wurde SAP BusinessObjects Cloud vorgestellt. Aufgefallen ist mir dabei das folgende Übersichtsbild:

sapanalytix-boc-dsagtt17-01

Quelle: SAP SE, „V010 –Wer morgen nicht von gestern sein möchte: SAP BusinessObjectsCloud –SAP Analytics aus der Wolke“ von Abassin Sidiq, Larissa Naujoks

Die Frage ist, was hier wohl „Verticals“ bedeutet? Der Stern deutet darauf hin, dass es sich um eine geplante Function handelt. In der Vergangenheit war hier auch schon mal GRC zu lesen oder auch „Embedding – Analytics into Applications“ wie noch in der letzten Roadmap vom Januar 2017. Natürlich könnte unter Verticals genau das Thema Embedding gemeint sein.

In einer Fiori-Session wurde von Michael Falk folgende Folie als geplante Innovation vorgestellt:

sapanalytix-boc-dsagtt17-02

Quelle: SAP SE, „V026 – SAP Fiori Evolution“ von Michael Falk

Evtl. schließt sich hier ja auch wieder der Kreis zu dem Theme „Verticals“ bei BO Cloud.

Kundenvorträge sind natürlich immer sehr interessannt und willkommen. So hat Tjarko von Lehsten von der Swisscom AG gezeigt, wie man dort das Thema BW on HANA angeht. Dort präsentierte er, nicht zum ersten Mal, das Projekt OneBI, welches drei BW-Systeme im Greenfield-Ansatz auf eine BW on HANA/HANA Native-Plattform für den dortigen Bereich Finanzen und Controlling konsolidieren sollte. Das Projekt wurde im Rahmen des BW 7.5 Ramp-Ups in  Zusammenarbeit mit SAP durchgeführt und setzte auch gleich auf den BusinessObjects Enterprise-Tools auf.

Das Projekt hat eine Laufzeit von über 2 Jahren (5.000 Manntage), und läuft parallel zu einem OneERP-Projekt.

Trotz das das Projekt aktuell noch läuft, kann man heute schon einige Lessons Learned daraus mitnehmen:

  • Bei Realtime-Ansätzen muss man auch auf die Stammdaten achten
  • Frühzeitige Einbeziehung der Fachbereiche, Aufbau eines Play Lab
  • Schnelles und agiles natives Modellieren verlängert Test- und Go-Live-Zyklen
  • Bei agilem Projektmanagement sollten die funktionalen Anforderungen so genau wie möglich definiert werden
  • Richtlinien und Standard-Szenarien sind sehr hilfreich
  • Ein Training für BW on HANA und HANA-Technologie vor dem Projekt ist notwendig
  • ODP-DataSources und EIM (Smart Data Integration/Access) stellen wichtige Integrationsfunktionen dar
  • Man muss sich entscheiden, ob der EDW-Layer in der HANA oder im BW liegt
  • Data Streaming benötigt neue Skills und hat eine gewisse Komplexität. Es bedient auch ganz neue Anwendungsfälle.
  • Die Reduktion auf neue Objekte führt zu einer schnelleren Implementierung
  • SQL-basierte Transformationen sind schnell und stabil

Sicherlich für viele ein Traumprojekt mit der Möglichkeit, die Fähigkeiten der Systeme und Werkzeuge voll auszunutzen und deren Mehrwert im Vergleich zur „alten Welt“ zu erfahren.

Ein weiterer Erfahrungsbericht kommt von WITTENSTEIN SE. Im Vortrag „Chance und Change für BI: SAP BW im Kontext einer HANA Strategie bei der WITTENSTEIN SE“, gehalten von Pascal Kranich von WITTENSTEIN und Stefan Kahle von ISR AG.

WITTENSTEIN als mittelständisch orientiertes, produzierendes Unternehmen mit starker internationaler Ausrichtung setzt stark auf die Digitalisierung. Industrie 4.0 spielt eine große Rolle. Der Mensch als Entscheider steht im Mittelpunkt. Daraus folgt: „Business Intelligence Fähigkeiten der Organisation werden zum strategischen Wettbewerbsfaktor“.

In der Data Warehouse-Zielarchitektur laufen betriebswirtschaftliche Daten aus SAP ERP, produktionsorientierte Daten aus dem MES und Sensor- und Maschinendaten, welche zuerst in Hadoop gesammelt werden zusammen.

In der weiteren Präsentation werden verschiedene Beispiele zu Mixed Models (BW & HANA-Modellierung) dargestellt.

Die Lessons Learned von WITTENSTEIN:

  • HANA allein ist kein EDW und BW kann nicht alle Optimierungen nutzen, welche HANA bietet
  • Man hat die Qual der Wahl zwischen BW und HANA und muss klare Regeln festlegen und diese einhalten
  • Sponsorship spielt eine wichtige Rolle
  • Kommunikation ist alles
  • Organisation ist herausforderner als die Technik

Einige Parallelen finden sich in den Erfahrungen die man macht sowohl bei Swisscom wie auch bei WITTENSTEIN. Gleichzeitig hat man den Eindruck, BW on HANA ist angekommen und zeigt seinen Nutzen.

Dann ein etwas technischer Anwenderbericht über die Einführung einer Nearline-Storage (NLS)-Lösung für das BW der Münchner Stadtwerke im Rahmen einer bevorstehenden HANA-Migration einschließlich Upgrade. Die Einführung der Lösung wurde durch Roland Kramer unterstützt. Interessant dabei die doch gut aussehenden Monitoringmöglichkeiten

Trotz des eher technischen Aspekts des Projekts ist es doch interessant, das auch der Fachbereich hier ein sehr positives Feedback abgegeben hat. Leider ansonsten wenig weitere greifbare Lessons Learned.

Die Präsentation „V047 –IoT Optionen anhand konkreter Lösungs-und Kundenbeispiele“ von Smitha Rayala (SAP) zeigt hauptsächlich die Lösung „SAP Predictive Maintenance & Service“ (PdMS). Die HANA-basierte Lösung stellt sich recht komplex als Zusammenspiel von SAP-Systemen, Open Source und 3rd Party-Lösungen dar. Für die Datenintegration werden Werkzeuge wie SAP Data Services oder Smart Data Streaming genutzt und ein Multi-Temperature-Konzept mit SAP IQ für „warm data“ wird dargestellt. Ebenfalls kommen in der technischen Realisierung Hadoop und HANA Vora, sowie R zum Einsatz bzw. sind geplant. Dazu passend wird als Methodologie der CRISP-DM-Ansatz vorgestellt. Auch wenn die Folien nur wenig Details hergeben, zeigt es einfach mal ein eine konkrete Lösung im Analytics-Umfeld, welche auf den aktuellen Technologien und Ansätzen der SAP aufsetzen.

In einem zweiten Teil wird SAP Vehicle Insights als aktuell HCP-basierte Lösung vorgestellt. Auch hier zeigt sich, das im Hintergrund eine Vielzahl an Technologien und Werkzeugen der SAP zusammenspielen und Analytics einen wichtigen Bestandteil darstellt:

sapanalytix-boc-dsagtt17-03

Quelle: SAP SE, „V047 –IoT Optionen anhand konkreter Lösungs-und Kundenbeispiele“ von Smitha Rayala

Der Vorteil im HCP-Betrieb wird darin gesehen, dass man trotz des komplexen Zusammenspiels eigentlich keine Betriebskosten hat, da alles von der SAP gemanaged wird.

Von Dr. Stefan Hoffmann (SAP) präsentierte „V132 – SQL Datawarehousing gemeinsam mit Business Warehouse BW4/HANA und deren gemeinsame Nutzung mit BW Inhalten“. Da das HANA DW-Konzept vorsieht, rund um HANA als Datenbank ein größeres Toolset bevorzugt aus dem eigenen Haus einzusetzen, wurden diese auch so vorgestellt. Zuerst im Gesamtkontext, dann auch einzeln:

  • SAP Enterprise Architect Designer – zur Modellierung des semantischen und logischen Datenmodells
  • SAP HANA EIM: SDI/SDQ und ADP – oder auch SAP HANA Enterprise Information Management: Smart Data Integration/Smart Data Quality und Agile Data Preperation für ETL und Datenqualität.
  • SAP HANA Web IDE – zur Modellierung von Calculation Views
  • SAP HANA CDS Development – graphischer und scriptbasierter Editor für virtuelle Datenmodelle auf ABAP-Basis
  • SAP Data Warehousing Foundation – Data Temperature Management Strategie mit dem Data Lifecycle Manager (DLM)
  • Native DSO (NDSO) – Quasi das Standard DSO nativ auf HANA implementiert und in FlowGraphs integriert
  • SAP HANA Data Warehouse Scheduler – macht den Eindruck als wäre es die HANA-Variante der Prozessketten.

In dem Kontext sei auch das Februar-Update der SAP Data Warehouse Overview & Roadmap-Präsentation erwähnt. Darin wird auch nochmal der grundsätzliche Ansatz und die Differenzierung zum BW/4HANA erläutert. Dort wird auch ganz frisch der oben beschriebene Swisscom-Fall als Beispiel für ein Mixed Model vorgestellt.

Zusammenfassend lässt sich aus der Folien-Perspektive sagen, die Technologietage sind wohl keine Veranstaltung um große Neuigkeiten zu kommunizieren. Jedoch gab es interessante Kundenvorträge und Deep Dives wie den von Ulrich Christ und Jürgen Haupt. Auch lohnt sich wohl immer mal der Blick links und rechts von BI und BW.

SAP Core Data Service (CDS)-Views für Analytics

Mitte 2015 gab es in den Niederlanden eine Videoaufzeichnung zu einem BI Podcast zwischen Ulrich Christ (SAP Produktmanager für HANA im Bereich Data Warehousing), der auch aus den OpenSAP-Kursen zu BW-Themen bekannt ist und Jürgen Haupt, SAP Produktmanager SAP EDW, der auch sehr bekannt für das Thema LSA ist, mit dem Titel „S/4HANA Analytics with CDS views and BW as evolutionary extension„.

Ulrich Christ zeigt dabei eine Demo mit Analysis for Office auf einem CDS-Modell, welches in einem S/4HANA-System liegt. Er erklärt die Mächtigkeit im Vergleich zu Data Dictionary Views und wesentliche Elemente eines CDS:

  • Annotations – besonders interessant hier ist die Analytics Annotation.
    • SAP beschreibt diese als „Enable the analytic manager for multidimensional data consumption, performing data aggregation, and slicing and dicing data. BI frontends like Design Studio and Analysis Office can consume the data via the analytic manager.
    • Durch die Annotation wird z. B. definiert, um welche Kategorie von Daten es sich handelt  – Stammdaten (#DIMENSION) oder transaktionale Daten (#FACT, #CUBE) oder um Plandaten (#AGGREGATIONLEVEL).
    • Hier wird auch festgelegt, ob der CDS-View für die Extraktion geeignet ist und evtl. Delta-Verfahren unterstützt. Damit bildet der View beispielsweise auch die Basis für eine BW DataSource.
  • Associations – Diese dienen der Ergänzung der grundlegenden Daten. So können hier für transaktionale Daten noch Attribute oder Texte hinzugefügt werden. Im Vergleich zu einen SQL-Join sind Associations wiederverwendbar.

Ulrich Christ macht klar, dass CDS-Views langfristig die neue Grundlage für BW-DataSources in S/4HANA sind. Wie SAP in der Präsentation „SAP S/4HANA Analytics & SAP BW Data Integration“ zeigt, geht dies mittlerweile sogar noch darüber hinaus. SAP sieht CDS-Views im ABAP-Layer als Virtual Data Model (VDM), welches Daten für BI (über Transient Provider), Hybride transaktionale und analytische Anwendungen (HTAP) und weitere S/4HANA-Anwendungen Daten bereitstellt:

sapanalytix_cds01

Quelle: „SAP S/4HANA Analytics & SAP BW Data Integration

Auf HANA-Ebene hat diese Rolle im Wesentlichen HANA Live, wobei das CDS-Konzept ja mittlerweile auf HANA übertragen wurde. Eine Erklärung der Unterschiede und Gemeinsamkeiten der beiden Konzepte findet sich von Horst Keller in seinem Blog. Ein guter Überblick und Vergleich findet sich auch hier.

Von Ulrich Christ kommt dazu die Aussage, dass HANA Live durch das veränderte Datenmodell in S/4HANA evtl. nicht mehr vollständig funktionieren wird und CDS das Konzept für Operational Reporting sein wird.

In einer Präsentation der SAP TechEd 2015 werden folgende Nachteile von SQL im Vergleich zu CDS aufgezeigt:

  • Eine große semantische Lücke zwischen der konzeptionellen Anforderung und der Umsetzung in SQL
  • Die Komplexität der Anforderung führt zu einer verschlechterten Performance

Bzgl. dem Argument „Aber dann nutze ich ja gar nicht mehr die Performance einer HANA-Datenbank aus, da die Anwendungslogik auf dem Application Server läuft“ gibt die Präsentation zwei Antworten:

  • Eingebaute SQL-Funktionen/-Ausdrücke können komplexe Berechnungen in die HANA-Datenbank oder auch jede andere von SAP unterstütze Datenbank pushen.
  • CDS Table Functions nutzen native HANA-Funktionen, welche in CDS implementiert wurden.

Mittlerweile hat sich Ulrich Christ in einem Blog vom November 2016 nochmal die genaue Verwendung von CDS im Kontext BW angeschaut und einige Dinge klar gemacht:

  •  Erweiterung von BW InfoProvidern um zusätzliche Informationen -> Nein!
    • Das BW-Datenmodell ist sehr ausgereift und komplex. Dies nachzubilden wäre nicht sinnvoll. Ein Ansatz, BW-Datenmodelle für SQL zu öffnen wären HANA Calculation Views. Ein Ansatz zur Integration von Non-BW-Daten ist über den OpenODS-View möglich.
    • CDS würde das Konzept der Analyseberechtigung umgehen. Ebenfalls HANA Calculation Views und die Ableitung von HANA Privileges aus Analyseberechtigungen wären hier der Ansatz.
  • SAP BW Technischer Content -> Ja!
    • Hier wird tatsächlich seit BW 7.5 SP04 Content auf Basis von CDS-Views ausgeliefert.
  • Integration von Daten ins BW über CDS -> Ja!
    • Die Extraktion von S/4HANA-Daten über den Quellsystemtyp ODP-CDS ist möglich.
    • Über OpenODS-View können CDS-Views auch virtuell konsumiert werden.
  • BW Transformationen -> Vielleicht!
    • Ein komplexer Look-Up auf eine Z-Tabelle wäre denkbar.

Nun gut, aus meiner Sicht ist und bleibt CDS eine Technologie, welche zunehmend eine Rolle spielen wird und es gut ist, wenn man weiß, was sich tut und die CDS-Entwicklung evtl. sogar beherrscht. Hoffen wir nicht, das wie bei HANA Live der Ansatz wieder schneller weg ist, als S/4HANA in der Breite ins Laufen kommt.

BI & Machine Learning

Howard Dresner stellt in seinem aktuellen Blog die Frage „Is Artificial Intelligence the Future of Business Intelligence?

Bei SAP selbst tauchen Begriffe wie Machine Learning (ML) oder Artificial Intelligence (AI) immer wieder auf. So ist Bernd Leukert als SAP Vorstand für Produkte & Innovationen auch Aufsichtsrat des Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI). Bill McDermott hat in einem vor Kurzem erschienen Interview klar gesagt, dass SAP zukünftig eine führende Rolle in diesem Bereich einnehmen will. Er wird dabei wie folgt zitiert:

“We want to become the world-wide machine learning leader for corporate businesses, hands down,” …

“Our goal is to have the most intelligent business applications and we’re doing everything we can to achieve that.”

Nicht zuletzt hat SAP aktuell auf der MOOC-Plattform OpenSAP einen Kurs mit dem Titel „Enterprise Machine Learning in a Nutshell“ laufen.

Nun, schaue ich mir den OpenSAP-Kurs so an, dann sehe ich kaum Unterschiede zu dem, was ich schon 2006 zu Diplomarbeitszeiten gesehen und gelesen habe und was heute oft unter dem Label Predictive Analytics verkauft wird.

Schaut man sich die aktuellen Tools von SAP an, so findet man immer wieder die Verwendung der Automated Predictive Library (APL) und der Predictive Analysis Library (PAL) sowie der OpenSource Statistik-Bibliothek R, welche sich bei vielen Anbieter großer Beliebtheit erfreut. APL und PAL sind natürlich Teil von HANA selbst. Und im BW ist die Integration mit dem HANA Analysis Process möglich. Dann gibt es auch noch das Werkzeug SAP Predictive Analytics, welche grafische Oberflächen zur Modellierung bietet. Und auch in das noch sehr neue SAP Produkt SAP BusinessObjects Cloud hat Predictive mittlerweile Einzug gehalten.

Begriffe, welche man in dem Zusammenhang neben Künstliche Intelligenz und Maschinellem Lernen immer wieder hört, sind Data Mining, Statistik, Deep Learning und manchmal vielleicht auch noch Data Science.

Gartner beschreibt Maschinelles Lernen/Machine Learning wie folgt:

Advanced machine learning algorithms are composed of many technologies (such as deep learning, neural networks and natural-language processing), used in unsupervised and supervised learning, that operate guided by lessons from existing information. 

Lt. Gartner stellt sich Künstliche Intelligenz/Artificial Intelligence deutlich komplexer dar:

Artificial intelligence is technology that appears to emulate human performance typically by learning, coming to its own conclusions, appearing to understand complex content, engaging in natural dialogs with people, enhancing human cognitive performance (also known as cognitive computing) or replacing people on execution of nonroutine tasks. Applications include autonomous vehicles, automatic speech recognition and generation and detecting novel concepts and abstractions (useful for detecting potential new risks and aiding humans quickly understand very large bodies of ever changing information).

Gerade der hier auftauchende Begriff „Cognitive Computing“ zeigt, dass in dem Bereich aktuell viel Bewegung ist, bei dem IBM mit Watson ein Vorreiter ist. Jedoch beispielsweise auch die deutsche BITKOM das Thema für sich entdeckt hat.

Als ich 2006 meine Diplomarbeit zum Thema Data Mining (DM) schrieb, war die Welt noch etwas einfacher. Daten waren noch nicht so „Big“ oder „Smart“ und die Begriffswelt noch nicht so ausdifferenziert.

Data Mining beschrieb ich neben OLAP und Planung als Analysetechnik welches typischerweise auf einem Data Warehouse basiert:

„Data mining is the process of discovering meaningful new correlations,
patterns and trends by „mining“ large amounts of stored data using pattern
recognition technologies, as well as statistical and mathematical techniques.“
(Ashby, Simms 1998)

Bei der Herkunftsbestimmung aus diversen Büchern fand ich:

  • Statistik
  • Datenbankmanagement
  • Mustererkennung
  • Visualisierung
  • Künstliche Intelligenz – vor allem der Bereich „Maschinelles Lernen“

Viele der Begriffe versucht man heute viel deutlicher voneinander abzugrenzen, als das nach meinem Gefühl vor 10 Jahren der Fall war. Möglicherweise ist das aufgrund der weitergeführten Forschung in den Bereichen, dem technologischen Fortschritt sowie geänderter Rahmenbedingungen (z. B. 3 V’s) auch absolut sinnvoll.

Nehme ich mal die drei aus meiner Sicht am engsten miteinander verbundenen Begriffe und schaue mir mal die Trends bei Google an, zeigt sich folgendes:

ki_ml_dm01

Offensichtlich zeigen AI und DM eine gewisse Korrelation über die Zeit. Machine Learning hat dafür lange vor sich dahingedümpelt, bis die letzten Jahre der Trend doch angezogen hat, so das Machine Learning an den anderen beiden Begriffen vorbeigezogen hat. Interessant auch der Blick auf die weltweite Verteilung:

ki_ml_dm_02_welt

Möglicherweise sind die Begriffe auch noch sehr regional geprägt. Während Data Mining doch recht verbreitet zu sein scheint, ist Machine Learning wohl vor allem in Skandinavien populär.

Gartner hat im Hype Cycle für Advanced Analytics und Data Science, 2015 das Thema Machine Learning auf dem Gipfel der überhöhten Erwartungen gesehen. Direkt vor Predictive Analytics. Der Hype Cycle 2016 hat sich dazu kaum verändert.

Bei den vor Kurzem für 2017 veröffentlichten Technologie-Trends sieht Gartner das Thema AI & ML als Top 1 und meint:

AI and machine learning have reached a critical tipping point and will increasingly augment and extend virtually every technology enabled service, thing or application.

In diesem Sinne folgen an Stelle 2 und 3 auch gleich die Themen „Intelligent Apps“ und „Intelligent Things“, welche letztendlich wieder stark auf AI basieren.

Howard Dresner schließt seinen Blog mit der Überlegung, das AI im BI-Umfeld ein Thema ist, wenn sie die Daten besser analysieren kann, als ein Mensch. Jedoch warnt er auch, dass AI trotz seines Alters (Ursprünge in den 50er-Jahren) heute keine reife Technologie ist und für Fehler sehr wohl anfällig sein kann, wie bspw. Microsoft im Frühjahr 2016 erfahren musste.

Was bedeutet dies nun für den klassischen SAP BI-Berater, der mit SAP BW, BEx und evtl. BusinessObjects BI unterwegs ist? HANA kommt, aber ist eben noch nicht überall angekommen. Bis zur BusinessObjects Cloud ist es für viele vor allem in Deutschland ebenfalls noch ein langer Weg. Und SAP Predictive Analytics ist aus meiner Erfahrung von der Lizenz her recht teuer.

Ich glaube zurück zur SAP BW Data Mining Workbench und zum Analyseprozessdesigner möchte auch niemand unbedingt. Die Automated Analytics-Ansätze richten sich schon an den Business User. Muss man dann evtl. nur noch technisch und bei der Bereitstellung der Daten unterstützen? Oder braucht man gleich die Weiterbildung zum Data Scientist?

Ich denke es sind einfach auch verschiedene Skills, wie auch verschiedene Anforderungen an die IT, die hier im Spiel sind. Trivial zu beantworten ist dies deshalb sicherlich nicht. Jedoch ist aus heutiger Sicht klar, alles, was eine SAP aktuell unter Analytics zusammenfasst, kann sowieso nur im Team abgedeckt werden. Dieses aufzubauen und zu strukturieren ist vielleicht die wahre Herausforderung.

SAP HANA 2

Am 08.11.2016 hat SAP zum Start der SAP TechEd Barcelona das Release 2 der HANA-Datenbank vorgestellt. Geplantes Releasedatum für Kunden ist der 30.11.2016. Kurz darauf soll es auch die HANA 2 Express Edition geben, um Entwicklern einen schnellen Zugriff zu ermöglichen.

Bernd Leukert hat HANA 2 wie folgt angekündigt und beschrieben:

“The first version of SAP HANA is the synonym for real time processing of data. It’s already the backbone of thousands of major companies,” said Leukert. “I’m proud to officially announce today SAP HANA 2, which will be released at end of November. This next generation of SAP HANA is the digital foundation to transform any business, helping IT shift focus to innovation, continuing to evolve data management and application development.”

Wer mag, kann sich hier direkt die Ankündigung anschauen.

Bzgl. Analytics soll HANA 2 folgende Erweiterungen liefern:

„Analytical intelligence: Developers are embedding rich insight into applications with enhanced analytical processing engines for text, spatial, graph and streaming data. For example, new algorithms for classification, association, time series and regression have been added to the predictive analytics library to empower data scientists to discover new patterns and incorporate machine learning into custom applications.“

Wenn auch der Zusammenhang aus den bisherigen Meldungen mir noch nicht ganz klar ist, hat SAP zeitgleich cloudbasierte SAP HANA Microservices im Bereich Analytics angekündigt:

  • TEXT ANALYSIS ENTITY EXTRACTION – Ein Service zum hervorheben wichtiger Informationen in unstrukturierten Daten.
  • TEXT ANALYSIS FACT EXTRACTION – Ein Service zur Sentimentanalyse, bspw. bzgl. eines Produktes oder eines vom Unternehmen angebotenen Services. Ebenso einen Service bzgl. Öffentlicher Veranstaltungen (Public Sector) bspw. zur Risikoabschätzung sowie einen Service zur Analyse von Unternehmensereignissen (Enterprise) wie personelle Veränderungen oder die Neueinführung von Produkten.
  • TEXT ANALYSIS LINGUISTIC ANALYSIS – Ein Service zur Sprachanalyse, bspw. um welche Sprache es sich handelt oder im Weiteren der linguistischen Analyse des geschrieben selbst.
  • Earth Observation Analysis Service – Ein Service zur Auswertung von Satelliteninformationen bzgl. der Erde. Aktuell in der Beta-Version.

SAP verspricht sich von einer Microservices Architektur Folgendes:

  • Independence from the business domain, devices, and environments
  • Nonproprietary environment that offers freedom to choose the programming languages and underlying database technologies as well as gaining portability of services and applications between cloud infrastructures
  • Prebuilt business processes that allows organizations to develop new ways to utilize application data and services easily and flexibly, and scale to changing requirements

Bis zur Veröffentlichung Ende November wird evtl. noch die eine oder andere Information zu neuen Features fließen. Ab 01.12.2016 informiert die SAP dann in 12 Webinaren über die Neuigkeiten.

Bis dahin bietet die aktuelle HANA 2 FAQ Antwort auf wenigstens ein paar Fragen.

SAP’s Wege zum Data Warehouse

Es ist immer wieder interessant, SAP dabei zuzuschauen, wie man aktuell z. B. im BI-Frontendbereich auf Vereinfachung (Simplification) setzt, andererseits im Bereich Data Warehouse einen Strauß bunter Lösungen entstehen lässt, der kaum noch überschaubar ist. Im Folgenden ein wenig die Geschichte, soweit diese für mich nachvollziehbar ist.

SAP BW erblickte 1997 mit dem Release 1.2A als Business Information Warehouse das Licht der Welt. Nach Jahren der Weiterentwicklung hat die SAP 2016 dem Produkt SAP BW ein Ende gesetzt, nur um es unter dem Namen SAP BW/4HANA neu auferstehen zu lassen. Aber das ist nicht die ganze Geschichte. Bereits mit dem Kauf von BusinessObjects und Sybase ließ sich bereits eine komplett vom SAP BW eigenständige BI- und Data Warehouse-Umgebung schaffen. Mit dem Aufkommen von HANA (als damals High-Performance ANalytical Applicance) war schnell klar, dass hier auch etwas neues entsteht. Und so bewirbt die SAP das HANA Data Warehouse, welches bereits 2013 von Thomas Zurek angedeutet wurde.

SAP BW stellen jedoch nicht die Ursprünge des Data Warehouses von SAP da. Bereits vorher war dies bei SAP vielfältig ein Thema. Geht man heute im SAP ERP durch den Customizing-Leitfaden, so findet man nach wie vor beispielsweise im Logistik-Umfeld das Logistics Data Warehouse.

Wenn man bei SAP also von Data Warehouse redet, muss man sich wirklich erstmal Fragen, welches man hier meint.

 

Pre-SAP BW (ERP DWH-Ansätze)

Ja auch heute noch stößt man bei vielen Unternehmen auf die verschiedenen Ausprägungen, welche noch deutlich weiter als das SAP BW zurückreichen. Da gibt es das Logistik-Informationssystem (LIS), welches für verschiedene Logistik-Module vorkonfigurierte, verdichtete Datenebenen bietet und quasi ein embedded Realtime-Reporting mit einer oft akzeptablen Performance liefert. Mit dem bereits erwähnten Logistic Data Warehouse, war (und ist) es möglich eigene Verdichtungsebenen und Fortschreibungsregeln zu definieren um dann flexibel darauf auswerten zu können. Wer BW-Releases vor 7.0 kennt und sich die Fortschreibung im LIS einmal angeschaut hat, wird überrascht gewesen sein und danach wissen, woher das Fortschreibungskonzept dafür stammte.

Auch vom CO-PA kennt man verschiedene Verdichtungsebenen und Auswertungswerkzeuge. Das Ganze gipfelt im EIS/FIS – also im Führungsinformationssystem, welches schon den Ansatz hat, sich auch den verschiedenen Informationssystemen oder auch externen Daten eine Datenbasis auszuwerten, welche flexibel ausgewertet werden kann.

Auch wenn hier Teile wie gesagt durchaus in vielen Unternehmen noch aktiv sind, so wurde doch irgendwann aus sicherlich vielfältigen und nachvollziehbaren Gründen (Performance, Systemlast, Flexibilität, …) entschieden einen Schritt weiter zu gehen. Dieser Schritt war SAP BW.

 

SAP BW

Wie anfangs erwähnt, hat das SAP BW seinen Anfang etwa 1997 oder 1998 mit dem veröffentlichen Release 1.2A. Das Projekt startete als “Reporting Server”, was möglicherweise die Grundlage für die bekannten RS*-Transaktionen gelegt haben dürfte.

Der Sprung zum Release 2.0 kam im August 2000 mit 2.0B, bei dem z. B. das Operational Data Store seinen Weg ins BW gefunden hat. Eine gewisse Erfolgsgeschichte, haben sich daraus doch 3 Varianten und zuletzt das Advanced DSO entwickelt. Im Dezember 2000 folgte bereits 2.1C.

Mit dem Release 3.0A wechselte der Name von Business Information Warehouse mit dem Akronym BIW zu noch kürzer BW.

Ein großer Sprung ereignete sich dann wieder März 2004. Damals kam das Thema Netweaver auf, und das BW-Release 3.5 war Teil von SAP Netweaver 2004.

Vermutlich am 06.06.2006 gab es ein einen großen Releasesprung. Zuerst unter dem Namen SAP NetWeaver 2014s BI capabilities (so wurde mir das damals von SAP gesagt 😉 ) sollte dies das Release SAP BI 7.0 werden. Eine kurze Periode, in der die SAP dem BW den Namen Business Intelligence verpasste. Kurz deshalb, weil SAP 2007 ein Übernahmeangebot für BusinessObjects machte und 2008 diese vollendete. BI wanderte vom BW zu BusinessObjects und das BW bekam mit dem Release 7.3 offizell wieder seine Bezeichnung BW zurück.

Noch ein wichtiger Meilenstein kam mit dem 7.0-Release. Der BWA (Business Warehouse Accelerator), damals noch unter dem Namen BIA (Business Intelligence Accelerator) wurde released. Der erste Ausflug in die In-Memory Welt für SAP BI/BW und der Vorläufer von HANA.

Mit dem Release 7.3 gab es neben der Rückkehr zum Namen BW auch noch zum nächsten großen Sprung. Mit SAP BW powered by SAP HANA. Mit SAP HANA hatte SAP Ende 2010 einen großen Schritt gewagt und heute, knapp 6 Jahre später fast ihre gesamt Produktstrategie darauf ausgerichtet. Nur etwa 1 Jahr später ging SAP BW 7.3 SP5 in den Ramp-Up für HANA.

Im März 2014 folgte das Release SAP BW 7.4. Dieses Release sollte die möglichkeiten von HANA deutlich besser ausnutzen und neue Features auf Basis der HANA-Technologie liefern. Als Enabler für das Logical Data Warehouse sollte es alle Daten als In-Memory Data Fabric in einen gemeinsam Kontext stellen.

Im Herbst 2015 wurde SAP BW 7.5 vorgestellt. Es soll das letzte seiner Art sein. Das Release wurde in 2 Modi vorgestellt. SAP BW 7.5 powered by SAP HANA und SAP BW 7.5, edition for HANA. Mit dem Modus “edition for HANA” leitete die SAP den nächsten Schritt ein. Ein SAP BW, welches nur noch die neuen, HANA-optimierten Objekte einsetzt und die bisher eingesetzten Modellierungsobjekte wie InfoCubes, Datastore-Objekt, InfoSet, MultiProvider usw. obsolet macht. Neben der Modellierung verändern sich auch auch die Schnittstellentechnologien sowie die Modellierungsfläche, welche für neue Objekte von Anfang an in der Eclipse-Umgebung zu finden war.

 

SAP BW/4HANA

Am 07.09.2016 wurde BW/4HANA offiziell vorgestellt bzw. Verfügbar gemacht. Erste Informationen dazu wurden ab 31.08.2016 bekannt gegeben.

Mit BW/4HANA wurde das SAP BW auf Wartung gesetzt und es wird kein Neues Release mehr geben. BW/4HANA gilt als neues Produkt. Als logischer, jedoch nicht rechtlicher Nachfolger. Das lässt sich leicht darauf erklären, hier eine Menge Code z. B. für die bisherigen Modellierungsobjekte sowie für die BEx-Suite entfernt wurde.

Eine gute Annäherung und Vorstellung, was BW/4HANA bedeutet, bekommt man über die rund um den Startzeitpunkt veröffentlichten Blogs:

Thomas Zurek:

Neil McGovern

Marc Bernard

 

SAP HANA Data Warehouse

Zum SAP HANA Data Warehouse habe ich bereits ein wenig geschrieben und möchte im Wesentlichen darauf und auf die Blogs von Thomas Zurek verweisen:

Thomas Zurek:

Sowie zusammenfassende Blog-Einträge von mir:

 

SAP (Sybase) IQ Data Warehouse

2010 hat SAP Sybase übernommen, welches im Bereich BI/Datenmanagement Lösungen wie Sybase IQ, den PowerDesigner und eine Lösung für Complex Event Processing beisteuerte.

SAP IQ ist im BW-Umfeld am ehesten als Datenbank für Nearline-Storage (NLS) bekannt. Die Datenbank ist spaltenbasiert und auf sehr große Datenmengen (Petabyte). Zuletzt 2014 hat SAP IQ im Zusammenspiel mit SAP HANA einen neuen Weltrekord für das weltgrößte Data Warehouse mit 12,1 Petabyte aufgestellt.

Des weiteren dürfte SAP IQ im Frontendbereich bei SAP Lumira eine gewisse Bekanntheit haben, sollte man sich fragen, wo eigentlich die ganzen Daten gespeichert und verarbeitet werden, welche in die Lumira Desktop-Version integriert werden.

Schaut man sich die lose gekoppelte Umgebung des HANA DWH an, dann liegt der Gedanke nahe, dass man hier eigentlich eine HANA auch gegen eine SAP IQ austauschen könnte. Das scheint aber bei der SAP kein populäres Konzept zu sein.

Eher findet man die Datenbank zur Entlastung von HANA als schneller Nearline-Storage, welcher im Multi-Temperature-Konzept der SAP den Bereich der kalten Daten (cold) abdecken soll.

Alternativ zu IQ als NLS kommt auch immer öfters Hadoop ins Spiel. Vor allem, wenn man über Big Data spricht. Mit HANA Vora hat die SAP hier ja sogar einen eigenen Ansatz vorgestellt.

 

SAP BW/4HANA

Am 31.08.2016 wurde SAP BW/4HANA vorgestellt. Wie SAP S/4HANA ist BW/4HANA ein nur auf HANA laufendes SAP-System. Genau wie S/4 HANA gilt BW/4 HANA NICHT als legaler Nachfolger des SAP BW on HANA. Zukünftige Entwicklungsressourcen werden ganz klar in BW/4 HANA fließen und alle bisherigen SAP BW-Versionen gehen in die Wartung über. Mit dem neuen System wird der Ansatz, welcher mit SAP BW 7.5 begonnen und kurzzeitig unter dem Namen B/4 HANA diskutiert wurde, konsequent fortgesetzt.

SAP sieht das System als „next-generation data warehouse application for running a real-time digital enterprise„:

SAP BW Generationen

Copyright: SAP 2016

SAP möchte damit das Logical Data Warehouse, cloudbasiert (aber zur Not auch On-Premise) und mit HANA Vora für den Data Lake ermöglichen. Man möchte fast sagen: Cloud-, HANA, Big Data-First heißt das Motto.

Nach allem was ich bisher so gesehen habe, lassen sich die wirklichen Neuerungen auf folgende Punkte zusammenfassen:

  • Nur noch HANA, keine andere DB mehr
  • Der Support für SAP BW 7.5 on Any DB endet 2024
  • Kein Legacy-Code (kein InfoCube, Standard DSO, InfoSet, … mehr)
  • SAP NetWeaver wird nicht mit BW/4HANA ausgeliefert
  • Die BEx-Suite wird nicht weiter unterstützt
  • Es werden nur noch ODP-DataSources für SAP-Quellsysteme unterstützt

Die SAP hat zur Veröffentlichung am 31.08. eine zentrale Seite im SCN mit einer Menge weiterführender Informationen eingerichtet.

Auch hat Thomas Zurek (VP of SAP HANA DW) die Neuerungen präsentiert. Jedoch aus meiner Sicht nur weitgehend die Entwicklung zusammengefasst, welche mit BW on HANA zuletzt bereits sichtbar war. Mittlerweile (05./07.09.) hat er jedoch noch etwas nachgelegt und auch das Warum? und den Datenmodellierungsansatz näher erläutert.

Doppelt fleißig war man bei der FAQ. Neben der SAP hat auch John Appleby eine solche zur Verfügung gestellt.

Jetzt sind aber nicht alle ganz so unkritisch, wie bspw. die ASUG, die der SAP News-Meldung kaum nachsteht. Die DSAG mahnt gleich an, bestehende Kunden nicht zu vergessen. Nicht zu unrecht, bedenkt man, dass mit der Ankündigung gleich mal die Weiterentwicklung der SAP BW-Schiene on Any DB ein Ende gesetzt wurde.

Als Berater darf man sich freuen. Sind doch bis 2024 eine Menge BW-Migrationen und ein steigender Beratungsbedarf zu erwarten. Schließlich sind aktuell im Jahre 4 nach BW on HANA gerade mal gut 20 % der SAP-Kunden (3.700 von 17.000) auf HANA. In den nächsten Jahren müssen damit pro Jahr ca. 2.000 BW-Systeme releasegewechselt und auf HANA gebracht werden, womit sich die bisherige Geschwindigkeit verdoppeln würde.

Große Diskussionen kann ich bisher nicht sehen. Fragen, welche gestellt werden sind z.B.:

  • Was sind die Hauptunterschiede zwischen BW 7.5 und BW/4HANA?
  • Laufen auf BW/4HANA weiterhin alle Add-Ons? (SAP Note -> 2189708)
  • Welches Release wird in welche Situation empfohlen?
  • Wie passt das neue Release mit der Übernahme des Big Data-as-a-Service Anbieters Alticscale zusammen?

GA des SAP BW/4HANA 1.0 wird groß zusammen mit Amazon am 07.09.2016 gefeiert. Weitere wichtige Erweiterungen werden dann für Q4/2016 – Q2/2017 erwartet. Auf weitere Informationen in den nächsten Tagen, Wochen und Monaten kann man also gespannt sein.