Teknologier

Vi tar ikke i bruk teknologier etter mote, men etter driftsrealitet, levetid, integrasjonsbehov og teamets evne til å forvalte dem. Det avgjørende er ikke buzzordet, men om systemet senere forblir ryddig å drifte, utvidbart og mulig å overta.

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 arbeider, hvilke prosesser det bærer, hvor dataflyter bryter, og hvilke arvetråder som bremser driften. Ut fra dette blir det en moderniseringsbane som ikke bare ser ryddig ut på papiret, men som også tåler hverdagen.

I mange applikasjoner som har vokst over tid, ligger den egentlige verdien ikke i brukerflaten, men i år med faglogikk, særregler, unntak og erfaringskunnskap. Denne substansen kaster man ikke bort lettvint. Vi skiller ansvar tydelig, restrukturerer 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 forståelig videreutvikling med en tydelig teknisk avgrensning.

Ofte betyr det også å få historisk framvokste monolitter tilbake i en form som blir vedlikeholdbar, testbar og utvidbar. Datatilgangen stabiliseres, forretningslogikk frigjøres fra UI-kode, grensesnitt blir planbare, og framtidige utvidelser må ikke lenger kjempes inn mot det eksisterende. Målet er ikke kosmetisk modernisering, men et system som gir virksomheten rom igjen 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-services og REST-servere. Nettopp derfor planlegger vi disse delene ikke som et ettermontert tillegg, men som del av samme arkitektur. En service som bare på et senere tidspunkt «på et eller annet vis» kommer til, blir nesten alltid et særtilfelle.

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

Dette er særlig avgjørende i multiplattform-prosjekter. En desktop-klient på Windows, macOS eller Linux skal faglig sett ikke bety noe annet enn en tilhørende REST-server eller en bakgrunnstjeneste. Derfor tenker 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år grunnsetning

Teknologi er for oss ikke et trossystem. Det avgjørende er at arkitektur, team-egnethet, drift og framtidige 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 etablert forretningslogikk, høytytende klienter og multiplattform-egenskaper kommer til sin rett 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?

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

Vanlige spørsmål om teknologi og arkitektur

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