Operational BI: Vergleich und Auswahlkriterien von

CEA v6.4

München, 25. Juni 2009

Andreas Pabst

Operational BI: Vergleich und Auswahlkriterien von Techniken und Technologien

CEA v6.425.06.2009

DOAG - VORTRAG JUNI 2009 V2.0.PPT

Titel / Thema

Operational BI: Vergleich und Auswahlkriterien von Techniken und Technologien

• Operationalisierung von Business Intelligence bedingt die Bereitstellung von Daten in angemessener Aktualität. Der Vortrag befasst sich den relevanten Konzepten zur Datenintegration und –präsentation und entwirft Bewertungskriterien zur Auswahl geeigneter Techniken und Technologien.

• Im zweiten Teil erfolgt eine Gegenüberstellung etablierter Technologien in den Produkten der Hersteller Oracle und SAP/Business Objects sowie Erfahrungsberichte aus aktuellem Projektumfeld.

Erwartungshaltung / Abgrenzung:

• Wir stellen keine grundlegend neuen Konzepte und Aspekte vor. Der Vortrag ist ein Versuch der Systematisierung gepaart mit Best Practices.

• Inhalt des Vortrages:

– Gegenüberstellung bekannter Konzepte, Technologien und Architekturen,

– Bewertung und daraus abgeleitete Empfehlungen sowie Entwicklungstrends.

– Betrachtung der Produktpalette von Oracle und SAP/BO hinsichtlich abgedeckter Technologien

• Abrundung des Vortrages: Vorstellung von Integrationslösungen in Projekten (Fallstudien).

CEA v6.425.06.2009


Agenda

• Operational Business Intelligence

• Architektur, Technik & Technologien für operational BI

• Bewertungskriterien, Bewertung

• Produkte für operational BI

• Fallbeispiele

CEA v6.425.06.2009


Operational Business Intelligence

Definitionen, Begriffe

• Operational BI

– stellt Informationen und Erkenntnisse einer breiten Menge von Anwendern in kurzer Zeitspanne für das Management und die Optimierung von zeitkritischen Geschäftsprozessen zur Verfügung

– ist i.G. zur traditionellen BI nicht reaktiv ausgerichtet, sondern unterstützt Entscheidungsabläufe während des Geschäftsprozesses; befähigt die Anwender damit zur proaktiven Arbeit (vorausschauend)

– bedient sich dabei konsolidierter, historisierter und analysierter Daten aus analytischen Systemen (DWH, ODS, Datamarts)

- Erkennen operationaler Ereignisse

- Verknüpfung mit (vorberechneten) analytischen Daten

- Rückmeldung der Informationen / Entscheidungen an die operative Ebene

– Das DWH ist für die Bildung des historischen Kontextes notwendig, nicht aber für die operationalen Daten selbst.

– bedingt die direkte Verknüpfung von dispositiven und operativen Daten

- i.G. zu Workflow-Konzepten in den Geschäftsprozessen, die nur mit operativen Daten arbeiten

- i.G. zu real-time DWH (i.S. klass. DWH, das real-time Daten verarbeiten kann)

Definition des TDWI:

„Operational BI delivers information and insights to a broad range of users within hours or minutes for the purpose of managing or optimizing operational or time-sensitive business processes.“

[TDWI; Eckserson, W.; siehe (10)]

CEA v6.425.06.2009



Die drei Ebenen von Business Intelligence

geringe Kontrolle der Datenqualität

Kaum Reproduzierbarkeit von Berichten

Hohe Datenaktualität (z.B. letzte 5 Minuten) und Verfügbarkeit

Benötigt höhere DQ / führt zu hoher DQ

Reproduzierbarkeit von Berichten

Moderate Datenaktualität (z.B. Vortag)

Benötigt höhere DQ / führt zu hoher DQ

Reproduzierbarkeit von Berichten nötig zwecks Nachvollziehbarkeit von strategischen Entscheidungen.

moderate Datenaktualität (z.B. Vortag)

