Teknologiar

Vi brukar ikkje teknologiar etter moten, men etter driftsrealitetar, levetid, integrasjonsbehov og teamkapasitet. Avgjerande er ikkje slagordet, men om systemet seinare blir lett å drifte, utvidbart og overtakbart.

Når kva retning er fornuftig

Delphi-modernisering i praksis

Når ein gammal Delphi-applikasjon framleis har fagleg verdi, moderniserer vi ikkje blindt. Vi analyserer først korleis systemet faktisk fungerer, kva prosessar det støttar, kvar dataflytar bryt saman og kva gamle restar som bremsar drifta. Ut frå dette kjem ein moderniseringsveg som ikkje berre ser ryddig ut på papiret, men som held i kvardagen.

I mange oppbygde applikasjonar ligg den reelle verdien ikkje i brukargrensesnittet, men i år med faglogikk, spesialreglar, unntak og erfaringskunnskap. Denne substansen kastar ein ikkje lett på dynga. Vi skil ansvar tydeleg, reordnar databasen, byter ut gamle åtkomstvegar, opprettar nye REST-grensesnitt og kompletterer ved behov klientar for Windows, macOS og Linux på same faglege grunnlag. Slik oppstår ikkje eit brutalt brot, men ei etterprøvbar vidareutvikling med klar teknisk avgrensing.

Ofte betyr det òg å bringe historisk oppvaksne monolittar tilbake i ei form som er vedlikehaldbar, testbar og utbyggbar. Dataåtkomsten blir stabilisert, forretningslogikk blir løyst ut av brukargrensesnittkode, grensesnitt blir planbare og framtidige utvidingar treng ikkje lenger å bli kjempa fram mot eksisterande system. Målet er ikkje kosmetisk modernisering, men eit system som gir føretaket attende handlingsrom for nye krav.

Tenester og servere som del av same arkitektur

Mange føretakssystem treng i dag ikkje berre ein klient, men òg bakgrunnstenester, Windows- eller Linux-tenester og REST-server. Difor planlegg vi desse delane ikkje som eit seinare påbygg, men som del av same arkitektur. Ein teneste som først blir lagt til seinare, blir nesten alltid eit særtilfelle.

Når data skal behandlast distribuert, grensesnitt leverast, eksportar køyrast, importar overvaksast eller oppgåver køyrast tidsstyrt i bakgrunnen, må det tekniske ansvaret vere avklart frå start. Kva delar køyrer i klienten, kva i tenesta, kva på serveren, korleis blir feil synlege, korleis kan tilstandsendreingar ettersporast, korleis held faglogikken seg konsistent? Desse spørsmåla svarar vi tidleg på, slik at enkeltkomponentar blir til eit robust heilskapssystem.

Det er særleg avgjerande i multiplattformprosjekt. Ein desktop-klient på Windows, macOS eller Linux må fagleg ikkje meine noko anna enn ein følgjande REST-server eller ein bakgrunnsteneste. Difor tenkjer vi datamodell, prosessar, rettigheitshandtering, integrasjonar og drift alltid i lag. Slik oppstår ei arkitektur der klientar, tenester og servere snakkar same språk.

Vårt prinsipp

Teknologi er for oss ikkje eit spørsmål om tru. Avgjerande er at arkitektur, teamkompetanse, drift og framtidige utvidingar passar for føretaket. Det er ikkje den høgaste stemmen som vinn, men den plattforma som gjev moglegheit til å styre risiko, vedlikehaldsvennlegheit og vekst på ein fornuftig måte.

Ein del oppgåver løyser vi medvite med Delphi, fordi der opparbeidd forretningslogikk, ytingssterke klientar og multiplattformkapasitet spelar sine styrkar. Andre krav passar betre til C#, til tenester, eit portal eller ei kombinasjon av begge delar. God arkitektur oppstår ikkje av mote, men av klarleik: Kva ansvar har kvar systemdel, kva levetid kan ein vente, kor stort er teamet, kor kritisk er drifta og kva utvidingar kjem realistisk dei næraste åra?

Nett der byrjar for oss profesjonell programvareutvikling. Vi vil ikkje berre levere noko som fungerer i dag, men skape eit teknisk grunnlag som seinare framleis er etterprøvbart, kan overtakast og er økonomisk forsvarleg å vedlikehalde.

Vanlege spørsmål om teknologi og arkitektur

Teknologiske val må passe til teamet, faglegheit og drift. Difor avklarer vi desse spørsmåla ikkje abstrakt, men alltid i det konkrete systemet.