Modernisere Delphi utan å miste faglogikk

Delphi-applikasjonar har i mange verksemder gått stabilt i fleire år – og dekkjer nett den faglogikken som sikrar omsetnad, servicekvalitet og samsvar. Ved ei modernisering handlar det derfor sjeldan om ei «ny overflate», men om ei kontrollert vidareutvikling der reglar, unntakstilfelle og historisk prosesskunnskap blir verna.

I dette innlegget viser vi ein prakseprøvd framgangsmåte for å modernisere Delphi stegvis: frå kartlegging til fråkopling av UI/datatilgang og vidare til teknisk modernisering (Unicode/64‑Bit, BDE-avløysing, API/tenester) – inklusive sikring gjennom testar, overvaking og parallelldrift. Målet er ei moderniserbar arkitektur, utan Big-Bang-Rewrite og utan tap av logikk.

Moderniseringar mislukkar i praksis sjeldan på grunn av kompilatoren eller eit rammeverk, men på grunn av feilaktige føresetnader om systemåtferd. Over tid oppdanna Delphi-applikasjonar inneheld typisk fagreglar i GUI-hendingar, SQL i skjema-logikk, variantar per kunde/tenant, historisk betinga unntakstilfelle samt integrasjonar som berre er dokumenterte «i drift».

Ei Big-Bang-Rewrite tvingar fram ei nyrekonstruksjon av denne kunnskapen – inkludert feila som det gamle systemet lenge ikkje lenger gjer. Den betre tilnærminga er å behandle faglogikken som ei verdifull ressurs: isolere, sikre, og deretter modernisere steg for steg.

Eit berekraftig målbildet for prosesskritiske B2B-system er ikkje «alt nytt», men ei arkitektur som tillet endringar – utan å sette den løpande drifta i fare:

• tydeleg skilje mellom UI, domenelogikk, datatilgang og integrasjonar
• test- og målbarheit (regresjon, logging, overvaking, reproduserbare builds)
• gradvis utskiftbarheit (modernisere UI utan umiddelbar DB-migrasjon – eller omvendt)
• API-evne (t.d. REST), for å knyte til portalar, mobil eller systemintegrasjonar
• driftsklare utrullingar med rollback-alternativ

Delphi eignar seg godt til dette, fordi eksisterande units og domeneklasser kan gjenbrukast medan omgjevnadane blir moderniserte.

Før kode blir endra, trengst eit solid avgjerdsgrunnlag – ikkje full dokumentasjon. Desse tre resultata har vist seg nyttige:

• Faglogikk-kart: kritiske use-cases, reglar/utrekningar, variantar (tenantar/land/kundar), grensesnitt, jobbar/batch-køyringar.
• Risiko-profil: særleg feilkritiske område, datakvalitet, regulatoriske krav, flaskehalsar i drift (ytelse, stabilitet, vedlikehald).
• Moderniserings-backlog: prioriterte pakkar etter forretningsverdi og risiko (kva må vere stabilt, kva kan endrast, kva kjem seinare).

Med dette kan modernisering planleggast: med klare inkrement i staden for eitt einskildt «alt eller ingenting»-prosjekt.

For å hindre at faglogikk «utilsikta» blir endra, trengst ei sikring som fungerer uavhengig av UI-refaktorisering. Typiske byggjestykke:

• Characterization/Golden-Master-testar: eksisterande åtferd blir fryst via representative input/output (rapportar, utrekningar, prosesssteg).
• Regresjonstestar på use-case-nivå: dei forretningskritiske flytane blir automatisert eller halvautomatisert ettergjorde.
• Telemetri: logging, måledata og feilmønster blir gjort samanliknbare føre/etter ei endring.
• Parallelldrift & kontrollert omstilling: nye modulær køyrer ved sida av det eksisterande (Feature Toggles, pilotgrupper), med tydeleg rollback-strategi.

Først når desse tryggingsnetta er på plass, løner den faktiske tekniske moderniseringa seg – fordi risiko og etterarbeid går drastisk ned.

Den vanlegaste årsaka til tap av forretningslogikk er samblanding av UI, datatilgang og fagreglar. Modernisering startar derfor med avkopling – ikkje med utskifting av UI-rammeverket.

Eit pragmatisk mål er ein 3‑lags‑struktur:

• Presentation: VCL/FMX, Presenter/ViewModel, berre UI‑nær validering (format, obligatoriske felt)
• Business: domenemodellar, tenester, reglar, tilstandslogikk, berekningar
• Data/Integration: Repositories, DB‑tilgang, adapter til ERP/DMS/CRM, REST‑Clients, messaging

