Modernizovati Delphi bez gubitka poslovne logike

Delphi-Anwendungen laufen in vielen Unternehmen seit Jahren stabil – und bilden genau die Domänenlogik ab, die Umsatz, Servicequalität und Usaglašenost sichert. Bei einer Modernisierung geht es daher selten um „neue Oberfläche“, sondern um eine kontrollierte Weiterentwicklung, bei der Regeln, Sonderfälle und historisches Prozesswissen erhalten bleiben.

In diesem Beitrag zeigen wir ein praxiserprobtes Vorgehen, um Delphi schrittweise zu modernisieren: von der Bestandsaufnahme über die Entkopplung von UI/Datenzugriff bis zur technischen Modernisierung (Unicode/64‑Bit, BDE-Ablösung, API/Services) – inklusive Absicherung durch Tests, Monitoring und Parallelbetrieb. Ziel ist eine modernisierbare Architektur, ohne Big-Bang-Rewrite und ohne Logikverlust.

Modernisierungen scheitern in der Praxis selten am Compiler oder an einem Framework, sondern an falschen Annahmen über das Systemverhalten. Über Jahre gewachsene Delphi-Anwendungen enthalten typischerweise Domänenregeln in GUI-Events, SQL in Formularlogik, Varianten pro Kunde/Mandant, historisch bedingte Sonderfälle sowie Integrationen, die nur „im Betrieb“ dokumentiert sind.

Ein Big-Bang-Rewrite zwingt dazu, dieses Wissen neu zu rekonstruieren – inklusive der Fehler, die das Altsystem längst nicht mehr macht. Der bessere Ansatz ist, die Domänenlogik als Vermögenswert zu behandeln: isolieren, absichern, dann Schritt für Schritt modernisieren.

Ein tragfähiges Zielbild für prozesskritische B2B-Systeme ist nicht „alles neu“, sondern eine Architektur, die Veränderungen ermöglicht – ohne den laufenden Betrieb zu gefährden:

• klare Trennung von UI, Domänenlogik, Datenzugriff und Integrationen
• Test- und Messbarkeit (Regression, Logging, Monitoring, reproduzierbare Builds)
• schrittweise Austauschbarkeit (UI modernisieren ohne sofortige DB-Migration – oder umgekehrt)
• API-Fähigkeit (z. B. REST), um Portale, Mobile oder System-Integrationen anzubinden
• betriebsfähige Deployments mit Rollback-Option

Delphi eignet sich dafür gut, weil bestehende Units und Domänenklassen weiterverwendet werden können, während außen herum modernisiert wird.

Bevor Code angepasst wird, braucht es eine belastbare Entscheidungsgrundlage – keine Voll-Dokumentation. Bewährt haben sich diese drei Ergebnisse:

• Mapa domenske logike: kritične slučajevi upotrebe, pravila/izračuni, varijante (Mandanten/Länder/Kunden), sučelja, poslovi/Batch-Läufe.
• Risikoprofil: besonders fehlerkritische Bereiche, Datenqualität, regulatorische Anforderungen, Engpässe im Betrieb (Performance, Stabilität, Wartbarkeit).
• Modernisierungs-Backlog: priorisierte Pakete nach Business-Wert und Risiko (was muss stabil bleiben, was darf sich ändern, was später).

Damit lässt sich Modernisierung planbar machen: mit klaren Inkrementen statt einem einzigen „Alles-oder-nichts“-Projekt.

Damit Fachlogik nicht „versehentlich“ verändert wird, braucht es eine Absicherung, die unabhängig vom UI-Refactoring funktioniert. Typische Bausteine:

• Characterization/Golden-Master-Tests: vorhandenes Verhalten wird über repräsentative Eingaben/Ausgaben eingefroren (Reports, Berechnungen, Prozessschritte).
• Regressionstests auf Use-Case-Ebene: die geschäftskritischen Abläufe werden automatisiert oder halbautomatisiert nachgestellt.
• Telemetry: Logging, Metriken und Fehlerbilder werden vor/nach einer Änderung vergleichbar gemacht.
• Parallelbetrieb & kontrollierte Umstellung: neue Module laufen neben dem Bestand (Feature Toggles, Pilotgruppen), mit klarer Rollback-Strategie.

Tek tek kad su ta sigurnosna mreža uspostavljena, stvarna tehnička modernizacija ima smisla – jer se rizik i naknadni rad drastično smanjuju.

Najčešći razlog gubitka logike je miješanje UI, pristupa podacima i poslovnih pravila. Modernizacija stoga počinje razdvajanjem – ne zamjenom UI-Frameworks.

Pragmatičan cilj je 3‑slojna struktura:

