IDAREF als Lösung für Big Data und DWH Architektur Herausforderungen

Business Intelligence, Datawarehousing, Reporting, Dashboarding, Data Mining usw. sind alles Schlagwörter mit welchen sich in den letzten 20-30 Jahren ganze IT- und Business Organisationen beschäftigt haben.

In dieser Zeit haben sich verschiedene Industrievertreter hervorgetan, um eine gewisse Standardisierung von solchen Projekten und Architekturen zu etablieren. Die wichtigsten dieser Vertreter sind Dr. Ralph Kimball mit seinem Ansatz der dimensionalen Modellierung und dem Conformed Stammdatenbus und Bill Inmon mit seiner Corporate Information Factory (CIF), welche auf einem 3NF-EDW Core Modell basiert. Weiter zu erwähnen gibt es den Data Vault Ansatz von Dan Linstedt der immer wichtiger wird und immer öfter in Projekten angewendet wird. Data Vault ist vor allem eine Core DWH Modellierungstechnik, welche im Frontroom mit Kimball ergänzt wird. Zudem gibt es von Softwareherstellern verschiedene weitere Ansätze, welche dem einen oder anderen Herren etwas näher liegen (z.B. Teradata Solution Methodology oder SAP BW Large Scale Architecture LSA++)

Man könnte daher meinen, dass solche Projekte und Architekturen mittlerweile zur Routine geworden sind, dass sich eine Methodik, ein Standard durchgesetzt hat. Das ist jedoch weit gefehlt. Alle der 3 oben genannten Herren haben es nicht geschafft, einen einheitlichen Industriestandard für DWH Projekte und Architekturen zu etablieren. Zu gross sind die Interpretationsmöglichkeiten der Ansätze und ihre Basisphilosopien widersprechen sich teilweise von Grund auf (3NF vs. Denormalisierung / Modell all vs. modell the required / Bottom-up vs. TopDown etc.). So passiert es in der Praxis oft, dass in Projekten ein regelrechter religiöser Streit entbrennt, wie man ein DWH bzw. eine DWH Architektur aufbaut bzw. modelliert.

Weiter stellt man als Berater in der täglichen Arbeit immer wieder folgende schwerwiegenden Mängel in der Erstellung von DWH‘s fest:

• Keine standardisierte Vorgehens- und Modellierungsmethodik
• Schwaches Daten-, ETL- und Infrastrukturarchitekturmanagement
• Schwach ausdefinierte Organisation sowohl auf IT- wie auch auf Businessseite (fehlendes Projektmanagement, fehlen verschiedener fachlicher Rollen wie z.B. Data Steward, Daten-, ETL-, Business Analyst, Infrastruktur-Architekt, Sponsor etc.)
• Sehr schwammig definierte Anforderungen
• Short-cut bzw. Quick&Dirty Implementationen, dies einerseits wegen fehlenden zeitlichen und finanziellen Ressourcen und andererseits wegen fehlenden Skills
• Mehrere historisch gewachsene DWH’s in derselben Firma > führt zu sehr viel politischen Diskussionen

Vielfach führen oben genannte Schwächen zu erheblichen Problemen im Bereich der Nachhaltigkeit, der Akzeptanz, der Performance, von längeren Projektlaufzeiten, von höheren Wartungsaufwänden, zusammengefasst zu einem überdurchschnittlich hohen TCO.

Weiter erschwerend kommt hinzu, dass DWH’s oft zum Zwecke von Datenqualitätsmanagement-, Datenintegrations- und Datenverteilungsplattformen (zentraler Data Hub) eingesetzt werden. Zudem sind in den letzten Jahren verschiedene industrielle Trends entstanden, wie z.B.

• Big Data / Unstrukturierte Daten
• Data Scientist (Datenwissenschaftler)
• Agile DWH
• Real-Time / Data Streaming Analytics
• Standardisierung / Industrialisierung von BI/DWH

Die erweiterten Anforderungen und die Trends der letzten Jahre stellen die bestehenden DWH Architekturen auf eine massive Bewährungsprobe. Diese Tatsachen erfordern ein Umdenken, ein Paradigmawechsel, wie wir in Zukunft effiziente und agile DWH-, Datenintegrations- und Big Data-Architekturen erstellen, welche einen tiefen TCO aufweisen.

Aufgrund dieser verschiedenen Missstände, Erfahrungen aus Projekten in der Praxis, der erweiterten Anforderungen und den Trends der letzten Jahre, haben wir als IT-Logix AG ein Data & Analytics Reference Architecture Framework (IDAREF) entwickelt. In dieses Framework sind ca. 15 Jahre Projekterfahrung aus duzenden von DWH- und Datenintegrations-Projekten eingeflossen. Zudem trägt dieses Framework allen zurzeit vorherrschenden Trends (Big Data, Data Science, Real-Time/Data Streaming Analytics, Unstrukturierte Daten, Agilität, Standardisierung etc.) Rechnung.

