Modernisere Delphi uten å miste forretningslogikken

Delphi-applikasjoner har i mange virksomheter gått stabilt i år – og gjengir nøyaktig den faglogikken som sikrer omsetning, tjenestekvalitet og etterlevelse. Ved modernisering handler det derfor sjelden om en «ny overflate», men om en kontrollert videreutvikling der regler, spesialtilfeller og historisk prosesskunnskap bevares.

I dette innlegget viser vi en praksisprøvd tilnærming for å modernisere Delphi trinnvis: fra bestandskartlegging via avkobling av UI og datatilgang til teknisk modernisering (Unicode/64‑Bit, BDE-avløsning, API/tjenester) – inkludert sikring gjennom tester, overvåking og parallellkjøring. Målet er en moderniserbar arkitektur, uten Big-Bang-rewrite og uten tap av logikk.

Moderniseringer mislykkes i praksis sjelden på grunn av kompilatoren eller et rammeverk, men på grunn av feil antakelser om systemets oppførsel. Over år vokste Delphi-applikasjoner inneholder typisk fagregler i GUI-events, SQL i skjemalogikk, varianter per kunde/mandant, historisk betingede spesialtilfeller samt integrasjoner som kun er dokumentert «i drift».

En Big-Bang-rewrite tvinger til å rekonstruere denne kunnskapen på nytt – inkludert feilene det gamle systemet for lengst ikke lenger gjør. En bedre tilnærming er å behandle faglogikken som en verdifull ressurs: isolere, sikre, og så modernisere trinnvis.

Et holdbart målbilde for prosesskritiske B2B-systemer er ikke «alt nytt», men en arkitektur som muliggjør endringer – uten å sette den løpende driften i fare:

• klar separasjon av UI, domenelogikk, datatilgang og integrasjoner
• test- og målbarhet (regresjon, logging, overvåking, reproduserbare builds)
• trinnvis utskiftbarhet (modernisere UI uten umiddelbar DB-migrering – eller omvendt)
• API-støtte (f.eks. REST), for å koble til portaler, mobil eller systemintegrasjoner
• driftsklare utrullinger med tilbakerullingsmulighet

Delphi egner seg godt til dette, fordi eksisterende units og domeneklasser kan gjenbrukes mens omgivelsene moderniseres.

Før kode endres, trengs et pålitelig beslutningsgrunnlag – ikke full dokumentasjon. Følgende tre resultater har vist seg nyttige:

• Faglogikk-kart: kritiske use-caser, regler/beregninger, varianter (mandanter/land/kunder), grensesnitt, jobber/batchkjøringer.
• Risikoprofil: spesielt feilkritiske områder, datakvalitet, regulatoriske krav, flaskehalser i driften (ytelse, stabilitet, vedlikeholdbarhet).
• Moderniserings-backlog: prioriterte pakker etter forretningsverdi og risiko (hva som må forbli stabilt, hva som kan endres, hva som kan komme senere).

Dette gjør modernisering planbar: med klare inkrementer i stedet for ett enkelt «alt-eller-ingenting»-prosjekt.

For å hindre at faglogikk «utilsiktet» endres, trengs en sikring som fungerer uavhengig av UI-refaktorisering. Typiske byggeklosser:

• Characterization/Golden-Master-tester: eksisterende atferd fryses via representative innganger/utganger (rapporter, beregninger, prosesssteg).
• Regresjonstester på use-case-nivå: de forretningskritiske flytene gjenskapes automatisk eller halvautomatisk.
• Telemetri: logging, metrikker og feilmønstre gjøres sammenlignbare før/etter en endring.
• Parallellkjøring & kontrollert overgang: nye moduler kjører ved siden av det eksisterende (feature toggles, pilotgrupper), med tydelig tilbakerullingsstrategi.

Først når disse sikkerhetsnettene er på plass, lønner den egentlige tekniske moderniseringen seg – fordi risiko og etterarbeid reduseres drastisk.

Den vanligste årsaken til tap av logikk er blanding av UI, dataadgang og fagregler. Modernisering begynner derfor med avkobling – ikke med utskifting av UI-rammeverket.

Et pragmatisk mål er en 3‑lagsstruktur:

• Presentasjon: VCL/FMX, Presenter/ViewModel, kun UI-nær validering (format, obligatoriske felt)
• Forretningslag: domenemodeller, tjenester, regler, tilstandslogikk, beregninger
• Data/Integrasjon: repositories, DB-tilgang, adaptere til ERP/DMS/CRM, REST-klienter, meldingssystemer