Praksisregel: fagreglar flyttast frå OnClick/OnExit inn i domenetenester. SQL flyttast ut av Forms og inn i Repositories. Slik blir logikken testbar og seinare gjenbrukbar gjennom UI, tenester og jobbar.

Ved Strangulation Pattern blir nytt funksjonell målretta bygd «ved sida av» det eksisterande: nye funksjonar blir implementerte direkte i den avkoplede strukturen medan gamalsystemet held fram. Steg for steg tek det nye laget meir ansvar, til gamle delar fell bort.

Døme (typisk B2B):

• De ekstrakterer ordrelogikken til ein domeneteneste.
• Det eksisterande VCL‑UIet brukar først same tenesta (ingen prosessbrot).
• Parallelt blir det oppretta ein REST‑endepunkt for eit kundesenter eller ei integrasjon.
• Etter stabilisering blir einskilde gamle Forms bytte ut – utan at kjerne‑logikken må byggjast opp på nytt.

Slik reduserer du prosjektrisiko, opprettheld driftsevne og oppnår raskt målbar nytte (t.d. API, ytelse, vedlikehaldbarheit).

Avhengig av utgangssituasjonen er desse byggjesteinane ofte relevante – avgjerande er prioritering etter risiko og forretningsverdi:

• BDE/Legacy‑DB‑tilgang erstatte: moderne drivarar/tilbydarar, tydelege transaksjonsgrenser, reproduserbare utrullingar.
• Unicode: strenghandsaming, database/grensesnitt, tredjepartskomponentar.
• 64‑Bit: avhengigheiter, minne/ytelse, eksterne bibliotek.
• API‑ og tenestelag: REST, Windows-/Linux‑tenester, integrasjonar.
• Build & Release: CI/CD, artefakthandtering, signerte installatørar, tilbake­rulling.

Viktig: Desse punkta bør ideelt sett gjennomførast etter avkopling og sikring – då kan endringar verifiserast trygt.

Ein komplett omskriving kan i nokre tilfelle vere fornuftig – ofte er det likevel den dyreste vegen for å få «moderne teknologi». Desse spørsmåla hjelper til ved vurderinga:

• Er faglogikken fullstendig forstått og testbar – eller ligg mykje kunnskap implisitt i drift?
• Postar det harde deadline (t.d. plattformavvikling, compliance) som gjer parallell drift umogleg?
• Kor stor er variasjonsbreidda (kunde-/tenantlogikk)?
• Kor kritisk er tilgjengelegheit, og kva toleranse finst for endringar i prosessane?
• Kva delar er verkeleg «skuld» (UI, datatilgang, integrasjonar, deployment) – og kva delar er stabile?

I mange B2B‑scenario fører ein trinnvis tilnærming raskare til målbare resultat, fordi han kontrollerer risiko og vernar faglogikken.

Delphi‑Moderniserings‑Audit (for prosesskritiske applikasjonar): Vi analyserer arkitektur, avhengigheiter, risikoområde og leverer ein prioritert roadmap for korleis du moderniserer utan å miste faglogikk.

• Input: kodebase (read‑only), build‑oppsett, 2–3 kjerne‑use‑cases, systemomgjevnad (DB, integrasjonar).
• Resultat: faglogikk-/modulkart, risiko- og avhengheitsanalyse, tilrådd målarkitektur, gjennomføringsplan i inkrement med sikring (testar/parallelldrift).
• Valgfritt: Proof of Concept for avkopling + første Golden-Master-test.

Slik får du eit påliteleg beslutningsgrunnlag, før budsjett og tid blir brukt i eit risikabelt omskrivingsprosjekt.

Kan ein modernisere Delphi utan å skrive applikasjonen på nytt?
Ja. I mange tilfelle blir faglogikk og datatilgang først løyst frå kvarandre, deretter teknisk modernisert. Det reduserer risiko og held drifta stabil.

Korleis hindrar ein at faglogikk blir „stille“ endra?
Gjennom Golden-Master-/regresjonstestar, telemetri samt ein kontrollert parallelldrift med klar rollback-strategi.

Kva steg gir ofte raskast nytte?
Transparens (Assessment), avkopling av UI/SQL, BDE-utfasing og eit API-/service-lag for integrasjonar – kvart steg sikra gjennom testar.

Kor lang tid tek ei modernisering?
Det avheng av kritiske brukstilfelle, variantmangfald og avhengigheiter. Eit Audit leverer typisk på kort tid eit påliteleg veikart og prioriterte inkrement.