Anforderungen

Echtzeit-,kurzfristige und historische Daten

mittl. / unteres Management, Sachbearbeiter und operationale Prozesse

tägliches operationale Geschäft

Fokus auf Aktualität und Automatisierbarkeit. Daher keine Einbindung manueller Schritte wie Freigabe, Kommentierung. Fokus auf dem Wertschöpfungsgrad „Information“

historischmittleresManagement, Analysten

taktische Initiativen

Herunterbrechen strategischer Ziele auf Kampagnen und Initiativen. Definition und Management des operativen Geschäftes.

historischTop-Management, Analysten

strategische Ziele, Wertschöpfungskette

Durch fachliche Validierung (Freigabe von Kennzahlen, Kommentierung von KPIs) entsteht aus Information das höherwertige Wissen. Darauf beruhen strategische Entscheidungen

DatenBenutzergruppeBusiness Fokus

CEA v6.425.06.2009



• Datenlatenz: Verzögerung zwischen dem Zeitpunkt der Datenänderung in der Quelle und dem Zeitpunkt der Bereitstellung der geänderten Daten im Ziel.

• Der Wert von operativen Informationen sinkt, je älter diese werden. Deswegen muss die Latenzzeit zwischen Ereignis und Reaktion minimiert werden.

• Die Datenlatenz ist das wichtigste Bewertungskriterium für Datenintegrationstechnologien / -architekturen.

• Die maximal akzeptable Latenz liegt entsprechend den fachlichen Anforderungen im Bereich von wenigen Sekunden bis hin zu einem Monat.

In diesem Zusammenhang gebräuchliche Begriffe:

• Realtimebei null Latenz

• Near Realtimebei geringer Latenz (Sek. bis Std.)

• Righttimebei einer Latenz, die den fachlichen Anforderungen gerade gerecht wird

Der Wert von operativen Informationen sinkt mit der Latenz.

CEA v6.425.06.2009



Varianten von operational BI

• Level 1: Analyse operationaler Prozesse Reporting direkt auf dem Quellsystem oder auf Replikaten

• Level 2: Performance-Monitoring; Signalisierung der Abweichungen (Alerting)

• Level 3: Unterstützung operationaler Prozesse durch Einbettung von BI in den Prozess

• Level 4: Ausführung (Automatisierung) des operationalen Prozesses

CEA v6.425.06.2009


Agenda





• Fallbeispiele

CEA v6.425.06.2009


Architektur, Technik & Technologien für operational BI

Technologien für Datenintegration

Merkmale

ETL/ELT

EII

EDR

EAI

• Extrahieren, Transformieren, Laden von Daten (Persistieren)• Komplexe Transformationen, Datencleansing möglich• performant für Massendaten / effizient für grosses Datenvolumen• Last auf Quellsystem während der Extraktion

• Anfrage wird in Sub-Anfragen an die Quellsysteme aufgeteilt• Server setzt die Teilergebnisse zum Gesamtergebnis zusammen• einfache Transformationen• Cache kann Verfügbarkeit / Performance optimieren• Problem: Datenqualität kann nicht bedient werden (muss bereits vorhanden

sein)

• Replikation (Kopie) aus einem System in andere• i.d.R. keine Transformation, keine Konsolidierung, keine DQ• geringe Latenz

• Austausch zwischen Systemen (der operativen Ebene)• Hub&Spoke-Architektur, Minimierung der Anzahl von Schnittstellen• Geringe Transformation mgl. • Ausgelegt für viele Einzeltransaktionen • Nicht ausgelegt für Massendaten

CEA v6.425.06.2009


• spezielle Technik zur Ermittlung von Datenänderungen, basiert auf Replikation• eine Capture-Aktivität protokolliert zeitnah alle Datenänderungen der Quelle in eine Stage (Push)• Datenziel holt synchron oder asynchron die Änderungen (Pull)• CDC repliziert lediglich – keine Integration in das Ziel• CDC repliziert fast immer identische Strukturen (Tabellen)

