Delphi Virksomhedsapplikationer: Hvorfor mange systemer kører stabilt – og hvordan I kan gøre dem fremtidssikre

I mange virksomheder kører Delphi virksomhedsapplikationer i årevis pålideligt: produktionstilknyttede registreringer, disponering, lager, forsendelse, service, kvalitetssikring eller administrative kerneprocesser. Sådanne systemer er sjældent „pæne“, men de er ofte ekstremt værdifulde – fordi de afbilder processer, som ikke kan presses ind i standardsoftware. Netop derfor er Delphi i praksis stadig relevant: ikke som en trend, men som en stabil basis for individuel virksomhedssoftware, der er opstået under tidspres og siden er vokset over år.

For IT-ledelse og administration er spørgsmålet mindre „Delphi: ja eller nej?“, og mere: Hvordan holder jeg systemet driftsdueligt, sikkert og ændringsbart, uden at blokere driften med et Big-Bang-nybyggeri? Denne artikel klassificerer typiske Delphi-landskaber og viser praksisnære moderniseringsveje – med fokus på drift, data, grænseflader, vedligeholdbarhed, sikkerhed og migration. Uden framework-interna, men med konkrete beslutninger, der tæller i hverdagen.

Hvorfor Delphi hænger fast i virksomheder – og hvorfor det ikke automatisk er dårligt

Mange Delphi-applikationer blev opbygget i en tid, hvor desktop-software (VCL, altså den klassiske Windows-grænseflade) var den hurtigste vej til at digitalisere processer. Det førte til systemer med høj forretningslogik-tæthed, tætte databasehenvisninger og mange „små“ specialtilfælde, som tilsammen bærer driften. Det forklarer holdbarheden: Forretningslogikken er testet – ikke gennem Unit-Tests, men gennem mange års produktiv drift.

Risikoen ligger som regel ikke i Delphi som sprog, men i de tilstødende områder: gamle dataadgangsmetoder (f.eks. BDE, die Borland Database Engine), 32‑bit-afhængigheder, forældet kryptering, uklare grænseflader, manglende observability (Monitoring/Logging), uklare rettighedsmodeller eller manglende opdateringsstrategier. Når disse randområder moderniseres, kan en Delphi-applikation fortsat være en meget pålidelig byggesten i de digitale virksomhedsløsninger.

Typiske udgangssituationer: Sådan ser Delphi virksomhedsapplikationer ud i virkeligheden

Den, som overtager eller skal stabilisere et Delphi-landskab, støder ofte på hybridformer. Til planlægning og budget er det nyttigt at navngive udgangssituationen klart:

• Monolitisk desktop-klient med direkte databaseadgang (ofte historisk opstået, delvis med „Fat Client“-logik).
• Client-server med services: Windows- und Linux-Services eller Linux-Daemon håndterer baggrundsjobs (importer, eksporter, udskriftskørsler, e-mail, planlægning).
• Hybrid: desktopen forbliver førende, suppleret med en REST-API for portaler eller tredjepartsintegrationer (REST = HTTP-baseret grænseflade, der typisk leverer data som JSON).
• Flere datakilder: SQL Server/PostgreSQL plus „altlast“ (Firebird, Paradox-filer, DBF, Access).
• Terminalserver/RDS eller Virtual Desktop Infrastruktur (VDI) til central drift, delvist med periferitilknytning (scannere, vægte, etiketudskrivning).

Enhver af disse varianter kan fungere – men moderniseringsfokus er forskellige. En desktop-monolit har ofte først brug for afkobling og klarere grænseflader. Et servicelandskab har brug for ordentlig driftshåndtering, versionering og overvågning. Og i hybridformer bliver data- og grænsefladestrategien den centrale løftestang.

Modernisering uden Big Bang: beslutningslogik for IT og beslutningstagere

Den vigtigste beslutning lyder: Hvad skal stabiliseres på kort sigt, og hvad kan moderniseres trin for trin? Et komplet nybyggeri har høje risici: parallelt arbejde med forretningskoncepter, dobbelt vedligehold, migrationsvinduer og ofte undervurderede »randfunktioner« (særlige udskrifter, korrekturprocesser, nødprocedurer). Samtidig må man ikke ignorere reelle blokerende forhold (f.eks. BDE, ikke-patchbare afhængigheder, ikke-reviderbar Security).

