Projekt Data Warehousing. Ich habe grade mal wieder eine Abfuhr bei einer Bewerbung bekommen, die Hürde des Recruiters nicht geschafft. Da klang recht unverblümt ein freundlich verpacktes unqualifiziert heraus. Als Rentner sollte man doch das machen, was von einem erwartet wird: Zuhause rumsitzen und auf den Tod warten. Drauf ein fröhliches jetzt erst recht!
Um es vorab zu klären: Beim Data Warehousing handelt es sich um strukturierte Daten, also um Daten, die in definierten Datensätzen innerhalb von Tabellen geordnet sind. Hier liegt auch der große Unterschied zum Datamining, wo unstrukturierte Daten, z. B. eingehende Mail oder Rückmeldungen über ein Portal ausgewertet werden.
Für mich selbst ist SAP BW auch deshalb faszinierend, weil es genau dort ansetzt, wo die in einem Unternehmen anfallenden Daten auf ein für das Reporting notwendiges Minimum reduziert und harmonisiert werden. Je höher die Stellung in der Krawattenhierarchie eines Unternehmens, desto höher der Abstraktionsgrad, desto höher die Anforderungen an die Datenbereitstellung. Data Warehousing mit SAP BW ist letztendlich Business, gepaart mit etwas Technik und einem Hauch von Programmierung. Datenflüsse werden mit vorgegebenen Elementen modelliert. Das hat dem Flair von Lego. Wichtig ist dabei eine Kenntnis der Datenquelle und dessen Datenbankaufbau plus der notwendigen Datenkonstellationen, die den gewünschten Informationsinhalt liefern. Um Daten erweitern zu können, besitzt ein Datenfluss die Möglichkeit, Daten über ABAP zu ergänzen. Die Anforderungen an eine formale ABAP-Programmierung auf einem SAP BW kriege ich noch nach einer halben Dose Bier hin, nach der zweiten Dosenhälfte schlafe ich eh ein.
Ich hatte es schon angesprochen, beim Data Warehousing geht es im Kern um Fragen des Business. Ich selbst habe über vier Jahrzehnte in der Elektrizitätsversorgung gearbeitet. Ich beziehe mich also auf genau diese Branche, die einige produktspezifische und juristische Besonderheiten hat. Die gehören allerdings nicht zum Umfang dieses Projektes, es würde den Umfang sprengen. Es kann also sein, das angesprochene Fragestellungen manchmal etwas branchenspezifisch sind.
Roadmap
Das Thema ist durchaus komplex und um mich jetzt nicht vollkommen zu verzetteln, greife ich auf ein altes Werkzeug zurück: Die Roadmap, einen Plan mit Bereichen, die ich für mein Ziel ansprechen muss. Eine Agenda, die das enthält, was der Kern für das Verständnis eines Unbeteiligten am Thema ist und was das Verständnis fördert. Damit ergibt sich automatisch auch, was für mein Thema irrelevant ist. Das ist ein Plan, kein in Stein gemeißeltes Glaubensbekenntnis. Mir ist das Thema aus der Vergangenheit bekannt, das bedeutet aber nicht, dass im Projektverlauf nicht neue Erkenntnisse, neue Sichtweisen auftreten können.
Nun zur Roadmap: SAP Data Warehouse gehört zum Themenkomplex Data Warehousing, auf deutsch Datenlager. Es handelt sich um die Lösung eines Herstellers, der SAP. Eine recht noble und entsprechend teure, wie ich zugeben muss. Da sind zunächst die Fragestellungen nach dem Was und dem Warum. Was ist ein Data Warehouse? Warum betreibe ich den Aufwand? Kann ich ein Data Warehouse auch ohne spezielle Software aufbauen? Wo unterscheiden sich Datenlager von aktiven, transaktionalen Systemen? Das ist noch recht allgemein, gehe ich weiter auf mein Thema zu, komme ich um das Trägersystem der SAP nicht herum: SAP HANA. Ein technischer Leckerbissen mit Ecken und Kanten. Zum Schluss natürlich mein Thema SAP BS4/HANA in der derzeit aktuellen Version 2.0. Das ist keine Lösung, die Reif vom Baum gefallen ist. Ich selbst habe die Entwicklung bis zum Vorläufer ab der Version 1.x (nie Lauffähig) bis hin zu 7.5 aktiv als Entwickler und Supporter gelebt.
Parallel zu diesem Projekt läuft ein weiteres im Bereich Fotografie, um mir entsprechendes Bildmaterial anzufertigen.
BTW: Dieses Projekt dient auch dazu, eine Form der Darstellung heraus zu arbeiten.