Letztes Mal hab ich berichtet, warum man überhaupt migrieren will, und heute erzähle ich euch, wie das funktioniert.Die Kernaufgaben einer Migration bestehen darin, Anwendungen auf einer neuen Plattform zum Laufen zu bringen, und ihnen die hierfür erforderlichen Geschäftsdaten zur Verfügung zu stellen. Eine Plattform besteht hierbei u.a. aus Hardware, Betriebssystem, Compiler, Entwicklungsumgebung, Archivsystemen, Druckstraßen und vielem mehr, und praktisch alles davon kann im Rahmen einer Migration ausgetauscht werden und soll danach auch noch zusammen funktionieren. Eine Fülle von Möglichkeiten, Fehler zu machen, und deswegen macht man sowas auch nicht von Hand, sondern beschafft sich zunächst die richtigen Werkzeuge dafür. Die gibt es mittlerweile zahlreich, z.B. von den Hardware-Herstellern selber, von ausschließlich auf Migrationen spezialisierten Drittanbietern, oder eben auch von uns: Accenture Application Renewal.
Um Code auf einer anderen Plattform zum Laufen zu bringen, wird er konvertiert, etwa von einem Cobol-Dialekt in einen anderen oder auch zwischen unterschiedlichen Programmiersprachen. Hierzu wird vom Konvertierungswerkzeug zunächst eine Sourcecodeanalyse durchgeführt und die gefundene Codestruktur in ein Zwischenformat übertragen. Dies hat u.a. den Vorteil, dass dieses Zwischenformat in einer für Analysen geeigneteren Form abgelegt und mit Metadaten angereichert werden kann. Aus dem Zwischenformat wird in einem nächsten Schritt der Sourcecode für die Zielplattform erzeugt, indem sog. Konvertierungsregeln angewendet werden. Diese Regeln geben z.B. die Syntax einer If-Abfrage in der Zielsprache vor, oder bestimmen geeignete Zieldatentypen und -größen für die verwendeten Variablen. Erst die Verwendung eines regelbasierten Konvertierungswerkzeugs ermöglicht einen industrialisierten Migrationsansatz, d.h. die massenhafte gleichförmige Transformation von Code. Dadurch muss der konvertierte Code nicht notwendigerweise vollständig getestet werden, es genügt vielmehr, für jede angewendete Konvertierungsregel ein oder mehrere Codestellen zu bestimmen und diese erfolgreich zu durchlaufen. Testabdeckung wird somit nicht anhand der Menge des im Test ausgeführten Codes, sondern der Anzahl der durchlaufenen, unterschiedlichen Konvertierungsregeln gemessen.
Um den Anwendungen auch die Geschäftsdaten zur Verfügung zu stellen, ist zunächst zu bestimmen, welche Daten von den Programmen benötigt werden, wo diese gespeichert sind, und in welchem Format. Dieses Quelldatenformat wird dann mit Hilfe von aus der Datenbeschreibung generierten Programmen validiert. Nach der Beseitigung etwaiger Unstimmigkeiten zwischen Datenbeschreibung und realen Daten können schließlich Entladeprogramme aus dem validierten Quellformat erstellt werden, welche die zu migrierenden Daten in ein transferierbares Zwischenformat umwandeln. Als Zwischenformat eignet sich z.B. pures ASCII, weil es von praktisch allen Plattformen verarbeitet werden kann. Parallel dazu wird passend zur Codekonvertierung ein Zieldatenformat festgelegt. Hieraus werden dann Beladeprogramme erzeugt, welche die transferierten Daten aus dem Zwischen- in das Zielformat übertragen. Die Verwendung eines Zwischenformats ermöglicht es hierbei, die beiden Blöcke Ent- und Beladung separat zu implementieren und zu testen. Dies erleichtert nicht nur die Analyse und Beseitigung von Fehlern, sondern spart auch Zeit.
Und was man sonst noch so für eine Migration braucht und übersehen kann, und warum das alles sogar Spaß macht, das erzähle ich euch das nächste Mal.
Gruß
Dierk
Keine Kommentare:
Kommentar veröffentlichen