Technologien für Delphi, C#, Datenbanken und Services

Tittel (Variant A): Teknologier for bedriftsprogramvare: Delphi, C#, Arkitektur & Plattformen
Tittel (Variant B): Teknologivalg & arkitektur: Delphi-modernisering, C#-tjenester, Multiplattform

Meta-beskrivelse (Variant A): Vi velger teknologier etter driftsrealitet: Delphi for langsiktig forretningslogikk & multiplattform-klienter, C# for REST-tjenester & portaler. Layer-3-arkitektur, integrasjoner og drift i fokus.
Meta-beskrivelse (Variant B): Delphi, C#, REST og plattformer (Windows/macOS/Linux/ARM64) – med arkitektur som forblir vedlikeholdbar. Vi rådgir, moderniserer og integrerer uten unødvendige brudd.

Vi velger ikke teknologier etter motetrender, men etter driftsrealitet, levetid, integrasjonsbehov og teamets kompetanse. Avgjørende er ikke slagordet, men om systemet senere forblir lett å drifte, utvide og overta.

• Vedlikeholdbarhet over år i stedet for kortsiktige trendendringer
• Integrasjon i eksisterende bedriftssystemer (REST/APIer, dataflyt, prosesser)
• Planbar arkitektur (UI, forretningslogikk, datatilgang klart adskilt)
• Multiplattform og nye målsystemer (Windows/macOS/Linux, Windows 11 ARM64)

Teknologikomponenter

Delphi

Sterk for etablert forretningslogikk, databasenære prosesser, rapporter og stabile multiplattform-klienter (Windows, macOS, Linux). Ideell når eksisterende faglighet skal videreføres og moderniseres på lang sikt.

Se Delphi

C#

Sterk for REST-tjenester, integrasjoner, portaler og moderne backend-tjenester. Fornuftig når grensesnitt, skalering, tydelige servicegrenser og tilknytning til eksisterende systemer står i sentrum.

Se C#

Arkitektur (Layer-3)

Vi skiller presentasjon, forretningslogikk og datatilgang, slik at endringer forblir planbare. Det reduserer sideeffekter, forenkler testing og gjør utvidelser mulig uten «kamp mot eksisterende systemer».

Se Layer-3

Plattformer (inkl. Windows 11 ARM64)

I tillegg til klassiske x64-mål tar vi hensyn til aktuelle plattformer tidlig, slik at ny maskinvare og deploys ikke blir et særskilt prosjekt senere.

Se ARM64

Når hvilken retning er fornuftig

Delphi er fornuftig når…

• eksisterende faglogikk skal videreføres og den faglige verdien ligger i kjernen
• komplekse skrivebordsprosesser må forbli stabile (inkl. offline-/periferitilknytning)
• Windows-, macOS- og Linux-klienter skal bygges på felles faglig grunnlag
• overlevering til et team med Delphi-erfaring er realistisk eller kan bygges opp

C# er fornuftig når…

• REST-servere, tjenester eller integrasjoner står i fokus
• portaler, eksterne grensesnitt eller identity-/rettighetsmodeller dominerer
• et driftskonsept med deploys, overvåkning og skalering er viktig
• flere systemer skal orkestreres via APIer

Hybrid er fornuftig når…

• eksisterende applikasjoner og nye portaler må samarbeide
• skrivbord, tjenester og web skal bruke samme datagrunnlag, men trenger klart adskilte ansvar
• modernisering skal skje trinnvis (Layer-3 i stedet for Big-Bang)

Praktisk merknad: I mange prosjekter er det ikke «språket» som er flaskehalsen, men den klare separasjonen av ansvar, dataflyter og drift. Nettopp der oppstår langsiktig vedlikeholdbarhet.

Delphi-modernisering i praksis

Når en gammel Delphi-applikasjon fortsatt har faglig verdi, moderniserer vi ikke blindt. Vi analyserer først hvordan systemet faktisk fungerer, hvilke prosesser det understøtter, hvor dataflyter bryter sammen og hvilke arvlastninger som hemmer driften. Ut fra dette oppstår en moderniseringsvei som er bærekraftig i det daglige.

Typiske moderniseringskomponenter

• Skille mellom brukergrensesnitt, forretningslogikk og dataaksess (Layer-3) for forutsigbare endringer
• Stabilisering og rydding av dataaksess der historisk oppbygde tilgangsveier skaper problemer
• Innføring eller utbygging av REST-grensesnitt for integrasjoner og nye frontends
• Trinnvis utvidelse med klienter for Windows, macOS og Linux på samme faglige basis

Hva dette betyr for deres virksomhet