Datenintegration

Datenquellen

Push Ansatz

Quell-system

Datenziele

Protokollierung der Datenänderungen

Pull Ansatz

Datenkonsolidierung

DWH

Staging Area


Change Data Chapture - Funktionsweise, Varianten

1) Trigger- und application based CDC

– Changes werden direkt durch die Anwendung oder indirekt durch Trigger in Tabellen getrackt

– bspw. SAP Change Log bzw. Oracle Synchron. CDC

2) Audit-based CDC

– Tabellen werden um zusätzl. Spalten erweitern (Timestamps oder Change Tracking Version-Nr)

– Darüber werden die Änderungen erkannt

3) Snapshot based CDC

– Vergleich zweier Datenkopien (Snapshot) zum Erkennen der Änderungen

4) Log-based CDC

– Auswertung des Logfiles der Anwendung bzw. Datenbank

– bspw. Oracle Asynchronous CDC

Variante 4) erscheint als die am geeignetste Variante:– Keine Codeänderung notwendig– geringe zusätzliche Resourcenbelastung (DB-Logs existieren sowieso für Transaktionsabsicherung)– Asynchroner Modus: keine Beeinträchtigung der originalen Transaktion

CEA v6.425.06.2009


Anwendungs-

kern

ODS

DWHETL

CDC

Middleware

Quellsystem

ETL

Replikat

BI Server

(EII)


potentielle* Elemente einer Datenintegrations-Architektur für operational BI

real-time Systemanteil (Hochverfügbar, gerige Latenz)

* Die hier dargestellten Elemente können einzeln oder in Kombination Teil einer Architektur für operational BI sein.

CEA v6.425.06.2009


Agenda





• Fallbeispiele

CEA v6.425.06.2009


Bewertungskriterien, Bewertung

Kriterien Ausprägungen

Performance

Anwender

Funktional

Architektur

• Latenzzeit (near realtime) – hinsichtlich Konsolidierung (Datenintegration, hoher Durchsatz)– hinsichtlich Föderation (kurze Antwortzeit, Abfrage-Performance)

• Skalierbarkeit

• wachsende Anzahl und veränderte Profile (Rollen) • Zielgruppe: operat. Sachbearbeiter und operat. Prozesse

• einzelne Transaktionen (kleine Datenmengen pro Ereignis)– Abstriche bei Komplexität von Transformationen wg. Latenz

• Fehlerhandling (schnellere Prüfungen und Cleansing) – gute Datenqualität sollte daher bereits in den Quellen vorliegen

• kontinuierliche, ereignisgesteuerte Datenintegration(statt zyklisch, zeitgesteuert)

• Erfassung aller Ereignisse (Änderungen)• SOA (Services als Datenquellen, BI-Services)

Bewertungskriterien ergeben sich aus den Anforderungen an Datenintegration und

-bereitstellung für operational BI

Betrieb

• Hohe Verfügbarkeit (SLA‘s)• Backup / Recovery (im Fehlerfalle muss das Recovery schneller

erfolgen als im traditionellen BI)• Belastung der operationalen Systeme gering/konstant halten

CEA v6.425.06.2009


Strategische

BI

Bewertungskriterien, Bewertung

Aktualität der Daten

Granularität der Daten

Performance (Durchsatz) /

Volumen pro Transport

Performance (Antwortzeit)

Benötigte DQ

Verfügbarkeit

hochniedrigAnforderungskategorien

Anforderungsprofile für operationale und analytische Datenintegration

Datenintegration

operationaler Systeme

Operational

BI

CEA v6.425.06.2009


Agenda





• Fallbeispiele

CEA v6.425.06.2009


Produkte für operational BI

Produkt/Technologie-Matrix Oracle vs. SAP/BO

• BO Data Federator(Federation Server, kein Tool)

• Oracle BI EE (Frontend Tool)• EII (Positionierung: Frontend)

• Multi- / virtuelle Provider (SAP BW)