Bei der Benennung des Frameworks wurden bewusst die beiden Terms Data und Analytics eingesetzt, da dieses Framework einerseits den erweiterten Anforderungen und den Trends Rechnung tragen soll und anderseits auch als Datendrehscheibe ausserhalb von analytischen Anforderungen eingesetzt werden kann. Dies hat zum Namen „IT-Logix Data & Analytics Reference Architecture Framework (IDAREF)“ geführt.

Das Framework basiert auf einem Layerkonzept (z.B. ODS, Core, DWH etc.), welches genau beschreibt, welche Services pro Layer zu erwarten sind, wie die Datenmodellierung gemacht wird und wie die ETL Architektur aussieht. Das an sich ist nichts Neues. Wo sich das Framework aber von anderen Standard DWH Architekturen differenziert sind folgende Tatsachen:

• Es werden verschiedene Eingangspunkte und „Short-Cut“ Architekturen bewusst zur Verfügung stellt. Beispielsweise wird bewusst erlaubt, Reporting auf den operativen Systemen zu betreiben. Dies hat aber verschiedene Nachteile zur Folge, wie z.B. dass die Maintenance steigt, das Know-How über das operative System sehr gross sein muss, dass Business Logik mehrmals abgebildet werden muss, dass die technischen Skills von Business Usern höher sein müssen usw.
• Es können direkt SLA’s (z.B. Timeliness, Level of Integration, Level of Quality, Projekt Lieferzeiten etc.) abgeleitet werden, je nachdem welchen Architekturweg man einschlägt.
• Das Framework ist sogenannt „tailorbar“. Dies bedeutet, dass man je nach Anforderung klein einsteigen kann bzw. nur einen Teil des Frameworks zu Beginn eines Projektes implementieren muss und die Gesamtarchitektur mit steigenden Anforderungen über die Zeit wachsen lassen kann.
• Das Framework ist auf einem logischen Layer angesiedelt und ist somit produktneutral. Das Framework kann je nach Kundenwunsch mit Produktnamen versehen werden (z.B. die ODS wird in Hadoop gespeichert, die Daten werden mittels SAP Data Services / SAP SLT / Sybase Replication in die ODS geladen, die virtuelle Integration wird mit SAP BO Universes gemacht, als Frontend kommt je nach Use Case SAP BO Webi, SAP Design Studio, R/Shiny, SAS zum Einsatz usw.)
• Oftmals bestehen bereits ein oder mehrere DWH‘s in einer Firma. Durch ein evolutionäres Wachstum der Plattform passiert es meist, dass mit der Zeit die Maintenance sehr kostenintensiv wird und die Anpassungsfähigkeit für erweiterte Anforderungen bzw. die Erweiterbarkeit auf vorherrschende Trends eingeschränkt ist. Hierbei kann dieses Architekturframework als SOLL-Architektur herangezogen werden, um so einen SOLL-IST Vergleich der bestehenden Architektur zu ermöglichen. Daraus kann anschliessend ein Projektportfolio und eine Projektroadmap abgeleitet werden, um phasenweise auf diese SOLL-Architektur zu wachsen.
• Das Framework macht sehr konkrete und strikte Vorgaben pro Layer, welche Services angeboten werden, wie die Modellierung auszuführen ist, wie die Implementation der ETL Prozesse umzusetzen ist, wie die Daten pro Layer zur Verfügung gestellt werden usw.
  Somit erhält das Framework annähernd den Charakter von Standardsoftware. Dies hat einerseits zum Vorteil, dass konzeptionelle und vor allem philosophische Diskussionen wie man eine Data & Analytics Plattform baut, der Vergangenheit angehören. Jedoch haben die strikten Vorgaben auch zum Nachteil, dass es wenig Freiheitsgrade in Bezug auf „Customizing“ gibt bzw. es wird nicht empfohlen, Anpassungen in Basisservices zu machen, da sonst die aufeinander abgestimmten Services pro Layer nicht mehr zusammen passen könnten und somit das Framework aufbricht und so der TCO erhöht wird.
• Durch die Standardisierung der Architektur und der Governance wird die Agilität massiv erhöht und so ein massiv tieferer TCO erreicht, da konzeptionelle und vor allem philosophische Diskussionen, welche oft auch zu politischen Grabenkämpfen führen, der Vergangenheit angehören.
• Das Framework zeigt auf, welche Anforderungen aus Sicht Skills, Projektaufwand, Maintenance und Governance zu erwarten sind, wenn ein bestimmter Architekturweg gewählt wird bzw. eine bestimmte Anforderung vorhanden ist.

Das Framework bildet somit eine Grundlage für die Weiterentwicklung von bestehenden DWH Architekturen und gibt eine Antwort auf alle vorherschenden Trends und Herausfoderungen in einer Datenladenschaft. Dies erlaubt auch in Zukunft agil und mit einem tiefen TCO eine Datenladenschaft weiterzuentwickeln und betreiben zu können.