OWB2ODI-Mit der Migration das DWH modernisieren.pptx

•  In unserem Vortrag soll es nicht so sehr um die rein technische Seite der Migra5on gehen •  Wir zeigen hier nicht wie das Migra5onswerkzeug konﬁguriert und bedient wird •  Wir wollen einen Ausblick geben, wie eine Migra5on vom OWB zum ODI als Projekt umgesetzt wird •  Und welche Chancen so eine Migra5on evtl. bieten kann, um nicht einfach nur „ein Tool durch ein anderes zu ersetzen“ •  „DWH“ steht hierbei vertretend für alle Umgebungen, in denen OWB -‐ ETL-‐
Prozesse zum Einsatz kommen, egal ob es sich „Datenhub“, „Opera5onal Datastore“ oder „Data Marts“ schimpQ 1 2 3 4 5 6 7 8 9 • 
• 
• 
• 
• 
Der ODI ist nicht nur aus Sicht von Oracle der logische Nachfolger des OWBs Die E-‐LT-‐Strategie wird mit dem ODI fortgeführt und erweitert. Durch die technische und methodische Nähe beider Tools ist der Ums?eg schnell realisiert. Für die Migra?on vom OWB zum ODI liefert Oracle ein Migra?onswerkzeug, welches für den überwiegenden Teil der Objekte solide funk?oniert. Lediglich das Fehlen einer Migra5on von Prozessﬂüssen (Oracle Workﬂow à ODI Packages) kann als Manko angesehen werden. In der Praxis wird der OWF aber überraschenderweise wenig verwendet. Hat man den Weg in Richtung ODI erst einmal vollzogen, dann stellt man schnell fest, dass die Produk?vität deutlich steigt. Das liegt u.a. an •  der Modularisierung durch den Einsatz von Knowledge Modulen •  die damit einhergehende Standardisierung der E-‐LT-‐Prozess •  die Möglichkeit der Automa?sierung micels des ODI SDK 10 •  Zentrale Komponente des ODIs sind die Knowledge Module (KM) •  Für jede Phase des ETL-‐Prozesses gibt es verschiedene KMs, die für die unterschiedlichen Technologien entwickelt wurden. •  Die Anpassung der KMs ist leicht zu erlernen, da man sich in der Sprache des dazugehörigen Systems bewegt (z.B. SQL + PL/SQL wenn mit einer Oracle-‐DB agiert wird) •  Über die KMs werden Prozesse automa?sch standardisiert und einzelne Funk5onen (z.B. Historisierung/SCD2) als Modul ausgelagert. •  Damit ist die Implemen?erung der eigentlichen Mappings deutlich weniger komplex à deklara5ves Design in Perfek5on! • 
• 
• 
• 
• 
• 
Reverse: Engineering Metadaten Journalize: Über CDC Delta abgrenzen Load: Aus Quellen in Staging Check: Constraints vor dem Laden prüfen Integrate: Transformieren und in Ziel integrieren Service: Daten-‐ oder Transforma5onsservice •  Beispiel KMs (out-‐of-‐the-‐box): •  Oracle GoldenGate •  Oracle DB Link 11 •  Mit der Version ODI 12c sind viele Funk5onen des OWBs in den ODI integriert worden. •  Bei der Erstellung von Mappings hat der Entwickler miclerweile eine ähnliche Operatoren-‐Vielfalt zur Verfügung, alle anderen Funk?onen lassen sich durch KMs oder Einbinden von Rou5nen implemen5eren. •  Um viele neue Funk?onen muss sich der Entwickler nicht mehr explizit kümmern, da diese in die KMs integriert wurden (z.B. SCD2) •  Nach unserer Erfahrung ist die Lernkurve eines OWB-‐Entwicklers beim Erlernen des ODIs sehr steil. 12 •  Mit der Java-‐API hat man quasi alle Möglichkeiten, eine Automa5sierung zu implemen5eren. •  Es können alle Funk?onen des ODI gesteuert werden. Das ODI SDK ersetzt OMB*Plus im OWB, ist aber durch die Verwendung von Java stac tcl deutlich ﬂexibler und besser einzusetzen. •  Durch die Automa5sierung lassen sich Entwicklungsvorgaben großﬂächig anwenden. Änderungen an den Standards werden einmalig im Java Code geändert und dann schnell auf die betroﬀenen Bereiche ausgerollt. Das ist ein entscheidender Faktor bei der Steigerung der Entwicklungsgeschwindigkeit. •  In unseren Projekten setzen wir die Automa5sierung z.B. bei der Generierung von Data Vault-‐Mappings und bei der Replika?on von Daten aus den Quellen in die Stageebene ein. 13 •  Wenn eine Migra5on angegangen werden muss und beschlossene Sache ist, wo bieten sich evtl. Poten5ale mit geringem bzw. gar keinem Mehraufwand das bestehende DWH zu modernisieren? •  Welche Dinge kann man generell bei einer Migra5on, die ja doch auch immer eine Umgestaltung ist, überdenken und vielleicht neu regeln? Was kommt auf den Prüfstand? •  Mehr rausholen, als nur eine 1:1 -‐ Migra5on 14 •  Automa?sches Testen wird noch nicht in jedem DWH-‐Projekt durchgeführt •  Der Wechsel zu einem neuen Tool bietet die Chance bzw. die Notwendigkeit, ein Testmanagement einzuführen oder dieses zu verbessern. •  Überprüfung der Migra5on -‐ wurden alle Prozesse rich?g migriert und liefern sie die selben Daten? •  Einführung eines kon5nuierlichen und automa5sierten Testmanagements, um die Korrektheit der Prozesse regelmäßig zu prüfen. •  Ein Testmanagement ist aus heu?gen DWHs nicht mehr wegzudenken und gerade im agilen Umfeld ein Muss. •  Kann auch dazu genutzt werden, um Datenqualitätschecks zu ins?tu?onalisieren und im Repor5ng auszuweisen à DQ-‐Data Mart á la Kimball •  Knowledge Module (Check-‐, Load-‐ und Integra5on-‐KM) bieten hier an den verschiedensten Stellen die Möglichkeit, Prüfungen auf den Quell-‐ und/oder Zieltabellen auszuführen und diese zu vergleichen •  z.B. Häuﬁgkeiten, Gesamtsummen, konkrete Werte, etc. •  Tes]ools können aus dem ODI angetriggert werden •  z.B. in Loadplänen, über Prozeduren, direkt in Packages) 15 •  Aus unterschiedlichen Gründen kann es notwendig sein, dass auch die Laufzeitmetadaten im Zuge einer Migra5on übernommen werden müssen •  Revisionssicherheit •  Monitoring inkl. Performanceanalysen •  Sowohl die Audit-‐Daten des OWBs als auch die des ODIs werden im Repository abgelegt und können per SQL ausgelesen werden. •  Allerdings ist die Struktur unterschiedlich… •  Unsere Best Prac?ce in vielen Projekten: Auslesen der Audit-‐Daten in einen separaten Data Mart, um •  das Repository vom Datenumfang klein halten (Performance) •  in einer separaten Struktur (Performance-‐Mart) die Möglichkeit für umfangreiche Analysen der ETL-‐Prozesse bieten. •  In einer OWB2ODI-‐Migra?on ist es daher sinnvoll, die OWB-‐Audit-‐Daten zunächst in diesem Data Mart zu sichern und sie so mit den ODI Audit-‐Daten zusammenzuführen. •  "Nebenbei" hat man so die Möglichkeit, einen Abgleich der Performance von OWB-‐ und ODI-‐Mappings zu erstellen und direkt die möglichen Problembereich zu iden5ﬁzieren. 16 •  Der überwiegende Teil der OWB-‐Installa5onen nutzt nur das Core-‐ETL. •  Komfor_unk?onen wie z.B. die Nutzung von SCD2 in Dimensionsoperatoren oder das Load Ordering dürfen somit nicht genutzt werden. Aber auch der Oracle Workﬂow behält viele Operatoren nur der Enterprise ETL-‐Op?on vor. •  Die Folge sind sehr komplexe Mappings. Auch besteht häuﬁg die Notwendigkeit, ein MERGE in mehreren Mappings zu implemen5eren, deren Basisabfrage iden5sch ist. •  Mit den Möglichkeiten des ODIs stehen dem Entwickler alle notwendigen Funk?onen zur Verfügung, um die Komplexität zu minimieren und Wartbarkeit zu verbessern. •  Beispiel: Für die Implemen5erung einer SCD2-‐Historisierung exis5ert im ODI ein KM, welches mit wenigen Konﬁgura5onsschricen zum gewünschten Ergebnis führt. Das eigentliche Mapping konzentriert sich dabei auf das Wesentliche: die Übertragung der Daten von der Quelle ins Ziel. •  Gibt es spezielle Anforderungen an die Datenverarbeitung, so können eigene KMs schnell erstellt und eingesetzt werden (z.B. für Par55on Exchange Loading) •  Im Bereich der Prozessteuerung bietet der ODI mit den Packages und den Ladeplänen ein mäch5ges Werkzeug, um komplexe Vorgänge abzubilden. 17 •  Eine Migra?on bietet nicht nur die Möglichkeit „Workarounds“ abzulösen, sondern auch Grundlegendes zu ändern •  Teilweise muss dies gemacht werden, weil der ODI einige Möglichkeiten nicht bietet (S5chwort Workﬂows) •  Datenmodell-‐Änderungen, hin zu mehr Standardisierungen •  Möglicherweise Data Vault •  Einheitliche Steuerspalten und Namenskonven5onen •  Standardbeladungen, ETL-‐Muster, nicht mehr jede Tabelle/Quelle wird anders beladen, sondern alle einheitlich •  Wird durch die IKM unterstützt •  Zusammenführen von Logik, die in mehreren OWB-‐Mappings gleich gebaut ist in ein Mapping, das mehrfach verwendet wird •  Temporäre Mappings im ODI •  Chance, altes loszuwerden •  ETL-‐Prozesse, die nicht mehr genutzt werden •  Fakten/Dimensionen, die nicht mehr genutzt werden •  Umstellung SCD1/SCD2 (braucht der Fachbereich wirklich SCD2-‐
Dimensionen?) •  Chance, neues einzuführen •  Eine eigene Test-‐/Integra5onsumgebung (erst zum Test der Migra5on, später zum Test von Neuentwicklungen) 18 •  Durch den Einsatz von In-‐Memory Technologien können einzelne ETL-‐Prozesse im Sinne eines Batch-‐Ablaufes ggf. komplec en_allen •  Zum Beispiel zur Virtualisierung des Repor?ng Layers, indem die Dimensionen und Fakten nicht mehr separat durch ETL geladen werden, sondern direkt auf den persis5erten Daten des DWH-‐Core durch Views abgebildet werden •  Erhöhung der Aktualität der verfügbaren Daten für das Repor5ng •  Ablösung von Persis?erungen, die nur für Performance-‐Op5mierungen geschaﬀen wurden •  En_ernen von Vorberechnungen von Kennzahlen in Form von MAVs •  Dazu muss der Core natürlich die entsprechenden Daten auch bereits vorhalten und die komplece, im User View – Layer benö5gte Historie, muss vorhanden sein •  Außerdem müssen die entsprechenden Core-‐Tabellen im In-‐Memory verfügbar sein •  Erfordert aber keine Anpassungen an den Ladeprozessen, die Tabellen befüllen, die anschließend im Memory verfügbar sein sollen •  Security muss ggf. im Core schon implemen5ert sein, wenn dies vorher sonst in den Data Marts gelöst war •  Durch Wegfall von zum Beispiel Bitmap-‐, oder B-‐Tree-‐Indizes lässt sich dadurch weiter Speicher sparen 19 •  Um den Umfang der OWB Migra?on auf das Notwendige zu reduzieren, sollten das OWB Repository um nicht mehr genutzte Objekte bereinigt werden. •  Eventuell ist die Migra5on auch der rich5ge Zeitpunkt, die Projekte im Repository neu zu strukturieren (S5chwort "historisch gewachsen") •  Eine Neustrukturierung kann ein großes OWB-‐Projekt in kleinere auaeilen und kann eine Migra5on zum ODI in kleinere Abschnice auQeilen •  Die Neustrukturierung und die notwendigen Prüfungen lassen sich mi]els OMB*Plus und PL/SQL automa?sieren. •  Hierfür sind verschiedene SQL-‐Abfragen auf das Repository hilfreich. •  Zum Beispiel können die OWB Objekte iden5ﬁziert werden, die seit einem längeren Zeitraum nicht mehr ausgeführt wurden. •  Es ist zu prüfen, ob die gefundenen Objekte s5llgelegt oder gelöscht werden können (eine Sicherung der betroﬀenen Objekte ist ratsam). 20 •  Check Knowledge Module (CKM) sind essen?eller Bestandteil des ODIs, um die Datenqualität und –konsistenz zu prüfen. •  Im OWB gibt es die "Data Quality Op?on", die aber wenig bis gar nicht zum Einsatz kam (Lizensierung) •  Micels benutzerdeﬁnierter Regeln und Constraints lassen sich die Daten individuell analysieren und bei Verletzung der Vorgaben in Fehlertabellen ausschleusen. •  Die CKMs können sowohl auf bestehende Daten/Tabellen angewendet (STATIC_CONTROL) oder im Zuge der Datenverarbeitung eingesetzt werden (FLOW_CONTROL). •  Über die CKMs kann die Komplexität der OWB-‐Mappings ebenfalls deutlich reduziert werden. 21 22 •  Muss der OWB wirklich abgelöst werden? Diese Frage stellt sich zunächst, denn ein Austausch der ETL-‐Strecken stellt eine erhebliche Inves??on und ein gewisses Risiko dar. •  Es ist daher zu prüfen, wie lange die Applika?on, die über den ETL-‐Prozess beliefert wird, noch betrieben werden soll. •  Der Premier Support für den OWB läuQ noch bis 2018. Wenn die Applika5on davor (oder kurz danach) außer Betrieb gestellt werden sollte, lohnt sich eine vorherige Migra5on zum ODI vor diesem Hintergrund nicht. •  Sollten Sie auf die Migra?on verzichten, so häce dies allerdings eine kleine Nebenwirkung zur Folge: Sie müssten auf ein Upgrade der zugrundeliegenden Oracle Datenbank auf 12.2 ﬀ. verzichten und könnten eventuelle Features der neuen Version nicht nutzen. 23 •  Die nachfolgenden Punkte müssen grundsätzlich geklärt werden. Je nach Migra5onsszenario können einzelne Punkte einmalig bearbeitet werden, andere müssen in jeder Itera5on erneut untersucht und beantwortet werden. •  Analyse •  Systemrahmenbedingungen analysieren •  ODI-‐Lizenzsitua5on prüfen •  OWB-‐Repository bereinigen •  OWB-‐Version prüfen bzw. upgraden •  ODI-‐Systemumgebung au|auen •  Migrierbarkeit der OWB-‐Objekte prüfen •  Lösungen für nicht migrierbare OWB-‐Objekte suchen •  Chancen/Verbesserungspoten5al iden5ﬁzieren •  Konzep5on/Planung •  ODI-‐Know-‐how au|auen •  ODI-‐Einführungsszenario planen •  Frozen-‐Zone planen •  Fallback-‐Szenario planen •  Umsetzung •  Parallele ETL-‐Strecke au|auen •  OWB-‐Objekte migrieren •  Manuelle Nacharbeiten durchführen 24 •  Die Architektur und Vorgehensweise zur Erstellung von ETL-‐Strecken in OWB und ODI weichen voneinander ab. •  Auch wenn erfahrene OWB Entwickler sich rela5v schnell in der neuen Umgebung zurech_inden, werden sie beim Ums5eg auf den ODI Einarbeitungszeit und Unterstützung benö5gen. •  Das ODI-‐Konzept muss rechtzei?g verstanden werden, um das neue Tool rich5g einzusetzen. •  Dafür muss frühzei5g Budget und genügend Zeit für ein Selbststudium oder Schulungen eingeplant werden. 25 •  Grundsätzlich sind zwei Einführungsszenarien denkbar: •  Big Bang •  Itera?v/Inkrementell •  Das Migra?onswerkzeug zur Überführung vom OWB zum ODI ist miclerweile so ausgereia, dass eine komplec manuelle Migra?on keine sinnvolle Alterna?ve ist. Trotzdem gibt es einzelne Aspekte, die einen manuellen Eingriﬀ sinnvoll bzw. notwendig erscheinen lassen. 26 •  Eine Big Bang-‐Migra?on verspricht die schnellste Umstellung, birgt aber das höchste Risiko. •  Auch organisatorisch ist diese Art der Migra5on eine Herausforderung, da ein Parallelbetrieb und umfangreiche Qualitätstests geplant werden müssen. •  Ein Code-‐Freeze ist Voraussetzung für diese Art der Migra5on, dieser ist abhängig von der Dauer der Migra?on und der nachfolgenden Tests und manuellen Anpassungen. •  Manuelle Anpassungen sind im jeden Fall einzuplanen (Anpassungen/Korrekturen von Mappings, Erstellen von Packages als Ersatz für den Oracle Workﬂow) •  Idealerweise wird die Migra?on auf einer separaten Umgebung, z.B. einer Testumgebung, durchgeführt und läuQ bereits parallel zur OWB-‐Umgebung •  Somit können Schwachstellen, wie langsamere Mappings oder Probleme bei der Datenverarbeitung frühzei?g erkannt und behoben werden. •  Alle ODI-‐Komponenten können im Vorwege eingerichtet werden, im Gegensatz zum ODI werden keine Objekte in der Datenbank deployt. •  Am Tage der Umstellung werden dann die OWB-‐Prozesse deak5viert und die ODI-‐
Agenten gestartet. •  Das OWB Repository sowie die Mappings (PL/SQL-‐Packages) können im Nachgang gelöscht werden 27 •  Ein itera?ver-‐inkrementeller Ansatz bietet sich insbesondere bei großen OWB-‐
Projekten an. •  Große Installa5onen können in handhabbare Abschni]e (z.B. OWB-‐Projekte) aufgeteilt und separat migriert werden. •  Ein Code-‐Freeze bezieht sich damit immer nur auf den gerade betroﬀenen Abschni], in den anderen Bereichen kann weiterentwickelt werden. •  Hier muss natürlich vorher sichergestellt werden, dass zwischen den einzelnen OWB-‐Projekten oder Inkrementen keine Abhängigkeiten bestehen, die zu Seiteneﬀekten führen könnten •  Die Phasen Analyse, Konzep?on/Planung und Umsetzung werden kürzer, da sie sich nur auf den Teilbereich beziehen. •  Nachdem ein Abschnic abgenommen wurde, kann dieser in die Produk5on überführt werden. •  Nachteil: Für die Dauer der Gesamtmigra?on laufen die OWB-‐ und ODI-‐
Umgebungen parallel. •  Weitere denkbare Szenarien •  Den OWB weiter betreiben und nur Neuentwicklungen im ODI vollziehen à Sinnvoll, wenn die betroﬀenen OWB-‐Module sowieso auslaufen sollen •  Au|au nur der Steuerung von OWB-‐Mappings im ODI und sukzessives Ablösen der OWB-‐ durch ODI-‐Mappings à Langsamste Variante eines itera5ven Ansatzes, nur sinnvoll, wenn 28 •  Je nach Ausprägung der OWB-‐Mappings kann das Migra?onswerkzeug bis zu 100% in den ODI überführen. •  Trotzdem wird es einzelne Mappings geben, die manuell erstellt werden sollten, z.B. •  wenn eine Historisierung durch komplexe Mappings umgesetzt wurde und jetzt mit dem SCD2-‐KM implemen5ert werden kann. •  wenn Opera5onen auf mehrere Mappings verteilt werden mussten, um das lizenzpﬂich5ge Load Ordering zu umgehen •  wenn im OWB Dimensions-‐ und Cube-‐Operatoren genutzt wurden, die einen Großteil der Logik kapseln •  OWB-‐Prozessﬂüsse werden überhaupt nicht migriert. Die ODI-‐Mappings müssen entweder über ODI-‐Packages oder über eine externe Ablaufsteuerung ausgeführt werden. Hier ist in jedem Fall mit Mehraufwand zu rechnen. •  Um hier eine genaue Abschätzung des zu erwartenden Umfanges zu erhalten, sind Abfragen auf das OWB Repository ein wich5ges Hilfsmicel. OPITZ CONSULTING setzt diese Abfragen bei Migra5onsprojekten ein. •  Eine komple] manuelle Migra?on ist in der Regel nicht sinnvoll und unnö5g aufwendig, ein gewisser manueller Anteil ist aber immer zu erwarten und sollte frühzei5g abgeschätzt und eingeplant werden. •  Insbesondere, wenn man aber eine Migra?on zu einem anderen ETL-‐Werkzeug 29 •  Neben der eher technischen Planungs-‐ und Umsetzungsphase die wir schon im Abschnic „Migra5onsszenarien“ betrachtet haben, gibt es auch aus Gesamtprojektsicht ein paar Planungsaspekt die berücksich5gt werden sollten •  Im Folgenden aus Projektmanagement-‐Sicht ein paar Empfehlungen, die unabhängig des gewählten Szenarios beim Projekt „Migra5on OWB2ODI“ durchgeführt werden sollten 30 •  „Ziel ist doch aber die Migra5on?“ à das mag durchaus das Oberziel des Projektes sein, aber das lässt sich meist noch in untergeordnete Ziele runterbrechen •  Leistungsziele à Was soll im Rahmen der Migra5on noch erreicht werden? Ablösung von Altlasten? Vereinheitlichungen? Umstellung ohne Störung des Produk5vbetriebs? Hier könnten zum Beispiel auch die aufgezeigten Chancen aus Punkt 2 als Ziele mit eingehen. •  Kostenziele à Grenze des Projektbudgets, Budget für Umsetzung, Budget für Lizenzen, Budget für externe Leistungen •  Terminziele à ist ein Code-‐Freeze für den Zeitraum der Migra5on angedacht? Wie lange darf dieser sein? Gibt es evtl. ein SaisongeschäQ (z.B. Weihnachtsszeit), so dass vor Beginn bzw. während der Hauptsaison keine gravierenden Änderungen am System durchgeführt werden sollen? •  Soziale Ziele à Schulung der Mitarbeiter, Umsetzung ohne Überstunden, Zufriedenheit von Fachabteilungen nicht gefährden •  Nicht-‐Ziele à Was soll konkret ausgeschlossen für die Umsetzung der Migra5on? Was ist „Out-‐of-‐Scope“? Z.B. keine Op5mierung des Core-‐DWH-‐Modells, … •  Deﬁni5on von Muss-‐, Kann-‐ und Soll-‐Zielen, um zu schauen wo am ehesten Abstriche gemacht werden können, wenn oﬀensichtlich nicht alle Ziele erreicht werden können. •  Außerdem muss dann auch noch betrachtet werden, in welcher Beziehung die Ziele zueinander stehen. Schließen sich Ziele ggf. gegensei5g aus, oder behindern 31 •  Es sollte inital eine Analyse des Projektumfeldes durchgeführt werden, um die verschiedenen Faktoren zu ermiceln, die Einﬂuss auf das Migra5onsprojekt und dessen Verlauf haben können •  Die Sachfaktoren beschreiben dabei alle nicht menschlichen Gegebenheiten, wie beispielsweise Verträge, VorschriQen, Richtlinien, Infrastruktur, Technik, kulturelle Besonderheiten und vieles mehr. Sie ergeben sich aus Fragen wie „Was beeinﬂusst mein Projekt?“ oder „Auf was wirkt mein Projekt ein?“. •  Die Sozialfaktoren meinen alle Personen oder Personengruppen die irgendeine geartete Beziehung zum Projekt haben. Diese als Stakeholder bezeichneten Faktoren können beispielsweise Projektmitglieder, Projektgegner, Kunden, AuQraggeber, Verbände, GemeinschaQen sein. Sie lassen sich durch Fragen wie „Wer beeinﬂusst mein Projekt?“ oder „Auf wen wirkt das Projekt ein?“ bes5mmen. •  Sachfaktoren könnten im Rahmen der Migra5on poten5elle Fehlerquellen sein, die man im Vorfeld berücksich5gt haben sollte •  Hierdurch lassen sich vielleicht posi5ve Abhängigkeiten iden5ﬁzieren: •  Z.B. wenn in nächster Zeit sowieso ein Hardwaretausch eingeplant ist, bietet es sich ggf. an das gleich im Rahmen der Migra5on durchzuführen um so zu Testzwecken zwei parallele Umgebungen zu haben 32 •  Was passiert, wenn die Migra5on oder Teile davon schief gehen? •  Was kann es für technische, rechtliche, organisatorische, kaufmännische, terminliche Risiken geben? •  Rechtliche: •  Sind Compliance-‐Regelungen von den bestehenden ETL-‐Prozessen betroﬀen, deren Nicht-‐Einhaltung zu Geldstrafen führen kann? •  Organisatorische/Technische: •  Bereiten die ETL-‐Prozesse evtl. Daten für Produk5onsprozesse oder opera5ve Abläufe auf, so dass ggf. bei einer Nichtverfügbarkeit von Daten mit Produk5onss5llstand gerechnet werden kann? •  Terminliche: •  Sind nachfolgend an die Migra5on weitere abhängige Projekte geplant, die bei Verzögerungen in der Migra5on verschoben werden müssten? •  Kaufmännische/Technische: •  Könnten wich5ge Berichte fehlerhaQ sein und dadurch falsche Management-‐Entscheidungen getroﬀen werden? à Imageverlust der IT-‐
Abteilung •  Abwägen, ob es evtl. sinnvoller sein könnte die Kosten für eine weitere Testumgebung zu inves5eren 33 •  Egal in welcher Form die eigentliche Umsetzung nachher sta}indet, sollte man sich auch bereits im Vorfeld Gedanken über die Strukturierung der Migra5on und einzelne Umsetzungsschrice machen. •  Strukturierung kann in folgenden Formen erfolgen: •  Objektorien5ert: Orien5ert sich am zu erstellenden Produkt/Dienstleistung •  Organisa5onsorien5ert: Orien5ert sich an beteiligten Fachabteilungen und Spezialisten •  Funk5onsorien5ert: Orien5ert sich an den im Projekt erforderlichen Funk5onen und Ak5vitäten •  Damit lassen sich dann anschließend auch leichter zeitliche Abhängigkeiten iden5ﬁzieren und in der Umsetzungsplanung berücksich5gen. •  So sollten natürlich idealerweise die Entwicklerschulungen im ODI schon zu Beginn sta}inden, um in der Umsetzung und insbesondere in den manuellen Nacharbeiten der Migra5on keine Zeit durch weitere Einarbeitung zu verlieren. •  Klar ist natürlich auch, dass selbst bei itera5ver Vorgehensweise bes5mmte Arbeiten bereits zu Beginn erledigt werden müssen. Denn selbst wenn eine Umsetzung pro OWB-‐Projekt vorgesehen ist muss die Zielumgebung mit dem ODI bereits vor dem ersten zu migrierenden Projekt exis5eren 34 •  Sollte eigentlich nicht erwähnenswert sein, aber wir erleben es immer wieder beim Kunden, dass im Bereich der Dokumenta5on gespart wird •  Auch wenn im Agilen Manifest einer der Grundsätze „Funk5onierende SoQware mehr als umfassende Dokumenta5on“ heißt, sollte man nicht ganz auf Dokumenta5on verzichten •  Fehlende Dokumenta5on von fachlichen Anforderungen die in ETL-‐Prozessen umgesetzt sind erschwert später häuﬁg das Leben, insbesondere bei solch schwerwiegenden Projekten wie einer Migra5on, da man sich hier öQer mal wünscht zu wissen, „warum“ früher bes5mmte Entwicklungen so vorgenommen wurden •  Da hier im Rahmen der Migra5on sowieso in der Vorbetrachtung die fachliche Logik angeschaut werden muss, bietet es sich an fehlende Dokumenta5onen nachzuholen •  Auch die Sicherung der aktuellen OWB-‐Umgebung, der vorhandenen Mappings und Prozessﬂüsse, bevor diese durch ODI abgelöst und gelöscht werden, gehört in den Bereich Dokumenta5on •  Durch den rich5gen Einsatz von vorhandenen Werkzeugen wie SVN/GIT, Jira oder Conﬂuence (oder sons5gem Wiki) wird auch das Projekt der Migra5on wesentlich sicherer und nachvollziehbarer durchgeführt 35 36 •  Wie gezeigt bietet sich als zukünQige Alterna5ve für den OWB der ODI durchaus an, obwohl hier keine „kostenlose“ Variante mehr möglich ist •  Auch andere ETL-‐Werkzeuge kosten häuﬁg Geld, teils sogar mehr als der ODI •  Die Migra5on hin zum ODI ist aber sicher eine der einfachsten Varianten, unter anderem durch das exis5erende Migra5ons-‐Tool •  Die Migra5on bieten mit ein paar Überlegungen wie gezeigt ggf. auch Poten5al für „Up-‐Selling“, um nicht nur einen einfachen „Tool-‐Tausch“ durchzuführen •  Der grobe Rahmen, auch aus Projektsicht ist für alle Migra5onen vom OWB zum ODI erst mal iden5sch •  Die genauen Ausprägungen sind dann jeweils abhängig von der Komplexität und der Kri5kalität der jeweiligen Umgebung 37 38 39

Download Report