• Presentation: VCL/FMX, Presenter/ViewModel, samo UI-bliska validacija (format, obavezna polja)
• Business: domenski modeli, servisi, pravila, logika stanja, proračuni
• Data/Integration: Repositories, pristup bazi podataka, adapteri za ERP/DMS/CRM, REST-Clients, Messaging

Praktično pravilo: poslovna pravila se premještaju iz OnClick/OnExit u domenske servise. SQL se premješta iz Forms u Repositories. Tako postaje logika testabilna i kasnije se može ponovno koristiti preko UI, servisa i poslova.

Pri Strangulation Pattern se novo ciljano razvija „pored“ postojećeg: nove funkcije se već implementiraju u entkoppelten strukturi, dok naslijeđeni sistem nastavlja raditi. Korak po korak novi sloj preuzima više odgovornosti, sve dok stari dijelovi ne budu uklonjeni.

Primjer (tipično B2B):

• Izvlačite logiku narudžbi u domenski servis.
• Postojeći VCL-UI u početku koristi isti servis (bez prekida procesa).
• Paralelno se pojavljuje REST-Endpunkt za portal za klijente ili integraciju.
• Nakon stabilizacije pojedinačni stari Forms se zamjenjuju – bez potrebe da se osnovna logika rekonstruira.

Tako smanjujete rizik projekta, održavate operativnu sposobnost i brzo ostvarujete mjerljivu korist (npr. API, performanse, mogućnost održavanja).

Ovisno o početnom stanju, ovi građevni blokovi su često relevantni – presudno je prioritiziranje prema riziku i poslovnoj vrijednosti:

• BDE/Legacy-DB-Zugriff ablösen: moderni Treiber/Provider, čiste granice transakcija, reproducibilna Deployments.
• Unicode: rukovanje stringovima, baza podataka/Interfaces, komponente trećih strana.
• 64‑Bit: zavisnosti, memorija/performanse, externe Libraries.
• Sloj API-ja i servisa: REST, Windows-/Linux-Services, integracije.
• Build & Release: CI/CD, upravljanje artefaktima, potpisani Installer, Rollback.

Važno: Ovi koraci se idealno provode nakon razdvajanja i osiguranja – tada se promjene mogu sigurno verificirati.

Potpun Rewrite je u nekim slučajevima smislen – često je to najskuplji put do „moderne tehnike“. Sljedeća pitanja pomažu pri procjeni:

• Je li poslovna logika u potpunosti razumljena i testabilna – ili je puno znanja implicitno u operativnom radu?
• Postoje li strogi Deadlines (npr. kraj platforme, Compliance) koji isključuju paralelan rad?
• Kolika je raznolikost varijanti (logika kupaca/mandanata)?
• Koliko je kritična dostupnost i kolika je tolerancija na promjene procesa?
• Koji dijelovi su stvarno „krivci“ (UI, pristup podacima, integracije, Deployment) – a koji su stabilni?

U mnogim B2B-scenarijima postupni pristup brže dovodi do mjerljivih rezultata, jer kontrolira rizike i štiti poslovnu logiku.

Delphi-Modernisierungs-Audit (za procesno kritične aplikacije): Analiziramo arhitekturu, zavisnosti, područja rizika i isporučujemo prioritetnu roadmapu kako modernizirati bez gubitka poslovne logike.

• Ulaz: kodna baza (read-only), Build-Setup, 2–3 ključna slučaja upotrebe, sistemsko okruženje (DB, integracije).
• Rezultat: karta poslovne logike/modula, analiza rizika i zavisnosti, preporučena ciljna arhitektura, plan implementacije u inkrementima uključujući osiguranje (testovi/paralelni rad).
• Opcionalno: Proof of Concept za odvajanje + prvi Golden-Master-Test.

Tako dobijete pouzdanu osnovu za odluku prije nego što se budžet i vrijeme ulože u rizično prepisivanje.

Može li se Delphi modernizirati bez ponovnog pisanja aplikacije?
Da. U mnogim slučajevima se prvo odvaja poslovna logika i pristup podacima, a zatim se tehnički modernizuje. To smanjuje rizik i održava stabilan rad.

Kako spriječiti da se poslovna logika „tiho“ mijenja?
Putem Golden-Master i regresionih testova, telemetrije te kontrolisanog paralelnog rada s jasnom rollback-strategijom.

Koji koraci često donose najbrže koristi?
Transparentnost (procjena), odvajanje UI/SQL, BDE-zamjena i API-/Service-sloj za integracije — svaki osiguran testovima.

Koliko traje modernizacija?
To zavisi od kritičnih slučajeva upotrebe, raznolikosti varijanti i zavisnosti. Audit obično u kratkom vremenu pruža pouzdanu roadmapu i prioritetizirane inkremente.