I praksis fungerer en tredelt roadmap:

• Stabilisere: build-proces, reproducerbare releases, ren logging, Backup/Restore-tests, hurtige sikkerhedsforbedringer.
• Afkoble: klare lag (f.eks. Layer-3-arkitektur: UI, forretningslogik, dataadgang), definere grænseflader, modernisere dataadgang.
• Udvide: REST-APIs, portaler, nye klienter, nye databaser, tværplatform, multi-tenant-funktionalitet – dér hvor det fagligt og økonomisk giver mening.

Nøglen er, at hvert trin leverer en driftsdygtig tilstand og ikke kun »forarbejde«. Så bevares proceskapaciteten, og ændringer er kontrollerbare.

Delphi Modernisering: Hvor de største risici reelt ligger

Begrebet »modernisering« bruges ofte for bredt. For driften er typisk fem risikozoner afgørende:

1) Dataadgang og driver-landskab (BDE, ODBC, forældede klienter)

En BDE-udskiftning er en klassiker: Så længe Borland Database Engine er i produktion, opstår konflikter med aktuelle Windows-versioner, drivere, rettigheder og sikkerhedsbaselines. Derudover bliver driften skrøbelig, fordi komponenter ikke længere vedligeholdes. Her er BDE-udskiftning med native tilslutning ofte det pragmatiske moderniseringstrin: et moderne dataadgangslag i Delphi, som binder forskellige databaser rent op og gør driver-/pooling-emner lettere at håndtere.

Vigtigt for IT: En BDE-udskiftning er ikke kun »driverudskiftning«. Typiske efterfølgende opgaver er SQL-dialekt-tilpasninger, transaktionsgrænser (transaktion = beslægtede databaseændringer, som enten gennemføres fuldstændigt eller slet ikke), fejlbehandling, tegnsæt/Unicode og performance-profilering.

2) 32‑Bit-afhængigheder og overgangen til 64‑Bit

Overgangen til 64‑bit fejler sjældent på Delphi selv, men på eksterne komponenter: printerdriver-wrappere, gamle COM/ActiveX-biblioteker, specialiserede hardware-SDKs eller forældede databaseklienter. Til planlægningen er en afhængighedsinventar påkrævet: Hvilke DLLs indlæses? Hvilke komponenter er ikke 64‑bit-kompatible? Findes der erstatning, eller kan funktionen udlægges til en separat proces (f.eks. som en service)?

En ren tilgang er at indføre 64‑bit først dér, hvor det giver driftsmæssige fordele (hukommelsesbehov, store datamængder, moderne platformkrav) – og midlertidigt kapsle 32‑bit for perifere funktioner i stedet for at blokere hele klienten.

3) Unicode-migration og datakonsistens

Unicode betyder: Tekster gemmes ikke længere i lokale codepages, men i et ensartet tegnsæt (typisk UTF‑16/UTF‑8 afhængigt af niveau). I veletablerede Delphi-applikationer gælder det for gamle datafelter, eksportformater, udskriftsskabeloner og grænseflader. Problemer viser sig ofte først i hverdagen: specialtegn i navne, internationale adresser, varetekster, e-mail-indhold.

For virksomheder er det afgørende at teste ende-til-ende: databasekollation, import/eksport (CSV, XML, JSON), EDI-formater, PDF-generering, SMTP/IMAP, og også visningen i UI. En Unicode-migration er gennemførlig, men den kræver tests med reale data og klare acceptkriterier.

4) Grænseflader og integrationer (REST, ERP, DMS, Identity)

Mange Delphi-systemer er „øer“, fordi direkte databaseadgang historisk var den hurtigste vej. I dag har man brug for rene integrationer: ERP, DMS, CRM, portaler, maskinforbindelse. Her har det vist sig hensigtsmæssigt at uddelegere integrationslogikken til REST-services eller baggrundstjenester. En Delphi REST-API und REST-Server er ikke et mål i sig selv, men en driftskomponent: versionerede endepunkter, klar autentificering, kontrolleret logging og begrænsede dataudleveringer.

