Was glauben Sie, ist all diesen Verfahren gemeinsam? 

• DWH Metadaten Management (DWH MeDM)
• DWH Data Life Cycle Management (DWH DLM)
• DWH Information Requirements Engineering (DWH IRE)
• DWH Forward/Reverse/Re-Engineering (DWH Engineering)
• DWH Schema Evolution (DWH Evolution)

Mit diesen Verfahren wird versucht, die Effizienz und Effektivität des DWH-Lebenszyklus zu verbessern. 

Bild ansehen  

Weshalb sollten Softwarewerkzeuge diese Verfahren unterstützen?

Die Hersteller von Softwarewerkzeugen für  das Datenmanagement im BI-Umfeld haben ihre Hausaufgaben in Bezug auf den Funktionsumfang ihrer Werkzeuge aus Sicht der Anwender weitgehend gemacht. Bis auf wenige Spezialisten bieten alle Hersteller eine breite Toolsuite an, die da und dort noch besser integriert werden muss.  Spannend wird es nun jedoch, wie die sich aktuell abzeichnende Herausforderung gemeistert wird, nämlich die Verkürzung der Durchlaufzeiten zur Umsetzung neuer Anforderungen bzw. der Anpassung bestehender DWH-Implementierungen. Dies bedeutet,  dass in den Bereichen Data Warehouse, Data Integration und Data Quality inkl. Stammdatenqualität immer schneller auf Wünsche aus den Geschäftsbereichen zu reagieren ist. Die Durchlaufzeiten der BI-Projektphasen Requirements Engineering, Design und Implementierung können nur verkürzt werden, indem  die Effizienz bei der Erfassung und Umsetzung der Anforderungen

• sowohl durch verbesserte Verfahren in der Anforderungsanalyse 
• als auch durch die werkzeugseitige Unterstützung dieser Analyseverfahren

drastisch gesteigert wird. 

BARC @ 11th European TDWI Conference (6.-8.Juni 2011, München)

BARC präsentiert in seinem Datenmanagement-Track diese Verfahren aus zwei Perspektiven. 

• Hersteller stellen vor, wie sie Ihren Kunden bei diesen Themen mit ihren Werkzeugen helfen. 
• BARC stellt vor,
• was Anwender zu diesem Thema sagen,
• welche Herausforderungen dabei zu bewältigen sind und
• welche Werkzeuge die Anbieter zur Verfügung stellen.

Die im Protokoll angeführten Termine für die weiteren Aktivitäten der AG MDM waren zu optimistisch.  Wir haben uns jedoch vorgenommen, folgende Themen verstärkt zu verfolgen:

-          Definition und Abgrenzung MDM

-          Entwicklung eines Kennzahlensystems zur Bewertung der MDM-Qualität

BARC hat hierzu schon einige Vorarbeiten geleistet. Wir werden diese in den nächsten Folgen hier in Auszügen vorstellen.

Von den in der folgenden Liste angeführten Herstellern von DQ- oder/und MDM-Produkten

Es war insofern eine interessante Mischung, da die ersten drei Anbieter von ganzen Werkzeug-Suiten für Informationsmanagement sind, Dataflux sich von DQ zu MDM entwickelt, Teradata aus der BI-Welt kommt und die letzten beiden, Trillium und Uniserv, Spezialisten für DQ sind. Besonders interessant war, dass Microsoft sich entschlossen hat, nach dem langen Schweigen, das dem Kauf von Stratature folgte, noch vor der ersten Beta-Version, die noch dieses Jahr folgen soll, seine Strategie bekannt zu geben.

Ich darf Sie bitten, mir Ihre Gedanken und Anregungen unter spriglinger@barc.de zukommen zu lassen. Die nächste Folge meines Blogs wird sich detaillierter mit den vorgestellten Produkten beschäftigen.

Hinweis in eigener Sache: Besuchen Sie mich auch auf www.xing.com. Ich bin dabei, unter der Gruppe „DGIQ“ eine Arbeitsgruppe für MDM aufzubauen. Mein Ziel ist eine Community, die sich zu dem Thema DQ&MDM austauscht.

Das Thema „Stammdatenmanagement“ (kurz: MDM) hat sich aus der Praxis entwickelt. Die Ursprünge liegen in den 80er-Jahren, hier vor allem in den Produktinformationssystemen der industriellen Produktentwicklung und in den Kundeninformationssystemen des Massengeschäfts. Verschärft hat sich das Thema dadurch, dass sich die Monolithen von ERP-Systemen diversifizierten und zu Best-of-Breed-Lösungen wurden. Parallel dazu führten die Anforderungen im Bereich „Business Intelligence“ zu einer Lösungsarchitektur, in der das Thema „Qualität der Daten“ berücksichtigt werden musste (BI-Lösungsarchitektur).

Bild ansehen

Die Praxis zeigt jedoch, dass das Management der Datenqualität nur in Richtung Dataware-House nichts an den Datenquellen des Dataware-House verbessert. Damit werden dieselben Daten immer wieder in die Hand genommen. Dies behindert wiederum die Verbesserung der Geschäftsprozesse. Die Prozessinitiativen sind damit ebenfalls zum Treiber für die Verbesserung der Datenqualität, besonders in den operativen Systemen geworden. Damit musste es zu einer Transformation der Lösungsarchitektur kommen, worin Dienste zur Verbesserung der Daten- und Stammdatenqualität ein zentrales Element in der Service-orientierten IT-Architektur bilden (SOA- & DataGovernance-Lösungsarchitektur).

Bild ansehen

Ich möchte von diesem Bild ausgehen und in den nächsten Folgen dieses Blogs Anregung geben, welche Unterschiede es zwischen dem „klassischen Ansatz“ zur Verbesserung der Datenqualität und dem zur Verbesserung der Stammdatenqualität gibt, welches Nutzenpotential dahinter steckt und wie man dieses Potential feststellt und hebt. Dies werde ich mit Informationen über die am Markt angebotenen Lösungen verbinden.

Ich freue mich schon auf Ihre Gedanken und Anregungen dazu. Und wenn Sie uns auf der TDWI-Konferenz besuchen! Wir möchten Ihnen dort zeigen, wie man die Lösungsvielfalt der Datenmanagement-Anbieter entwirren kann und wie die Produktanbieter sich selbst sehen.

Hinweis in eigener Sache: Besuchen Sie mich auch auf www.xing.com. Ich bin dabei, unter der Gruppe „DGIQ“ eine Arbeitsgruppe für MDM aufzubauen. Mein Ziel ist eine Community, die sich zu dem Thema DQ&MDM austauscht. Ich habe ein erstes Treffen im Rahmen der oben erwähnten TDWI-BARC-Konferenz, wahrscheinlich am 16.6 abends geplant.