Mnoge družbe že leta ali desetletja vzdržujejo stabilne Delphi aplikacije, ki zajemajo jedro njihovih procesov: obdelavo naročil, proizvodnjo, servis, logistiko, obračunavanje, upravljanje naprav, tokove dokumentov. V teh sistemih ni le kode, ampak zanesljivo prepletenost poslovnih pravil, podatkovnega modela, vodenja uporabnika in operativnih izkušenj. Prav to naredi modernizacijo zahtevno: dejanska vrednost redko leži v uporabniškem vmesniku, temveč v zraščeni poslovni logiki.
Če se modernizacija razume kot »gradnja na novo«, je izguba skoraj zagotovljena. Ne zato, ker bi bile nove tehnologije same po sebi slabe, temveč ker se implicitno znanje iz starega sistema – posebni primeri, zgodovinski podatki, izjeme v procesih, regulatorni detajli – pri migraciji pogosto ne rekonstruira v polnosti. Rezultat so drage regresijske napake, spremenjeni časi procesov, težave pri sprejemanju in projekt, ki traja dlje, kot je bilo predvideno.
Vendar je Delphi zelo dobro mogoče modernizirati, ne da bi izgubili poslovno logiko. Ključ je nadzorovan, postopni pristop: najprej ustvariti preglednost (arhitektura, podatki, tveganja), nato razvezati (UI, dostop do podatkov, domenska logika), nato modernizirati (gonilniki baze, Unicode/64-bit, API-ji, storitve, večplatformnost) – ob tem pa zagotoviti nemoteno delovanje. Ta prispevek opisuje praktične vzorce modernizacije, tipične pasti in postopek, ki deluje v B2B-okoljih z visoko procesno kritičnostjo.
Zakaj Delphi-modernizacija redko pomeni »tehnični projekt«
V praksi modernizacije ne propadejo zaradi manjkajočega compiler-flag-a, temveč zaradi napačnih predpostavk o vedenju sistema. Delphi aplikacije, ki so bile skozi leta razširjane, pogosto vsebujejo:
- Poslovna pravila v GUI- dogodkih (OnClick, OnExit, OnValidate), pogosto razpršena po mnogih formah
- SQL-poizvedbe »blizu površja« in leta optimizirane za natanko eno podatkovno bazo
- Zaobide za zgodovinske podatke, posebne primere, različice za kupce ali logiko več naročnikov
- Batch-procese, ki v praksi tečejo ob fiksnih urah in imajo odvisnosti
- Integracije v ERP, DMS, CRM ali naprave, ki so komaj dokumentirane
- Tihljeno znanje v obliki operativnih rut: »Če pride napaka X, najprej preveri Y«
Kdor tukaj začne z Big-Bang-Rewrite, mora vse to znanje znova ustvariti – vključno z napakami, ki jih stara rešitev že dolgo ne povzroča. Boljši pristop je, da se poslovna logika obravnava kot sredstvo: najprej izolirati, nato zavarovati, nato modernizirati.
Modernizacija brez izgube logike: ciljno stanje in vodilna načela
Vzdržno ciljno stanje za B2B-sisteme ni »vse na novo«, temveč arhitektura, ki omogoča spremembe. Tipične lastnosti:
- Ločene odgovornosti (UI, domena/poslovna logika, dostop do podatkov, integracije)
- Testnost in merljivost (regresijski testi, beleženje, monitoring, reproducibilni buildi)
- Postopna zamenljivost (modernizirati UI brez takojšnje prenove podatkovnega modela; migrirati DB brez nove pisave UI)
- API-odzivnost (REST-Server ali plast storitev za priklapljanje portalov, mobilnih rešitev in integracij)
- Operabilnost (Windows- in Linux-storitev, jasni deploymenti, rollback-strategija)
Pri Delphi je to še posebej dosegljivo, ker lahko obstoječe unit-e in domenske razrede ponovno uporabite, medtem ko zunanjost modernizirate: dostop do podatkov od BDE na BDE-zamenjavo z nativno povezavo, novi REST-endpointi, novi UI-moduli, nova deployanja.
Inventura stanja: Kaj je res treba ohraniti?
Preden se »dotaknete« kode, se obrestuje strukturirana inventura. Cilj ni popolna dokumentacija, temveč zanesljiva podlaga za odločanje.
1) Zemljevid poslovne logike namesto maratonskega branja kode
Praktično se je izkazal zemljevid poslovne logike z naslednjimi perspektivami:
- Use-Cases: Kateri osnovni postopki so poslovno kritični? (npr. vnos naročila, račun, storniranje, vračilo, servisiranje strojev, vzdrževalna pogodba)
- Pravila: Katere validacije, izračuni, stanja ali avtomati obstajajo?
- Variante: Več naročnikov, konfiguracije kupcev, specifična pravila po državah
- Vmesniki: Import/Export, ERP/DMS/CRM, naprave/protokoli
- Batch/Jobi: nočni zagon, poročila, usklajevanja podatkov
Iz tega zemljevida nastanejo prioritetni paketi modernizacije: kaj mora ostati stabilno, kaj se lahko spremeni, kaj lahko počaka.
2) Vidno narediti tehnični dolg
Tipični tehnični dolg v starejših Delphi sistemih:
- Borland BDE/Paradox-odvisnosti
- ANSI-nizi/ manjkajoča Unicode-migracija
- Samo 32-bit, zastarele komponente tretjih oseb
- Monolitična logika form, globalne spremenljivke, enote z neželenimi stranskimi učinki
- Nejasne transakcijske meje in »SQL povsod«
Umetnost ni te točke dogmatično »odpraviti«, temveč jih razporediti v zaporedje, ki minimizira tveganje in maksimira poslovno vrednost.
Arhitekturna razvezava: vzvod proti izgubi logike
Najpogostejši razlog za izgubo logike je zmešnjava UI, dostopa do podatkov in poslovnih pravil. Zato modernizacija začne z razvezavo – ne z »novim UI-frameworkom«.
Layer-3 arhitektura kot pragmatično ciljno stanje
Za mnoge Delphi obstoječe aplikacije dobro deluje Layer-3 arhitektura:
- Presentation Layer: VCL/FMX-Forms, ViewModels/Presenter, validacija omejena na UI (format, obvezna polja)
- Business Layer: domenski modeli, storitve, pravila, stanja, izračuni
- Data/Integration Layer: repository-i, SQL/ORM-komponente, adapterji vmesnikov, REST-klienti, messaging
Dodana vrednost: poslovna logika postane testna in ponovno uporabna. Kasneje lahko portali, REST-server ali Linux-storitve uporabijo iste domenske storitve. Tako modernizirate »zunanjost« brez ponovnega izumljanja jedrne logike.
Strangulation Pattern: postopno »objemanje« starega sistema
Preizkušen migracijski vzorec je Strangulation Pattern: nove funkcionalnosti nastajajo že v novi strukturi (npr. domenska storitev + repository), medtem ko se obstoječe forme postopoma prenavljajo. Stara okolja ostanejo delujoča, a jih zamenjujete kos za kosom.
Pomembno je aktivno obvladovanje odvisnosti: ne »forma kliče SQL«, temveč »forma kliče servis«, in servis odloča. Ta majhna obrat je pogosto največji dobiček.
Modernizacija dostopa do podatkov: BDE-zamenjava in FireDAC skrbno načrtovati
Osrednji korak modernizacije je zamenjava BDE. Podjetja pogosto podcenjujejo, da gre pri tem ne le za gonilnike, temveč za SQL-semantiko, transakcije, zaklepe, tipe podatkov in obnašanje ob napakah. Sodobni Delphi stack-i običajno temeljijo na BDE-Ablosung mit nativer Anbindung z nativnimi gonilniki (npr. za MariaDB/MySQL, PostgreSQL, SQL Server).
Kaj je treba pri prehodu res odločiti
- Ciljna baza: Ostaja obstoječa DB ali je smiselna menjava (npr. iz Paradox/Firebird v MariaDB ali PostgreSQL)?
- Transakcijski model: Kje se transakcije začnejo/končajo? Kateri use-case-i morajo biti atomski?
- Sočasnost/zaklepanje: optimistično proti pesimističnemu, obravnava deadlock-ov, strategije ponovnih poskusov
- SQL-dialekt: funkcije za datume, obnašanje nizov, NULL-obravnava, občutljivost na velike/male črke
- Performance: indeksi, načrti poizvedb, paginacija, množični vnosi
Poslovna logika je tesno vezana na vedenje podatkov. Kdor migracijo opravi »mimo poti«, tvega subtilne razlike v praksi: zaokroževanja, razvrščanje, meje datumov, konflikti zaklepanja. Zato mora podatkovna raven zgodaj vstopiti v načrt modernizacije, vključno z migracijskim potekom in strategijo testnih podatkov.
Pragmatični koraki za FireDAC-migracijo
Namesto popolnega prepisovanja aplikacije v enem zamahu se je uveljavilo naslednje zaporedje:
- Uvesti plast dostopa do podatkov (Repository/DAO) kot fasado
- Preklapljati posamezne use-case-e na FireDAC (npr. najprej »branje«, kasneje »pisanje“)
- Poenotiti upravljanje povezav, obravnavo napak, beleženje
- Postopno izklapljati BDE komponente tam, kjer je fasada stabilna
Tako aplikacija ostaja vedno dostavljiva in se izognete dolgotrajnemu obdobju »vmesnega stanja«.
Unicode, 64-bit in odvisnosti: pasti modernizacije v podrobnostih
Mnoge modernizacije ne propadejo na ravni koncepta, temveč na podcenjenih detajlih. Trije takšni so v Delphi projektih še posebej pogosti.
Unicode-migracija: ne le nizi, ampak pretoki podatkov
Pri zelo starih različicah Delphi sistemi izvirajo iz ANSI-svete. Unicode-migracija zadeva:
- Vrste nizov in konverzije (WideString/AnsiString/UnicodeString)
- Obravnavo datotek in poti (Windows-API, omrežne poti)
- Import/Export (CSV, fiksne dolžine polj, EDI, legacy-vmesniki)
- Razvrščanje/kollacija v bazi
Ključno je identificirati kritične tokove podatkov (npr. besedila na računih, nazive artiklov, mednarodne naslove) in zanje postaviti regresijske teste. Unicode ni zgolj »prenova«, temveč celovit proces zagotavljanja kakovosti.
Prehod na 64-bit: pomnilnik ni edini problem
Prehod na 64-bit se pogosto reducira na »velikost kazalcev«. V praksi gre bolj za:
- Zastarele komponente tretjih oseb brez 64-bit podpore
- COM/ActiveX odvisnosti
- DLL-i in gonilniki (črtne kode, naprave, kriptografija, podpisovanje)
- Installer/deployment in registry-poti (WOW64)
Razumna strategija je najprej inventar vseh zunanjih odvisnosti in določitev alternativ. Potem je 64-bit korak načrtljiv – ne presenečenje tik pred izidom.
Windows 11 ARM64: zgodnja preverba namesto kasnega plačila
S Windows 11 ARM64 se pojavi nova razred ciljnih sistemov. Tudi če ne vsako podjetje takoj rabi nativne ARM64 build-e, je pametno zgodaj preveriti:
- Ali obstajajo nativne odvisnosti (DLL-i, gonilniki), ki na ARM64 ne tečejo?
- Ali aplikacija temelji na emulaciji in ali je to sprejemljivo?
- Kako je z installerjem, posodabljanjem/in-situ popravili?
V modernizacijskih projektih je to tipična »pozna« tema, ki potem postane draga. Bolje jo je zgodaj vključiti v platformno roadmapo in tehnično razčistiti.
REST-Server in storitve: narediti poslovno logiko uporabno za portale in integracije
Mnogi podjetja ne modernizirajo Delphi zaradi zastarelega namiznega videza, temveč zaradi novih zahtev: portal za stranke, dostopi partnerjev, mobilni procesi, integracija z ERP/DMS/CRM, poročevalske pipe. To zahteva jasne vmesnike. REST-Server je pogosto najučinkovitejši most.
API najprej? Le če so pravice in domena vključene
API je korist, le če uveljavlja enako poslovno logiko kot klient. Sicer nastaneta dve ločeni zbirki pravil: ena na namizju, ena v backendu. Posledice so neskladja in varnostne vrzeli.
Zato naj REST-Serverska plast čim bolj neposredno naslanja na domenske storitve. Tipične gradnike predstavljajo:
- Avtentikacija/avtorizacija (vloge, večnaročniški kontekst, pravice)
- DTO-ji/serializacija s pojasnjenimi pravilniki verzioniranja
- Transakcijski in koncept napak (HTTP-statusi, Problem-Details, beleženje)
- Idempotentnost in sočasnost (za retries, obdelavo v čakalni vrsti)
Tako se REST-Server postavi kot stabilna integracijska točka – ne kot »drugi klient«.
Modernizacija Linux-storitev in Windows-storitve
Batch-procesi in integracije v mnogih podjetjih tečejo kot Windows storitve, Task Scheduler jobi ali celo »skriti« namizni primerki. Pri modernizaciji se obrestuje konsolidacija:
- Ločiti UI in ozadno logiko
- Konfigurabilni urniki in jasni operativni parametri
- Čisto beleženje (strukturirani logi, korelacija po job/request)
- Možnost poganjanja storitev kot Linux (npr. za containerizirane deploymente)
Prednost ni le »moderna«, temveč operativna: reproducibilno delovanje, manj ročnih intervencij, lažje iskanje napak.
Modernizacija UI, ne da bi se dotaknili jedra: VCL, FMX in hibridni pristopi
Mnogi načrti modernizacije začnejo pri UI. To je lahko smiselno – dokler je jasno, kaj je cilj. Če je poslovna logika razvezana, je mogoče UI varneje zamenjati.
Postopna modernizacija VCL-aplikacij
VCL je v mnogih B2B-scenarijih še vedno robustna izbira, zlasti za okolja z močnim Windows poudarkom in visoko produktivnostjo na namizju. Modernizacija tu lahko pomeni:
- Reduce UI-logike (Presenter/ViewModel), premestiti poslovna pravila v storitve
- Poenotiti nabor komponent, konsolidirati lastne kontrole
- Izboljšati odzivnost (Async, ozadni jobi, progres, preklic)
- Povečati dostopnost, konsistentno validacijo, jasnejša sporočila o napakah
To prinese otipljive koristi, ne da bi bilo treba popolnoma prepisati vmesnik.
Delphi večplatformno: kdaj je FMX smiselna izbira
Če obstajajo resni večplatformni zahtevki (Windows, macOS, morebiti Linux v kontekstu storitev), je FMX lahko opcija. Ključno je pričakovanje: večplatformnost pomeni dodatno testno in integracijsko delo (fonti, tisk, dialogi OS, datotečni sistemi, pakiranje/deployment). Stroške je mogoče dobro ovrednotiti, če je poslovna logika že v čisti plasti.
Pragmatična pot pogosto vodi v hibrid: VCL ostane za Windows klienta, medtem ko nova frontenda (portal, mobilna aplikacija) uporabljata REST-Server. Tako dosežete večplatformnost prek mej sistema, ne z enim samim UI-stakom.
Testiranje in regresija: kako »prikirniti« poslovno logiko
»Izguba poslovne logike« v praksi pomeni, da sistem v robnih primerih vrne drugačne rezultate. To redko nastane takoj opazno, a je drago. Zato testnost ni luksuz, temveč orodje modernizacije.
Zlati use-case-i in referenčni podatki
Uveljavilo se je nabiranje »zlatih« use-case-ov: realni, kritični postopki z določeno podatkovno situacijo in pričakovanimi rezultati (npr. veriga dokumentov od ponudbe do dobropisa, ali servisni nalog z rezervnimi deli in časovnimi vnosih). Ti služijo kot regresijski testi ali vsaj kot ponovljivi testni skripti.
Pomembno: ne le poti uspeha, temveč tudi tipične poti napak (konflikti zaklepanja, manjkajoče pravice, nepopolni master podatki, podvojena import datoteka).
Avtomatizacija tam, kjer prinese največ
Ne vsak obstoječi projekt takoj potrebuje 80 % pokritost z enotnimi testi. Visok ROI je pogosto pri:
- Domenskih storitvah (izračuni, pravila, prehodi stanj)
- Dostopu do podatkov s čistimi pogodbenimi vmesniki (mapping, SQL, transakcije)
- API-testih (avtentikacija, pravice, verzioniranje)
Cilj je stabilnost ob spremembah, ne akademske metrike.
Operativni model v praksi: načrt modernizacije v fazah
Iz B2B-perspektive mora modernizacija ostati dostavljiva. Tipičen načrt, ki se orientira po tveganjih:
Faza 1: Analiza, ciljna arhitektura, hitri presežki (2–6 tednov)
- Zemljevid sistema (moduli, baze, vmesniki, jobi, odvisnosti)
- Matrika tveganj (BDE, tretje strani, 32/64-bit, Unicode, deployment)
- Določitev ciljne arhitekture (Layer-3, plast storitev, API-strategija)
- Quick Wins: stabilizirati build-proces, izboljšati logging, urediti verzioniranje
Faza 2: Razvezava poslovne logike (teče, inkrementalno)
- Identificirati domenske storitve in jih izvleči iz form
- Uvesti repository-fasade
- Prvi regresijski testi za kritične use-case-e
Faza 3: Modernizacija dostopa do podatkov/DB-plasti
- Uvesti FireDAC, vzpostaviti koncept povezav in transakcij
- Modularna BDE-zamenjava (ali migracija baze z vzporednim obratovanjem)
- Testirati performance in obnašanje zaklepov pod obremenitvijo
Faza 4: Dodajanje REST-Serverja in integracij
- API z avtentikacijo, pravicami, verzioniranjem
- Priklop portalov/integracij brez podvajanja logike
- Konsolidacija storitev za batch in ozadje
Faza 5: Platformne in UI-odločitve (64-bit, ARM64, večplatformno)
- 64-bit build, zamenjava odvisnosti
- Preverjanje/planiranje ARM64-kompatibilnosti
- UI-modernizacija: VCL osvežitev ali FMX/hibrid, odločeno na podlagi poslovnega učinka
Zaporedje je izbrano z namenom, da zgodaj pridobite preglednost, nato stabilizirate jedro in šele potem uveljavljate vidne spremembe. Tako se zmanjša tveganje in obratovanje ostane načrtljivo.
Tipični antipatterni: kaj modernizacije nepotrebno podraži
Nekateri vzorci se v revizijah in reševalnih projektih pojavljajo znova in znova:
- »Gradimo novo in prevzamemo le funkcionalnosti«: skoraj vedno vodi v izgubo logike, ker manjkajo posebni primeri.
- API kot paralelni svet: poslovna pravila ostanejo v klientu, backend pa jih znova izumi.
- Menjava baze brez semantičnih testov: isti podatki, a drugačno vedenje (NULL, razvrščanje, logika datumov).
- Prepozno upravljanje odvisnosti: 64-bit/ARM64 spodleti zaradi majhne DLL tik pred Go-Live.
- »Refaktoriranje najprej« brez ciljnega stanja: veliko sprememb, malo merljivega učinka, visoka regresija.
Protiprimer je vedno isti: najprej razjasniti ciljno arhitekturo in tveganja, nato inkrementalno preurejati, ob tem testirati in narediti poslovno logiko vidno.
Zaključek: modernizirati pomeni ohraniti – in ciljno razširiti
Modernizacija Delphi brez izgube poslovne logike ni protislovje, temveč disciplina. Podjetja se ne rabijo odločati med »vse obdržati« in »vse zamenjati«. S čisto ločitvijo arhitekture (npr. Layer-3), nadzorovano BDE-zamenjavo proti FireDAC, API-strategijo prek REST-Serverja ter jasnim načrtom za Unicode, 64-bit in nove platforme kot je Windows 11 ARM64 je mogoče zraščeni sistem postopno preoblikovati v trajnostno strukturo.
Kritično je obravnavati poslovno logiko kot osrednji asset: izolirati, narediti testno, nato modernizirati. Tako nastane arhitektura, ki podpira portale, storitve in večplatformne zahteve, brez ogrožanja tekočega obratovanja.
Če načrtujete Delphi Modernizacijo in želite vpeljati jasno usklajevanje poslovne logike, dostopa do podatkov in obratovanja, se z nami pogovorite o realistično izvedljivem migracijskem načrtu: https://net-base-software-gmbh.de/kontakt/