Stammdaten: der Business Case für SOA

27.09.2007
Von Jan-Henrik Fischer 
Lösungen für die Stammdatenverwaltung sollten eng mit Geschäftsprozessen und BI-Systemen verknüpft sein.
Das Architekturbeispiel zeigt ein zentrales MDM-System, das unabhängig von Enterprise DWH oder operativen Systemen die Verwaltung der Unternehmensstammdaten auf SOA-Basis steuert.
Das Architekturbeispiel zeigt ein zentrales MDM-System, das unabhängig von Enterprise DWH oder operativen Systemen die Verwaltung der Unternehmensstammdaten auf SOA-Basis steuert.

Anforderung

an ein MDM-System

an einen SOA-Service

Connectivity

Stammdaten müssen unternehmensweit zugänglich sein.

Services müssen unternehmensweit zugänglich sein.

Distribution

Stammdaten müssen aufgrund definierbarer Prozesse verteilbar sein.

Services müssen über verschiedene Systeme hinweg verteilt werden können.

Integration

Ein MDM-System sollte möglichst wenig Integrationsaufwand bereiten, wenn es von bestehenden Anwendungen benutzt werden soll.

Services müssen als Web-Services standardisiert sein. Die Integration selbst muss unabhängig vom Service erfolgen.

Sicherheit

Auf Stammdaten muss man aufgrund klar formulierter Sicherheitsregeln zugreifen können.

Services müssen über die Sicherheits-Infrastruktur vor unautorisiertem Zugriff geschützt werden können.

Audit-Fähigkeit

Der Zugriff sollte sich auditfähig gestalten lassen, so dass auch verschiedene Compliance-Policies eingehalten werden können.

Jeder Serviceaufruf sollte auditfähig sein.

Data Analysis

Die Daten müssen analysiert werden können, um sie gegebenenfalls in einen auf Unternehmensebene standardisierten Zustand zu überführen.

Keine Anforderung an einen Service.

Data Correction

Stammdaten sind besonders kritisch hinsichtlich der Datenqualität. Änderungen an Stammdaten müssen sich kontrollieren und korrigieren lassen.

Keine Anforderung an einen Service.

Data Conversion

Stammdaten müssen in verschiedene Standardformate und Attribute in verschiedene Datentypen konvertierbar sein.

keine Anforderung an einen Service

Zentrales Management

Zentrale Erfassung der Stammdaten.

Die zentrale Verwaltung von Diensten muss unternehmensweit möglich sein.

Publication

Medienunabhängige Publikation aller Daten.

Services und die Daten sollten medienunabhängig dargestellt werden.

Quelle: entnommen dem Buch "SOA goes real" von Daniel Liebhard

Unter dem Schlagwort Master-Data-Management (MDM) wird seit einiger Zeit einer zentralen und systemunabhängigen Verwaltung von Stammdaten das Wort gesprochen. Dabei schien es eigentlich, dass mit dem Aufbau eines Data Warehouse (DWH) ein solcher "Single Point of Truth" bereits existierte. So ließ sich dank zentraler Systeme für Business Intelligence, die auf einem Enterprise DWH basieren, die Konsistenz von Kennzahlen insbesondere in Controlling- und Finanzabteilungen verbessern.

Mehr zum Thema

www.computerwoche.de

1220503: Stammdatenprojekt Andritz Gruppe;

523132: Stammdaten und Kennzahlen;

555548: Produkte für Stammdaten-Management;

591814: Grundlagen Stammdaten-Management.

Fortschritte

Zwar finden sich in den von den BI-Lösungen generierten Berichten immer wieder unterschiedliche Ergebnisse, aber diese ließen sich meist erklären. Ebenso wurden technische Beschränkungen früherer zentraler DWH beseitigt und erste MDM-An-sätze als Ergänzung zu den BI-Systemen implementiert. So können Anwender durch eine Synchronisation der Stammda-ten zwischen den BI-Systemen ihre Berichte vergleichen. Ein DWH bietet heute zudem viele Auswertungs- und Kombinationsmöglichkeiten für Kunden- oder Produktdaten, die zu präziser kalkulierten Geschäftsmodellen führen. BI wird operativ.

Neben dem Enterprise DWH kann auch ein spezielles Realtime- oder Near-Realtime-Data-Mart oder eine Event-driven Architecture die Basis für ein operatives BI sein. Anwendungsbeispiele sind dynamisch kalkulierte Kundenpräferenzen in Verkaufsprozessen oder die Betrugserkennung (Fraud Detection) und Kreditrisikoberechnungen in Echtzeit.

Prozessunterstützung

Allen operativen BI-Prozessen ist gemein, dass sie parallel auf verschiedene Systeme zugreifen, die die jeweiligen Stammdaten wie Kunden, Produkte, Organisa-tionen und Geschäftspartner enthalten. Voraussetzung ist jedoch, dass es technisch gelingt, historische Daten (BI) mit Echtzeit-Informationen aus den operativen Systemen zu kombinie-ren und die Ergebnisse regelbasierend in einen operativen Prozess einzubringen. Sind zu-dem Auswertungsprozesse mit kollaborativem Charakter gewünscht, müssen die gemeinsamen Stammdaten synchro-nisiert werden. Hierfür sind mittlerweile Werkzeuge erhältlich, die Prozesse im Kunden- und Produktumfeld unterstüt-zen. Diese Lösungen dienen der "Customer Data Integration" (CDI) oder dem Produkt-In-formations-Management und decken Teilausschnitte eines MDM ab.

Elemente von MDM-Systemen

