Teknologier

Vi anvender teknologier ikke efter mode, men ud fra driftsmæssige realiteter, levetid, integrationsbehov og teamets kompetencer. Det afgørende er ikke modeordet, men om systemet efterfølgende kan drives stabilt, udvides og overtages.

Hvornår hvilken retning giver mening

Delphi-modernisering i praksis

Når en gammel Delphi-applikation fagligt stadig er værdifuld, moderniserer vi ikke blindt. Vi analyserer først, hvordan systemet faktisk fungerer, hvilke processer det bærer, hvor datagennemløb bryder sammen, og hvilke gamle byrder der hæmmer driften. Ud fra det opstår en moderniseringssti, der ikke blot ser ordentlig ud på papiret, men som i hverdagen forbliver holdbar.

I mange ældre, opbyggede applikationer ligger den egentlige værdi ikke i brugerfladen, men i årtiers faglogik, særlige regler, undtagelser og erfaringsviden. Denne substans kasserer man ikke letfærdigt. Vi adskiller ansvar konsekvent, reorganiserer databasen, udskifter gamle adgangsveje, opretter nye REST-grænseflader og supplerer om nødvendigt klienter til Windows, macOS og Linux på samme faglige grundlag. På den måde opstår der ikke et brat brud, men en gennemskuelig videreudvikling med klart teknisk snit.

Ofte betyder det også at omdanne historisk opståede monolitter til en form, der er vedligeholdelsesvenlig, testbar og udvidelsesbar. Dataadgangen stabiliseres, forretningslogik løsnes fra brugerfladekode, grænseflader kan planlægges, og fremtidige udvidelser behøver ikke længere kæmpes igennem mod det eksisterende. Målet er ikke kosmetisk modernisering, men et system, der giver virksomheden rum til nye krav.

Services und Server als Teil derselben Architektur

Mange virksomhedssystemer behøver i dag ikke kun en klient, men også baggrundstjenester, Windows- eller Linux-services og REST-servere. Netop derfor planlægger vi disse dele ikke som en efterfølgende tilføjelse, men som en del af den samme arkitektur. En service, som først kommer til bagefter, bliver næsten altid et særtilfælde.

Hvis data skal behandles distribueret, grænseflader stilles til rådighed, eksporter køres, importer overvåges eller opgaver tidsstyret køres i baggrunden, må det tekniske ansvar afklares fra starten. Hvilke dele kører i klienten, hvilke i tjenesten, hvilke på serveren, hvordan bliver fejl synlige, hvordan bliver tilstandsændringer sporbare, og hvordan forbliver faglogikken konsistent? Disse spørgsmål besvarer vi tidligt, så enkeltdele bliver til et robust samlet system.

Det er særligt afgørende i multiplatformsprojekter. En desktop-klient på Windows, macOS eller Linux må fagligt ikke betyde noget andet end en ledsagende REST-server eller en baggrundstjeneste. Derfor tænker vi datamodel, processer, rettigheder, integrationer og drift altid sammen. Så opstår der en arkitektur, hvor klienter, services og servere taler samme sprog.

Unser Grundsatz

Teknologi er for os ikke et trosgrundlag. Det afgørende er, at arkitektur, teamkapacitet, drift og fremtidige udvidelser passer til virksomheden. Ikke den mest højlydte platform vinder, men den, med hvilken risiko, vedligeholdelse og vækst kan styres fornuftigt.

Visse opgaver løser vi bevidst med Delphi, fordi den etablerede forretningslogik, performante klienter og multiplatformsevne kommer til deres ret dér. Andre krav passer bedre til C#, til services, et portal eller til en kombination af begge dele. God arkitektur opstår ikke af mode, men af klarhed: Hvilket ansvar har hvilken systemdel, hvilken forventet levetid, hvor stort er teamet, hvor kritisk er driften, og hvilke udvidelser vil realistisk komme i de kommende år?

Lige dér begynder for os professionel softwareudvikling. Vi vil ikke blot levere noget, der fungerer i dag, men skabe et teknisk fundament, som også senere er gennemskueligt, overtageligt og økonomisk holdbart at vedligeholde.

Ofte stillede spørgsmål om teknologi og arkitektur

Teknologiske beslutninger skal passe til teamet, til fagdomænet og til driften. Netop derfor afklarer vi disse spørgsmål ikke abstrakt, men altid ud fra det konkrete system.