Teknologier

Vi anvender teknologier ikke efter mode, men efter driftsrealitet, levetid, integrationsbehov og teamets evne til at håndtere dem. Det afgørende er ikke slagordet, men om systemet senere forbliver let at drive, udbygge og overtage.

Hvornår hvilken retning er fornuftig

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 understøtter, hvor dataflows bryder sammen, og hvilke restbyrder der hæmmer driften. Deraf opstår en moderniseringssti, der ikke kun ser ren ud på papiret, men som også er bæredygtig i daglig drift.

I mange ældre applikationer ligger den egentlige værdi ikke i brugerfladen, men i års faglogik, særlige regler, undtagelser og erfaringsviden. Den substans kasserer man ikke let. Vi adskiller ansvar konsekvent, omstrukturerer databasen, afløser gamle adgangsveje, opretter nye REST-schnittstellen og supplerer efter behov klienter for Windows, macOS og Linux på samme faglige grundlag. Dermed opstår der ikke et brat brud, men en efterviselig videreudvikling med klart teknisk snit.

Ofte betyder det også, at historisk opståede monolitter bringes tilbage i en form, der er vedligeholdelsesvenlig, testbar og udvidelsesbar. Dataadgangen stabiliseres, forretningslogik løsnes fra brugerfladekode, grænseflader bliver planlæggelige, og fremtidige udvidelser behøver ikke længere kæmpes igennem på bekostning af det eksisterende. Målet er ikke kosmetisk modernisering, men et system, der igen giver virksomheden luft til nye krav.

Services og servere som del af samme arkitektur

Mange virksomhedssystemer har i dag ikke kun brug for en klient, men også baggrundstjenester, Windows- eller Linux-tjenester og REST-servere. Netop derfor planlægger vi disse dele ikke som efterfølgende påbygninger, men som en del af samme arkitektur. En tjeneste, der først senere på en eller anden måde tilføjes, bliver næsten altid et specialtilfælde.

Hvis data skal behandles distribueret, grænseflader stilles til rådighed, eksporter køres, importer overvåges eller opgaver planlægges og udføres i baggrunden, må det tekniske ansvar være afklaret fra begyndelsen. Hvilke dele kører i klienten, hvilke i tjenesten, hvilke på serveren, hvordan synliggøres fejl, hvordan kan tilstandsændringer følges, hvordan forbliver faglogikken konsistent? Disse spørgsmål besvarer vi tidligt, så enkeltkomponenter bliver til et belastbart samlet system.

Det er især afgørende i multiplatformprojekter. 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 en arkitektur, hvor klienter, tjenester og servere taler samme sprog.

Vores grundsætning

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

Visse opgaver løser vi bevidst med Delphi, fordi der den eksisterende forretningslogik, performante klienter og multiplatformkapabilitet kommer bedst til deres ret. Andre krav passer bedre til C#, til tjenester, 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 forventet levetid, hvor stort er teamet, hvor kritisk er driften, og hvilke udvidelser er realistiske i de kommende år?

Netop dér begynder professionel softwareudvikling for os. Vi ønsker ikke blot at levere noget, der fungerer i dag, men at skabe et teknisk grundlag, som også senere kan eftervises, overtages og drives økonomisk bæredygtigt.

Ofte stillede spørgsmål om teknologi og arkitektur

Teknologiske beslutninger skal passe til teamet, fagområdet og driften. Derfor afklarer vi disse spørgsmål ikke abstrakt, men altid ud fra det konkrete system.