Eine MDM-Lösung lässt sich anhand verschiedener Kriterien beschreiben. Häufig geschieht dies nach dem Ort der Stammdatenhaltung (Data Warehouse, separates System oder operatives System) oder nach dem Datenfluss beziehungsweise der Datenhierarchie. In letzterem Fall haben Anwender vier Architekturoptionen:

- ein zentrales MDM-System, das die Stammdaten einheitlich hält und verteilt,

- die Bestimmung eines führenden Systems, das die Stammdaten an abhängige Systeme weitergibt und zur Referenz abbildet (Mapping),

- die Verwendung eines Repository, um die dezentral gehaltenen Stammdaten abbilden zu können, oder

- die Definition einheitlicher Standardstrukturen für Stammdaten, an die sich alle Systeme halten müssen.

Grundsätzlich können Anwen-der ein MDM-System individuell oder mit Hilfe marktgängiger Produktkomponenten aufbauen. Die Ausgestaltung der Lösung hängt dann von den indivi-duellen Umständen und An-forderungen des Unternehmens ab. So sollte eine Stammdatenlösung nicht Teil eines DWH sein, wenn Unternehmen ihre enge Verzahnung mit operativen Systemen planen, da dies nach bisherigen Erfahrungen eine Prozessintegration be- oder gar verhindert.

Der Aufbau und die damit verbundene Pflege eines zentralen MDM-Systems ist hingegen nicht sinnvoll, wenn nur wenige Stammdaten im Unternehmen zu synchronisieren sind. Um grundsätzlich ein besseres Verständnis für die eigenen Bedürfnisse in puncto MDM zu bekommen, sollten Anwender zunächst "Pain Points" in den betrieblichen Prozessen identifi-zieren und deren Ursachen analysieren. So gewinnt man einen guten Überblick über die betroffenen Systeme und den Gesamtaufwand.

Anspruch und Wirklichkeit

Zunehmend werden MDM-Systeme beim Aufbau einer Service-orientierten Architektur (SOA) empfohlen. Damit könnte der seit langem gesuchte erfolgversprechende Business Case für das SOA-Konzept gefunden sein. Bisher steht SOA vor allem für eine brillante, immer wieder verfeinerte Grundidee, die sich aber bisher nicht im großen Stil durchgesetzt hat. MDM könnte diese Lücke zwischen Anspruch und Wirklichkeit schließen. Die Anforderungen im Stammdaten-Management ergeben sich unmittelbar aus den betrieblichen Prozessen. In diesen variieren je nach Geschäftskontext die führenden beziehungsweise abhängigen Systeme.

Die Stammdaten müssen sich in diesen dynamischen Abläufen flexibel konsumieren, konsolidieren und propagieren lassen. Dies entspricht genau den Prinzipien einer SOA. Wie gut MDM und SOA tatsächlich zusammenpassen, hat Daniel Liebhart, Mitglied im SOA-Expertenrat der computerwoche, anhand eines Anforderungsabgleichs eindringlich aufgezeigt (siehe Tabelle "Wie MDM zur SOA passt").

MDM-Systeme für SOAs gerüstet

Neben den Kernfunktionen, mit denen sich Stammdaten ana-lysieren, korrigieren und konvertieren lassen, kann ein MDM-System auch alle Grundanforderungen für seine Nutzung in einer SOA erfüllen. So lassen sich Verantwortlichkeiten, Verfügbarkeiten und andere Rahmen-bedingungen formulieren und die notwendige Datenqualität zentral und über klare Prozes-se steuern. Die vorhandenen Systemschnittstellen lassen sich als MDM-Services abbilden und von anderen Anwendungen konsumieren. Dabei ist zwischen Consumer-, Producer-, Update- und Delivery-Services zu un-terscheiden. Mit Hilfe von Designumgebungen können An-wender unter Verwendung der "Business Process Execution Language" (BPEL) die Services zu MDM-Prozessen orchestrieren, um sicherzustellen, dass diese Prozesse tatsächlich rasch anpassbar, extrem flexibel und stark kollaborativ sind. Der Aufbau eines MDM-Systems auf SOA-Basis ist zwar eine Grundsatzentscheidung, belässt dem Anwender aber die erwähnten Architekturoptionen (siehe Grafik "Unabhängiges MDM-System").

Angesichts dieser Möglichkeiten und Vorteile fragt man sich, warum BI-Systeme erst jetzt zur Schaffung konsistenter operativer und eigener Stammdaten herangezogen werden. Die Antwort liegt in der Entwicklung: BI-Systeme waren ursprünglich nicht für operative Aufgaben bestimmt. Erst durch die wachsende Bedeutung von Datenanalysen und deren Integration in betriebliche Prozesse ist die Frage nach zentralen Stammdaten wichtiger geworden. Ein häufiges Beispiel ist die Einführung von SAP-Standardsoftware, die zugleich mit "SAP Netweaver BI" ein speziell abgestimmtes operatives BI-System bietet. Will man dieses nutzen, ist oft die Synchronisation mit einem bereits vorhandenen Enterprise-BI-System erforderlich.

Zugleich müssen aber auch die Stammdaten im ERP-System gepflegt werden. Beide Anforderungen lassen sich am besten von einem MDM-System abdecken. Sicher wäre es aus wirtschaftlicher und strategischer Sicht weise und vorausschauend gewesen, sich frühzeitig eine ganzheitliche Stammdatenverwaltung aufzubauen. Jede architektonische Neuerung hat jedoch ihre Zeit, und die von MDM beginnt gerade. (as)