Welche BI-Architektur braucht Ihr Reporting?

Transkript

1 Welche BI-Architektur braucht Ihr Reporting?

2 Variante 1: Direkter Zugriff Keine redundanten Daten Schnelle Erkenntnisse Echte Daten für PoCs Echtzeit-Reporting ohne Zwischenstufen Belastung der operativen Systeme Business-Logik muss in Dashboards / Reports implementiert werden! Performance der Reports Nur Experten können Reports entwickeln (kein Self-Service BI!) Bei Änderungen in Quellsystem müssen Reports geändert bzw. neu aufgesetzt werden Report-Entwickler müssen mit den Daten in Quellsystemen vertraut sein Keine Nachvollziehbarkeit der Daten Data Governance und Zugriffsberechtigungen (IT macht nicht mit!) PoC Tools PoC Dashboards / Reports Einmalige Auswertungen Echtzeit-Reporting

3 Variante 2: Data Mart Zentrale Business-Logik Einfache Entwicklung und Wartung der Reports Klare Trennung zwischen Entwicklung der Reports und Datenaufbereitung (Voraussetzung für Self-Service BI) Verschiedene Self-Service BI Tools einsetzbar Performance der Reports (Front-End) Kontrollierter Zugriff auf die operativen Systeme (geringere Last und verbesserte Performance am Back-End) Kontrollierte Verteilung der Daten (Data Governance, Zugriffsberechtigungen) Redundante Daten Spezialisierte BI-Tools erforderlich (Cubes, ETL-Tools) Experten Know-how erforderlich (BI-Architekten, ETL-Entwickler) Schnell unübersichtlich wenn mehrere Fachbereiche involviert Keine Staging Area für Datenvalidierung (Nachvollziehbarkeit der Daten zum Ladezeitpunkt) Belastung der operativen Systeme durch die ETL-Prozesse bei großen Datenmengen Änderungen im Quellsystem können größere Anpassungen der ETLs bedeuten Komplexe Steuerung der Zugriffsberechtigungen bei mehreren Fachbereichen Reporting/Analytics für einen Fachbereich Self-Service BI Schneller Aufbau einer skalierbaren, performanten und IT-konformen Reporting-Lösung Nachvollziehbarkeit der Daten und große Datenmengen spielen eine untergeordnete Rolle

4 Variante 3: Data Mart mit Staging Siehe Variante 2... Durch Staging kann nachvollzogen werden, welche Daten, mit welchen Werten zu welchem Zeitpunkt geladen wurden Entlastung der operativen Systeme bei großen Datenmengen (Schritt 1: Extraktion, Schritt 2: Transformation, Laden) Bei Änderungen im Quellsystem muss nur ein ETL Paket geändert werden (Nur Extraktion) Insgesamt robuster und performanter Siehe Variante 2... Steigende Komplexität Redundante Daten (auf 2 Ebenen) Siehe Variante 2... Nachvollziehbarkeit der Daten wichtig Große Datenmengen / lange Ladezeiten Vorbereitung auf die Enterprise Architektur...

5 Variante 4: Enterprise Architektur Siehe Varianten 2 und 3... Core / SPOT: Single Point Of Truth oder zentrale Stelle für die Verwaltung der Dimensionen (Stammdaten) und Fakten (Bewegungsdaten) Enterprise Self-Service BI möglich (vielfaltige Anzahl der Report-Entwickler) Weitgehende Unabhängigkeit von Front-End Werkzeugen Einfache Verteilung der Daten unter Berücksichtigung der Zugriffsberechtigungen und Data Governance Verbesserte Performance beim Zugriff auf die einzelnen Data Marts Reporting für mehrere Fachbereiche / gesamtes Unternehmen... Siehe Varianten 2 und 3... Redundante Daten: Weitere Ebene Komplexität Entwicklungszeit Neue Tools erforderlich, z.b. DWH-Automation (Vorteil!) Robustes, performantes und IT-konformes Enterprise Reporting Enterprise Self-Service BI

6 MultiBase Mehr über MultiBase erfahren Sie unter Kennen Sie schon unsern Podcast We Love Analytics? Mehr darüber erfahren Sie hier: MULTIBASE GMBH RUDOLF-DIESEL-STRASSE GILCHING DEUTSCHLAND TEL FAX ANFRAGE@MULTIBASE.DE