Teknologier

Vi anvender ikke teknologier efter mode, men efter driftsrealitet, levetid, integrationsbehov og teamkapacitet. Det afgørende er ikke modeordet, men om systemet senere forbliver let at drive, udbygge og overtage.

Hvornår hvilken retning giver mening

Delphi-modernisering i praksis

Når en ældre Delphi-applikation fagligt stadig er værdifuld, moderniserer vi ikke blindt. Vi analyserer først, hvordan systemet faktisk fungerer, hvilke processer det understøtter, hvor dataflow bryder sammen, og hvilke gamle byrder der hæmmer driften. Derudfra opstår en moderniseringsvej, der ikke kun ser ren ud på papiret, men som også er holdbar i dagligdagen.

I mange opbyggede applikationer ligger den egentlige værdi ikke i brugerfladen, men i års domænelogik, specialregler, undtagelser og erfaringsviden. Denne substans kasseres ikke uden videre. Vi adskiller ansvar tydeligt, reorganiserer databasen, afløser gamle adgangsveje, skaber nye REST-grænseflader og supplerer efter behov klienter til Windows, macOS og Linux på samme faglige grundlag. Dermed opstår ikke et brat brud, men en efterprøvbar videreudvikling med klart teknisk snit.

Ofte betyder det også at bringe historisk opbyggede monolitter tilbage i en form, der er vedligeholdelses-, test- og udvidelsesvenlig. Dataadgangen stabiliseres, forretningslogik løsnes fra UI-kode, grænseflader gøres planbare, 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 igen luft til nye krav.

Services og servere som del af samme arkitektur

Mange virksomhedssystemer har 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 påbygning, men som del af samme arkitektur. En service, der først på en eller anden måde kommer til senere, 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 køres tidsstyret i baggrunden, skal det tekniske ansvar være afklaret fra starten. Hvilke dele kører i klienten, hvilke i tjenesten, hvilke på serveren, hvordan bliver fejl synlige, hvordan kan tilstandsændringer efterprøves, hvordan forbliver domænelogikken konsistent? Disse spørgsmål besvarer vi tidligt, så de enkelte byggesten bliver til et robust samlet system.

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

Vores princip

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

Nogle opgaver løser vi bevidst med Delphi, fordi opbygget forretningslogik, performante klienter og multiplatformevne her kan spille deres styrker ud. Andre krav passer bedre til C#, til services, et portal eller en kombination af begge. God arkitektur opstår ikke af mode, men af klarhed: Hvilket ansvar har hvilken systemdel, hvilken levetid kan forventes, hvor stort er teamet, hvor kritisk er driften, og hvilke udvidelser er realistiske de kommende år?

Netop dér begynder professionel softwareudvikling for os. Vi vil ikke blot levere noget, der virker i dag, men skabe et teknisk fundament, der også senere er efterprøveligt, overtagerbart og økonomisk at vedligeholde.

Hyppige spørgsmål om teknologi og arkitektur

Teknologiske beslutninger skal passe til teamet, fagligheden og driften. Netop derfor afklarer vi disse spørgsmål ikke abstrakt, men altid i det konkrete system.