Derudover bliver Identity relevant: SAML 2.0 (Single Sign-on mellem virksomhedsidentiteten og applikationen) eller OAuth2/OpenID Connect, afhængigt af kontekst. Beslutningen påvirker ikke kun applikationen, men også drift, auditérbarhed og offboarding-processer.

5) Drift: opdateringer, overvågning, gendannelse

En applikation er i virksomheden kun så god som dens drift. Typiske svagheder: manuelle installationer, manglende rollback-strategi, næsten ingen telemetri og uklare ansvarsforhold ved fejl. Modernisering betyder her ikke „Cloud“, men: reproducerbare udrulninger, sporbar konfiguration og målbar systemsundhed.

Arkitektur, der hjælper i hverdagen: Layer-3, klare grænser, færre sideeffekter

Når Delphi-projekter vokser over år, blandes UI-logik ofte sammen med forretningsregler og dataadgang. Det gør ændringer risikable: et nyt felt i dialogen fører pludselig til bivirkninger i importer eller rapporter. Den Layer-3-arkitektur (præsentation, forretningslogik, dataadgang) er her mindre teori end et praktisk middel til at gøre ændringer kalkulerbare.

Vigtigt er afhængighedsretningen: UI’en må bruge forretningsfunktioner, men forretningen bør ikke vide, hvad knapper hedder. Dataadgangen leverer objekter/data, men afgør ikke faglige regler. Det gør det lettere:

• målrettede tests af forretningsregler, uden at skulle starte UI’en,
• trinvis udskiftning af dataadgang (f.eks. fra BDE til BDE-Ablosung mit nativer Anbindung),
• paralleldrift af flere brugerflader (Desktop plus Portal),
• stabilere releases, fordi sideeffekter reduceres.

For beslutningstagere er det et økonomisk argument: Ikke fordi arkitektur „smuk“ er, men fordi den gør vedligeholdelse mere planbar.

Modernisere databaser: FireDAC, PostgreSQL, SQL Server – og hvad det betyder for driften

Beslutninger om databaser er ofte historiske i Delphi-virksomhedsapplikationer. I driften tæller især: backup/gendannelse, overvågning, HA/failover, sikkerhedsopdatering og rettighedsstyring. Dataadgangen bør matche dette.

FireDAC som standardiseringslag

FireDAC kan fungere som et teknisk standardiseringslag, fordi forbindelsesstyring, parameterbinding, transaktioner og driverudvalg bliver mere konsistente. For driften vigtigt: connection pooling (genbrug af forbindelser), timeouts og klar fejlkategorisering (f.eks. „Deadlock“, „Timeout“, „Unique Constraint“).

PostgreSQL i produktion med Delphi: muligheder og faldgruber

PostgreSQL vælges ofte, når åbne standarder, god SQL-funktionalitet og solide driftsmuligheder er efterspurgt. Typiske punkter ved migrationen:

• Datatyper: Dato/tid, Boolean, UUID, JSONB – brug dem konsekvent i datamodellen i stedet for at gemme alting som tekst.
• Transaktionsisolation: Konsistens vs. parallelitet; relevant for bogføringslogik og batchbehandling.
• Indeksstrategi: Ydeevne opnås sjældent ved ‚mere CPU‘, men gennem passende indekser og rene forespørgsler.

For administratorer er det vigtigt, at applikationen ikke kræver ’superuser‘-rettigheder, men arbejder med minimale roller. Det er et afgørende punkt ved revisioner og sikkerhedsrevisioner.

Modernisere SQL Server-tilslutning

I mange miljøer er SQL Server standard. Så handler det mindre om migration og mere om korrekt anvendelse: parametriserede forespørgsler (mod SQL-injektion), fornuftig isolation, brug af Stored Procedures hvor governance kræves, og en klar adskillelse mellem applikations-login og admin-logins. I praksis er det også værd at kigge på collations (sortering/tegnsammenligning), da de bliver relevante ved Unicode-spørgsmål og sammenligninger (f.eks. store/små bogstaver).

REST-API eftermonteres: Muliggør integrationer uden at „åbne“ databasen

