Szoftvermodernization
Mikor érdemes modernizálni egy üzletileg kritikus szoftvert, és mikor éri meg újraépíteni?
Amit a Német Vöröskereszt digitalizációs projektje megtanított nekünk
Nálunk, a Glosternél évek óta ugyanaz a kérdés kerül elő minden komplex, egyedi fejlesztésű vállalati rendszernél: mikor érdemes egy meglévő rendszert teljesen lecserélni, és mikor célszerűbb lépésről lépésre továbbfejleszteni?
Sok vállalatnál az a megérzés, hogy egy 10-20 éve futó rendszer előbb-utóbb menthetetlenül elavul. Hogy innen már csak egy út vezet: a teljes újraírás. A saját tapasztalatom szerint ez ritkán igaz.
Egy üzletileg kritikusalkalmazás ugyanis nem csak forráskód. Évek, sokszor évtizedek alattfelhalmozott üzleti tudást, speciális folyamatokat és számtalan integrációthordoz magában. Ezt lecserélni komoly technikai, üzleti és szervezeti kockázat,és ez a kockázat nagyon ritkán fér bele egy éles, napi működésű rendszeréletébe.
A Német Vöröskeresztnél (DRK) futó projektünk pontosan ezt mutatta meg: a fokozatos modernizáció sokkal fenntarthatóbb és biztonságosabb út lehet, mint a nulláról indulás. A kihívás minden iparágban ugyanaz. Legyen szó egészségügyről, autóiparról, gyártásról, pénzügyről vagy közigazgatásról, egy idő után szinte minden szervezet ugyanazzal a mintázattal szembesül:
Ez különösen igaz azokra a rendszerekre, amelyek napi működéshez (vagy akár emberéletekhez) kapcsolódnak. Ott egy néhány órás leállás sem megengedhető. Pontosan ilyen helyzetben volt a Német Vöröskereszt laborinformatikai rendszere is.
A modernizációs projektek során általában három út közül lehet választani.
A Német Vöröskeresztnél is ezt az utat választottuk. Nem azért, mert ez volt a kényelmesebb megoldás, hanem mert ez volt a felelős.
Első ránézésre úgy tűnhet, hogy egy laborinformatikai rendszer fejlesztéséről van szó. Valójában ennél sokkal többről.
A platform különböző gyártók laborberendezéseit köti össze, érzékeny egészségügyi adatokat kezel, és olyan folyamatokat támogat, ahol a megbízhatóság és a rendelkezésre állás nem elvárás, hanem alapkövetelmény. A rendszer leállása egyszerűen nem volt elfogadható.
Emlékszem, az egyik korai egyeztetésen az egyik DRK-s kollégánk feltette a kérdést, amit azóta is sokszor felidézünk a csapatban: „Mi történik, ha ez a rendszer akár egyetlen órára leáll?" A válasz nem technikai volt, hanem emberi: ez a pillanat tette világossá, hogy itt nem a technológiaválasztás a fő kérdés.
A kérdés nem ez volt. Hanem az: hogyan lehet egy üzletileg kritikus rendszert úgy továbbfejleszteni, hogy közben a működés végig stabil maradjon?
Büszkék vagyunk arra, hogy olyan szervezetekkel dolgozhatunk együtt, mint a Német Vöröskereszt, ahol a laboratóriumi működés modernizálása nem csupán egy új szoftver bevezetését jelentette, hanem a kritikus egészségügyi infrastruktúra hosszú távú jövőbiztossá tételét is.
A projekt eredményei jól mutatják, hogy a megfelelő architektúra és modernizációs stratégia milyen kézzelfogható üzleti értéket képes teremteni:
Számunkra ezeknél is fontosabb eredmény, hogy a DRK ma egy olyan platformmal rendelkezik, amely új laborokkal, új eszközökkel és új technológiákkal folyamatosan bővíthető, anélkül, hogy a napi működést veszélyeztetné.
Ez a projekt jól mutatja, hogy az egészségügyi szolgáltatóknak nem kell választaniuk az innováció és a működési folytonosság között. A kettő a megfelelő stratégiával egyszerre is megvalósítható.
A projekt során Dockerre, Kubernetesre, microservice architektúrára és cloud-native megoldásokra építettünk. Nem azért, mert ezek épp most divatosak, hanem mert konkrét problémákra adnak választ.
Egy moduláris architektúra lehetővé teszi például, hogy
A technológia önmagában soha nem cél. Mindig azt vizsgáljuk, milyen üzleti problémát old meg. Nem mi szolgáljuk a technológiát, hanem a technológia szolgál minket.
Az egyik legfontosabb tapasztalatunk, hogy nincs minden helyzetre univerzálisan jó architektúra.
Nem minden alkalmazásnak van szüksége microservice-ekre. Nem minden rendszernek kell azonnal a felhőbe költöznie. És nem minden legacy rendszert kell lecserélni.
A valódi feladat, hogy megtaláljuk azt a modernizációs utat, amelyik a leginkább illeszkedik az adott vállalat üzleti céljaihoz, technológiai környezetéhez és szabályozási követelményeihez. A DRK esetében a rendelkezésre állás, a nagyobb terhelés alatti stabilitás és a hosszú távú bővíthetőség volt a legfontosabb. Más szervezeteknél ezek a prioritások egészen máshogy rendeződhetnek.
Sok projekt kizárólag az aktuális problémák megoldására koncentrál. Mi ennél tovább gondolkodunk: már a tervezés fázisában figyelembe vesszük a következő évek várható igényeit, új üzleti folyamatokat, új integrációkat, új szabályozási elvárásokat, az AI alkalmazását, új cloud szolgáltatásokat.
Egy jól felépített architektúra ezeket később képes befogadni anélkül, hogy ismét teljes rendszerátalakításra lenne szükség. A jó architektúra nem a mai problémára válaszol. A holnapira.
A DRK projekt jó példa, de korántsem egyedi eset. Ugyanezekkel a kihívásokkal találkozunk más iparágakban is:
Számunkra egy sikeres modernizáció elsősorban nem technológiai kérdés. Sokkal inkább szemlélet. Négy alapelv bizonyult különösen fontosnak.
A digitális transzformáció nem feltétlenül egy új rendszer bevezetésével kezdődik. Azzal kezdődik, hogy felismerjük: a meglévő rendszereinkben már óriási érték rejlik.
A Német Vöröskereszt projektje jól mutatja, hogy még a legkritikusabb alkalmazások is biztonságosan és fokozatosan modernizálhatók úgy, hogy közben a napi működés zavartalan marad. Nálunk, a Glosternél ezt tekintjük az egyik legfontosabb kompetenciánknak: segítünk ügyfeleinknek abban, hogy meglévő rendszereiket hosszú távon fenntarthatóvá, rugalmasan továbbfejleszthetővé és a jövő technológiáira felkészített platformmá alakítsák.
Ha te is egy olyan üzletileg kritikus rendszert működtetsz, amelyet túl kockázatosnak tartasz lecserélni, érdemes feltenned a kérdést: valóban új rendszert kell építeni, vagy elég a meglévőt okosan továbbfejleszteni? Tapasztalatunk szerint a legtöbb esetben létezik egy harmadik út: a fokozatos, üzletileg biztonságos modernizáció.
Mert a sikeres modernizáció nem egy új rendszerrel kezdődik. Hanem a megfelelő stratégiával.
Ha szívesen végiggondolnád a saját rendszered modernizációs útját velünk, beszéljünk a projektedről.
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)
