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
Keine Kommentare:
Kommentar veröffentlichen