Hvis portaler, mobile processer eller tredjepartsleverandører skal tilsluttes, er direkte adgang til databasen som regel den dårligste løsning: svær at versionere, risikabel for dataintegriteten og næsten ikke auditérbar. En REST-API etablerer et kontrolleret integrationslag. Den definerer, hvilke data i hvilket format og med hvilke regler der gøres tilgængelige.

For drift og sikkerhed er fire ting afgørende:

• Autentificering: Token-baseret, ideelt knyttet til centrale identiteter (f.eks. via SAML 2.0/OIDC i et foranliggende gateway, afhængig af arkitektur).
• Autorisation: Rettighedskontrol på forretningsobjekter, ikke blot ‚brugeren må bruge endpoint‘.
• Versionering: Endepunkter eller payload-versioner, så portal og backend kan udrulles uafhængigt.
• Ratebegrænsning og logning: Beskyttelse mod misbrug og pålidelig diagnostik ved fejl.

I mange virksomhedsnetværk kører sådanne services bag en reverse proxy (f.eks. nginx). Så skal håndteringen af forwarded headers være korrekt (ægte klient-IP, HTTPS-detektion, korrekte URL-baser), ellers passer logs, redirects og sikkerhedsregler ikke. Det er ikke en detalje, men relevant for incident-analyse og compliance.

Windows-Service og Linux-services: Korrekt drift af baggrundsprocesser

Delphi bruges i virksomheder ikke kun til desktop-klienter, men også til tjenester: dataimporter, scheduler, mailafsendelse, PDF-generering og integrations-workere. For driften er det væsentligt, at en service ikke bare „kører“, men kan startes, stoppes og overvåges kontrolleret.

Tjekliste for service-egnede Delphi-komponenter

• Ekstern konfiguration: ingen „faste“ stier/hosts i binærfilen; konfiguration som fil eller miljøvariable, med klar dokumentation.
• Graceful Shutdown: afslut eller afbryd kørende jobs ordentligt, så der ikke opstår delvist oprettede poster.
• Idempotens: gentagen eksekvering af et job må ikke skabe duplikatregistreringer (idempotens = samme kald, samme resultat).
• Logging med korrelation: per opgave/transaktion en ID, så logs fra flere komponenter kan samles.
• Monitoring: health-endpoints eller i det mindste verificerbare metrikker (f.eks. „sidste kørsel“, „fejlfrekvens“, „kø-længde“).

Ved Linux-Services (f.eks. som daemon under systemd) kommer paketering, rettighedskoncept og filsystem-layout oveni. Det er afgørende, at serviceidentiteten har minimale rettigheder, og at Secrets (adgangskoder, Tokens) ikke ligger i klartekst i udrulningen. Afhængig af miljøet kan en Secret-Store eller mindst en sikret konfigurationssti være nødvendig.

Sikkerhed og compliance: Hvad der typisk skal følges op på for Delphi-applikationer

Mange eksisterende applikationer er funktionelt korrekte, men sikkerhed blev „på det tidspunkt“ vurderet anderledes. I dag er kravene klarere: patchbarhed, sporbarhed, kryptering, adgangskontrol. Typiske tiltag med høj nytte i forhold til risiko:

• Transportkryptering: TLS for services og API-kommunikation; ingen ukrypterede HTTP-forbindelser i det interne netværk „af vane“.
• Håndtering af adgangskoder og Secrets: ingen adgangskoder i INI-filer uden beskyttelse; om muligt centraliseret identitetsløsning og token-baseret håndtering.
• Audit-logging: hvem udførte hvilken kritisk handling (stamdata, godkendelser, eksporter), med tidsstempel og identitet.
• Rettighedskoncept: modeller roller og rettigheder fagligt; adskil admin-funktioner; kontroller lejer-/mandantadskillelse.
• Kryptografi — pragmatisk korrekt: ingen hjemmelavede løsninger; brug etablerede algoritmer som AES (symmetrisk) og aktuelle hashfunktioner, samt integritetsbeskyttelse.

Vigtigt: sikkerhed er ikke kun kode. Den vedrører også drift (adgangsrettigheder på servere, log-opbevaring, backup-kryptering) og processer (hændelseshåndtering/Incident Response, regelmæssige opdateringer, udfasning af komponenter).

