Teknologiprofil
Oversigt over vores tekniske fundament
Delphi. C#. SQL. APIs.
Teknologier, der passer til forretningslogik, data og drift.
Teknologi i billeder
Technologieentscheidungen werden bei uns über Zielarchitektur sichtbar.
Nicht das Schlagwort ist entscheidend, sondern wie Plattform, Services und Schichten später zusammenarbeiten. Diese Skizzen machen die Richtung greifbar.
Shared Core für mehrere Ziele
Multiplatform er hensigtsmæssigt, når flere klienter anvender den samme forretningslogik og ikke divergerer.
* Verwendete Plattformnamen und Marken gehören den jeweiligen Rechteinhabern.
C# og tjenester som supplement
Portale, REST und Dienste ergänzen den Kern dort, wo Web- und Betriebslogik stärker werden.
Zielhardware früh mitdenken
Plattformwechsel wie ARM64 gehören in Architektur und Deployment, bevor sie zum Supportproblem werden.
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ächster Schritt
Wenn Sie eine konkrete Modernisierung, API- oder Plattformfrage haben, sollten wir den technischen Zuschnitt früh sauber einordnen.
Net-Base bewertet bestehende Systeme, Datenpfade, Schnittstellen und Zielplattformen nicht isoliert, sondern im Zusammenhang von Fachlogik, Betrieb und späterem Ausbau.
- Eksisterende tilstand, målbillede og tekniske risici vurderes samlet.
- REST, Datenzugriff, Portale und Rollout werden nicht als Spätfolgen verschoben.
- Sie sehen früh, welcher Weg wirtschaftlich und betrieblich tragfähig ist.