Teknologier

Vi velger ikke teknologi etter motetrender, men etter driftsrealitet, forventet levetid, integrasjonsbehov og teamets kapasitet. Avgjørende er ikke slagordet, men om systemet senere kan driftes, utvides og overtas på en ryddig måte.

Når hvilken retning er hensiktsmessig

Delphi-modernisering i praksis

Når en gammel Delphi-applikasjon fortsatt har faglig verdi, moderniserer vi ikke blindt. Vi analyserer først hvordan systemet faktisk fungerer, hvilke prosesser det bærer, hvor dataflyter svikter og hvilke arvler som hemmer driften. Ut fra dette utarbeider vi en moderniseringsvei som ikke bare ser ryddig ut på papir, men som fungerer i daglig bruk.

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 lettvint. Vi skiller ansvar tydelig, omorganiserer databasen, erstatter gamle tilgangsveier, etablerer nye REST-grensesnitt og supplerer ved behov klienter for Windows, macOS og Linux på samme faglige grunnlag. Resultatet blir ikke et brutalt brudd, men en etterprøvbar videreutvikling med klart teknisk snitt.

Ofte betyr det også å bringe historisk oppbygde monolitter tilbake til en form som er vedlikeholdbar, testbar og utvidbar. Datatilgangen stabiliseres, forretningslogikk løsnes fra UI-kode, grensesnitt blir planlagte og fremtidige utvidelser trenger ikke lenger sloss mot eksisterende løsning. Målet er ikke kosmetisk modernisering, men et system som gir selskapet rom for nye krav.

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. Derfor planlegger vi disse delene ikke som påbygg, men som deler av samme arkitektur. En tjeneste som legges til i etterkant, blir nesten alltid et spesialtilfelle.

Når data skal behandles distribuert, grensesnitt eksponeres, eksport kjøres, import overvåkes eller oppgaver planlegges og kjøres i bakgrunnen, må det tekniske ansvaret være avklart fra starten. Hvilke deler kjører i klienten, hvilke i tjenesten, hvilke på serveren, hvordan blir feil synlige, hvordan spores tilstandsendringer, hvordan holdes faglogikken konsistent? Disse spørsmålene besvarer vi tidlig, slik at enkeltkomponenter blir til et robust helhetssystem.

Dette er spesielt viktig i multiplattformprosjekter. En desktop-klient på Windows, macOS eller Linux må faglig ikke mene noe annet enn en tilhørende REST-server eller en bakgrunnstjeneste. Derfor tenker vi datamodell, prosesser, rettigheter, integrasjoner og drift sammen. 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, teamkapasitet, drift og fremtidige utvidelser passer til virksomheten. Ikke den mest høylytte plattformen 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 der spiller etablert forretningslogikk, ytelsessterke klienter og multiplattformstøtte på sine styrker. Andre krav passer bedre til C#, til tjenester, til en portal eller til en kombinasjon av begge deler. God arkitektur oppstår ikke fra mote, men fra klarhet: Hvilket ansvar har hvilken systemdel, hvilken levetid kan forventes, hvor stort er teamet, hvor kritisk er driften og hvilke utvidelser er realistiske i de kommende årene?

Der begynner for oss profesjonell programvareutvikling. Vi vil ikke bare levere noe som fungerer i dag, men etablere et teknisk fundament som senere fortsatt er etterprøvbart, overtakbart og økonomisk å vedlikeholde.

Vanlige spørsmål om teknologi og arkitektur

Teknologiske valg må passe til teamet, fagområdet og driften. Derfor avklarer vi disse spørsmålene ikke abstrakt, men alltid ut fra det konkrete systemet.