Teknologier

Vi bruger ikke teknologier efter moden, men efter driftsrealitet, levetid, integrationsbehov og team-egnethed. Det afgørende er ikke buzzwordet, men om systemet senere kan drives rent, udbygges 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 reelt arbejder, hvilke processer det bærer, hvor dataflows bryder, og hvilke arvegods der bremser driften. Deraf opstår en moderniseringssti, som ikke kun ser ren ud på papiret, men som også holder i hverdagen.

I mange applikationer, der er vokset frem over tid, ligger den egentlige værdi ikke i overfladen, men i år med faglogik, særregler, undtagelser og erfaringsviden. Den substans kasserer man ikke letsindigt. Vi adskiller ansvarsområderne rent, reorganiserer databasen, udfaser gamle adgangsveje, etablerer nye REST-grænseflader og supplerer efter behov med clients til Windows, macOS og Linux på det samme faglige grundlag. Så opstår der ikke et hårdt brud, men en gennemskuelig videreudvikling med et klart teknisk snit.

Ofte betyder det også at bringe historisk fremvoksede monolitter tilbage i en form, der bliver vedligeholdbar, testbar og udvidbar. Dataadgangen stabiliseres, forretningslogik frigøres fra brugerfladekode, grænseflader bliver planlægbare, og fremtidige udvidelser behøver ikke længere at blive tilkæmpet mod den eksisterende løsning. Målet er ikke kosmetisk modernisering, men et system, der igen giver virksomheden luft til nye krav.

Services og servere som del af den samme arkitektur

Mange virksomhedssystemer har i dag ikke kun brug for en client, men også baggrundstjenester, Windows- eller Linux-services og REST-servere. Netop derfor planlægger vi ikke disse dele som en eftermontering, men som del af den samme arkitektur. En service, der bare på et senere tidspunkt på en eller anden måde kommer til, bliver næsten altid et særtilfælde.

Når data skal behandles distribueret, grænseflader stilles til rådighed, eksportkørsler afvikles, importer overvåges eller opgaver tidsstyres og udføres i baggrunden, skal det tekniske ansvar være afklaret fra starten. Hvilke dele kører i clienten, hvilke i tjenesten, hvilke på serveren, hvordan bliver fejl synlige, hvordan bliver tilstandsændringer eftersporbare, hvordan holdes faglogikken konsistent? De spørgsmål besvarer vi tidligt, så der ud af enkelte byggesten bliver et robust samlet system.

Det er afgørende, især i multiplatform-projekter. En desktop-client på Windows, macOS eller Linux må fagligt ikke mene noget andet end en tilhørende REST-server eller en baggrundstjeneste. Derfor tænker vi altid datamodel, processer, rettigheder, integrationer og drift sammen. Så opstår en arkitektur, hvor clients, services og servere taler det samme sprog.

Vores grundprincip

Teknologi er for os ikke et trosystem. Det afgørende er, at arkitektur, team-egnethed, drift og fremtidige udvidelser passer til virksomheden. Det er ikke den mest højlydte platform, der vinder, men den, hvor risiko, vedligeholdbarhed og vækst kan styres fornuftigt.

Nogle opgaver løser vi bevidst med Delphi, fordi moden forretningslogik, performante clients og multiplatform-egenskaber kan udspille deres styrker dér. Andre krav passer bedre til C#, til services, til en portal eller til en kombination af begge dele. 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 vil realistisk komme i de næste år?

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

Ofte stillede spørgsmål om teknologi og arkitektur

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.