Software-Modernisierung
Wann lohnt es sich, eine geschäftskritische Software zu modernisieren, und wann lohnt es sich, sie neu zu entwickeln?
Unser Projekt beim Deutschen Roten Kreuz hat uns eine klare Antwort gegeben
Bei uns bei Gloster stellt sich seit Jahren bei jedem komplexen, individuell entwickelten Unternehmenssystem dieselbe Frage: Wann lohnt es sich, ein bestehendes System komplett zu ersetzen, und wann ist es sinnvoller, es Schritt für Schritt weiterzuentwickeln?
In vielen Unternehmen herrscht die Auffassung, dass ein System, das seit 10 bis 20 Jahren im Einsatz ist, früher oder später unweigerlich veraltet sein wird. Dass es von da an nur noch einen Weg gibt: die komplette Neuprogrammierung. Meiner Erfahrung nach trifft dies jedoch selten zu.
Eine geschäftskritische Anwendung besteht nämlich nicht nur aus Quellcode. Sie umfasst über Jahre, oft sogar Jahrzehnte hinweg angesammeltes Geschäftswissen, spezielle Prozesse und unzählige Integrationen. Ein Austausch birgt erhebliche technische, geschäftliche und organisatorische Risiken, und diese Risiken lassen sich nur sehr selten in den laufenden, täglichen Betrieb eines Systems integrieren.
Unser Projekt beim Deutschen Roten Kreuz (DRK) hat genau das gezeigt: Eine schrittweise Modernisierung kann ein wesentlich nachhaltigerer und sicherer Weg sein als ein Neuanfang. Die Herausforderung ist in jeder Branche dieselbe. Ob im Gesundheitswesen, in der Automobilindustrie, in der Fertigung, im Finanzwesen oder in der öffentlichen Verwaltung – nach einer gewissen Zeit sieht sich fast jede Organisation mit demselben Muster konfrontiert:
Dies gilt insbesondere für Systeme, die für den täglichen Betrieb (oder sogar für Menschenleben) von Bedeutung sind. Dort ist selbst ein Ausfall von wenigen Stunden nicht zulässig. Genau in einer solchen Situation befand sich auch das Laborinformationssystem des Deutschen Roten Kreuzes.
Bei Modernisierungsprojekten stehen in der Regel drei Möglichkeiten zur Auswahl.
Auch beim Deutschen Roten Kreuz haben wir uns für diesen Weg entschieden. Nicht, weil dies die bequemere Lösung war, sondern weil es die verantwortungsvollere war.
Auf den ersten Blick könnte es so aussehen, als ginge es um die Entwicklung eines Laborinformationssystems. Tatsächlich geht es jedoch um viel mehr als das.
Die Plattform verbindet Laborgeräte verschiedener Hersteller, verarbeitet sensible Gesundheitsdaten und unterstützt Prozesse, bei denen Zuverlässigkeit und Verfügbarkeit keine bloße Erwartung, sondern eine Grundvoraussetzung sind. Ein Ausfall des Systems war schlichtweg nicht akzeptabel.
Ich erinnere mich, dass bei einer der ersten Besprechungen einer unserer Kollegen vom DRK die Frage stellte, die wir seitdem im Team immer wieder aufgreifen: „Was passiert, wenn dieses System auch nur für eine Stunde ausfällt?“ Die Antwort war nicht technischer, sondern menschlicher Natur: In diesem Moment wurde klar, dass hier nicht die Wahl der Technologie die entscheidende Frage ist.
Das war nicht die Frage. Die Frage lautete vielmehr: Wie lässt sich ein geschäftskritisches System so weiterentwickeln, dass der Betrieb dabei durchgehend stabil bleibt?
Wir sind stolz darauf, mit Organisationen wie dem Deutschen Roten Kreuz zusammenarbeiten zu dürfen, bei denen die Modernisierung des Laborbetriebs nicht nur die Einführung einer neuen Software bedeutete, sondern auch die langfristige Sicherung dieser kritischen Gesundheitsinfrastruktur.
Die Ergebnisse des Projekts zeigen deutlich, welchen greifbaren geschäftlichen Mehrwert eine geeignete Architektur und Modernisierungsstrategie schaffen können:
Für uns ist es jedoch noch wichtiger, dass das DRK heute über eine Plattform verfügt, die kontinuierlich um neue Labore, neue Geräte und neue Technologien erweitert werden kann, ohne den täglichen Betrieb zu beeinträchtigen.
Dieses Projekt zeigt deutlich, dass Gesundheitsdienstleister sich nicht zwischen Innovation und Betriebskontinuität entscheiden müssen. Mit der richtigen Strategie lassen sich beide Ziele gleichzeitig verwirklichen.
Im Rahmen des Projekts haben wir auf Docker, Kubernetes, Microservice-Architektur und Cloud-native Lösungen gesetzt. Nicht, weil diese Technologien gerade im Trend liegen, sondern weil sie Lösungen für konkrete Probleme bieten.
Eine modulare Architektur ermöglicht es beispielsweise, dass
Technologie ist niemals ein Selbstzweck. Wir prüfen stets, welches geschäftliche Problem sie löst. Nicht wir dienen der Technologie, sondern die Technologie dient uns.
Eine unserer wichtigsten Erkenntnisse ist, dass es keine Architektur gibt, die für alle Situationen gleichermaßen geeignet ist.
Nicht jede Anwendung benötigt Microservices. Nicht jedes System muss sofort in die Cloud verlagert werden. Und nicht jedes Altsystem muss ersetzt werden.
Die eigentliche Herausforderung besteht darin, den Modernisierungsweg zu finden, der am besten zu den Geschäftszielen, dem technologischen Umfeld und den regulatorischen Anforderungen des jeweiligen Unternehmens passt. Im Fall von DRK standen Verfügbarkeit, Stabilität unter hoher Auslastung und langfristige Erweiterbarkeit im Vordergrund. Bei anderen Organisationen können diese Prioritäten ganz anders gewichtet sein.
Viele Projekte konzentrieren sich ausschließlich auf die Lösung aktueller Probleme. Wir denken weiter: Bereits in der Planungsphase berücksichtigen wir die zu erwartenden Anforderungen der kommenden Jahre, neue Geschäftsprozesse, neue Integrationen, neue regulatorische Anforderungen, den Einsatz von KI sowie neue Cloud-Dienste.
Eine gut durchdachte Architektur ist in der Lage, diese später zu integrieren, ohne dass erneut eine vollständige Systemumstellung erforderlich wäre. Eine gute Architektur bietet keine Lösung für die Probleme von heute, sondern für die von morgen.
Das DRK-Projekt ist ein gutes Beispiel, aber keineswegs ein Einzelfall. Mit denselben Herausforderungen sind wir auch in anderen Branchen konfrontiert:
Für uns ist eine erfolgreiche Modernisierung in erster Linie keine technologische Frage. Es ist vielmehr eine Frage der Einstellung. Vier Grundprinzipien haben sich als besonders wichtig erwiesen.
Die digitale Transformation beginnt nicht unbedingt mit der Einführung eines neuen Systems. Sie beginnt damit, dass wir erkennen: In unseren bestehenden Systemen steckt bereits ein enormer Wert.
Das Projekt des Deutschen Roten Kreuzes zeigt deutlich, dass selbst die kritischsten Anwendungen sicher und schrittweise modernisiert werden können, ohne dass der tägliche Betrieb dabei beeinträchtigt wird. Bei uns bei Gloster betrachten wir dies als eine unserer wichtigsten Kompetenzen: Wir unterstützen unsere Kunden dabei, ihre bestehenden Systeme langfristig nachhaltig, flexibel weiterentwickelbar und zu einer Plattform zu machen, die für die Technologien der Zukunft gerüstet ist.
Wenn auch Sie ein geschäftskritisches System betreiben, dessen Austausch Sie für zu riskant halten, sollten Sie sich die Frage stellen: Muss wirklich ein neues System aufgebaut werden, oder reicht es aus, das bestehende System sinnvoll weiterzuentwickeln? Unserer Erfahrung nach gibt es in den meisten Fällen einen dritten Weg: die schrittweise, geschäftlich sichere Modernisierung.
Denn eine erfolgreiche Modernisierung beginnt nicht mit einem neuen System, sondern mit der richtigen Strategie.
Wenn Sie gerne gemeinsam mit uns die Modernisierung Ihres eigenen Systems durchdenken möchten, lassen Sie uns über Ihr Projekt sprechen.
At Gloster, the same question comes up every few years with every complex, bespoke enterprise system: when is it worth replacing an existing system entirely, and when is it wiser to develop it step by step? At many companies the gut feeling is that a system running for 10 to 20 years will eventually become hopelessly obsolete. That from here, only one road remains: the complete rewrite. In my experience, that is rarely true.
A business-critical application is more than source code. Over years, often decades, it accumulates business knowledge, specialised processes and countless integrations. Replacing all of that is a serious technical, commercial and organisational risk, and that risk very rarely fits within the life of a live system running day to day.
Our project at the German Red Cross (DRK) showed exactly that: gradual modernisation can be a far more sustainable and safer route than starting from zero.
Whether it is healthcare, automotive, manufacturing, finance or public administration, after a while almost every organisation runs into the same pattern:
This is especially true of systems tied to daily operations, or even to human lives. There, even a few hours of downtime is unacceptable. The German Red Cross's laboratory information system was in exactly this position.
In modernisation projects there are usually three roads to choose from.
At the German Red Cross we chose this road. Not because it was the more comfortable option, but because it was the responsible one.
At first glance it might look like the development of a laboratory information system. In reality it was about far more.
The platform connects laboratory equipment from different manufacturers, handles sensitive health data, and supports processes where reliability and availability are not an expectation but a baseline requirement. An outage of the system was simply not acceptable.
I remember, in one of the early meetings, a colleague at the DRK asked the question we have often recalled as a team since: "What happens if this system goes down for even a single hour?" The answer was not a technical one, it was a human one. That was the moment that made it clear the main question here was not the choice of technology.
The question was not which technology to use. The question was: how do you develop a business-critical system while keeping operations stable throughout?
We are proud to work with organisations like the German Red Cross, where modernising laboratory operations meant more than introducing new software. It meant making critical healthcare infrastructure fit for the long term.
The results of the project show clearly the tangible business value that the right architecture and modernisation strategy can create:
For us, a more important result still is that the DRK now has a platform that can be extended continuously with new laboratories, new devices and new technologies, without putting daily operations at risk.
This project shows that healthcare providers do not have to choose between innovation and operational continuity. With the right strategy, both can be achieved at once.
During the project we built on Docker, Kubernetes, microservice architecture and cloud-native approaches. Not because they happen to be fashionable right now, but because they answer specific problems.
A modular architecture makes it possible, for example, to develop individual components independently of each other, push new features into the live environment without downtime, spin up new laboratories in minutes, connect new laboratory equipment quickly, and have the system adapt automatically to increased load.
Technology in itself is never the goal. We always look at which business problem it solves. We do not serve the technology; the technology serves us.
One of our most important lessons is that there is no architecture that is universally right for every situation.
Not every application needs microservices. Not every system has to move to the cloud straight away. And not every legacy system needs replacing.
The real task is to find the modernisation route that fits best with a given company's business goals, technology environment and regulatory requirements. For the DRK, what mattered most was availability, stability under heavier load, and long-term extensibility. At other organisations these priorities may line up quite differently.
Many projects focus solely on solving the problems of the moment. We think further than that: as early as the design phase we take into account the likely needs of the coming years, new business processes, new integrations, new regulatory expectations, the use of AI, new cloud services.
A well-built architecture can absorb these later without needing another complete overhaul.
Good architecture does not answer today's problem. It answers tomorrow's.
The DRK project is a good example, but far from a unique one. We meet the same challenges in other sectors too:
The technologies differ. The challenges are surprisingly similar.
Digital transformation does not necessarily start with introducing a new system. It starts with recognising that our existing systems already hold enormous value.
The German Red Cross project shows that even the most critical applications can be modernised safely and gradually while daily operations stay undisturbed. At Gloster we consider this one of our most important competencies: we help our clients turn their existing systems into platforms that are sustainable for the long term, flexible to develop further, and ready for the technologies of the future.
If you too run a business-critical system that you consider too risky to replace, it is worth asking the question: do you really need to build a new system, or is it enough to develop the existing one intelligently? In our experience, in most cases there is a third road: gradual, commercially safe modernisation.
Because successful modernisation does not start with a new system. It starts with the right strategy.
If you would like to think through your own system's modernisation route with us, let's talk about your project. Talk to us about your project
Bei Gloster stellt sich uns seit Jahren dieselbe Frage – bei jedem komplexen, individuell entwickelten Unternehmenssystem: Wann lohnt es sich, ein bestehendes System vollständig zu ersetzen, und wann ist es sinnvoller, es Schritt für Schritt weiterzuentwickeln?
In vielen Unternehmen herrscht das Gefühl, ein System, das seit 10 bis 20 Jahren läuft, veralte früher oder später hoffnungslos. Und dass von hier nur noch ein Weg führt: die vollständige Neuentwicklung. Nach eigener Erfahrung trifft das nur selten zu.
Eine geschäftskritische Anwendung ist nicht nur Quellcode. Sie trägt über Jahre, oft über Jahrzehnte gewachsenes Fachwissen, spezielle Prozesse und unzählige Integrationen in sich. Das alles zu ersetzen, ist ein erhebliches technisches, geschäftliches und organisatorisches Risiko – und dieses Risiko ist im Lebenszyklus eines produktiv laufenden Systems nur sehr selten vertretbar.
Unser Projekt beim Deutschen Roten Kreuz (DRK) hat genau das gezeigt: Die schrittweise Modernisierung kann ein deutlich nachhaltigerer und sichererer Weg sein als der Start bei null.
Ob im Gesundheitswesen, in der Automobilindustrie, in der Fertigung, im Finanzwesen oder in der öffentlichen Verwaltung – nach einiger Zeit sieht sich fast jede Organisation mit demselben Muster konfrontiert:
Das gilt besonders für Systeme, die mit dem täglichen Betrieb (oder sogar mit Menschenleben) verbunden sind. Dort ist selbst ein Ausfall von wenigen Stunden nicht zulässig. Genau in dieser Situation befand sich auch das Laborinformationssystem des Deutschen Roten Kreuzes.
Bei Modernisierungsprojekten kann man in der Regel zwischen drei Wegen wählen.
Auch beim Deutschen Roten Kreuz haben wir diesen Weg gewählt. Nicht, weil das die bequemere Lösung war, sondern weil es die verantwortungsvolle war.
Auf den ersten Blick mag es so wirken, als ginge es um die Entwicklung eines Laborinformationssystems. In Wirklichkeit geht es um weit mehr.
Die Plattform verbindet Laborgeräte unterschiedlicher Hersteller, verarbeitet sensible Gesundheitsdaten und unterstützt Prozesse, in denen Zuverlässigkeit und Verfügbarkeit keine Erwartungen, sondern Grundvoraussetzungen sind. Ein Ausfall des Systems war schlicht nicht akzeptabel.
»Was passiert, wenn dieses System auch nur für eine einzige Stunde ausfällt?« – Diese Frage eines DRK-Kollegen in einer frühen Abstimmung machte deutlich, dass hier nicht die Technologiewahl die entscheidende Frage ist.
Die Frage war nicht, welche Technologie wir wählen sollten. Sondern: Wie lässt sich ein geschäftskritisches System so weiterentwickeln, dass der Betrieb dabei durchgehend stabil bleibt?
Die Ergebnisse des Projekts zeigen gut, welchen greifbaren geschäftlichen Nutzen die richtige Architektur und Modernisierungsstrategie schaffen können:
Noch wichtiger als diese Zahlen ist für uns das Ergebnis, dass das DRK heute über eine Plattform verfügt, die sich fortlaufend um neue Labore, neue Geräte und neue Technologien erweitern lässt, ohne den Tagesbetrieb zu gefährden.
Im Projekt haben wir auf Docker, Kubernetes, eine Microservice-Architektur und Cloud-native-Lösungen gesetzt. Nicht, weil sie gerade in Mode sind, sondern weil sie auf konkrete Probleme eine Antwort geben.
Eine modulare Architektur ermöglicht es zum Beispiel, dass sich die einzelnen Komponenten unabhängig voneinander entwickeln lassen, neue Funktionen ohne Ausfall in die Produktivumgebung gelangen, neue Labore sich innerhalb von Minuten in Betrieb nehmen lassen, neue Laborgeräte schnell angebunden werden und sich das System automatisch an die gestiegene Last anpasst.
Nicht wir dienen der Technologie, sondern die Technologie dient uns.
Es gibt keine Architektur, die für jede Situation gleichermaßen gut ist.
Nicht jede Anwendung braucht Microservices. Nicht jedes System muss sofort in die Cloud umziehen. Und nicht jedes Legacy-System muss ersetzt werden.
Die eigentliche Aufgabe besteht darin, den Modernisierungsweg zu finden, der am besten zu den geschäftlichen Zielen, zur technologischen Umgebung und zu den regulatorischen Anforderungen des jeweiligen Unternehmens passt.
Das DRK-Projekt ist ein gutes Beispiel, aber bei Weitem kein Einzelfall. Denselben Herausforderungen begegnen wir auch in anderen Branchen:
Die Technologien unterscheiden sich. Die Herausforderungen sind überraschend ähnlich.
Wenn auch Sie ein geschäftskritisches System betreiben, dessen Austausch Ihnen zu riskant erscheint, lohnt sich die Frage: Muss wirklich ein neues System gebaut werden, oder genügt es, das bestehende klug weiterzuentwickeln? Nach unserer Erfahrung gibt es in den meisten Fällen einen dritten Weg: die schrittweise Modernisierung bei beherrschbarem Geschäftsrisiko.
Eine erfolgreiche Modernisierung beginnt nicht mit einem neuen System. Sondern mit der richtigen Strategie.
Wenn Sie den Modernisierungsweg Ihres eigenen Systems gemeinsam mit uns durchdenken möchten, sprechen wir über Ihr Projekt. Jetzt Gespräch anfragen
.avif)
.webp)
