Teknologier

Vi tar ikke i bruk teknologier etter mote, men ut fra driftsrealitet, levetid, integrasjonsbehov og teamets kompetanse. Det avgjørende er ikke buzzordet, men om systemet senere forblir rent driftbart, utvidbart og overtakbart.

Når hvilken retning er fornuftig

Delphi-modernisering i praksis

Når en gammel Delphi-applikasjon fortsatt er faglig verdifull, moderniserer vi ikke blindt. Vi analyserer først hvordan systemet faktisk fungerer, hvilke prosesser det bærer, hvor dataflyt bryter, og hvilke arvetråder som bremser driften. Resultatet er en moderniseringssti som ikke bare ser ryddig ut på papiret, men forblir bærekraftig i hverdagen.

I mange modne applikasjoner ligger den egentlige verdien ikke i brukergrensesnittet, men i år med faglogikk, særregler, unntak og erfaringskunnskap. Denne substansen kaster man ikke bort lettvint. Vi skiller ansvarsområder tydelig, omorganiserer databasen, avvikler gamle tilgangsveier, etablerer nye REST-grensesnitt og kompletterer ved behov klienter for Windows, macOS og Linux på samme faglige grunnlag. Slik oppstår det ikke et hardt brudd, men en etterprøvbar videreutvikling med tydelig teknisk avgrensning.

Ofte betyr det også å bringe historisk fremvokste monolitter tilbake i en form som blir vedlikeholdbar, testbar og utvidbar. Datatilgangen stabiliseres, forretningslogikk løsnes fra UI-kode, grensesnitt blir planbare, og fremtidige utvidelser trenger ikke lenger å kjempes gjennom mot eksisterende løsning. Målet er ikke kosmetisk modernisering, men et system som gir virksomheten handlingsrom for nye krav igjen.

Tjenester og servere som del av samme arkitektur

Mange virksomhetssystemer trenger i dag ikke bare en klient, men også bakgrunnstjenester, Windows- eller Linux-tjenester og REST-servere. Nettopp derfor planlegger vi disse delene ikke som et ettermontert påbygg, men som del av samme arkitektur. En tjeneste som først senere på en eller annen måte kommer til, blir nesten alltid et særtilfelle.

Når data skal behandles distribuert, grensesnitt tilbys, eksportjobber kjøres, importer overvåkes eller oppgaver utføres tidsstyrt i bakgrunnen, må det tekniske ansvaret avklares fra start. Hvilke deler kjører i klienten, hvilke i tjenesten, hvilke på serveren, hvordan blir feil synlige, hvordan blir tilstandsendringer sporbare, hvordan holdes faglogikken konsistent? Disse spørsmålene avklarer vi tidlig, slik at enkeltkomponenter blir til et robust helhetssystem.

Dette er avgjørende spesielt i multiplattform-prosjekter. En desktop-klient på Windows, macOS eller Linux må faglig sett ikke mene noe annet enn en tilhørende REST-server eller en bakgrunnstjeneste. Derfor ser vi alltid datamodell, prosesser, rettigheter, integrasjoner og drift i sammenheng. Slik oppstår en arkitektur der klienter, tjenester og servere snakker samme språk.

Vårt prinsipp

Teknologi er for oss ikke et trossystem. Det avgjørende er at arkitektur, teamets arbeidsform, drift og fremtidige utvidelser passer virksomheten. Det er ikke den mest høylytte plattformen som vinner, men den som gjør det mulig å styre risiko, vedlikeholdbarhet og vekst på en fornuftig måte.

Noen oppgaver løser vi bevisst med Delphi, fordi moden forretningslogikk, ytelsessterke klienter og multiplattform-egenskaper spiller ut sine styrker der. Andre krav passer bedre til C#, til tjenester, til en portal eller til en kombinasjon av begge. God arkitektur oppstår ikke av mote, men av klarhet: Hvilket ansvar har hvilken systemdel, hvilken levetid kan forventes, hvor stort er teamet, hvor kritisk er driften, og hvilke utvidelser vil realistisk komme de neste årene?

Det er nettopp der profesjonell programvareutvikling starter for oss. Vi vil ikke bare levere noe som fungerer i dag, men etablere et teknisk grunnlag som også senere er forståelig, overtakbart og økonomisk vedlikeholdbart.

Vanlige spørsmål om teknologi og arkitektur

Teknologiske valg må passe til teamet, fagområdet og driften. Nettopp derfor avklarer vi ikke disse spørsmålene abstrakt, men alltid med utgangspunkt i det konkrete systemet.