Um eine Kerntechnologie auszutauschen, gibt es nie den richtigen Zeitpunkt. Je länger man wartet, desto kritischer wird die unvermeidliche Migration. Spätestens der Mangel an Experten, Support und Knowhow zum Ende der Lebenszeit der Technologie zwingt zum Handeln. Im schlimmsten Fall hindert eine veraltete Technologie die Organisation daran, marktkritische Innovationen zu adaptieren. Doch wie schafft man es, den Kern der Anwendung zu erneuern, ohne in einer Katastrophe zu enden?
Alle Situationen, bei denen das Support-Team unterstützen kann, findest Du im initialen Post.
Der Berg, an dem gute Absichten zerschellen
Wenn der Austausch einer Technologie, eines Frameworks oder einer Sprache zu einem Problem wird, ist die Codebasis meistens der Grund dafür. Bei der typischerweise enormen Größe sind unzählige Geschäftsregeln, Prozesse und Sonderlocken im Code vergraben, vergessen und leider oft unzureichend durch Regressionstests abgesichert. Dieser sprichwörtliche Berg schüchtert alle ein. Allein die Notwendigkeit treibt die ganze Organisation, nicht nur Entwickler, Ops, Tester oder Projektmanager dazu an, sich dieser Herausforderung zu stellen. Welche Alternativen haben die Beteiligten dann?
Die einen, die Tabula rasa-Befürworter, möchten alles neu schreiben. Die grüne Wiese lockt mit Versprechen von einer besseren, modernen, schnelleren Zukunft. Aber eine Neuentwicklung kann sehr lange brauchen. Funktionen, Regeln und Sonderbehandlungen können übersehen werden, was geschäftsbedrohend sein kann. Selbst das Neue kann auch schon obsolet werden, bevor es live geht. Hat schon jemand an einer Migration einer Migration gearbeitet? Nein, das ist kein Schreibfehler.
Die anderen, die Stabilitäts-Affinen, wollen den Kern behalten. Never touch a running system! Und wo ist das Problem den Cobol-Host zu erhalten? Sie wollen eher neue Anwendungen um den alten Kern herum bauen und dem Nutzer vormachen, alles wäre neu. Damit bleibt das Kernproblem aber bestehen. Die neuen Anwendungen können ihr Versprechen nur sehr schwer einlösen. Die Trägheit der Kernanwendung zieht die Entwicklungsgeschwindigkeit der neuen Teile schnell herunter. Oder aber die Integration von Altem und Neuen ist Aufwendiger als die Anwendung selbst.
Der Mittelweg der Migration
Trotz aller Stolpersteine gibt es Situationen, in denen beide genannten Wege berechtigt sind. Zumal der dritte Weg nicht nur mühsamer ist, sondern auch zusätzliches Wissen, mehr Geduld und vor allem die Bereitschaft, sich für „Unmögliches“ zu entscheiden, verlangt. Bei diesem Ansatz wird die Anwendung systematisch in fachliche „Inseln“ geschnitten, mit einem Sicherheitsnetz aus Tests überzogen und Schnitt für Schnitt in das neue System überführt. Der Vorteil ist dabei enorm: der Effekt einer Entwicklung „auf der Grünen Wiese“ ohne ein jahrelanges Warten auf den großen Hauruck sorgt für sukzessives, iteratives Umstellen der Anwendung. Die Nutzer kommt schon früh mit Teilen der neuen Anwendung in Berührung.
Damit es funktioniert, und das ist es, was es mühsam macht, braucht es Erfahrung in verschiedenen Architekturmustern, die Fähigkeit, Konzepte von einem Denkmodell in ein anderes zu übersetzen und auch teilweise eine andere Arbeitsweise als zuvor. Dieses Wissen ist im Unternehmen leider oft nicht vorhanden. Oder das Silo-Denken und jahrelange Konformität zu Unternehmensstandards ließen die nötige Flexibilität einrosten. Zusätzlich ist allen eingeschliffenen Strukturen zueigen, dass sie resistent gegenüber Änderungen sind.
Unser Support
Nutzer im Blick behalten, nichts Wichtiges übersehen, Neues lernen, unter Umständen gar noch andere Veränderungen in der Organisation mittragen. Das ist ganz schön viel auf einmal, ein Berg ist selten allein. Wir begegnen solchen Herausforderungen oft in unseren Projekten. Auch die Bandbreite der Lösungen, für die unsere Kunden sich entschieden haben, ist groß. Wir setzen auf unsere Erfahrung und versuchen eben dort den Teams helfen, wo sie diese Hilfe am dringendsten brauchen: Regressionsabsicherung, Transferleistung, Architektur-Knowhow oder neue Entwicklungspraktiken. Natürlich entsteht dabei vor allem Code, denn das zählt und trägt am meisten zum Neuen bei.
Unsere Developer-Coaches kommen ins Team und arbeiten mit am Berg. Sie haben dabei vor allem die Teammitglieder im Blick. Was fehlt an Wissen? Welche Hürden sind in der Technologie und Systemlandschaft zu überwinden? Was kann getan werden, damit die Organisation weiterhin funktioniert und trotzdem schnell und zuverlässig mit der neuen Lösung starten kann? Wenn wir wieder aus dem Projekt raus sind, sind die neue Anwendung und die Teams idealerweise bereit für die nächste Migration. Denn der Wandel ist die einzige Konstante in der Technologie.
Im nächsten Post dieser Reihe schauen wir auf die Herausforderungen, die Erfolg mit sich bringt.