• Virtuelle Cubes (Hyperion Essbase)• Oracle Heterogenous Services

• EII (Positionierung: Datenhaltung)

• Oracle Fusion Middleware

• Oracle Change Data Capture• Streams• Advanced Replication• MViews

• Oracle Warehouse Builder(DB-zentriert)

• Oracle Data Integrator

Oracle

• SAP XI• EAI

• SAP Change Log• EDR

• BO Data Integrator(Engine-basiert)

• ETL

SAP / BOTechnologie

CEA v6.425.06.2009


Produkte für operational BI

Produkttrends

CEA v6.425.06.2009


Agenda





• Fallbeispiele

CEA v6.425.06.2009


Fallbeispiele

Unternehmensberatung – operationales Reporting, near-realtime ETL

Update

• Inhalt: Bewertung von Beratungsleistungen; Fragebögen, Geschäftsprüfungen

• operationales Reporting: Bewertung von Ereignissen gegenüber anderen: wie stellt sich eine gegebene Antwort gegen die anderer.

• Near-realtime: Latenz < 5 Minuten

• Web-Anwendung, einige Hundert Anwender.

• Wegen der Komplexität der Transformation wurde hier ETL als Technologie gewählt.

• Aspekt: CDC vor Transformation ins Zielmodell (Standard)

3NF

Dimensionales Modell

Änderungen werden durch Anwendung selbst geschrieben (synchrones CDC mit Triggern) tgl. ca. 10.000 Ereignisse

OWB pullt alle 4 Minuten. Laufzeit ca. 90 sek. Komplexe Transformation: Umfangreiches Datenmodell wird denormalisiert (Baumstrukturen aufgelöst, mengenwertige Attribute transformiert)

CEA v6.425.06.2009


Update MView Logs

Fallbeispiele

Finanzdienstleister – operatives Reporting für Risikobewertung

und Preisfindung mittels CDC und Föderation

Real-Time-Reporting im BW:

Daten im InfoCube werden tgl. aktualisiert.Änderungen im Quellsystem (Oracle-DB) nach dem letzten Refresh werden über Virtual Provider gelesenMulti Provider fasst beide Quellen für Report zusammen

Transformation Quell-� Zielmodell

Oracle synchr. CDC Trigger) übernimmt die Änderungen des transformierten Modelles

Dimensionales Modell

3NF

Stornosätze und neue Buchungen generieren via Views.

• Aspekt: CDC nach Transformation ins Zielmodell

CEA v6.425.06.2009


Fallbeispiele

Logistik – Tracking & Tracing

• Kunden & Partner können über das Web den Status der Sendungen verfolgen.

• Near-realtime: 15 Minuten• ODS: Integration auf

Quellsystem-Ebene• Datamart: Historisierung,

Aggregation, Analyse• Visibility: Detailsicht markierter

Objekte• Dashboard: aggregierte Sicht• Alerting: ereignis-/zeitbezogen• kaum Tools, Performance

durch Bordmittel (Bitmap-Idx)

tgl. Bewegung:- 100.000 Sendungen - 500.000 Statusmeldungen - 1 GB DB-Wachstum

500.000 Events (Statusmeldungen) täglich

ca. 50.000 Monitoring Regeln

30.000 Alerts / Confirmations tgl.

1.5 GB Flatfile Import am Tag

Bestand: - 30 Mio Sendungen - 170 Mio Statusmeldungen- 1 TByte

Klass. DWH / BI

Operativ. Monitoring

Operativ. Alerting

CEA v6.425.06.2009


Fallbeispiele

Chemie/Pharma – operatives Reporting auf Basis Data Federation (virtual Provider)

• Data Föderation, operationales Reporting

• SAP 3.5, virtuelle Provider (BAPI) mit Zugriff auf verschiedeneexterne Quellen

• Stammdaten liegen in SAP, alle anderen Daten virtuell

• Einsatz: für Drill-Through auf die operative Ebene

CEA v6.425.06.2009


Alle Technologien in Erwägung ziehen

