Im Zusammenhang mit ScaleUp 360° Legacy IT, der Digitalsummit für IT-Entscheidungsträger, Leiter IT Operations, Leiter Mainframe- und Midrange Services und führende IT Architekten und Entwickler aus DACH, hat we.CONECT Global Leaders mit Dr. Karl-Ingo Friese, Senior Software Architekt bei PPI AG, ein Interview, über seinen Vortrag auf dem Summit, geführt.
Dazu zunächst eine Gegenfrage: Was macht ein Softwaresystem komplex? Sind es die Lines of Code? Die Anzahl der verwendeten Module (Programme, Klassen, …)? Die Anzahl beteiligter Personen und oder Fachabteilungen? Ist es der Vernetzungsgrad der Komponenten untereinander? Oder sind es eher äußere Faktoren: Ein System, das 24/7 laufen muss, niemals ausfallen darf und keine Fehler toleriert? Die Anzahl Subsysteme, die nachgelagert vom zu migrierenden System abhängig sind? Keine Migraition ist wie die andere, weil keine Software wie die andere ist. Dennoch gibt es gemeinsame Aspekte, aus denen sich die richtige Migrationsstrategie ableiten lässt.
Ein wichtiger Punkt ist der Zustand des Gesamtsystems. Gerade komplexe Systeme sind oft über die Jahre gewachsen und bestehen aus einem heterogenen Zoo aus den verschiedensten Hard- und Software Komponenten. Eingie davon modern und gut dokumentiert, andere sind historisch bedingt und seit Jahren nicht mehr gepflegt. Auch die Datenhaltung ist oft in die Jahre gekommen, oft aber so eng mit dem Gesamtsystem verwoben, dass eine Änderung nicht ohne weiteres möglich ist.
Für die Migration zu einem solchen Zeitpunkt ist externe Hilfe sinnvoll. Für eine Migration ist eine besondere, temporär benötigte, Expertise erforderlich. Der Entwurf einer neuen Architektur und des Migrationsprozesses erfordert Erfahrung mit unterschiedlichen Migrationsstrategien. Außerdem besteht für die Dauer der Migration ein (temporär) höhrerer Entwicklerbedarf. Und die Experten des Altsystems sind meist vollständig mit dessen Pflege und Wartung ausgelastet.
Durch diese Situation entsteht eine oft unterschätze soziale Komponente: Eine Migration erfolgt meist spät im Lebenszyklus einer Software, also zu einem Zeitpunkt, wo oft nur noch wenige Entwickler vorhanden sind (Stichwort Kopfmonopole). Wie reagieren Menschen, wenn eine Software, die sie seit 20 Jahre pflegen, abgelöst wird? Gleichzeitig müssen die neuen Mitarbeiter motiviert sein, sich in ein System einzuarbeiten, nur um dieses kurz darauf abzulösen. Ein Schlüssel zum Erfolg ist hier der respektvolle Umgang von alten und neuen Entwicklern, bei dem die Altentwickler als Experten des bestehenden Systems geschätzt und gewürdigt werden.
Big Bang, Chicken Little, Butterfly, Data base Last oder First … es gibt viele Ansätze eine Migration zu planen und zu gestalten. Hier ist fundiertes Expertenwissen gefragt, damit die unterschiedlichen Ansätze evaluiert und für das konkrete Projekt angepasst werden können.
Die Wahl einer erfolgreichen Migrationsstrategie hängt daher eng mit den Antworten auf die Fragen im ersten Absatz der ersten Frage zusammen: Welche Faktoren machen das abzulösende System komplex? Sind Fehler oder Downtimes tolerierbar? Wie schnell muss migriert werden? Erst wenn diese (und weitere) Punkte geklärt wurden, kann eine erfolgreiche Strategie bestimmt werden. Die Grundlage dafür wird oft ein etabliertes Verfahren sein, dass dann anhand der projektspezifischen Merkmale modifziert wird.
Monolothische Systeme stellen eine besondere Herausforderung da. Aus der Nähe betrachtet, handelt es sich oft um eine Vielzahl eng miteinander vernetzter Komponenten, die entweder direkt (Programmaufruf) oder indirekt (Programm A schreibt in Tabelle X und Programm B liest daraus) voneinander abhängen. Hier hat sich unserer Erfahrung nach eine inkrementelle Strategie mit einem agilen Vorgehensmodell bewährt.
Dennoch gibt es auch hier Schwierigkeiten. Versuche, ein solches System abzulösen, scheitern oft daran, dass sich keine sinnvollen Inkremente schneiden lassen. Hier ist es sinnvoll, zunächst die Migrationsziele zu betrachten und – wenn nötig – zu reduzieren. Eine neue Programmiersprache auf einer anderen Hardware in einem anderen Gastsystem, bei dem gleichzeitig das System neu konzeptioniert UND die Datenhaltung erneuert werden soll, ist in der Regel nicht darstellbar. Hier hilft es, sich in einem ersten Schritt auf das für den Kunden Wesentliche zu konzentrieren: Was soll durch die Migraiton erreicht werden? Ist dieser Punkt geklärt, lässt sich eine Interimsarchitektur entwerfen und diese mit einer speziell für dieses Projekt entworfenen / angepassten Strategie erreichen.
Weiter Informationen finden Sie unter folgendem Link:
Nehmen Sie am ScaleUp 360° Data Governance teil:
Der Digitalsummit für Data Strategie- und Data Governance Entscheider aus der deutschsprachigen Industrie