Planlæg migration: Fra „vokset system“ til en roadmap-kompatibel platform

Hvis en Delphi-applikation skal videreføres strategisk, har den brug for en roadmap, der forener tekniske og organisatoriske aspekter. En praksisnær fremgang begynder med transparens:

1) Teknisk statusopgørelse, der afbilder drift og risiko

• Komponentliste (Delphi-versioner, tredjepartsbiblioteker, drivere, Services, installationsprogrammer)
• Databaser og dataflows (import/eksport, batch-jobs, rapportering)
• Schnittstellen (Datei, TCP/IP, REST, SOAP, E-Mail, ERP/DMS/CRM)

2) Definér målbildet, men overbelast det ikke

Et målbildet er nyttigt, når det gør beslutninger enklere. Det bør beskrive, hvordan releases fremover skabes, hvordan grænseflader ser ud, hvordan dataadgang standardiseres, og hvordan driften overvåges. Det behøver ikke at betyde „alt nyt“. Ofte er et målbildet med tre til fem retningslinjer tilstrækkeligt: f.eks. FireDAC som standard, REST til integrationer, services med monitorering, identitetsintegration, klare lag.

3) Implementering i afgrænsede pakker

Moderniseringspakker bør være fagligt og teknisk afgrænsede: „BDE ud og standardisere dataadgang“, „REST-API til portal-brugstilfælde“, „64‑bit-klient plus kompatibilitetskapsel“, „hærde service-driften“. Hver pakke kræver acceptkriterier: målbar stabilitet, defineret performance, dokumenterede driftsprocesser.

C# og Delphi bringes sammen: Når portaler og services opstår ved siden af desktopen

I mange virksomheder er Delphi fast etableret i kernesystemet, mens portaler eller nye integrationsservices snarere opstår i C#/.NET. Det er ikke et modsætningsforhold, så længe arkitekturen adskiller klart: Delphi kan fortsætte med at drive det procesnære desktop-system stabilt, mens C# portaler eller C# services dækker moderne webkrav. Afgørende er systemernes fælles sprog: klare datakontrakter, konsistente identiteter, sporbare grænsefladeversioner og ensartet monitorering på tværs af systemgrænser.

For IT-ledelsen er det ofte den mest økonomiske vej: Den eksisterende værdiskabelse forbliver tilgængelig, mens nye kanaler kan opstå uden komplet migration.

Hvad I bør forberede internt: Dokumentation, driftshåndbog, vidensoverførsel

Delphi-systemer bæres ofte af få nøglepersoner. Det er en risiko, som kan reduceres med begrænset indsats. Især effektive er:

• Betriebshandbuch: tjenester, porte, konfiguration, Cron/Scheduler, typiske fejl, gendannelsestrin.
• Release-Notizen: hvad ændrer sig, hvilke DB-migrationer køres, hvordan er rollback muligt?
• Schnittstellenkatalog: endepunkter/formater, filudveksling, kontaktpersoner, versioner.
• Datenmodell-Übersicht: centrale tabeller/entiteter, nøgler, tenantlogik, arkivering.

Det er ikke bureaukrati, men grundlaget for planlagt drift, hurtigere incident-håndtering og mindre afhængighed af enkeltpersoner.

Konklusion: Delphi virksomhedsapplikationer er ikke problemet – manglende moderniseringsveje er det

Delphi virksomhedsapplikationer kan i årevis være en pålidelig, økonomisk kerne for procesnær software. Det kritiske punkt er sjældent sproget, men summen af gamle drivere, uklare grænseflader, manglende driftshærdning og ikke-vedligeholdte sikkerhedsmekanismer. Den, der planlægger stabilisering, frikobling og udvidelse som en kontrolleret køreplan, undgår den risikable Big Bang – og får alligevel REST-integrationer, 64‑bit-kompatibilitet, rene dataadgange og en drift, der matcher nutidens krav.

Hvis I ønsker at teknisk klassificere jeres Delphi-landskab og opstille en robust moderniseringsvej for dataadgang, grænseflader og drift, så tal med os:

Drøft projekt eller moderniseringsprojekt med Net-Base.