Mnoge tvrtke godinama ili desetljećima održavaju stabilne Delphi aplikacije koje pokrivaju srž njihovih procesa: obrada narudžbi, proizvodnja, servis, logistika, obračun, upravljanje uređajima, radni tokovi dokumenata. U tim sustavima nije samo riječ o kodu, nego o otpornom prepletu poslovnih pravila, podatkovnog modela, vođenja korisnika i operativnog iskustva. Upravo to čini modernizaciju zahtjevnom: stvarna vrijednost rijetko leži u sučelju, već u izgrađenoj poslovnoj logici.
Ako se modernizacija shvati kao „novo graditi“, gubitak je programiran. Ne zato što su nove tehnologije po sebi loše, nego zato što se implicitno znanje iz starog sustava – posebni slučajevi, povijesni podaci, iznimke u procesima, regulatorni detalji – pri migraciji često ne može u potpunosti rekonstruirati. Posljedica su skupi regresijski pogrešci, promijenjena vremena procesa, problemi s prihvaćanjem i projekt koji traje dulje nego što je planirano.
Delphi se međutim vrlo dobro može modernizirati bez gubitka poslovne logike. Ključ je kontrolirani, postupni pristup: prvo stvoriti transparentnost (arhitektura, podaci, rizici), zatim razdvojiti (UI, pristup podacima, domenska logika), potom modernizirati (pogoni baze podataka, Unicode/64-bit, API-ji, servisi, multiplatforma) – i pri tome osigurati kontinuitet rada. Ovaj članak opisuje praktične obrasce modernizacije, tipične zamke i pristup koji funkcionira u B2B okruženjima s visokom procesnom kritičnošću.
Warum Delphi-Modernisierung selten ein „Technikprojekt“ ist
U praksi modernizacije ne propadaju zbog nedostajućeg compiler-flag-a, nego zbog pogrešnih pretpostavki o ponašanju sustava. Delphi aplikacije koje su se tijekom godina nadograđivale često sadrže:
- Poslovna pravila u GUI-eventima (OnClick, OnExit, OnValidate), često razasuta po mnogim formama
- SQL-upite „blizu površine“ koji su godinama optimizirani za točno jednu bazu podataka
- Zaobilaznice za povijesne podatke, posebne slučajeve, varijante po kupcima ili logiku mandanta
- Batch-procese koji u praksi rade u fiksnim terminima i imaju ovisnosti
- Integracije u ERP, DMS, CRM ili strojeve koje su rijetko dokumentirane
- Tiho znanje u obliku operativnih rutina: „Ako greška X, prvo provjeri Y“
Tko započne s Big-Bang-Rewrite pristupom, mora sve to znanje ponovno proizvesti – uključujući i pogreške koje stari sustav već dugo ne čini. Bolji pristup je tretirati poslovnu logiku kao imovinu: prvo izolirati, potom osigurati, pa tek onda modernizirati.
Modernisierung ohne Logikverlust: Zielbild und Leitprinzipien
Održiv cilj za B2B sustave nije „sve novo“, nego arhitektura koja omogućava promjene. Tipične značajke:
- Odvojene odgovornosti (UI, domena/poslovna logika, pristup podacima, integracije)
- Testabilnost i mjerljivost (regresijski testovi, logging, monitoring, reproducibilni buildovi)
- Postupna zamjenjivost (modernizirati UI bez trenutačnog preuređenja podatkovnog modela; migrirati bazu podataka bez ponovnog pisanja UI-ja)
- API-mogućnost (REST-Server ili servisni sloj za priključenje portala, mobilnih rješenja i integracija)
- Operabilnost (Windows- i Linux-Services, jasni deploymenti, rollback strategija)
U Delphi je to posebno ostvarivo, jer možete nastaviti koristiti postojeće Unit-e i domenske klase dok modernizirate okolinu: pristup podacima od BDE prema BDE-Ablösung mit nativer Anbindung, novi REST-endpoints, novi UI-moduli, novi deploymenti.
Bestandsaufnahme: Was muss wirklich erhalten bleiben?
Prije nego što se „dirne“ u kod, vrijedi strukturirana inventura. Cilj nije potpuna dokumentacija, nego pouzdana podloga za odluke.
1) Fachlogik-Landkarte statt Code-Lesemarathon
Praktično se pokazala korisnom karta poslovne logike s sljedećim perspektivama:
- Use-Cases: Koji su ključni poslovni tokovi? (npr. unos narudžbe, račun, storniranje, povrat, servis stroja, ugovor o održavanju)
- Pravila: Koje validacije, kalkulacije, stanja i automati postoje?
- Varijante: Mandanti, konfiguracije po kupcu, pravila specifična za zemlje
- Schnittstellen: Import/Export, ERP/DMS/CRM, uređaji/protokoli
- Batch/Jobs: noćni poslovi, izvještaji, usklađivanja podataka
Iz te karte proizlaze prioritetni paketi modernizacije: što mora ostati stabilno, što smije promijeniti, a što može pričekati.
2) Technische Schulden sichtbar machen
Tipične tehničke dugove u starijim Delphi sustavima:
- Borland BDE/Paradox-ovisnosti
- ANSI-stringovi/izostanak Unicode-migracije
- Samo 32-bit, zastarjele komponente trećih strana
- Monolitična form-logika, globalne varijable, Unit-i s brojnim nuspojavama
- Neprecizne transakcijske granice i „SQL posvuda“
Umijeće je ne rješavati te točke dogmatski, nego ih poredati na način koji minimizira rizik i maksimizira poslovnu vrijednost.
Architektur-Entkopplung: Der Hebel gegen Logikverlust
Najčešći razlog gubitka logike je pomiješanost UI-ja, pristupa podacima i poslovnih pravila. Modernizacija stoga počinje entkoppelungom – a ne izborom „novog UI-frameworka“.
Layer-3 Architektur als pragmatischer Zielzustand
Za mnoge Delphi postojeće aplikacije vrlo dobro funkcionira Layer-3 Architektur:
- Presentation Layer: VCL/FMX-Forms, ViewModels/Presenter, validacija ograničena na UI (format, obavezna polja)
- Business Layer: domenski modeli, servisi, pravila, stanja, kalkulacije
- Data/Integration Layer: repository-i, SQL/ORM-dijelovi, adapteri sučelja, REST-klijenti, messaging
Dobitak: poslovna logika postaje testabilna i ponovno upotrebljiva. Kasnije isti domenski servisi mogu koristiti kundenportal, REST-Server ili Linux-servis. Time modernizirate „vanjsku kožu“, a da ne izmišljate iznova jezgru logike.
Strangulation Pattern: Altes System schrittweise „umarmen“
Dokazani obrazac migracije je Strangulation Pattern: nove funkcionalnosti nastaju već u novoj strukturi (npr. domenski servis + repository), dok se postojeće forme postupno preuređuju. Stari sustav ostaje operativan, ali se dio po dio zamjenjuje novim.
Važno je pritom aktivno preusmjeravati ovisnosti: ne „forma poziva SQL“, nego „forma poziva servis“, a servis odlučuje. Ova mala inverzija često donosi najveći benefit.
Datenzugriff modernisieren: BDE-Ablösung und FireDAC sauber planen
Jedan od centralnih koraka modernizacije je BDE-Ablösung. Tvrtke često podcjenjuju da se ne radi samo o driverima, nego o SQL-semantici, transakcijama, zaključavanjima, tipovima podataka i ponašanju pri pogreškama. Moderni Delphi stackovi tipično se oslanjaju na BDE-Ablosung mit nativer Anbindung s nativnim driverima (npr. za MariaDB/MySQL, PostgreSQL, SQL Server).
Was bei der Umstellung wirklich entschieden wird
- Odabrana baza podataka: Ostaje li postojeća DB? Je li smisleno preuređenje baze (npr. iz Paradox/Firebird u MariaDB ili PostgreSQL)?
- Transakcijski model: Gdje započinju/koje transakcije se završavaju? Koji use-case-ovi moraju biti atomski?
- Rukovanje konkurencijom/Locking: optimističko vs. pesimističko, rukovanje deadlockovima, strategije ponovnog pokušaja
- SQL-dijalekt: funkcije za datume, ponašanje stringova, rukovanje NULL-ovima, osjetljivost na velika/mala slova
- Performanse: indeksi, planovi upita, paginacija, batch-inserti
Poslovna logika je usko vezana uz ponašanje podataka. Tko migraciju radi „usput“, riskira suptilne razlike u praksi: zaokruživanja, sortiranja, granice datuma, konflikti zaključavanja. Zato podatkovna razina mora rano biti dio plana modernizacije, uključujući migracijski put i strategiju testnih podataka.
Pragmatische Schritte zur FireDAC-Migration
Umjesto potpunog preuređivanja aplikacije odjednom, pokazao se sljedeći redoslijed:
- Uvođenje sloja za pristup podacima (Repository/DAO) kao fasada
- Prebacivanje pojedinih use-case-ova na FireDAC (npr. prvo „čitanje“, pisanje kasnije)
- Ujednačavanje upravljanja konekcijama, rukovanja pogreškama, logiranja
- Postupno isključivanje BDE komponenti tamo gdje je fasada stabilna
Tako aplikacija ostaje stalno isporučiva i izbjegavate dugo razdoblje u kojem je „sve polu gotovo“.
Unicode, 64-Bit und Abhängigkeiten: Die Modernisierungsfallen im Detail
Mnoge modernizacije ne posrću zbog koncepta, nego zbog podcijenjenih detalja. Tri su posebno česta u Delphi projektima.
Unicode-Migration: Nicht nur Strings, sondern Datenflüsse
U vrlo starim verzijama Delphi sustavi potječu iz ANSI svijeta. Migracija na Unicode obuhvaća:
- Tipove stringova i konverzije (WideString/AnsiString/UnicodeString)
- Rukovanje datotekama i putanjama (Windows-API, mrežne putanje)
- Import/Export (CSV, fiksne duljine polja, EDI, legacy sučelja)
- Sortiranje/kolacija u bazi podataka
Presudno je identificirati kritične podatkovne tokove (npr. tekstovi računa, nazivi proizvoda, međunarodne adrese) i za njih postaviti regresijske testove. Unicode nije samo „preinaka“, nego sveobuhvatan proces kvalitete.
64-Bit Umstieg: Speicher ist nicht das einzige Thema
Prelazak na 64-bit često se svodi na „veličinu pointera“. U praksi su češći problemi:
- Zastarjele komponente trećih strana bez 64-bit podrške
- COM/ActiveX ovisnosti
- DLL-ovi i driveri (barcode, uređaji, kriptografija, potpisi)
- Installer/deployment i registry-putanje (WOW64)
Razumna strategija je prvo inventarizirati sve vanjske ovisnosti i definirati alternative. Tada je korak na 64-bit planiran i ne predstavlja iznenađenje neposredno prije izdanja.
Windows 11 ARM64: Früh prüfen statt spät bezahlen
S pojavom Windows 11 ARM64 dolazi nova klasa ciljanih platformi. Čak i ako svaka tvrtka ne treba odmah native ARM64 buildove, pametno je provjeriti rano:
- Postoje li native ovisnosti (DLL-ovi, driveri) koje na ARM64 neće raditi?
- Je li aplikacija ovisna o emulaciji i je li to prihvatljivo?
- Kakav je instalacijski paket, kako izgleda update/repair?
U projektima modernizacije to je tipična „kasna“ tema koja postane skupa. Bolje je rano je uključiti u roadmap platforme i tehnički razjasniti.
REST-Server und Services: Fachlogik für Portale und Integration nutzbar machen
Mnoge tvrtke ne moderniziraju Delphi zato što desktop-app izgleda zastarjelo, nego zato što se pojavljuju nove potrebe: Kundenportal, pristupi partnerima, mobilni procesi, integracija s ERP/DMS/CRM, reporting-pipelineovi. Za to su potrebni jasni sučelji. REST-Server često je najpraktičniji most.
API zuerst? Nur, wenn Rechte und Domänenlogik mitkommen
API je koristan samo ako provodi istu poslovnu logiku kao i klijent. Inače nastaju dva skupa pravila: jedan na desktopu, drugi u backendu. Posljedice su nekonzistentnosti i sigurnosne rupe.
Zato bi REST-server sloj trebao što izravnije stati na domenske servise. Tipične komponente:
- Autentikacija/autorizacija (role, mandanti, prava)
- DTO-i/serijalizacija s jasnim pravilima verzioniranja
- Transakcijski i koncept grešaka (HTTP-statusi, Problem-Details, logging)
- Idempotencija i konkurentnost (za retry-je, obradu u queueu)
Tako REST-server postaje stabilna točka integracije – a ne „drugi klijent“.
Linux-Services und Windows Services modernisieren
Batch-procesi i integracije u mnogim tvrtkama rade kao Windows servisi, Task Scheduler jobovi ili čak „skriveni“ desktop instance. Pri modernizaciji vrijedi konsolidirati:
- Razdvojiti UI i pozadinsku logiku
- Konfigurabilni rasporedi rada i jasni operativni parametri
- Čisto logiranje (strukturirani logovi, korelacija po jobu/zahtjevu)
- Mogućnost pokretanja servisa pod Linux (npr. za containerizirane deployment-e)
Prednost nije samo „modernost“, nego operativna: reproducibilan rad, manje ručnih intervencija, bolja dijagnostika pogrešaka.
UI modernisieren, ohne den Kern anzufassen: VCL, FMX und hybride Ansätze
Mnogi planovi modernizacije započinju s UI-jem. To može imati smisla – pod uvjetom da je jasno što time dobivate. Ako je poslovna logika entkoppelt, UI se može znatno sigurnije obnoviti.
VCL-Anwendungen schrittweise modernisieren
VCL je u mnogim B2B scenarijima i dalje robusna opcija, osobito za Windows-intenzivne okoline s visokim desktop produktivitetom. Modernizacija može značiti:
- Smanjiti UI-logiku (Presenter/ViewModel), premjestiti poslovna pravila u servise
- Očistiti komponentnu luku, konsolidirati vlastite kontrole
- Poboljšati responzivnost (async, pozadinski poslovi, progres, cancel)
- Pristupačnost, konzistentna validacija, jasnije poruke o pogreškama
To donosi opipljivu korist bez potpunog prepisivanja sučelja.
Delphi Multiplattform: Wann FMX Sinn ergibt
Ako postoje stvarni zahtjevi za multiplatformom (Windows, macOS, eventualno Linux u kontekstu servisa), FMX može biti opcija. Ključno je očekivanje: multiplatforma znači dodatni rad na testiranju i integraciji (fontovi, ispis, OS-dijalozi, datotečni sustav, pakiranje/deployment). Troškovi su dobro predvidivi ako je poslovna logika već u čistom sloju.
Čest pragmatičan put je hibrid: VCL ostaje za Windows-klijent, dok nova frontenda (portal, mobilna aplikacija) koriste REST-server. Na taj način postižete multiplatformu preko granica sustava, a ne jednim UI-slojem.
Testing und Regression: Wie man Fachlogik „festnagelt“
„Izgubiti poslovnu logiku“ u praksi znači: sustav daje drugačije rezultate u rubnim slučajevima. To rijetko odmah postane vidljivo, ali je skupo. Zato testabilnost nije luksuz, nego alat modernizacije.
Goldene Use-Cases und Referenzdaten
Pokazao se korisnim skup „zlatnih“ use-case-ova: stvarni, kritični tokovi s definiranim podacima i očekivanim rezultatima (npr. lanac dokumenata od ponude do kreditnota, ili nalog za održavanje s rezervnim dijelovima i evidentiranim vremenima). Oni se uspostavljaju kao regresijski testovi ili barem kao ponovljivi testni skripti.
Važno: ne samo putovi uspjeha, nego i tipični putevi pogrešaka (konflikti zaključavanja, nedostatna prava, nepotpuni master-podaci, duplikati import datoteka).
Automatisierung dort, wo sie den größten Hebel hat
Nije svaki naslijeđeni projekt odmah treba 80% pokrivenosti unit-testovima. Visoki ROI često nastaje kod:
- Domenskih servisa (kalkulacije, pravila, prijelazi stanja)
- Pristupa podacima s jasnim kontraktima (mapping, SQL, transakcije)
- API-testova (auth, prava, verzioniranje)
Cilj je stabilnost pri promjenama, a ne akademske metrike.
Vorgehensmodell in der Praxis: Ein Modernisierungsfahrplan in Etappen
Iz B2B perspektive modernizacija mora ostati isporučiva. Tipični plan, koji se orijentira na rizike:
Etappe 1: Analyse, Zielarchitektur, Quick Wins (2–6 Wochen)
- Karta sustava (moduli, baze podataka, sučelja, jobovi, ovisnosti)
- Matrica rizika (BDE, treće strane, 32/64-bit, Unicode, deployment)
- Definicija ciljane arhitekture (Layer-3, servisni sloj, API-strategija)
- Quick Wins: stabilizirati build-proces, poboljšati logging, urediti verzioniranje
Etappe 2: Entkopplung der Fachlogik (laufend, inkrementell)
- Identificirati domenske servise i izvući ih iz forma
- Uvesti repository-fasade
- Prvi regresijski testovi za kritične use-case-ove
Etappe 3: Datenzugriff/DB-Schicht modernisieren
- Uvesti FireDAC, etablirati koncept veza i transakcija
- Modularna BDE-Ablösung (ili migracija baze s paralelnim radom)
- Testirati performanse i ponašanje zaključavanja pod opterećenjem
Etappe 4: REST-Server und Integrationen nachrüsten
- API s autentikacijom, pravima, verzioniranjem
- Povezati portale/integracije bez duplicirane logike
- Konsolidirati servise za batch i pozadinske procese
Etappe 5: Plattform und UI-Entscheidungen (64-Bit, ARM64, Multiplattform)
- 64-bit build, zamijeniti ovisnosti
- Provjeriti/planirati ARM64 kompatibilnost
- UI-modernizacija: VCL refresh ili FMX/hibrid, temeljeno na poslovnoj koristi
Redoslijed je namjerno izabran tako da rano dobijete transparentnost, potom stabilizirate jezgru i tek nakon toga provodite „vidljive“ promjene u većem opsegu. Time pada rizik i rad ostaje planiran.
Typische Anti-Patterns: Was Modernisierungen unnötig teuer macht
U revizijama i spašavanjima projekata često se pojavljuju isti obrasci:
- „Wir bauen neu und übernehmen nur Features“: gotovo uvijek vodi gubitku logike, jer posebni slučajevi nedostaju.
- API als Parallelwelt: poslovna pravila ostaju u klijentu i ponovno se izmišljaju u backendu.
- Datenbankwechsel ohne Semantiktests: isti podaci, ali drugačije ponašanje (NULL, sortiranje, logika datuma).
- Zu spätes Dependency-Management: 64-bit/ARM64 propada zbog male DLL-ove neposredno prije Go-Live-a.
- „Refactoring zuerst“ ohne Zielbild: mnogo promjena, malo mjerljive koristi, visoka regresija.
Protudjelovanje je uvijek isto: prvo razjasniti ciljnu arhitekturu i rizike, potom inkrementalno preuređivati, testirati poslovnu logiku i učiniti je vidljivom.
Fazit: Modernisieren heißt bewahren – und gezielt erweitern
Modernizirati Delphi bez gubitka poslovne logike nije proturječje, nego disciplina. Tvrtke ne moraju birati između „sve zadržati“ i „sve zamijeniti“. Sa čistim razdvajanjem arhitekture (npr. Layer-3), kontroliranom BDE-Ablösung prema FireDAC, API-strategijom preko REST-servera te jasnim planom za Unicode, 64-bit i nove platforme poput Windows 11 ARM64 moguće je postojeći sustav postupno dovesti u održivu arhitekturu.
Ključno je tretirati poslovnu logiku kao centralnu imovinu: izolirati je, učiniti testabilnom, pa tek onda modernizirati. Tako nastaje arhitektura koja podržava portale, servise i multiplatformne zahtjeve bez ugrožavanja operativnog rada.
Ako planirate Delphi Modernisierung i želite pri tom jasno uskladiti poslovnu logiku, pristup podacima i operacije, razgovarajte s nama o realističnom migracijskom putu: https://net-base-software-gmbh.de/kontakt/