• Mindre risiko enn ved en ny plattform, fordi faglig substans bevares
• Bedre vedlikeholdbarhet og testbarhet gjennom klare ansvarsområder
• Mulighet for integrasjon uten å måtte omforme eksisterende system

Tjenester og servere som en del av samme arkitektur

Mange virksomhetssystemer trenger i dag ikke bare en klient, men også bakgrunnstjenester, Windows- eller Linux-tjenester og REST-servere. Derfor planlegger vi disse delene ikke som et påbygg i etterkant, men som en integrert del av samme arkitektur.

• Klare ansvarsområder: Hva kjører i klienten, hva kjører i tjenesten, hva kjører på serveren?
• Sporbarhet: Gjøre feil synlige, loggføre tilstandsendringer, holde prosesser målbare
• Konsistens: Samme faglogikk og samme regler over klient, tjeneste og API
• Drift: Utrullinger, oppdateringer og utvidelser uten spesialtilfeller

Særlig i multiplattformprosjekter er dette avgjørende: En desktop-klient på Windows, macOS eller Linux skal faglig ikke bety noe annet enn en ledsagende REST-server eller bakgrunnstjeneste. Derfor tenker vi datamodell, prosesser, rettigheter, integrasjoner og drift sammen.

Vårt prinsipp

Teknologi er ikke et trossystem for oss. Det avgjørende er at arkitektur, teamets evne, drift og fremtidige utvidelser passer virksomheten. Det er ikke den mest høylytte plattformen som vinner, men den som gjør det mulig å styre risiko, vedlikeholdbarhet og vekst på en fornuftig måte.

Neste steg

Hvis dere ønsker å avklare om Delphi, C# eller en hybridtilnærming er fornuftig for deres system, vurderer vi dette basert på det konkrete bestandet: mål, integrasjoner, levetid, team og drift. På denne basis utarbeides et robust forslag i stedet for en arkitektur som bare eksisterer på lysbilder.

Dere bidrar med: grov systemoversikt, viktigste prosesser, integrasjonspunkter, driftsrammer.

Dere får: teknologianbefaling, arkitekturskisse (Layer-3/tjenester), prioriteringer og en pragmatisk fremgangsmodell.

Ofte stilte spørsmål om teknologi og arkitektur

Når er Delphi å foretrekke fremfor en komplett ny plattform?

Hvis den faglige substansen ligger i kjernen av applikasjonen (regler, spesialtilfeller, prosesser) og programvaren fungerer stabilt i daglig bruk, er modernisering ofte mer økonomisk og mindre risikabelt enn et Big-Bang-nybygg. Forutsetningen er en planbar moderniseringsvei (f.eks. Layer-3, rene dataaksesser, definerte grensesnitt).

Når er en ny plattform likevel et bedre valg?

Når sentrale krav strukturelt ikke lenger kan oppfylles (f.eks. nødvendig skalering, sikkerhets-/compliance-krav, arkitekturbrudd i datamodellen) eller når den eksisterende løsningen faglig og teknisk ikke lenger er håndterbar. Også da kan migrasjonen ofte sikres trinnvis via grensesnitt og parallelt kjørende tjenester.

Hva betyr Layer-3-arkitektur konkret?

En bevisst adskillelse mellom brukergrensesnitt, forretningslogikk og datatilgang. Dette gjør endringer planbare, tester enklere og integrasjoner renere, fordi ikke hver tilpasning medfører bivirkninger i hele applikasjonen.

Hvordan integrerer dere eksisterende systemer (ERP, DMS, Schnittstellen, Datenbanken)?

Gjennom klart definerte grensesnitt (typisk REST/APIs) og sporbare dataflyter. Avgjørende er å avklare ansvarsfordelingen: Hvilken logikk ligger i kjernesystemet, hvilken i tjenester, og hvilken i eksterne systemer?

Hvordan unngår dere at tjenester „Sonderfälle“ blir?

Ved å planlegge tjenester og bakgrunnsprosesser som en del av arkitekturen fra starten: felles faglogikk, konsistente tilgangsrettigheter, overvåking/loggføring, definerte Deployments og klare feilmønstre.

Hvilken rolle spiller Windows 11 ARM64?

ARM64 blir mer relevant, fordi nye enhetsklasser og bedriftsmaskinvare bygger på det. De som tar hensyn til plattformer tidlig, unngår senere særprosjekter knyttet til build, deployment, drivere og runtime-avhengigheter.

Hvordan går dere fram ved teknologivalg?

Vi starter med en kort teknisk og faglig vurdering: mål, risikoer, integrasjoner, drift og team. Deretter utleder vi en anbefaling som både er robust i dag og fortsatt økonomisk holdbar om 2–5 år.