Core Software Revival: Praxis-Insights von und für Business & IT
Dazu beantworten wir Fragen, die Kunden aus unterschiedlichen Branchen im Zusammenhang mit dem Thema Core Software Revival immer wieder an uns stellen und beleuchten dabei Business- & IT-Aspekte der Modernisierung.
Was sind typische Modernisierungsbedarfe in Unternehmen, die Kernapplikationen betreffen?
Roland: Unternehmen entwickeln sich permanent weiter. Modernisierungsbedarfe entstehen einerseits durch steigende Kundenerwartungen hinsichtlich angebotener Services und User Experience, sowie durch die fortschreitende digitale Transformation. Will ein Unternehmen seinen Kunden beispielsweise digitale Add on-Services zu Produkten oder auch ganz neue Digitalservices bereitstellen, bedingt dies üblicherweise die Abbildung nahtloser End-2-End-Prozesse für diese Services und führt bestehende Kernsysteme oft an ihre Grenzen. Das macht deren Modernisierung in Teilbereichen oder ganzheitlich nötig. Im Gegenzug erhalten Unternehmen Einblick in die Nutzung von Services oder Produkten durch Ihre Kunden. Aufgrund der entstehenden Daten können sie diese besser verstehen, wertvolle Erkenntnisse gewinnen und Maßnahmen ableiten.
Anderseits werden auch Produkt-Entstehungs- und Bereitstellungsprozesse zunehmend digitalisiert. Durch notwendige Anpassungen in diesen Prozessen resultieren oftmals auch Modernisierungsbedarfe für Kernsysteme. Diese Digitalisierung und die damit einhergehende Entstehung von Daten ermöglichen den Aufbau von Digital Twins. Damit lassen sich Prozesse, Produkte oder Anlagen als virtuelle Objekte in der digitalen Welt abbilden und visualisieren.
Ein weiteres großes Thema ist die Erhöhung der Automatisierung von Prozessschritten in Fachabteilungen, um einerseits Mitarbeiter zu entlasten und anderseits die Effizienz zu steigern. Auch hier trifft man bei veralteten Kernsystemen oft auf Schranken, aus denen ein Modernisierungsbedarf entsteht. Ein weiterer Punkt ist die Geschwindigkeit solcher Anpassungen. Man möchte Business-Anforderungen und Prozessanpassungen möglichst schnell umsetzen, dabei hat man bei modernen Systemen natürlich bessere Möglichkeiten.
Ein Punkt, der zwar nicht Kernauslöser für Modernisierungen ist, jedoch immer wieder an uns herangetragen wird, ist auch die Akzeptanz von Kernsystemen durch die Mitarbeiter. Sind Systeme und Benutzeroberflächen veraltet, stoßen diese, insbesondere bei jungen Mitarbeiter*innen, oft auf Ablehnung und werden nicht als wertvolles Arbeitstool, sondern als Belastung wahrgenommen. Als Unternehmen möchte man seinen Mitarbeiter*innen jedoch ein modernes System zur Verfügung stellen, das eine effiziente Arbeitsweise ermöglicht.
Ist der Modernisierungsbedarf in Unternehmen immer eindeutig und wie geht man damit um, wenn IT und Business unterschiedliche Anforderungen oder Erwartungshaltungen haben?
Roland: Nein, Modernisierungsbedarfe sind nicht immer so eindeutig, bzw. ist auf den ersten Blick nicht immer klar, wo Modernisierungsbedarfe ihre Ursache haben. Oftmals ist es so, dass die Schmerzen an einer bestimmten Stelle liegen, sich jedoch bei einer detaillierteren Analyse herausstellt, dass die eigentliche Ursache für einen Modernisierungsbedarf wo anders liegt. In Projekten mit Kunden ist es immer unser Ziel, den tatsächlichen Pain zu lokalisieren und zu verstehen. Dabei gilt es herauszufinden, was das Allerwichtigste für die einzelnen Bereiche ist. Dazu gehen wir mit Analyse- und Kreativmethoden, basierend auf unserem Modernisierungs-Vorgehensmodell, Schritt für Schritt vor, um die tatsächlichen Pains und zu erreichende Ziele herausfinden und darauf aufbauend die richtigen Vorgehensschritte zu definieren.
Um das ganze besser verständlich zu machen, hier ein konkretes Beispiel: wir hatten vor kurzem ein IT-getriebenes Modernisierungsprojekt, bei dem die IT-Abteilung eine rein technische Modernisierung als Big Bang auf einer modernen Plattform vornehmen wollte. Das Business bzw. der entsprechende Fachbereich hatte jedoch, als er davon informiert wurde, viele Ideen und Verbesserungswünsche und wollte diese auch mit umgesetzt haben. Um sowohl die Anforderungen des Fachbereichs als auch jene der IT zu berücksichtigen, haben wir gemeinsam eine alternative Vorgehensweise für die Modernisierung erarbeitet und umgesetzt. Dem Fachbereich wurden modernisierte Frontends mit den gewünschten Verbesserungen bereitgestellt. Die Backendprozesse wurden vorerst weiter auf dem Mainframe betrieben und parallel nach und nach modernisiert. So bekam der Fachbereich aus seiner Sicht innerhalb kurzer Zeit ein neues System, das ihren Anforderungen entspricht und die IT konnte im Hintergrund iterativ den Mainframe ablösen, ohne dass das Business davon was mitbekam oder gebremst wurde.
Wie kommt man zu einer IT-technischen Bewertung eines Kernsystems?
Michael: Wir werden immer wieder gefragt, wie wir zu einer seriösen IT-technischen Einschätzung eines Legacy Systems kommen. Für eine solche Einschätzung gehen wir zweistufig vor, einerseits durch Stellen gezielter Fragen, anderseits durch Analysen des Bestandsystems. Wir beginnen meist mit der Frage nach dem aktuellen Zustand des Systems und ob es bekannte Probleme gibt. Dabei bekommen wir oft überraschende Aussagen. Auch fragen wir, welche Systeme sonst noch im Einsatz sind. Meist ist es so, dass eine Software nicht aus einem System besteht, sondern aus mehreren Systemen im Verbund. Daraus ergeben sie dann Folgefragen insbesondere zu Schnittstellen und Datenflüssen. Welche Systeme werden vom Bestandsystem versorgt beziehungsweise woher bezieht es Daten? Eine weitere wichtige Frage ist die nach der Modernisierung selbst - möchte man alles modernisieren oder sind es vielleicht nur Teile? Wenn möglich, sprechen wir auch mit dem bisherigen System-Provider bzw. deren Entwicklern, so noch vorhanden, um auch von dieser Seite eine Einschätzung des Modernisierungsbedarfes zu bekommen.
Ergänzend zu den Antworten gehen wir in eine tiefere technische Analyse, in dem wir den Source Code mit Tools untersuchen, und so dessen Zustand in Bezug auf Komplexitäten, Abhängigkeiten von Programmteilen bzw. Modulen und damit auch die Architektur, sowie die allgemeine Code-Qualität bewerten. Diese Analyse ergibt ein ergänzendes neutrales Bild des IT-technischen Zustands der Bestandssoftware.
Welche Modernisierungsmodelle gibt es und welches ist das Passende?
Michael: Abhängig davon, ob der Haupttreiber für eine Modernisierung prozessualer oder technischer Natur ist, gibt es Ablöse- oder Veränderungsmodelle. Letztere kommen üblicherweise bei technisch notwendigen Modernisierungen zum Einsatz. Wir sprechen hier von Modellen wie Lift & Shift, also einem technischen Plattformwechsel – heute meist zugleich in die Cloud. Ein anderer Ansatz ist Transpile, also das toolunterstützte Transformieren eines Systems von einer Programmiersprache in eine andere, zum Beispiel von Cobol in eine moderne Sprache wie Java. Beide Ansätze verfolgen die Idee einer 1:1 Migration. Will man nur Teile eines Systems verändern, kommt der Ansatz des Refactorings ins Spiel, wo man genau diese Teile modernisiert, kapselt oder nur besser wartbar macht.
Daneben gibt es Ablösemodelle, die vor allem dann zum Einsatz kommen, wenn größere Prozessänderungen anstehen. Darunter fallen die teilweise oder ganze Ablöse eines Legacy-Kernsystems durch eine Standardsoftware, insbesondere, wenn man bei der Prozessanalyse feststellt, dass viele Prozessschritte heute durch Standardsoftware abgedeckt werden. Alternativ oder oft ergänzend kann auch der Einsatz einer Low Code Plattform für einzelne Prozesse oder Prozessschritte sinnvoll sein. Diese Plattformen haben ihre Stärken meist in Workflow-artigen Abläufen bzw. eignen sich auch für Automatisierungen zwischen Kernsystemen. Passt keine der beiden genannten Ablösestrategien, bleibt noch das Rewrite, also das Neuschreiben des Legacysystems in einer modernen Programmiersprache unter Rücksichtnahme passender moderner Enterprise- und Softwarearchitekturprinzipien.
In der Praxis zeigt sich fast in allen Projekten, dass es nicht „die eine Strategie“ gibt, sondern üblicherweise gut gewählte Mischformen sinnvoll sind, je nachdem, wie das Gesamtsystem am besten abzulösen ist.
Das heißt, es können beispielsweise Teile durch Standardsoftware abgedeckt, andere mit Low Code Plattformen umgesetzt, während wieder andere komplett neu entwickelt werden, weil z.B. Prozesse komplett neu implementiert werden sollen. Wenn ein Teil der Software sehr gut läuft und alle Anforderungen erfüllt, bringt man diesen mit Transpile oder Lift und Shift auf eine neue Technologie.
Dazu ein weiteres Beispiel aus der Praxis, einmal mehr eine Mainframe Ablöse. Konkret handelt es sich um ein sehr großes System, das auf einem Mainframe beheimatet war und in die Cloud gehoben werden sollte. Somit war klar, dass wir beinahe alle Ablöseszenarien in irgendeiner Form brauchen werden. Bei der Analyse hat sich dann herausgestellt, dass es auf dem Mainframe ein spezifisches Berechtigungssystem gab, das so nicht mehr in die moderne Welt übernommen werden konnte. Dies war ein Fall für Refactoring auf Basis des Strangler Patterns. Um möglichst viel Zeit und Kosten für den Kunden zu sparen, wollten wir nicht das gesamte System neu schreiben, unser Kunde wollte das System jedoch trotzdem in die Cloud bringen. Der ursprüngliche Plan war, dies über Lift & Shift zu bewerkstelligen, musste jedoch verworfen werden, da manche Teile, wie die komplexe Jobsteuerung, so nicht mehr funktionieren würden. Zudem hat sich herausgestellt, dass die jüngeren Entwickler mit Cobol nicht so firm waren, was für einen Großteil der Businesslogik somit Transpile von Cobol nach Java bedeutet hat. Parallel zu den technischen Überlegungen haben unsere Kollegen aus dem Business-Consulting mit dem Fachbereich gearbeitet und festgestellt, dass dieser Bedarf an neuen, workflowartigen Features hatte. Da der Kunde dafür in einem anderen Bereich bereits eine Standardsoftware im Einsatz hatte, war deren Einsatz auch in diesem Umfeld mit entsprechenden Integrationen naheliegend, damit für die Nutzer kein Systemwechsel notwendig wurde. Andere Features aus dem Legacy System wiederum haben ergeben, dass sie nicht mehr passend waren und neu geschrieben werden mussten. Im Endeffekt kamen in diesem Projekt somit nahezu alle Modernisierungskonzepte zum Einsatz, um den besten Nutzen und Mehrwert für den Kunden und die Benutzer des Systems zu erzielen.
Zum Schluss stellt sich noch die Frage, wann ist der richtige Zeitpunkt einer Modernisierung?
Roland: Um es kurz zu machen, den richtigen Zeitpunkt, eine Modernisierung zu starten, gibt es eigentlich nicht. Wie Sie, werte(r) Leser*in, bereits erfahren haben, gibt es in der Praxis viele Herausforderungen in Modernisierungsvorhaben. Deshalb sträubt man sich gerne zu beginnen, aber wie das so ist im Leben, je länger man wartet, etwas zu verbessern, desto schlimmer wird es eigentlich. Unser Credo ist es daher, Modernisierungen frühzeitig anzugehen. Dadurch verschafft man sich Zeit für die Analyse und man kann auch in jeder Hinsicht besser planen. Es braucht üblicherweise auch Vorläufe, um das nötige Budget zu bekommen. Und deshalb ist die eigentliche Antwort, der richtige Zeitpunkt wäre gestern gewesen 😉
Wenn Sie noch Fragen haben, die unbeantwortet geblieben sind, so stellen Sie uns diese gerne über das Formular unten. Wir freuen uns, diese zu beantworten!
Get in touch
Wir freuen uns auf Ihre Anfrage
* Bitte füllen Sie diese Felder aus
