Spørgsmål og svar
Centrale FAQ i overblik
Hvem har ansvaret for databeskyttelse i virksomheden?
Ansvaret ligger fortsat hos virksomhedsledelsen. Opgaver kan delegeres, men ansvaret for beslutninger, prioriteringer og brugen af egnede leverandører kan ikke.
Hvornår giver en databeskyttelsesrådgiver mening?
Det afhænger af behandlingernes art og omfang, af lovpligtige krav og af det interne organisationsniveau. Også hvor der ikke er en formel pligt, kan ekstern støtte være fornuftig for at forankre databeskyttelse struktureret.
Hvor omfattende skal en ISO-9001-dokumentation være?
Så omfattende som nødvendigt, men så slank som muligt. Dokumentation bør afspejle processer, roller og dokumentation, ikke overhælde organisationen med tekster.
Hvad giver et internt audit, hvis ikke alt endnu er perfekt?
Netop dér er et internt audit værdifuldt. Det viser, hvor regler, dokumentation eller ansvarsforhold stadig er uklare, og hvilke tiltag der først skaber effekt.
Hvad kontrolleres konkret i et internet-audit?
Typisk: tracking- og cookie-logik, formularer, nyhedsbrevsflows, eksterne tjenester, hosting, opdateringsvedligeholdelse, roller, redirects, grundlæggende sikkerhed og den databeskyttelsesretlige vurdering af disse punkter.
Er databeskyttelse kun et juridisk emne?
Nej. Databeskyttelse har altid også organisatoriske og tekniske sider. Uden rene processer og uden teknisk vurdering er juridiske krav svære at omsætte i hverdagen.
Hvor hurtigt kan man etablere et robust niveau?
Det afhænger af udgangspunktet. Som regel kan en første struktureret arbejdsstatus nås markant hurtigere end en fuldstændig slutversion. Det afgørende er at prioritere emnerne fornuftigt.
Hvordan hænger databeskyttelse, QM og website-drift sammen?
De deler det samme grundspørgsmål: Hvilke processer styres hvordan, dokumenteres, kontrolleres og forbedres? Netop derfor kan mange emner bearbejdes bedre samlet end isoleret.
Dataadgang
BDE-udskiftning
BDE er sjældent kun en gammel driver. Den hænger som regel sammen med historisk SQL-logik, databaseantagelser og deployment-stier. Netop derfor besvarer vi emnet her bevidst lidt bredere.
BDE er sjældent kun en enkelt teknisk byggesten. Den hænger sammen med SQL, deployment, drivere, tegnsæt og historiske sideeffekter. Derfor behandler vi udskiftningen som et moderniseringstrin og ikke som et komponentbytte.
Er et skifte til FireDAC eller native drivere muligt uden en komplet ombygning?
Ja, ofte i trin. Det vigtige er at gennemgå SQL, datatyper, transaktioner og særtilfælde grundigt i stedet for blot at erstatte komponenter 1:1.
Hvorfor berører BDE-udskiftningen næsten altid også databasestrukturen?
Fordi man her ofte får syn for gamle tabeller, indekser, tegnsæt og historisk voksede SQL-stier, som af hensyn til stabilitet og performance bør ryddes med op.
Hvad vinder man konkret ved native databaseforbindelse?
Enklere deployment, bedre vedligeholdbarhed, forbindelser der kan kontrolleres, og et markant bedre fundament for services, API’er og fremtidige udvidelser.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og beslægtede emner.
C#
C# til services & portaler
Denne FAQ henvender sig til virksomheder, der ikke vil se C# som et mål i sig selv, men som en stærk byggesten til portaler, API’er, integrationer og serviceorienterede arkitekturdele.
C# er for os især stærk, når webportaler, API’er, tjenester, integrationer og et roligt driftsmæssigt snit står i forgrunden.
Hvornår er C# det bedre valg end Delphi?
Især når et projekt primært består af REST-API’er, portaler, backend-tjenester, integrationer eller cloudnære driftsmodeller.
Bruger I C# også sammen med eksisterende Delphi-systemer?
Ja. Netop denne kombination giver ofte mening: Delphi bærer produktiv faglogik i klienten, mens C# rent supplerer services, portaler og API-lag.
Hvad er typiske risici i C#-projekter?
Ofte bliver der bygget teknisk moderne for hurtigt, uden at roller, faglogik, logging, deployment og reelle driftsforhold bliver skåret rent tidligt nok. Det er præcis dér, vi sætter ind.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og nærliggende emner.
Delphi-team
Delphi-udviklere fra Freiburg
Ved denne forespørgsel handler det sjældent kun om en tilgængelig person. Oftest ligger spørgsmålet bagved, om en partner reelt og robust kan overtage legacy, faglogik, dataadgang og den tekniske retning.
Når man søger efter Delphi-udviklere, handler det sjældent kun om fri kapacitet. Oftest handler det om robust overtagelse af eksisterende løsning, arkitektur, dataadgang og reelt fagligt ansvar.
Hvornår giver en ekstern Delphi-udvikler mening?
Især når der mangler viden om den eksisterende løsning, modernisering er gået i stå, eller en applikation skal videreudvikles fagligt uden at miste sin substans.
Kan I også gå ind i voksede Delphi-applikationer?
Ja. Netop det er et fokusområde: Vi analyserer legacy-kode, database, deployment, særtilfælde og faglige forløb og bygger derpå videre kontrolleret.
Handler det kun om programmering eller også om teknisk retning?
Det handler udtrykkeligt også om retning. God Delphi-udvikling omfatter for os arkitektur, dataadgang, integrationer, REST-services og den reelle drift.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og nærliggende emner.
Modernisering
Delphi-modernisering
Disse svar hjælper især dér, hvor en legacy-applikation fagligt stadig er stærk, men teknisk har samlet for mange flaskehalse til at kunne bære nye krav rent.
Det kritiske punkt ved modernisering er sjældent kun overfladen. Oftest handler det om forretningslogik, data, afhængigheder og en migrationsstrategi, der fungerer i den daglige drift.
Skal en gammel Delphi-applikation udskiftes fuldstændigt?
Nej. Ofte er en kontrolleret ombygning mere fornuftig: forny dataadgangen, afkobl logikken, tilføj services og modernisér brugerflader målrettet.
Hvordan undgår man driftsbrud ved modernisering?
Med klare mellemtrin, rene grænseflader og en migrationssti, hvor gamle og nye dele kontrolleret kan eksistere side om side.
Kan eksisterende forretningslogik senere også flyttes over i services eller portaler?
Ja. Netop derfor løfter vi business-logik ud af UI-nær legacy-kode og bringer den ind i en struktur, som klienter, services og API’er kan bruge i fællesskab.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Teknologi
Delphi multiplatform
Denne FAQ belyser den tekniske side af multiplatform-strategien: kodebase, packaging, systemnærhed, release-processer og spørgsmålet om, hvornår flere klienter reelt bliver økonomisk.
Multiplatform fungerer kun rent, når kodebase, datamodel, platformforskelle og deployment planlægges bevidst. Det er netop dér, den egentlige projektværdi opstår.
Kan den samme applikation virkelig køre på Windows, macOS og Linux?
Ja, hvis brugerflade, forretningslogik, platformsærligheder og release-processer ikke blandes sammen, men struktureres rent.
Hvad er den hyppigste fejl i multiplatform-projekter?
At tænke for sent over filsystem, print, signering, målplatforme, packaging og UI-forskelle. Så bliver multiplatform hurtigt dyrt og inkonsistent.
Kan services og API’er bruge den samme forretningslogik?
Ja. En god arkitektur sikrer, at ikke hver platform udvikler sin egen faglige særvej.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
PostgreSQL
Delphi, PostgreSQL & FireDAC
Den, der bruger PostgreSQL og BDE-Ablösung mit nativer Anbindung, ønsker som regel mere end blot en ny komponent. Bag det ligger ofte spørgsmålet om, hvordan dataadgang, SQL, deployment og eksisterende logik bringes tilbage på en bæredygtig linje.
Med PostgreSQL og BDE-Ablösung mit nativer Anbindung handler det ikke kun om en ny forbindelseskomponent. Oftest ligger der bagved et større skridt mod mere robust SQL, bedre deployment og kontrollerbar datahåndtering.
Hvornår er PostgreSQL et godt valg for Delphi?
Hver gang stabilitet, flerbrugerdrift, klare SQL-stier, åben infrastruktur og ren udvidbarhed for desktop, services eller portaler er vigtige.
Er FireDAC altid den rigtige vej?
FireDAC er ofte en meget god vej, men ikke som et blindt skifte. Det afgørende er SQL-adfærd, datatyper, transaktioner, fejlstier og den konkrete bestand.
Kan BDE-, Paradox- eller gamle SQL-systemer gradvist overgå til PostgreSQL?
Ja. I mange tilfælde er en kontrolleret trinvist overgangsforløb mere økonomisk end et hårdt snit, så længe datamodel og faglogik tænkes rent med.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og relaterede emner.
Delphi REST
Delphi REST-API & REST-server
Denne FAQ besvarer det typiske principspørgsmål, om REST med Delphi kun er et teknisk tillæg eller en seriøs serverstrategi. Afgørende er altid, hvor rent klient, regler, data og drift holdes samlet.
REST med Delphi bliver stærkt, når API’er ikke står løsrevet ved siden af den eksisterende løsning, men bærer rettigheder, forretningslogik, datamodel og drift rent med.
Kan man bygge produktive REST-API’er med Delphi?
Ja. Især når den samme faglogik allerede lever i Delphi-bestanden, er en rent afgrænset REST-server ofte mere økonomisk end en fuldstændig ny parallelverden.
Hvornår kan en REST-server betale sig i forhold til direkte databaseadgang?
Så snart flere klienter, portaler, tjenester eller integrationer kontrolleret skal bruge de samme regler, og direkte SQL-adgang fagligt bliver for risikabel.
Hvordan holder du Delphi-klient og REST konsistente?
Gennem en arkitektur, hvor business-regler ikke forbliver skjult i formularer, men bliver fælles anvendelige for klient, API og baggrundsprocesser.
Læs emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og relaterede emner.
Delphi
Delphi til virksomhedsapplikationer
Her handler det om principspørgsmålet, hvornår Delphi også i dag er en bevidst arkitekturbeslutning, og hvornår andre byggesten giver mening at supplere med eller overtage.
I virksomheder handler det med Delphi sjældent om nostalgi, men om spørgsmålet, hvordan voksende faglogik, desktop-processer og flere målplatforme kan videreføres økonomisk og rent.
Hvorfor satser I stadig bevidst på Delphi i dag?
Fordi Delphi i mange virksomhedsapplikationer tilbyder en stærk kombination af modnet forretningslogik, højtydende desktop-processer, database-nærhed og en videreudvikling, der kan styres.
Er Delphi kun interessant til modernisering af eksisterende løsninger?
Nej. Delphi giver også mening til nye virksomhedsapplikationer, når produktive desktop-arbejdsgange, rapporter, lokal integration og en fælles faglig base for flere platforme er vigtige.
Hvor ligger grænserne for Delphi?
Frem for alt dér, hvor et initiativ primært er portal-, service- eller cloud-centreret. Så kombinerer vi Delphi bevidst med C#, REST-servere eller web-komponenter i stedet for at tvinge alt ind i ét værktøj.
Læs mere om emnet i dybden
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og relaterede emner.
Support
Delphi-vedligeholdelse & support
Vedligeholdelse lyder ofte mindre, end det er. I praksis handler det om stabile releases, synlige risici, teknisk orden og spørgsmålet om, hvordan et modnet system igen kan videreudvikles roligt.
Vedligeholdelse er i modnede Delphi-systemer mere end bugfixing. Det vedrører release-sikkerhed, datakonsistens, teknisk gæld og spørgsmålet om, hvordan nye krav roligt kan passe ind i den eksisterende løsning.
Hvad hører til en god Delphi-vedligeholdelse?
Fejlanalyse, videreudvikling, databasepleje, release-ledsagelse, teknisk dokumentation og en arkitektur, der ikke gør nye krav dyrere hver gang.
Kan support også starte uden en komplet ombygning?
Ja. Ofte begynder den med stabilisering, synliggørelse af risici og en prioriteret liste over tekniske og faglige forbedringer.
Hvordan reducerer I afhængighed af enkeltviden?
Ved at dokumentere datapath, komponenter, build-trin og kritisk forretningslogik struktureret og gøre implicit viden til gennemskuelig systemlogik igen.
Læs mere om emnet i dybden
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og relaterede emner.
Arkitektur
Layer-3-arkitektur
Layer-3 bliver ofte forklaret teoretisk. I praksis afgør denne struktur dog meget direkte, om nye clients, services, tests og udvidelser kan koble sig roligt på, eller om de løber dyrt fra hinanden.
Layer-3 er ikke et lærebogsord, men et meget praktisk svar på modnede monolitter, modstridende udvidelser og dyre koblinger i hverdagen.
Hvorfor er Layer-3 så vigtigt for virksomhedsapplikationer?
Fordi det først er den rene adskillelse af UI, forretningslogik og dataadgang, der sikrer, at udvidelser, tests, services og nye platforme ikke strander direkte på monolitten.
Er Layer-3 kun meningsfuld for store projekter?
Nej. Især mellemstore systemer har stor gavn af det, fordi senere krav kan kobles på langt mere kontrolleret.
Hvad er den mest almindelige fejl ved Layer-3?
At man kun tegner lag formelt, men fortsat gemmer de egentlige regler i UI-kode eller direkte i særlige SQL-stier. Så findes opbygningen kun på slides, ikke i systemet.
Læs emnet i dybden
Hvis du vil skifte fra denne FAQ til den mere dybdegående faglige side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og beslægtede emner.
Ydelser
Overblik over ydelser
På ydelsessiden opstår typisk de bredeste opfølgende spørgsmål: Hvad overtager vi konkret, hvor langt rækker vores tekniske ansvar, og hvordan griber modernisering, integrationer, drift og videreudvikling ind i hinanden?
Især ved voksede applikationer dukker ofte de samme faglige og tekniske spørgsmål op. Disse punkter afklarer vi tidligt, før et initiativ bliver til et diffust storprojekt.
Overtager I også eksisterende Delphi-systemer?
Ja. Vi går regelmæssigt ind i voksede Delphi-applikationer, analyserer eksisterende løsning, dataadgang, arkitektur og specialtilfælde og bygger videre derfra på en kontrolleret måde.
Kan REST-servere, portaler og desktop-klienter opstå ud fra ét initiativ?
Ja. Netop ved virksomhedsapplikationer planlægger vi disse byggesten bevidst samlet, så den samme forretningslogik ikke splitter op i flere særskilte løsninger.
Er en BDE-udfasning også mulig uden fuldstændig udskiftning?
I mange tilfælde ja. Vi frigør dataadgang, SQL og deployment trinvis fra den gamle struktur og opbygger en native, vedligeholdbar tilkobling.
Følger I også drift og videreudvikling?
Ja. Releaseprocesser, hosting, fejlanalyse, databasevedligeholdelse og senere udvidelser er en del af vores arbejdsbillede.
Læs emnet i dybden
Hvis du vil skifte fra denne FAQ til den mere dybdegående faglige side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og beslægtede emner.
Ydelse
Multiplatform med Delphi
Virksomheder spørger her typisk ikke kun til en teknisk mulighed, men til en robust strategi: Hvilke dele forbliver fælles, hvad skal håndteres platformspecifikt, og hvordan undgår man, at det bliver et dyrt parallelbyggeri?
Multiplatform bliver først værdifuldt, når den samme faglogik forbliver kontrolleret samlet på tværs af flere målsystemer, og platformssærligheder gøres synlige tidligt.
Kan man med Delphi ud over Windows ogsaa taenke macOS, Linux, iOS og Android ind?
Ja. Afhaengigt af projektmaalet planlaegger vi desktop-maal, mobile brugerflader og servernaere komponenter ud fra en faelles faglig linje, i stedet for at bygge hvert platformspor fagligt fra bunden.
Hvordan undgaar I, at multiplatform-projekter fagligt driver fra hinanden?
Gennem en faelles kode- og arkitekturstrategi: Forretningsregler, datamodel og processer forbliver centrale, mens platformspecifikke forskelle bevidst kapsles.
Er mobile udbygningstrin ogsaa stadig mulige senere?
Ja. Naar arkitektur, services og snitflader er forberedt rent, kan iOS- eller Android-maal tilkobles senere med markant bedre kontrol.
Laes emnet i detaljer
Hvis du vil gaa fra denne FAQ videre til den mere dybdegaaende fagside, finder du der den stoerre sammenhaeng med arkitektur, eksempler, beslutningsgrundlag og tilgraensende emner.
Projekter
Projektbilleder og referencemoenstre
Den, der ser paa projektsiden, vil som regel forstaa, hvilken type initiativer vi faktisk kan baere: engangsvaerktoejer eller mere langlivede systemer med drift, rettighedskoncept, versioner, integrationer og reel videreudvikling.
Mange initiativer lyder i starten forskellige og har alligevel faelles moenstre: voksede forretningslogikker, integrationer, rettigheder, versioner, driftsforhold og langsigtet udvidbarhed.
Arbejder I mest paa engangsvaerktoejer eller paa systemer, der baerer over laengere tid?
Tyngdepunktet ligger paa systemer med driftstid, ansvar og videreudvikling: virksomhedsapplikationer, platforme, services, portaler og produktlogik.
Kan eksisterende produkter eller interne systemer moderniseres parallelt?
Ja. Isser ved laengere tid voksede systemer planlaegger vi ofte en trinvis videreudvikling, saa drift og modernisering passer sammen.
Er hosting og teknisk drift en del af jeres arbejde?
Ja. Release, hosting, monitoring og driftsansvar indgaar i vores projektplanlaegning, saa den faerdige loesning ikke kun udvikles, men ogsaa kan drives baeredygtigt.
Laes emnet i detaljer
Hvis du vil gaa fra denne FAQ videre til den mere dybdegaaende fagside, finder du der den stoerre sammenhaeng med arkitektur, eksempler, beslutningsgrundlag og tilgraensende emner.
Serverarkitektur
REST-server & services
Hvis API’er og tjenester kun lyder teknisk moderne, men fagligt ikke er skarpt afgraenset, bliver de hurtigt et problem. Denne FAQ indplacerer netop disse beslutninger.
Mange systemer mislykkes ikke paa grund af API-ideen, men fordi serverlogik senere improviseres og haegtes paa en eksisterende desktop-base. Vi planlaegger disse dele bevidst samlet.
Hvornar har en virksomhedsapplikation derudover brug for en REST-server?
Så snart flere klienter, portaler, mobile adgange, eksterne integrationer eller frakoblede processer kontrolleret skal bruge den samme forretningslogik.
Understøtter I også Windows- og Linux-services?
Ja. Baggrundsprocesser, tidsstyring, synkronisering, eksport, licenstjenester og tekniske følgeprocesser hører til vores typiske opgaver.
Hvordan bevares den faglige konsistens mellem klient, REST og service?
Gennem en arkitektur, hvor business-regler ikke er gemt i enkelte brugerflader, men forbliver fælles anvendelige og sporbare.
Læs mere om emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Ydelse
Services, REST-server & portaler
Netop her skal rettigheder, dataflows, logging og faglige regler hænge sammen. Derfor behandler vi ikke emnet som en web-tilbygning, men som en ordnet udbygning af den samme applikationslinje.
Portaler, REST-API’er og tjenester fungerer kun godt, hvis de fagligt ikke står ved siden af kerne-systemet, men rent viderefører den samme data- og rollelogik.
Udvikler I både REST-servere og Windows- og Linux-services?
Ja. Baggrundstjenester, API’er, import, eksport, portaler og teknisk driftslogik hører til vores tilbagevendende opgavebilleder.
Hvornår har en virksomhedsapplikation derudover brug for et portal?
Altid når kunder, partnere eller interne roller kontrolleret skal have adgang til de samme processer, uden at man duplicerer faglige regler i adskilte brugerflader.
Hvordan forbliver rettigheder, logging og processer konsistente mellem klient og server?
Ved at vi ikke skjuler fagregler i enkelte endpoints eller UI’er, men etablerer en klar faglig midte, som klient, portal og service kan bruge sammen.
Læs mere om emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og tilstødende emner.
Teknologier
Teknologi og arkitektur i overblik
Denne FAQ samler de typiske orienteringsspørgsmål om teknologivalg: Hvornår er Delphi stærk, hvornår er C# den bedre byggeklods, og hvordan samler en ren arkitektur flere platforme, services og klienter kontrolleret?
Teknologiske beslutninger skal passe til teamet, fagligheden og driften. Netop derfor afklarer vi ikke disse spørgsmål abstrakt, men altid ud fra det konkrete system.
Hvornår er Delphi fornuftig i forhold til en komplet ny platform?
Altid når modnet domænelogik, højtydende desktop-processer og multiplatform-mål skal bæres videre på en økonomisk fornuftig måde, i stedet for at erstatte substans letsindigt.
Hvornår bruger I derudover C#?
Især til portaler, web-backends, REST-services, integrationer og serviceorienterede arkitekturdele, der kan kobles godt sammen med eksisterende desktop-systemer.
Hvor vigtig er Layer-3 i praksis?
Meget. Først den rene adskillelse af UI, forretningslogik og dataadgang gør modernisering, test, services og fremtidige platforms-skift håndterbare.
Tænker I nye platforme som Windows 11 ARM64 ind tidligt?
Ja. Ny mål-hardware og deployment-stier vurderes tidligt, så det ikke senere bliver til kostbare særprojekter.
Læs emnet i dybden
Hvis du vil skifte fra denne FAQ til den mere dybdegående fag-side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Virksomhedssoftware
Individuel virksomhedssoftware & Layer-3
Disse spørgsmål dukker typisk op, når standardsoftware fagligt ikke længere rækker, og en virksomhed vil vide, om et individuelt system virkelig kan bygges økonomisk, vedligeholdbart og udbyggeligt.
Netop ved individuel virksomhedssoftware handler det ikke kun om enkelte skærmbilleder, men om roller, data, kontrolspor og en arkitektur, der også senere forbliver fleksibel.
Er individuel virksomhedssoftware kun relevant for meget store virksomheder?
Nej. Den betaler sig altid, når standardsoftware kun kan afbilde processer via omveje, mediebrud eller dyre særregler, og den egentlige værdi ligger i ren domænelogik.
Hvorfor fremhæver I Layer-3 så kraftigt ved virksomhedsapplikationer?
Fordi det først er adskillelsen af UI, forretningslogik og dataadgang, der sikrer, at rapportering, nye clients, services og fremtidige udvidelser forbliver økonomisk styrbare.
Kan I også gå ind i modne eksisterende processer?
Ja. Netop dér bliver vores arbejde stærkt, fordi vi først gør fagprocesser, eksisterende data og legacy-logik læsbare og derfra udvikler en bæredygtig målarkitektur.
Læs emnet i dybden
Hvis du vil skifte fra denne FAQ til den mere dybdegående fag-side, finder du der den større sammenhæng med arkitektur, eksempler, beslutningsgrunde og tilstødende emner.
Se individuel virksomhedssoftware & Layer-3-applikationer i detaljer
Platform
Windows 11 ARM64
ARM64 påvirker mange applikationer tidligere end forventet. Denne FAQ besvarer de typiske spørgsmål om afhængigheder, tests, installere og den økonomiske vurdering af ny mål-hardware.
ARM64 er ikke længere et eksotisk sideemne, men en reel målplatform. Den der tænker det ind tidligt, undgår senere tekniske blindgyder i deployment og ved native afhængigheder.
Hvorfor bør Windows 11 ARM64 allerede tages i betragtning i dag?
Fordi nye hardwareklasser og mobile arbejdspladser i stigende grad satser på det, og teknisk efterarbejde senere bliver markant dyrere end en tidlig arkitekturbeslutning.
Hvad er særligt kritisk ved Delphi og native afhængigheder på ARM64?
Især eksterne biblioteker, databasedrivere, installere, setup-processer og tests på ægte målhardware skal kontrolleres tidligt.
Skal der skabes et helt selvstændigt produkt til ARM64?
Ikke nødvendigvis. Ofte er det nok at forberede build- og deployment-stierne rent og afkoble kritiske native afhængigheder i god tid.
Læs mere om emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og nært beslægtede emner.
Tjenester
Windows- & Linux-services
Når det gælder services, handler det sjældent kun om en kørende proces. Vigtigere er logging, observerbarhed, genstart, datakonsistens og det faglige spørgsmål om, hvilke dele der hører til i baggrunden, og hvilke der ikke gør.
Baggrundstjenester er ofte den usynlige kerne i et system. De skal køre roligt, behandle tilstandsskift rent og passe robust ind i drift med logging, restart og monitoring.
Hvornår har en virksomhedsapplikation derudover brug for Windows- eller Linux-services?
Altid når importer, eksporter, tidsstyring, synkronisering, licenslogik eller integrationer ikke skal være bundet til et logget ind desktop-miljø.
Kan services og REST komme fra den samme arkitektur?
Ja. Det giver ofte mening, fordi forretningslogik, datamodel og logging dermed ikke glider fra hinanden i flere tekniske øer.
Hvad er særligt vigtigt for services i produktion?
Klar fejlhåndtering, observerbare tilstande, restart-sikkerhed, logging, deployment og en fagligt konsistent behandling frem for stille baggrundsmagi.
Læs mere om emnet i detaljer
Hvis du vil skifte fra denne FAQ til den mere dybdegående fagside, finder du dér den større sammenhæng med arkitektur, eksempler, beslutningsgrundlag og nært beslægtede emner.