Teknologiprofil
Oversigt over vores tekniske fundament
Delphi. C#. SQL. APIs.
Teknologier, der passer til forretningslogik, data og drift.
Teknologi i billeder
Teknologibeslutninger bliver hos os synlige gennem målarkitektur.
Det afgørende er ikke buzzwordet, men hvordan platform, services og lag senere samarbejder. Disse skitser gør retningen håndgribelig.
Shared Core til flere mål
Multiplatform er hensigtsmæssigt, når flere klienter anvender den samme forretningslogik og ikke divergerer.
Anvendte platformnavne og varemærker tilhører de respektive rettighedshavere.
C# og tjenester som supplement
Portaler, REST og tjenester supplerer kernen dér, hvor web- og driftslogik bliver stærkere.
Inddrag målhardware tidligt
Platformsskift som ARM64 hører hjemme i arkitektur og deployment, før de bliver til et supportproblem.
Velegnede ydelses- og teknologiveje
Vigtige uddybninger om dette emne
Titel (Variant A): Teknologier til virksomhedssoftware: Delphi, C#, Arkitektur & Platforme
Titel (Variant B): Teknologivalg & Arkitektur: Delphi-modernisering, C#-services, multiplatform
Meta-beskrivelse (Variant A): Vi vælger teknologier efter driftsrealitet: Delphi til langtidsholdbar forretningslogik & multiplatform-klienter, C# til REST-services & portaler. Layer-3-arkitektur, integrationer og drift i fokus.
Meta-beskrivelse (Variant B): Delphi, C#, REST og platforme (Windows/macOS/Linux/ARM64) – med arkitektur, der forbliver vedligeholdbar. Vi rådgiver, moderniserer og integrerer uden unødvendige brud.
Vi anvender ikke teknologier efter mode, men efter driftsrealitet, levetid, integrationsbehov og teamets kapabiliteter. Afgørende er ikke modeordet, men om systemet senere kan drives, udvides og overdrages på en ordentlig måde.
- Vedligeholdelse over år fremfor kortsigtede trendskift
- Integration i eksisterende virksomhedssystemer (REST/APIs, dataflows, processer)
- Planbar arkitektur (UI, forretningslogik, dataadgang tydeligt adskilt)
- Multiplatform og nye målplatforme (Windows/macOS/Linux, Windows 11 ARM64)
Teknologikomponenter
Delphi
Stærk til modnet forretningslogik, database-nære processer, rapporter og stabile multiplatform-klienter (Windows, macOS, Linux). Ideel, når eksisterende fagfunktionalitet skal videreføres og moderniseres på lang sigt.
C#
Stærk til REST-services, integrationer, portaler og moderne backend-tjenester. Relevant, når grænseflader, skalering, tydelige servicegrænser og tilkobling til eksisterende systemer er i fokus.
Arkitektur (Layer-3)
Vi adskiller præsentation, forretningslogik og dataadgang, så ændringer forbliver planbare. Det reducerer sideeffekter, letter testning og gør udvidelser mulige uden „kamp mod det eksisterende“.
Platforme (inkl. Windows 11 ARM64)
Ud over klassiske x64-mål tager vi aktuelle platforme i betragtning tidligt, så ny hardware og udrulninger ikke senere bliver et særprojekt.
Hvornår hvilken retning er relevant
Delphi er relevant, når…
- eksisterende faglogik skal videreføres, og den faglige værdi ligger i kernen
- komplekse desktopprocesser skal forblive stabile (inkl. offline-/periferitilkobling)
- Windows-, macOS- og Linux-klienter skal bygges på et fælles fagligt grundlag
- overdragelse til et team med Delphi-erfaring er realistisk eller kan etableres
C# er relevant, når…
- REST-servere, services eller integrationer er i fokus
- portaler, eksterne grænseflader eller identitets-/adgangsstyringsmodeller dominerer
- et driftskoncept med udrulninger, overvågning og skalering er vigtigt
- flere systemer skal orkestreres via APIs
Hybrid er relevant, når…
- eksisterende applikationer og nye portaler skal samarbejde
- desktop, services og web bruger samme databasis, men har brug for tydeligt adskilte ansvar
- modernisering skal ske trinvis (Layer-3 frem for Big-Bang)
Praktisk note: I mange projekter er det ikke „sprogvalg“ der er flaskehalsen, men den klare adskillelse af ansvar, dataflows og drift. Netop dér skabes langsigtet vedligeholdbarhed.
Delphi-Modernisering i praksis
Hvis en ældre Delphi-applikation fagligt stadig er værdifuld, moderniserer vi ikke blindt. Vi analyserer først, hvordan systemet rent faktisk fungerer, hvilke processer det understøtter, hvor dataflow bryder sammen, og hvilke gamle byrder der hæmmer driften. Deraf opstår et moderniseringsforløb, der er holdbart i dagligdagen.
Typiske moderniseringskomponenter
- Adskillelse af brugergrænseflade, forretningslogik og dataadgang (Layer-3) for planlægbare ændringer
- Stabilisering og oprydning af dataadgangen, hvor historisk opståede adgangsveje skaber problemer
- Indførelse eller udbygning af REST-grænseflader til integrationer og nye frontends
- Trinvis udvidelse med klienter til Windows, macOS og Linux på samme faglige grundlag
Hvad det betyder for jeres virksomhed
- Mindre risiko end ved en ny platform, fordi den faglige substans bevares
- Mere vedligeholdelsesvenlighed og testbarhed gennem klare ansvarsfordelinger
- Integrerbarhed uden at ‚forvride‘ det eksisterende system
Services og servere som en del af samme arkitektur
Mange virksomhedssystemer har i dag ikke kun brug for en klient, men også baggrundstjenester, Windows- eller Linux-services og REST-servere. Derfor planlægger vi disse dele ikke som en efterfølgende påbygning, men som en integreret del af samme arkitektur.
- Klare ansvarsfordelinger: Hvad kører i klienten, hvad i tjenesten, hvad på serveren?
- Sporbarhed: Gøre fejl synlige, logge tilstandsændringer, holde processer målbare
- Konsistens: Samme forretningslogik og samme regler på tværs af klient, service og API
- Drift: Udrulninger, opdateringer og udvidelser uden særtilfælde
Vores princip
Teknologi er for os ikke et trossystem. Det afgørende er, at arkitektur, teamkapacitet, drift og fremtidige udvidelser passer til virksomheden. Ikke den højlydte platform vinder, men den, som gør det muligt at styre risiko, vedligeholdelse og vækst fornuftigt.
Næste skridt
Hvis I vil afklare, om Delphi, C# eller en hybridtilgang er fornuftig for jeres system, fastlægger vi det ud fra det konkrete bestandsgrundlag: mål, integrationer, levetid, team og drift. På denne basis udarbejdes et holdbart forslag i stedet for en arkitektur, der kun findes på slides.
I medbringer: grov systemoversigt, væsentligste processer, integrationspunkter, driftsrammer.
I får: teknologianbefaling, arkitektur-skitse (Layer-3/tjenester), prioriteringer og en pragmatisk fremgangsmodel.
Ofte stillede spørgsmål om teknologi og arkitektur
Hvornår er Delphi fordelagtigt sammenlignet med en komplet ny platform?
Hvis den faglige substans ligger i kernen af applikationen (regler, undtagelsestilfælde, processer) og softwaren kører stabilt i daglig drift, er modernisering ofte mere økonomisk og mindre risikofyldt end et big-bang-nybyggeri. Forudsætningen er en planbar moderniseringsvej (f.eks. Layer-3, rene dataadgangsveje, definerede grænseflader).
Hvornår er en ny platform alligevel det bedre valg?
Hvis centrale krav strukturelt ikke længere kan opfyldes (f.eks. nødvendig skalering, sikkerheds-/compliance-krav, arkitekturbrud i datamodellen) eller hvis det eksisterende system fagligt og teknisk ikke længere kan håndteres. Også i disse tilfælde kan migreringen ofte sikres trinvis via grænseflader og parallelt kørende services.
Hvad betyder Layer-3-arkitektur konkret?
En bevidst adskillelse af brugergrænseflade, forretningslogik og dataadgang. Dermed bliver ændringer planlagte, tests enklere og integrationer renere, fordi ikke hver tilpasning forårsager bivirkninger i hele applikationen.
Hvordan integrerer I eksisterende systemer (ERP, DMS, Schnittstellen, Datenbanken)?
Via klart definerede grænseflader (typisk REST/APIs) og gennemskuelige dataflows. Det er afgørende at afklare ansvar: Hvilken logik ligger i kernesystemet, hvilken i services, og hvilken i eksterne systemer?
Hvordan undgår I, at Services „Sonderfälle“ werden?
Ved at planlægge services og baggrundstjenester som en del af arkitekturen fra starten: fælles domænelogik, konsistente rettigheder, overvågning/logning, definerede deployments og klare fejlbilleder.
Hvilken rolle spiller Windows 11 ARM64?
ARM64 bliver mere relevant, fordi nye enhedsklasser og virksomhedshardware satser på det. Den, der tager platforme i betragtning tidligt, undgår senere særprojekter vedrørende build, deployment, drivere og runtime-afhængigheder.
Hvordan griber I teknologibeslutninger an?
Vi starter med en kort teknisk og faglig vurdering: mål, risici, integrationer, drift og team. Derudfra udleder vi en anbefaling, som både er holdbar i dag og stadig økonomisk bæredygtig om 2–5 år.
Næste trin
Hvis I har et konkret moderniserings-, API- eller platformsspørgsmål, bør vi tidligt afklare den tekniske afgrænsning.
Net-Base vurderer eksisterende systemer, dataveje, grænseflader og målplatforme ikke isoleret, men i sammenhæng med forretningslogik, drift og senere udbygning.
- Eksisterende tilstand, målbillede og tekniske risici vurderes samlet.
- REST, dataadgang, portaler og udrulning bliver ikke udskudt som efterfølgende opgaver.
- De ser tidligt, hvilken vej der er økonomisk og driftsmæssigt bæredygtig.