Montag, August 25, 2008

Application Renewal. Was noch fehlt.

In den letzten Beiträgen habe ich erzählt, was eigentlich hinter Application Renewal steckt und was die Kernpunkte eines Migrationsprojektes sind. Wenn das aber nur Codekonvertierung und Datenmigration wären, dann wäre es mit dem Anschaffen, Anpassen und Anwenden von Migrationswerkzeugen schon getan, und dann könnt's ja jeder. Nein, es sind noch zahlreiche andere Dinge zu berücksichtigen.

Bei einer Migration müssen praktisch alle Teile eines Systems angefasst oder zumindest betrachtet werden, und hier werden schnell Begehrlichkeiten geweckt. Diese alte Benutzerkontenverwaltung wollten wir schon immer austauschen, Single-Sign-On steht schon lange auf der Todo-Liste, und dem alten GUI für Online-Transaktionen sieht man ja noch die 3270-Masken an, hier brauchen wir was zeitgemäßes Browser-basiertes. Selbst wenn diese Punkte und ihre Folgen (Konzeption und Realisierung, Multi-Projekt-Management, Schulungen, ...) nicht an Land gespült werden oder man sie sinnvollerweise auf nach der Migration verschieben kann, bleiben genügend offene Flanken übrig: Funktioniert der Job-Scheduler auch auf der neuen Plattform, oder muss man ihn auswechseln? Werden die Druckstraßen Gott sei Dank per FTP angesprochen, oder verwenden Sie ein proprietäres Protokoll, das auf der Zielplattform nicht mehr existiert? Welche Schnittstellen zu anderen Anwendungssystemen gibt es beim Kunden, und können diese weiter bedient werden? Gibt es Datenträgeraustausche mit externen Firmen, benutzen sie alle schon CD/DVD oder Mailanbindung, oder werden noch Kassetten erzeugt, und ist dies auch auf der neuen Plattform möglich? Was für Archiv- und Auslagerungssysteme sind wie angebunden, und wenn ich sie nicht weiterverwenden kann, welche Teile sind bis wann umzustellen, welche gesetzlichen Aufbewahrungsfristen sind zu beachten? Welcher Teil der hoffentlich vorhandenen Dokumentation (Betriebskonzepte, Fachkonzepte, Testpläne, ...) kann weiterverwendet werden, und was ist von wem wie anzupassen? Gibt es Code-Repositories oder Change-Management-Datenbanken und wie bestückt man sie? Die Liste kann fortgeführt werden und man merkt, es gibt genügend Freiraum für Fehler und Versäumnisse.

Wie kann sowas jetzt Spaß machen? Ich weiß zumindest, warum es mir Spaß macht. In meiner Zeit bei Accenture war ich in unterschiedlichen Bereichen tätig: Fachkonzept, Anwendungsentwicklung, Test, Infrastruktur, technische Architektur, Helpdesk, ... In jedem Bereich konnte ich Neues lernen, aber erst jetzt auf einem Application Renewal Projekt habe ich den Eindruck, dass sich alles Gelernte zu einem ganzheitlich Nutzbaren zusammenfügt. Die Umstellung eines kompletten Systems betrifft nun mal per Definition alle Bereiche, vom Entwicklungsprozess bis hin zum Endanwender, von der Hardwarebeschaffung bis zum Abnahmekonzept. Für Neueinsteiger bietet sich somit ein weites Betätigungsfeld mit interessanten Aufgaben für jeden Geschmack, und Quereinsteiger können praktisch jede Erfahrung sinnvoll einbringen.

So, das wars fürs erste. Wenn jemand neugierig geworden ist oder Fragen zu Application Renewal hat: Mein Name ist Dierk Jordan, und ich stehe gerne zur Verfügung.

Gruß

Dierk

Montag, August 11, 2008

Application Renewal. Ein Migrationsprojekt.

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

Dienstag, August 05, 2008

Application Renewal. Aha. Und was ist das?

Totgesagte leben länger, und deswegen gibt es immer noch Mainframes. In letzter Zeit ist jedoch ein Trend weg vom Mainframe und hin zu Serversystemen spürbar. Warum jetzt? Der Betrieb von Mainframes ist nicht nur teuer, sondern er wird auch nicht billiger. Es wird mangels Nachwuchs immer schwieriger, Mainframe-Spezialisten zu finden. Die Lizenzgebühren können als horrend bezeichnet werden. Ein weiteres Problem ist, dass einige Hersteller mangels kritscher Masse den Support langsam auslaufen lassen. Der wesentliche Grund ist jedoch, dass aufgrund verbesserter Prozessorarchitekturen viele Serversysteme mittlerweile ähnlich leistungsfähig oder sogar noch besser sind als klassische Mainframes. Selbst Emulationen von Mainframes sind inzwischen möglich, bezahlbar und performant.

Firmen, die aufgrund von Wachstum ihre Rechnerkapazitäten erweitern müssen, stehen also zunehmend vor der Wahl, sich nicht den nächstgrößeren, leistungsfähigeren Mainframe anzuschaffen, sondern Ihre Applikationen und Daten z.B. auf eine serverbasierte Unix-Umgebung zu migrieren und dort weiter zu betreiben. Der Mehrwert für den Kunden liegt üblicherweise in deutlich niedrigeren Beschaffungs- und Betriebskosten, die sich sehr schnell amortisieren. Nicht erstaunlich, wenn man bedenkt, dass etwa hinter 1 GB Mainframe-RAM ein sechsstelliger Betrag stehen kann - in Euro. Eine Migration ist jedoch komplex und vom Aufwand her nicht zu unterschätzen. Benötigt werden passende Werkzeuge, zusätzliche Mitarbeiter und ein Plan. Nur wenige Firmen schaffen das alles alleine, zusätzlich zum laufenden Betrieb. Deswegen sind Migrationsprojekte ein zentrales Angebot der Accenture-Gruppe "Application Renewal".

Mein Name ist Dierk Jordan, Application Renewal Manager im Office Frankfurt, und ich arbeite derzeit auf einem solchen Migrationsprojekt bei einer deutschen Versicherung. Wir migrieren Cobol-Anwendungen von einem Mainframe auf eine AIX, implementieren die hierfür notwendige Software-Architektur auf der Zielumgebung, überführen die Daten von einem Netzwerk-Datenmodell in ein relationales, testen das ganze und schalten es scharf.

Und was das jetzt alles genau bedeutet, das erzähle ich euch in einem nächsten Blog.

Gruß

Dierk