SOA und BI – Freunde oder Feinde?

Anbieter zum Thema

Kodak Alaris Germany GmbH

PDV GmbH

Liferay GmbH

Data Warehousing erfordert spezialisierte Lösungen

Die klassische Data-Warehouse-Architektur leistet für viele BI-Projekte gute Dienste. Dabei werden Daten aus den operativen Systemen durch verschiedene Methoden der Datentransformation bezogen und in ein Data Warehouse geladen. Aus dem Data Warehouse werden die Daten in spezifische Datenbereiche (Data Marts) geladen, wenn sie nicht direkt von den operativen Systemen bezogen werden. Die vielen Anwendungen, wie beispielsweise Reporting, Dashboards oder auch statistische Berechnungen, können in die beiden Anwendungsbereiche Discovery & Mining und Information Access aufgeteilt werden.

So weit so gut – aber wo genau ist SOA wirklich nützlich? Tatsächlich gibt es eine Reihe von Nutzenpotenzialen, die sich jedoch meist nur indirekt auf die Qualität der Umsetzung einer Data-Warehouse-Architektur auswirken. Auf der Ebene der operativen Systeme hilft SOA, die durchschnittliche Datenqualität aller Systeme zu verbessern, und vereinfacht den Zugriff auf verschiedenste Datenbestände durch bereits vorhandene Integrationsdienste.

Zudem kann SOA Prozessinformationen liefern, die für ein BI-System eine wichtige Datenquelle darstellen können. Auf der Ebene der Datentransformation und der Replikation & Propagierung ist SOA nicht für den eigentlichen Datentransfer nützlich, kann jedoch für die Steuerung der entsprechenden Abläufe eingesetzt werden. Auf Ebene des Enterprise Data Warehouse und der Data Marts ist SOA nicht hilfreich, hier sind spezialisierte Lösungen die bessere Wahl. Die eigentlichen BI-Anwendungen sollten jedoch in jedem Fall so gestaltet werden, dass sie als Services in andere Applikationen integriert werden können.

Die Ausnahme: SARESA

Es gibt jedoch eine BI-Architektur, die vollständig auf SOA basiert. Sie wurde von der Technischen Universität in Wien entwickelt und bildet einen geschlossenen „Sense & Response“-Kreislauf ab (Sense – Interpret – Analyse – Decide – Respond). Diese Sense & Response Service Architecture (SARESA) kombiniert SOA mit modernen BI-Technologien zu einem System, welches laufende Geschäftsprozesse überwacht und eine unmittelbare Reaktion auf kritische Ereignisse erlaubt. Die Architektur gruppiert sämtliche Funktionen als Services, die über einen Enterprise Service Bus verbunden sind. SARESA basiert auf SOA und nutzt Standarddienste, die von den meisten SOA Software Stacks der großen Hersteller bereitgestellt werden. Dennoch wird die Data-Management-Komponente des Systems, das eigentliche Data Warehouse, getrennt gehalten.

Fazit: Weder noch

Selbstverständlich können BI-Anwendungen mit SOA realisiert werden. Dies betrifft jedoch lediglich die Strukturierung der gegebenen Anwendung. So betrachtet sind SOA und BI keine wirklichen Feinde mehr, solange sie die friedliche Koexistenz verschiedener Systemlandschaften akzeptieren. In der Praxis sollten Data Warehouses und Data Marts weiterhin mit spezialisierten Werkzeugen realisiert und der Datentransport nicht mittels Webservice-Technologie umgesetzt werden. Der Nutzen und damit der Einfluss von SOA auf das Thema BI wird in näherer Zukunft jedoch indirekt und punktuell sogar direkt spürbar sein. So ist zu erwarten, dass sich die durchschnittliche Datenqualität eines Unternehmens aufgrund der Aufgliederung bestehender Systeme in Services verbessern wird. Eine lose Koppelung von Systemen erfordert verlässlichere Daten, damit die beabsichtigten Einsparungen durch Wiederverwendung (Skaleneffekte) erzielt werden können.

Ob nun als Master Data Management oder als einzelne Data Services realisiert: je mehr Nutzer, desto besser die Qualität der Daten. Diese Tendenz wird unter anderem Auswirkungen auf einen der komplexeren Bereiche der BI haben, auf die Bereinigung von Daten, das sogenannte Data Cleaning. Der zweite Aspekt betrifft die Steuerung der Ladeprozesse und damit die Qualität der Bereitstellung aktueller Ergebnisse. Realisiert eine Organisation ihre Anwendungen auf SOA-Basis, werden Abläufe als Workflows getrennt umgesetzt.

Diese Workflows werden entweder als grob granulare BPEL-/ BPM-Abläufe oder als fein granulare Business Rules formal beschrieben und damit ausführbar gestaltet. Damit werden sie auch überwachbar und können zumindest teilweise nützliche Kennzahlen liefern. Auf diese Weise verbessern sich die Qualität und die Aktualität der Aussagen, die mit den Instrumenten von BI gemacht werden können.

(ID:2022290)