Trend SOA

Datenintegrations-Plattform

• Traditionelle Trennung operativ / analytisch wird durchbrochen– Closed Loops– Operationalisierung der BI

• Klassisches DWH / ETL konzeptionell für operational BI ungeeignet Unterschiede in Zweck und Anforderungen

• Verlagerung von Transformationslogik in die operationale Ebene gewährleistet Konformität der Transformationen für operationale und analytische Ebene

• Domänenkonzept und MDM gewährleistet unternehmensweite Datenqualität

• Herstellertrend

• alle relevanten Technologien werden abgedeckt,

• einheitliche Metadaten

architektonische Trennung von analyt. und operat. BI

• eigener Systemanteil (Datenhaltung, Datenintegration).

• Operat. BI verstehen als weitere Datenquelle für das klassische DWH

• nur dieser operationale Systemanteil muss hochverfügbar sein, nicht das gesamte DWH.

Zusammenfassung

Datenintegration und –präsentation für operational BI

CEA v6.425.06.2009


• tatsächlich benötigte Latenz

• benötigte Datenqualität

• Lastprofil (bspw. Anzahl User)

• ...

Es gibt keine Lösung für alle Fälle. Abwägen!

• Komplexität an Transformation

• vorhandene Datenqualität

• Belastbarkeit operationaler Systeme

• SOA-Einführung?

• ...

Fazit

Was habe ich?

Was benötige ich?

CEA v6.425.06.2009


Quellen(1) Operational Data Integration – A New Frontier for Data Management; Philip Russom

TDWI Best Practices Report 2nd. Qu. 2009

(2) Innovative Prozess-Steuerung; Prof. Dr. Peter Gluchowski, Prof. Dr. Hans-Georg Kemper, Prof. Dr. Andreas SeufertBI Spektrum 01/2009

(3) Was macht Operational BI aus? Dr. Andreas Bauer, Dr. Thilo SchmidBI Spektrum 01/2009

(4) Visibility und Monitoring; Dr. Frank WietekBI Spektrum 01/2009

(5) Data Integration Architecture; Philip RussomWhat Works in Data Integration Vol. 25 / 2008

(6) Data Integration: Consider It an Enabling Platform; John WilliamsWhat Works in Data Integration Vol. 25 / 2008

(7) Data Warehouse Alternatives: Seven Data Integration Options for BI Solutions; Kevin R. QuinnWhat Works in Data Integration Vol. 25 / 2008

(8) Data Integration Tools – Comparison and market Analysis; Philip Russom, Mark MadsenTDWI Technology Market Report 2008

(9) Operational Intelligence und Enterprise Decision Management; Christian Schieder, Christian Kurze7.TDWI Konferenz 2008 München

(10)Best Practices in Operational BI; Wayne W. EckersonWhat Works in Enterprise BI, Vol. 24 / 2007

(11)Navigation the Next Major Fork in the BI Roadmap; Dr. Barry Devlin7.TDWI Konferenz 2008 München

(12)Operational Data Integration; Philip Russom What Works in Data Integration Vol. 23 / 2007

(13)Data Integration: One Size Does Not Fit All; Frank DavisWhat Works in Data Integration Vol. 23 / 2007

(14)New Trends in Data Acquisition Services for the Real-Time Enterprise; Stephen Probst, Alok Pareek Business Intelligence Journal Vol 14 1st Qu. 2009

(15)Database Replication: Solving Realtime Movement of OLTP-Data; Bill JacobsBusiness Intelligence Journal Vol 13 4th Qu. 2008

(16)Q&A: Best Practices in Operational BI; Wayne W. EckersonBusiness Intelligence Journal Vol 12 3rd Qu. 2007

(17)Real Time BI: Drivers, Deployments, and Decisions; Robert StackowiakBusiness Intelligence Journal Vol 12 1st Qu. 2007

CEA v6.425.06.2009


Fragen?

Documents

Operational BI: Vergleich und Auswahlkriterien von