Praksisregel: Fagregler flyttes fra OnClick/OnExit til domenetjenester. SQL flyttes fra Forms til repositories. Slik blir logikk testbar og senere gjenbrukbar via UI, tjenester og jobber.

Ved Strangulation Pattern skapes nytt målrettet „ved siden av“ det eksisterende: Nye funksjoner implementeres allerede i den avkoblede strukturen, mens det gamle systemet kjører videre. Steg for steg tar det nye laget mer ansvar, til gamle deler faller bort.

Eksempel (typisk B2B):

• Dere ekstraherer ordrelogikken til en domenetjeneste.
• Det eksisterende VCL-UI bruker først samme tjeneste (ingen prosessbrudd).
• Parallelt opprettes en REST-endepunkt for et kundeportal eller en integrasjon.
• Etter stabilisering blir enkelte gamle Forms erstattet – uten at kjernelogikken må bygges på nytt.

Slik reduserer dere prosjektrisiko, opprettholder driftsevne og oppnår raskt målbar nytte (f.eks. API, ytelse, vedlikeholdbarhet).

Avhengig av utgangssituasjonen er disse byggesteinene ofte relevante – avgjørende er prioritering etter risiko og forretningsverdi:

• BDE/Legacy-DB-tilgang erstatte: moderne drivere/provider, klare transaksjonsgrenser, reproduserbare utrullinger.
• Unicode: strenghåndtering, database/grensesnitt, tredjepartskomponenter.
• 64‑Bit: avhengigheter, minne/ytelse, eksterne biblioteker.
• API- og tjenestelag: REST, Windows-/Linux-tjenester, integrasjoner.
• Bygg & Release: CI/CD, artefakthåndtering, signerte installasjonsprogrammer, rollback.

Viktig: Disse punktene bør ideelt sett gjennomføres etter avkobling og sikring – da kan endringer verifiseres trygt.

En fullstendig omskriving er i noen tilfeller fornuftig – ofte er det imidlertid den dyreste måten å skaffe „moderne teknologi“ på. Disse spørsmålene hjelper med vurderingen:

• Er faglogikken fullstendig forstått og testbar – eller ligger mye kunnskap implisitt i driften?
• Finnes det harde frister (f.eks. plattformens slutt, compliance) som utelukker parallell drift?
• Hvor stor er variasjonsomfanget (kunde-/mandantlogikk)?
• Hvor kritisk er tilgjengeligheten, og hvor høy er toleransen for prosessendringer?
• Hvilke deler er virkelig „skyldige“ (UI, dataadgang, integrasjoner, deployment) – og hvilke er stabile?

I mange B2B-scenarier fører en trinnvis tilnærming raskere til målbare resultater, fordi den kontrollerer risiko og beskytter faglogikken.

Delphi-moderniserings-audit (for prosesskritiske applikasjoner): Vi analyserer arkitektur, avhengigheter, risikoområder og leverer en prioritert roadmap for hvordan dere kan modernisere uten å miste faglogikken.

• Input: kodebase (read-only), Build-Setup, 2–3 kjerne-use-cases, systemmiljø (DB, integrasjoner).
• Resultat: Forretningslogikk-/modulkart, risiko- og avhengighetsanalyse, anbefalt målarkitektur, implementeringsplan i inkrementer inkl. sikring (tester/parallell drift).
• Valgfritt: Proof of Concept for avkobling + første Golden-Master-test.

Slik får du et pålitelig beslutningsgrunnlag før budsjett og tid brukes på en risikofylt omskriving.

Kan man Delphi modernisere uten å skrive applikasjonen på nytt?
Ja. I mange tilfeller blir forretningslogikk og dataadgang først avkoblet, og deretter teknisk modernisert. Det reduserer risiko og holder driften stabil.

Hvordan hindrer man at forretningslogikk „stille“ endres?
Gjennom Golden-Master-/regresjonstester, telemetri samt en kontrollert parallell drift med klar rollback-strategi.

Hvilke skritt gir ofte raskest nytte?
Transparens (Assessment), avkobling av UI/SQL, BDE-utfasning og et API-/service-lag for integrasjoner – hver sikret gjennom tester.

Hvor lang tid tar en modernisering?
Det avhenger av kritiske brukstilfeller, variantmangfold og avhengigheter. En audit leverer typisk på kort tid et pålitelig veikart og prioriterte inkrementer.