close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

Die fünf größten Fallstricke bei der Datenmigration – und wie man

EinbettenHerunterladen
Die fünf größten Fallstricke bei
der Datenmigration –
und wie man sie vermeidet
W H I T E PA P E R
Dieses Dokument enthält vertrauliche, unternehmenseigene und geheime Informationen („vertrauliche
Informationen“) der Informatica Corporation und darf ohne vorherige schriftliche Genehmigung von Informatica
weder kopiert, verteilt, vervielfältigt noch auf andere Weise reproduziert werden.
Es wurde alles unternommen, um die Genauigkeit und Vollständigkeit der in diesem Dokument enthaltenen
Informationen sicherzustellen. Dennoch können Druckfehler oder technische Ungenauigkeiten nicht vollständig
ausgeschlossen werden. Informatica übernimmt keine Verantwortung für Verluste, die aufgrund der in diesem
Dokument enthaltenen Informationen entstehen können. Die hierin enthaltenen Informationen können sich ohne
vorherige Ankündigung ändern.
Die Berücksichtigung der in diesem Dokument besprochenen Produktmerkmale in neuen Versionen oder
Upgrades von Informatica Softwareprodukten sowie der Zeitpunkt der Veröffentlichung dieser Versionen oder
Upgrades liegen im alleinigen Ermessen von Informatica.
Geschützt durch mindestens eines der folgenden US-Patente: 6032158, 5794246, 6014670, 6339775,
6044374, 6208990, 6208990, 6850947, 6895471 oder durch folgende angemeldete US-Patente:
09/644280, 10/966046, 10/727700.
Diese Ausgabe wurde im Juni 2010 veröffentlicht.
White Paper
Inhaltsverzeichnis
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Nichtbefolgung optimaler Vorgehensweisen . . . . . . . . . . . . . . . . . . . . . . . . 3
Teamstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Risikominderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Datenerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Außerbetriebnahme von Altsystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Flexibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Prüfung und Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Laden von Testinstanzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Daten in Produktivsystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Datenqualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Übergang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Unterlassen der Datenerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Stammdatenerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Data Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Außerbetriebnahme von Altsystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Auswirkungsanalyse für die Zielanwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Lücken in der Strategie für den Datentransfer . . . . . . . . . . . . . . . . . . . . . . 7
Wiederverwendbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Datenqualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Prüfung und Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Konnektivität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Mangelnde Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Unzureichende Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Schlussfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Informationen zu Informatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Die fünf größten Fallstricke bei der Datenmigration - und wie man sie vermeidet
1
Zusammenfassung
Vermutlich lesen Sie diesen Artikel, weil Ihr Unternehmen ein Projekt zur Migration von
Anwendungsdaten plant. Möglicherweise sollen die Geschäftsprozesse modernisiert werden,
um Kosten zu sparen und wettbewerbsfähiger zu werden. Dazu müssen alte Anwendungen
außer Betrieb genommen und neue Anwendungen bereitgestellt werden, um neue Ansätze bei
Geschäftsprozessen zu unterstützen. Vielleicht integrieren Sie Daten aus einer Fusion oder
Übernahme. Was auch immer genau dahinter steht, mit der Datenmigration steht und fällt ein
größeres Projekt der Unternehmensstrategie, in das erheblich Zeit und Geld investiert wurden.
Das Projekt wird keinen Erfolg haben, wenn die Daten zu spät geliefert werden oder den
Geschäftsprozess nicht korrekt unterstützen. Scheitern ist also keine Option.
Es gibt fünf häufig gemachte Fehler, die Datenmigrationsprojekte verzögern oder sogar
scheitern lassen können:
1. Nichtbefolgung optimaler Vorgehensweisen. Für die Datenmigration sind besondere
Fähigkeiten, Tools und Pläne nötig, die sich von denen für andere IT-Projekte unterscheiden.
2. Unterlassen der Datenerkennung oder fehlendes Verständnis für die Daten. Die
Datenstrukturen der Quell- und Zielanwendung müssen vollständig verstanden sein und der
Zugriff darauf im Zeitverlauf muss durchdacht sein.
3. Lücken in der Strategie für den Datentransfer. Beim Transfer der Daten müssen Strategien
für den Datenzugriff, die Validierung und die Prüfung bedacht werden.
4. Mangelnde Zusammenarbeit. Betriebliche Anwender und Datenverwalter müssen bei der
Verifizierung der Daten und der Sicherstellung ihrer Anwendbarkeit einbezogen werden.
5. Unzureichende Tools. Richtige Tools für die Datenmigration umfassen alle erforderlichen
Prozesse und zwingen die IT nicht dazu, das Rad mehrfach neu zu erfinden.
Dieses White Paper beschreibt jeden dieser Fallstricke genauer und enthält Empfehlungen
dafür, wie sie zu vermeiden sind. Es ist nicht als vollständige Anleitung für die Planung einer
Migration von Anwendungsdaten gedacht, sondern vielmehr als Ratgeber dazu, wie häufige
Fehler in Projektteams zu vermeiden sind.
2
White Paper
Nichtbefolgung optimaler Vorgehensweisen
Viele IT-Teams gehen davon aus, dass sie für die Migration von Anwendungsdaten die
gleichen optimalen Vorgehensweisen verwenden können, die sie auch bei der Entwicklung von
Anwendungscode einsetzen. Dies erscheint logisch, führt aber häufig zu Verzögerungen und
Fehlschlägen. Warum? Weil als Ergebnis bei der Datenmigration etwas anderes gewollt ist, als
bei jedem anderen IT-Projekt. Bei der Entwicklung von Anwendungscode geht es darum, neue
Funktionen umzusetzen oder Prozesse zu optimieren. Bei der Migration von Anwendungsdaten
geht es darum, einer neuen Anwendung einen Satz von Daten bereitzustellen, der direkt in
Produktivsystemen genutzt werden kann. Dies ist ein wesentlicher Unterschied, der bei der
Strukturierung des Projekts berücksichtigt werden muss. Dem Team für die Migration von
Anwendungsdaten muss klar sein, welche Vorgehensweisen spezifisch für dieses Projekt sind,
einschließlich:
Teamstruktur
Wenn Sie die Beteiligten und ihre Rollen auflisten, nehmen Sie jeden mit auf, der ein Interesse
an dem Ergebnis hat: betriebliche Interessengruppen, Datenexperten oder Datenverwalter
des Unternehmens, Datenarchitekten sowie Teamleiter und Entwickler. Große Migrationen
sollten auch über einen Projektmanager und ein Team zum Testen der Datenqualität und der
Anwendbarkeit in der neuen Anwendung verfügen.
Risikominderung
Das Ergebnis einer Datenmigration hat enorme Auswirkungen auf die größeren Projekte,
denen die Migration dient. Daher ist es wesentlich, dass das Team für die Datenmigration
und das Team für das betreffende Projekt zusammenarbeiten, um Erwartungen, Ziele und
Zeitrahmen gemeinsam zu planen. Wenn beispielsweise ein Projektteam die Implementierung
einer neuen Instanz von SAP ECC6 plant, muss es das Team für die Datenmigration bei der
Planung von Konfigurationsänderungen wie auch bei der Strategie für die Inbetriebnahme des
Produktivsystems mit einbeziehen. Wenn die Kommunikation scheitert, scheitert auch das Projekt.
Datenerkennung
Bei der Migration von Anwendungsdaten liegt der Fokus in der Phase der Erstanalyse stärker
als bei anderen Projekten auf den Dateninhalten. Es muss festgelegt werden, welche Daten
migriert werden, was mit Daten geschieht, die nicht migriert werden, und wie die Daten
zugeordnet und optimiert werden, die die Zielanwendung benötigt. Eine Zuordnung anhand der
Feldnamen in DDLs oder Copybooks reicht dabei nicht aus. Eine zu ungenaue Datenanalyse
kann zu falscher Zuordnung der Quellen führen und durch unterlassenes Profiling kann das
Fehlen von Inhalten übersehen werden. Das Datenmigrationsteam muss die Daten sowohl der
Quell- als auch der Zielanwendung für alle Anwendungen und Systeme genau untersuchen, um
die bestehenden Inhalte, Regeln und Beziehungen genau zu verstehen.
Außerbetriebnahme von Altsystemen
Die Außerbetriebnahme von Quellanwendungen, Servern und Datenbanken kann erhebliche
Vorteile bieten, daher müssen Planungen für die Außerbetriebnahme integraler Bestandteil
der Datenmigration sein. Zusätzlich muss das Team von der neuen Anwendung nicht mehr
benötigte Daten untersuchen, um festzulegen, wie und wie lange diese archiviert werden und
wie bei Bedarf auf sie zugegriffen wird.
Die fünf größten Fallstricke bei der Datenmigration - und wie man sie vermeidet
3
Flexibilität
Bei der Migration von Anwendungsdaten ist der Zeitrahmen oft eng gesteckt und neue
Erkenntnisse über den Zustand der Daten können kurzfristig erhebliche Änderungen der
Anforderungen nach sich ziehen. Daher benötigt das Datenmigrationsteam eine Infrastruktur,
die es ihm ermöglicht, Zugriffskomponenten und Zuordnungen schnell zu ändern und
zu aktualisieren. Sie müssen die Daten und Anforderungen analysieren, die Daten in
verschiedenen Testinstanzen zuordnen und testen und sie dann mit minimalen Auswirkungen
auf die laufenden Geschäftsprozesse in die Produktivsysteme übertragen können.
Prüfung und Validierung
Die Einhaltung behördlicher Vorgaben und die Datenqualität haben mittlerweile nicht nur
für Finanzdienstleistungen herausragende Bedeutung, sondern ebenso für Einzelhandel,
Gesundheitswesen, öffentliche Verwaltung und andere Bereiche. Daher benötigt das
Datenmigrationsteam eine Infrastruktur und eine Lösung, die Prüfungen der Anzahl von
Datensätzen, der Inhalte und der Zuordnungen einfach möglich machen. Das ermöglicht dem
Team den Nachweis darüber, ob und was extrahiert und geladen wurde und warum diese
Entscheidungen so getroffen wurden.
Laden von Testinstanzen
Zum Testen einer Datenmigration gehört es, mehrere Dateninstanzen in eine Testversion der
Zielanwendung zu laden, die Leistung zu evaluieren und zu ermitteln, warum bestimmte Daten
nicht geladen wurden, bevor die Tests der tatsächlichen Datennutzung in der Zielanwendung
beginnen können. Das Testen des Ladevorgangs und der Zielfunktionalität sollte in einer frühen
Phase des Projekts beginnen.
Daten in Produktivsystemen
Da das Ziel des Datenmigrationsprojekts in einem Satz von Daten zur Nutzung in
Produktivsystemen besteht, kann die Datenmigration nur durch Extraktion und Zuordnung
realer Daten aus Produktivsystemen erfolgen. Bei den meisten IT-Projekten testen Entwickler
einen neuen Prozess oder eine Schnittstelle anhand speziell erstellter Testdatensätze oder
einer kleinen Untergruppe der Daten aus Produktivsystemen. Bei der Datenmigration ist diese
Vorgehensweise nicht angebracht. Das Datenmigrationsteam testet, bereinigt und optimiert
die Daten der Produktivsysteme. Es kann seine Ziele nicht erreichen, wenn es nicht die realen
Daten verwendet.
Datenqualität
Es muss immer sichergestellt sein, dass die Zielanwendung mit den Daten arbeiten kann. Um
dies garantieren zu können, ist oft eine Bereinigung, Optimierung und Konsolidierung der Daten
erforderlich. Wenn die Zielanwendung neue Funktionen im Geschäftsbetrieb implementiert oder
Geschäftsabläufe konsolidiert, planen Sie Arbeiten an der Datenqualität in Ihr Migrationsprojekt
mit ein.
Übergang
Der Übergang zum tatsächlichen Laden der Daten in die Produktivsysteme muss anhand der
geschäftlichen Erfordernisse, der Risikotoleranz und der Kundenerwartungen geplant werden.
Der Plan für den Übergang muss eines der ersten Ergebnisse des Teams sein. Auf ihn muss
der gesamte Ansatz zugeschnitten sein. Möglicherweise muss die Ausfallzeit minimiert werden,
möglicherweise aber auch nicht. Möglicherweise können Sie die meisten Transaktionsdaten
schon Wochen vor dem tatsächlichen Übergang verlagern. Möglicherweise ist das Risiko so
hoch, dass eine Parallelverarbeitung vorgesehen werden soll. Beispielsweise entwickelte ein
Versicherungsunternehmen ein Übergangsverfahren, das speziell auf seine geschäftlichen
Erfordernisse zugeschnitten war. Es migrierte die Daten der einzelnen Kundenkonten jeweils
zum jährlichen Ablaufdatum der Verträge zur neuen Anwendung. Das Verfahren dauerte ein
ganzes Jahr, brachte dafür aber keinerlei Ausfallzeiten oder negative Auswirkungen auf die
Kunden mit sich.
4
White Paper
Unterlassen der Datenerkennung
Wenn das Team, das sich mit den Daten des alten Mainframes auskannte, schon lange
in Rente ist, Ihre Systeme über viele Jahre hinweg organisch gewachsen sind oder Ihr
Unternehmen Daten eines übernommenen Konkurrenten integrieren möchte, verfügen Sie
möglicherweise nicht über ausreichend Informationen über die alten Anwendungen und ihre
Daten. Die Unwissenheit darüber kann bei Datenmigrationsprojekten allerdings zu sehr ernsten
Problemen führen.
Beispielsweise musste eine Institution der öffentlichen Verwaltung Daten aus einem
Rechtsfallmanagementsystem migrieren. Die Datenverwalter hatten die zentrale Falltabelle
als Quelle der Falldaten identifiziert. Beim Data Profiling stellte sich jedoch heraus, dass etwa
20 % der ursprünglichen Falldatensätze in einer zweiten Tabelle gespeichert waren und nur bei
einem Statuswechsel in die zentrale Tabelle eingetragen wurden.
Es kommt häufig vor, dass Datenverwalter die tatsächliche Quelle der Daten falsch zuordnen.
Der tatsächliche Inhalt der Daten hat sogar meist eher wenig Ähnlichkeit mit dem Inhalt,
den das Team erwartet. Datenverwalter und andere Anwender sehen Daten meist nur in
extrahierter, aggregierter oder präsentierter Form. Auch Entwicklerteams für die Datenmigration,
die mit granularen Daten auf Tabellenebene arbeiten, wissen häufig nicht genau, welche
Daten den geschäftlichen Erfordernissen entsprechen. Obwohl Datenmodell, Beziehungen,
Spaltennamen und Strukturen einige Metadaten bieten, die für ein gutes Verständnis der Daten
notwendig sind, werden auch dadurch meist nicht alle Details verständlich. In COBOL werden
Datenobjekte beispielsweise „redefiniert“, in Java werden Werte „überladen“. Seit mindestens
30 Jahren benennen Entwickler Datenobjekte also anders als nach deren tatsächlichem Inhalt.
Üblicherweise möchte das technische Team die Anforderungen schnell erhalten, mit der
Programmierung beginnen und anhand der Ergebnisse schrittweise Verbesserungen vornehmen.
Durch diesen gut gemeinten Ansatz stolpern Teams jedoch häufig über den Fallstrick
mangelnden Wissens über die Daten. Bei der Migration von Anwendungsdaten ist es besser,
wenn die Datenerkennungen (und die Überraschungen, die sie mit sich bringen) hauptsächlich
am Beginn des Projektes stattfinden. Wenn die Daten vorab analysiert werden, lassen sich
kostspielige Nachbesserungen bei der Extraktion und Zuordnung der Daten vermeiden. Wenn
die Daten nicht komplett neu zugeordnet und die Extraktionsstrategie nicht neu entwickelt
werden müssen, vermindern Sie damit auch das Risiko langer Projektverzögerungen. Hier
kann das IT-Team einmal nicht die Datenanalyse überspringen, um zur „richtigen Arbeit“
überzugehen, denn Datenanalyse gehört zur „richtigen Arbeit“.
Die fünf größten Fallstricke bei der Datenmigration - und wie man sie vermeidet
5
Um die Folgen nicht richtig verstandener Daten aufgrund von übersprungener oder nur minimal
durchgeführter Datenerkennung zu vermeiden, sollte das Team folgende Schritte durchführen:
Stammdatenerkennung
Der erste Schritt bei einer Datenmigration ist nicht die Zuordnung auf Feldebene, sondern die
Analyse auf Einheitenebene, um die für die Zielanwendung benötigten Stammdateneinheiten
zu bestimmen. Identifizieren Sie die Quelle von Produkt-, Kunden-, Zulieferer- und Vorgangsdaten
und validieren Sie diese gegen andere Quellen (darunter bei Konsolidierungen gegebenenfalls
auch das Ziel) derselben Daten. Evaluieren Sie die Primärschlüsselkonventionen über Datenbanken
hinweg, ermitteln Sie, ob ein Abgleich oder eine Konsolidierung erforderlich ist und analysieren Sie
Lücken über die Systeme hinweg. Wenn beispielsweise im Abrechnungssystem 20.000 Kunden
erfasst sind, im Liefersystem jedoch 20.500, muss das Team analysieren, wieso dies so ist und
welche Über- oder Untergruppe der Daten migriert werden soll.
Data Profiling
Der nächste Schritt ist das Profiling auf Tabellen- und Spaltenebene. Das Team muss
Inkonsistenzen, Redundanzen, Ungenauigkeiten und die referenzielle Integrität über Tabellen
und Datenquellen hinweg evaluieren. Die resultierenden Berichte und Metriken liefern die
notwendigen Datenpunkte zum weiteren Verständnis und zur weiteren Analyse der Inhalte.
Außerbetriebnahme von Altsystemen
Bestandteil der Datenmigration ist, dass das Team eine minimale Untergruppe der Daten für
die Zuordnung zur neuen Zielanwendung identifizieren muss. Ältere Datensätze mit veralteten
und nicht vollständig verstandenen Daten lassen den Arbeitsaufwand exponentiell wachsen.
Das Team sollte auch Lösungen für den langfristigen Zugriff auf Daten, die nicht migriert
werden, erarbeiten und dabei die Erfüllung gesetzlicher und interner Vorgaben sowie die
Anforderungen langfristiger Trendanalysen berücksichtigen.
Auswirkungsanalyse für die Zielanwendung
Das Team muss die Auswirkungen von drei Problemen der Datenverwaltung auf die
Zielanwendung berücksichtigen:
• Data Governance nach der Migration, idealerweise durch Wiederverwendung des Wissens
und der Geschäftsregeln, die bei der Vorbereitung der Datenmigration entwickelt wurden
• Abgleich der Referenz- und Stammdaten der Zielanwendung mit den Quelldaten,
möglicherweise durch Konfigurationsänderungen der Zielanwendung
• Sicherung der Leistungsstärke der Zielanwendung, insbesondere bei Konsolidierungen,
bei denen große Mengen von Stammdaten oder Transaktionsdaten in eine bestehende
Anwendung übertragen werden
6
White Paper
Lücken in der Strategie für den Datentransfer
Der Transfer geschäftskritischer Daten muss exakt und sorgfältig erfolgen. Auf diesen Daten basiert
schließlich der Erfolg des Unternehmens. Viele Teams gehen davon aus, dass eine Datenmigration
lediglich aus der Datenzuordnung von einer Tabelle zu einer anderen besteht. Sie umfasst jedoch
wesentlich mehr. Nur einige Beispiele: Ein betriebliche Anwender benötigt vermutlich eine Prüfung
des Transfers, die Datenqualität stellt fast immer eine Herausforderung dar. Meist wird es viele
Änderungen im Projekt und Datenerkennungen geben, die zu erheblichen Verzögerungen führen
können. Wenn beim Datentransfer nicht sichergestellt ist, dass die neue Anwendung richtig
unterstützt wird, können zudem negative Folgen für den Geschäftsbetrieb Ihres Unternehmens
eintreten. Eine Datenmigration ist immer riskant und eine der Fallen besteht darin, im Laufe des
Projekts keine richtige Strategie zur Minderung des Risikos zu finden. Im Folgenden sind vier
Bereiche genannt, die man zur Migration der Anwendungsdaten berücksichtigen sollte, um im
Zeitrahmen zu bleiben und nach dem Transfer richtig funktionierende Daten abzuliefern.
Wiederverwendbarkeit
Das Risiko bei der manuellen Programmierung von Komponenten für die Datenmigration ebenso
wie beim Unterlassen der Erstellung spezifischer Geschäftsregeln für die Zielanwendung besteht
darin, dass das Team viele dieser Komponenten für zukünftige Migrationen oder Projekte zur Data
Governance oder Datenqualität neu programmieren, umarbeiten oder neu erstellen muss. Auch
wenn es gelungen ist, die Daten zu transferieren und ihre Korrektheit zu bestätigen, beginnt die
Arbeit höchstwahrscheinlich von vorne, wenn das nächste Mal eine Migration zu diesem System
ansteht oder die Daten bereinigt oder überwacht werden sollen. Bedenkt man den Aufwand an
Datenerkennungen, der für den korrekten Datentransfer notwendig war, ist diese mangelnde
Wiederverwendbarkeit eine erhebliche Verschwendung von Zeit und Ressourcen für die Zukunft.
Eine Institution der öffentlichen Verwaltung konsolidierte Daten aus 70 verschiedenen
Quellanwendungen in einer einzelnen SAP-Instanz für die Finanzberichterstattung. Da
sichergestellt wurde, dass die Geschäftsregeln für die Zielanwendung wiederverwendbar waren,
konnte die Institution mehrere verschiedene Migrationen einfach durchführen und dabei volles
Vertrauen in die Datenqualität haben sowie erheblich Zeit sparen.
Datenqualität
Die Definition von Datenqualität ist kontextabhängig. Für die regionale Analyse der
Kundenabwanderung kann es beispielsweise ausreichend sein, wenn die Daten zu Postleitzahlen
nur zu 98 % korrekt sind. Für die Rechnungsstellung hingegen sind Daten, die nur zu 98 %
korrekt sind, vollkommen inakzeptabel. Bei einer Datenmigration müssen die Daten für die
Geschäftsprozesse der Zielanwendung geeignet sein. Teams für die Datenmigration gehen oft
fälschlicherweise davon aus, dass sie von guter oder zumindest ausreichender Qualität sind.
Die Sicherung von Datenqualität ist ein iterativer Prozess, bei dem Experten für den Inhalt der Daten,
meist betriebliche Anwender, direkt beteiligt sein müssen. Ein übliches Beispiel ist der Datenabgleich
und die Entfernung von Dubletten. Ohne die Einbeziehung von Experten für den Inhalt der Daten
kann es Unternehmen so wie einer großen US-amerikanischen Krankenversicherung ergehen, die
ein Team von Programmierern engagiert hatte, um bei der Migration von Anbieterdaten in ein neues
Forderungsmanagementsystem zu helfen. Da das Migrationsteam kaum Kenntnisse über den Inhalt
der Daten und die Geschäftsprozesse hatte, wurden viele Datensatzdubletten übersehen und so
Fehler in die Zieldatenbank eingebracht. Die fehlerhaften Daten gelangten in die Produktionssysteme
und verursachten Verzögerungen und Fehler in der Zahlungsverarbeitung in bisher nie da gewesenem
Ausmaß, wodurch wiederum zahlreiche Anbieter und Kunden ihre Verträge kündigten. Dieser Fehler
hatte erhebliche negative Auswirkungen auf das Unternehmen.
Im Gegensatz dazu stellte ein europäisches Einzelhandelsunternehmen bei der Migration
seiner veralteten Mainframe-Anwendung für das Supply Chain Management ein Team von
Datenexperten zusammen, um den Spezialisten für die Datenmigration bei der Entwicklung
von Datenabgleichsalgorithmen für die Konsolidierung der Produktdaten zu helfen. Dadurch
konnte erreicht werden, dass das Unternehmen statt eines Datensatzes für ein bestimmtes
Sportschuhmodell eines Herstellers in Rot und eines weiteren Datensatzes für dasselbe
Modell in Blau nach der Migration nur noch über einen Datensatz für den Sportschuh mit
Die fünf größten Fallstricke bei der Datenmigration - und wie man sie vermeidet
7
dem optionalen Attribut „Farbe“ verfügte. So konnte es Produkte eindeutig identifizieren. Das
Ergebnis hatte deutliche Verbesserungen der Lieferkettenprozesse zur Folge.
Datenqualität hat also erhebliche Auswirkungen auf Ihre Geschäftsprozesse. Eine Datenmigration stellt
sowohl eine Gelegenheit als auch eine Verpflichtung für das Team dar, Lücken und Anforderungen zu
evaluieren, die zu migrierenden Daten zu bereinigen und Dubletten zu entfernen. Das Team für die
Migration der Anwendungsdaten muss die Datenqualität mit bekannten optimalen Vorgehensweisen
und passenden Tools optimieren können. Und das Team des Unternehmens muss in jedem Schritt
des Datenmigrationsprozesses eingebunden sein.
Prüfung und Validierung
Durch gesetzliche Vorschriften und Branchenvorgaben wird die Berücksichtigung von
Prüfungen und Maßnahmen zur Einhaltung von Vorgaben ein wesentlicher Bestandteil von
Datenmigrationsprojekten. Das Datenmigrationsteam muss nachweisen können, dass die in
das Zielsystem geladenen Daten mit den Daten aus dem Quellsystem übereinstimmen – nicht
nur aufgrund behördlicher Vorgaben, sondern auch, damit das Unternehmen auf die neue
Anwendung vertrauen kann. Mehrere Ansätze können diese Validierung vereinfachen:
• Datenqualitätsübersichten. Im Rahmen der Sicherung der Datenqualität definieren
betriebliche Anwender über Datenqualitätsmetriken, welche Anforderungen sie an Daten in
Produktivsystemen stellen.
• Quelle-Ziel-Datensatzvalidierung. Die Datenmigration umfasst einen eigenen Prozess,
der überprüft, ob die Datensätze aus dem Quellsystem in das Zielsystem übernommen
wurden, und wenn nicht, warum nicht. Dieser Prozess kann aus einem Datensatzzähler
bestehen, kann aber auch komplexer sein, wenn die Daten umgewandelt werden, um den
Anforderungen der Zielanwendung zu entsprechen.
• Validierung über eine Sekundärquelle. Das Datenmigrationsteam identifiziert eine
zweite Datenquelle, der betriebliche Anwender vertrauen, und validiert dann sowohl die
Originalquelle als auch die Sekundärquelle. Beachten Sie, dass dieser Ansatz zusätzliche
Arbeit bedeutet und weitere unerwartete Probleme mit den Daten auffallen können.
• Metadaten-Management. Wenn der Weg der Daten durch die einzelnen Schritte der
Datenmigration nachvollzogen werden kann, kann das Datenmigrationsteam auftretende
Datenprobleme leichter lösen und die Auswirkungen von Änderungen an der Zuordnung oder
den Prozessen genauer beurteilen.
• Dokumentation. Gut dokumentierte Zuordnungen bei der Datenmigration ermöglichen
Auditoren und betrieblichen Anwendern die Nachverfolgung von Änderungen.
Konnektivität
Konnektivität unterstützt sowohl Flexibilität als Schlüssel zum Erfolg, Datenqualität als iterativen
Prozess als auch Datenerkennungen als Weg zu neuen Möglichkeiten und Erkenntnissen.
Daher muss Konnektivität flexibel sein und dem Team ermöglichen, kurzfristig Extraktionen
durchzuführen, Zuordnungen nach Bedarf zu ändern und dabei die Datenqualität zu optimieren.
Wenn möglich, sollte das Team über schnell extrahierbare Daten aus den Quellanwendungen
verfügen, die es selbst kontrolliert und die leicht zu modifizieren sind.
Ein typisches Beispiel für die möglichen Auswirkungen eines unflexiblen Ansatzes für die
Konnektivität ist ein US-amerikanisches Unternehmen der Fertigungsindustrie, das Dutzende
von Anwendungen im Rahmen eines globalen Modernisierungsprogramms in einer einzelnen
SAP-Instanz konsolidierte. Für eines der Quellsysteme nutzte das Team bestehende monatlich
extrahierte Daten einer alten Mainframe-Anwendung. Obwohl die Datenextrakte alle Daten
enthielten, die das Team zu verwenden plante, konnten vorgesehene Änderungen an den
Quelldaten nicht getestet werden. Auch ein testweises Laden des kompletten Zielsystems war
lediglich einmal monatlich möglich. Durch diese Einschränkung konnten die Datenverwalter
des Unternehmens die Validität ihrer Datenqualitätsmaßnahmen auf dem Quellsystem sowie
der vom Entwicklerteam erarbeiteten Geschäftsregeln nicht überprüfen. Sie konnten nur
einmal im Monat einen Testlauf durchführen. Durch den langen Validationszyklus zwischen den
monatlichen Testläufen ohne alternative Testmöglichkeit wurde das Projekt erheblich verzögert.
8
White Paper
Mangelnde Zusammenarbeit
Stellen Sie sich folgendes Szenario vor: ein Datenmigrationsteam stellt fest, dass die
Kundendaten nicht über einer eindeutige Kennzeichnung oder ein Attribut verfügen, wodurch
klar wird, ob der Kunde eine natürliche Person oder ein Unternehmen ist. Das Quellsystem
erforderte eine solche Unterscheidung nicht, das Zielsystem erfordert sie aber. Die Entwickler
verbringen Wochen damit, verschiedene Zeichenkettensuchen und Algorithmen anhand der
Inhalte zu testen. Sie haben damit bei ca. 95 % der Daten Erfolg, kämpfen aber immer noch
mit den verbleibenden 5 %. Statt zu versuchen, das Problem alleine zu lösen, könnten die
Entwickler bei den Datenverwaltern oder dem Implementierungsteam Rat suchen, was die
unklaren Daten anbetrifft. Sie könnten nachfragen, ob ein Standardwert funktionieren könnte
oder welche Auswirkungen die momentane Datenqualität haben könnte – aber sie tun es
nicht. Stattdessen verbringen sie Wochen mit der Arbeit an diesem einen Problem. Solche
Vorgänge sind nicht ungewöhnlich. Die meisten Datenmigrationsteams erkennen den Wert der
Zusammenarbeit mit den betrieblichen Anwendern und Datenverwaltern nicht.
Die Vermeidung dieses Problems ist einfach: Beziehen Sie die Datenexperten, im Allgemeinen
die betrieblichen Anwender, ein. Bei großen Projekten können Sie diesen sogar formell eine
Funktion als Datenverwalter zuweisen. Dies sind die Personen, die dafür qualifiziert sind,
zu beurteilen wann Daten „gut genug“ sind, was im Quellsystem korrigiert werden muss,
was wie verbessert werden muss und welche Umwandlungen richtig funktionieren oder
nicht. Sie entscheiden, welche Daten migriert und welche archiviert werden. Sie beurteilen
Datenqualitätsübersichten und genehmigen Optimierungen der Datenqualität. Es reicht nicht
aus, betriebliche Anwender nur bei der ersten Quelle-Ziel-Zuordnung und bei Akzeptanztests
einzubinden. Erfolgreiche Datenmigrationsprojekte, die rechtzeitig fertig werden, mit dem
geplanten Budget auskommen und das volle Vertrauen der Endanwender genießen, beziehen
betriebliche Anwender vom ersten bis zum letzten Tag ein.
Unzureichende Tools
Viele Teams versuchen entweder, eine Datenmigration selbst zu programmieren oder setzen
ihre vorhandenen Tools nicht effektiv ein. Jede Datenmigration ist ein Einzelfall und die
Unternehmensziele sind jeweils andere, aber bestimmte Anforderungen sind für alle Branchen
und alle Arten von Anwendungen gleich. Die Wahl der richtigen Tools und das Wissen um deren
korrekte Anwendung erhöhen die Erfolgschancen bei jeder Migration von Anwendungsdaten
erheblich. In der folgenden Tabelle finden Sie bekannte Erfolgsfaktoren für Datenmigrationen
und die zugehörigen Tools. Darin ist auch die Zuordnung zu den Funktionen der Informatica®
Plattform aufgeführt, die verschiedene Aspekte der Integration von Unternehmensdaten
von Data Warehousing und Stammdatenverwaltung bis zu Datensynchronisierung und
Datenqualitätsmanagement unterstützt und dabei eine enge Zusammenarbeit zwischen der IT
und den Geschäftsbereichen ermöglicht.
Für die Datenmigration umfasst die Informatica Plattform Tools und Funktionen für die
Datenintegration (DI), die Datentransfer, Wiederverwendbarkeit, Konnektivität und Prüfungen
unterstützen. Sie enthält darüber hinaus Tools für die Datenqualität (DQ) und Funktionen
für die Datenerkennung und Datenbereinigung. Die Produktpalette von Informatica zum
Information Lifecycle Management (ILM) ermöglicht die Archivierung für die Außerbetriebnahme
alter Anwendungen und die Steigerung der Leistung von Zielanwendungen sowie die Bildung
von Datenuntergruppen für einen flexiblen Extraktionsprozess und Datenmaskierung für die
Gewährleistung der Sicherheit.
Die fünf größten Fallstricke bei der Datenmigration - und wie man sie vermeidet
9
Collaboration
Data Quality
Reusability
Data
Discovery
Audit
Connectivity
Informatica Platform for Data Migration
Enterprise Data
Integration
Data Quality
Application ILM
Informatica bietet eine umfassende, einheitliche, offene und wirtschaftliche
Datenintegrationsplattform, die optimale Vorgehensweisen bei der Datenmigration unterstützt.
Mit derselben Plattform können Sie die laufende Datenintegration verwalten, einschließlich
Datensynchronisierung, Data Governance und Stammdatenverwaltung. Viele unserer Kunden
nennen erhöhte Anwenderproduktivität als einen der größten Vorteile der Plattform, da
ihre Teams damit Datenintegrationsprozesse schnell erstellen und im Ergebnis qualitativ
hochwertige Daten liefern können.
10
White Paper
Erfolgsfaktor
Produktfamilie Funktionen der Informatica Plattform
Datenerkennung
DQ, ILM
•Erkennung von Datenqualitätsproblemen zu Beginn der Datenmigration
und damit Vermeidung von Verzögerungen
•Verwaltung des Datenzuwachses
•Unterstützung bei der Einhaltung gesetzlicher Auflagen
•Schutz sensibler Daten
•Sichere Außerbetriebnahme alter Systeme und Anwendungen
Datentransfer:
Wiederverwendbarkeit
DI, DQ, ILM
•Zugriff auf praktisch alle Datentypen im Unternehmen, wie:
–Strukturierte, unstrukturierte und halbstrukturierte Daten
–Relationale, mainframe-, datei- und standardbasierte Daten
–Daten in Nachrichtenwarteschlangen
•Vermeidung von Neuprogrammierung durch eine flexible Architektur auf
Metadaten-Basis, die Definitionen über mehrere Plattformen und Projekte
hinweg standardisiert und wiederverwendet
•Sämtliche Profiling- und Regelspezifikationen von Unternehmensanalysten
und Datenverwaltern anwendungs- und projektübergreifend wiederverwenden
Datentransfer:
Datenqualität
DQ
•Daten analysieren, bereinigen und einem Profiling unterziehen
•Logische Datenobjekte definieren und modellieren
•Datenqualitätsregeln mit ausgereifter Datenumwandlungslogik kombinieren
•Midstream-Profiling durchführen, um die Logik schon bei ihrer Entwicklung
zu validieren und zu testen
Datentransfer:
Prüfung und
Validierung
DI, DQ
•Konsolidierung von Metadaten in einem einzigen Integrationskatalog, um
eine bessere Transparenz komplexer Datenbeziehungen zu schaffen und
das Vertrauen in die Daten zu erhöhen, die die Grundlage geschäftlicher
Entscheidungen bilden
•Validierung der Datenumwandlungen und Datenqualität-Mappings durch
einen speziellen Abgleichsprozess
•Profilieren, Analysieren und Erstellen von Datenqualitätsübersichten
•Durchführung von Tiefenanalysen bestimmter Daten mangelnder
Datenqualität, um ihre Auswirkung auf die Datenmigration zu ermitteln und
herauszufinden, wie sie behoben werden können
Datentransfer:
Konnektivität
DI, ILM
•Datenquellen auffinden und darauf zugreifen, egal, ob am Standort, bei
Partnern oder in der Cloud
•Zugriff auf und Aktualisierung von Unternehmensdaten, ohne dass spezielle
Programmierkenntnisse in folgenden Bereichen erforderlich sind:
–Gängige Unternehmensanwendungen und Anwendungspakete, unabhängig
davon, ob diese Anwendungen im eigenen Haus oder extern ausgeführt
oder als SaaS (Software as a Service) gehostet werden
–Alle wichtigen Unternehmensdatenbanksysteme und Data
Warehousing-Umgebungen
–Mainframe-Systeme
–Midrange-Systeme
–Message-Oriented Middleware (MOM)
–Branchenweite Technologiestandards wie beispielsweise E-Mail, JMS,
LDAP und Webdienste
•Zeitnaher Zugriff auf Datenbankänderungen mit Funktionen für Change
Data Capture
•Schnelles Auffinden von Daten mit flexiblen Objektfilterungsverfahren zur
Reduzierung von Fehlern und Beschleunigung der Entwicklung mit einer
Point-and-Click-Benutzeroberfläche
•Erstellung von Datenuntergruppen für die Aufbereitungs- oder
Entwicklungsumgebungen für die Datenmigration, was dem Team einen
schnellen Start in das Projekt sichert
•tMaskierung wichtiger Daten für den Datenschutz und die Einhaltung behördlicher
Vorgaben für die Entwicklungs- und Testumgebungen der Datenmigration
Zusammenarbeit
DI, DQ, ILM
•Bereitstellung robuster, visueller Tools und leistungsstarker ProduktivitätsTools für das Team, die die Zusammenarbeit zwischen Architekten, Analysten
und Entwicklern erleichtern
•Bereitstellung von Tools für Unternehmensanalysten und Datenverwalter,
mit denen diese das Data Profiling selbst durchführen können
•Profilieren, Analysieren und Erstellen von Datenqualitätsübersichten
•Durchführung von Tiefenanalysen bestimmter Daten mangelnder
Datenqualität, um ihre Auswirkung auf die Datenmigration zu ermitteln und
herauszufinden, wie sie behoben werden können
•Überwachen und Austauschen von Messgrößen für Datenqualität und
Berichten durch E-Mail-Versand entsprechender URLs an Kollegen
•Festlegung von Zielen für die Datenqualität und von gültigen Referenzdatensätzen
•Definition, Validierung, Konfiguration und Testen der Datenqualitätsregeln
•Effiziente Zusammenarbeit mit IT-Entwicklern, um Profile auszutauschen
und Datenqualitätsregeln zu implementieren
•Erkennen von Unregelmäßigkeiten und Verwaltung von
Ausnahmedatensätzen zur Datenqualität
•Kontinuierliche Verfolgung der Datenqualitätsziele
•Mobilisierung der wichtigen Personen zur Verbesserung der Daten
Die fünf größten Fallstricke bei der Datenmigration - und wie man sie vermeidet
11
Schlussfolgerungen
Die Anwendung der richtigen Tools und Vorgehensweisen ermöglicht es dem Team für die
Migration der Anwendungsdaten, häufig gestellte Fallen zu vermeiden, die zu Kostensteigerungen
und Verzögerungen führen können. Die Informatica Plattform ist eine umfassende, einheitliche,
offene und wirtschaftliche Datenintegrationsplattform, die alle notwendigen Tools für optimale
Vorgehensweisen bei der Datenmigration umfasst. Ihre umfangreichen Funktionen helfen Ihrem
IT-Team bei der Verwaltung und dem Verständnis von Quelldaten, sowohl bei der Datenerkennung
als auch für langfristige Zugriffsanforderungen. Sie ermöglicht dem Team, robuste und flexible
Strategien für Zugriff, Validierung und Prüfung für die Datenmigration zu entwickeln. Und
schließlich gibt die Informatica Plattform Ihren betrieblichen Anwendern und Datenverwaltern die
Möglichkeit, zu verifizieren und sicherzustellen, dass die Daten für die Zusammenarbeit und für
die Tools im täglichen Geschäftsbetrieb geeignet sind.
Informationen zu Informatica
Das Unternehmen Informatica (NASDAQ: INFA) ist führender Anbieter von Datenintegrationssoftware.
Unternehmen in aller Welt erhalten in der heutigen globalen Informationswirtschaft durch die
zeitgerechte Bereitstellung vertrauenswürdiger und relevanter Daten einen Wettbewerbsvorteil, damit
ihre Hauptunternehmensziele erreicht werden. Weltweit vertrauen über 4300 Unternehmen darauf,
dass sie dank Informatica Datenbestände innerhalb oder außerhalb des Unternehmens und in der
Cloud abrufen, integrieren und auf deren Richtigkeit vertrauen können.
12
White Paper
Die fünf größten Fallstricke bei der Datenmigration - und wie man sie vermeidet
13
Informatica GmbH, Lyoner Straße 15, D-60528 Frankfurt am Main
Telefon: +49 69 92 88 09 0 Fax: +49 69 92 88 09 500 www.informatica.com/de
© 2010 Informatica Corporation. Alle Rechte vorbehalten. Gedruckt in den USA. Informatica, das Informatica-Logo und The Data Integration Company sind Marken oder eingetragene Marken der Informatica Corporation in den USA
und in anderen Rechtsräumen weltweit. Alle weiteren Firmen- und Produktbezeichnungen können Handelsnamen oder Marken ihrer jeweiligen Eigentümer sein. Erstveröffentlichung: Juni 2010
7155DE (18.06.2010)
Document
Kategorie
Kunst und Fotos
Seitenansichten
5
Dateigröße
622 KB
Tags
1/--Seiten
melden