WHITE PAPER. Die fünf größten Fallstricke bei der Datenmigration und wie man sie vermeidet

WHITE PAPER Die fünf größten Fallstricke bei der Datenmigration und wie man sie vermeidet

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 Datentransfer: Datenqualität Datentransfer: Prüfung und Validierung Datentransfer: Konnektivität DI, DQ, ILM DQ DI, DQ DI, 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 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 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 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äts- Tools 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)