Teknologier

Vi använder inte tekniker efter trend, utan efter driftsrealitet, livslängd, integrationsbehov och teamförmåga. Avgörande är inte modeordet, utan om systemet senare förblir rent driftbart, utbyggbart och överlämningsbart.

När vilken inriktning är meningsfull

Delphi-modernisering i praktiken

När en äldre Delphi-applikation fortfarande är värdefull ur verksamhetsperspektiv moderniserar vi inte blint. Vi analyserar först hur systemet faktiskt fungerar, vilka processer det bär, var dataflöden bryts och vilka arvslaster som bromsar driften. Därifrån tar vi fram en moderniseringsväg som inte bara ser ren ut på papper, utan håller i vardagen.

I många mogna applikationer ligger det egentliga värdet inte i gränssnittet, utan i år av facklogik, specialregler, undantag och erfarenhetskunskap. Den substansen kastar man inte bort lättvindigt. Vi separerar ansvar tydligt, strukturerar om databasen, fasar ut gamla åtkomstvägar, skapar nya REST-gränssnitt och kompletterar vid behov med klienter för Windows, macOS och Linux på samma fackliga grund. På så sätt uppstår inget hårt avbrott, utan en spårbar vidareutveckling med en tydlig teknisk inriktning.

Ofta innebär det också att historiskt framvuxna monoliter förs tillbaka till en form som blir underhållbar, testbar och utbyggbar. Dataåtkomsten stabiliseras, businesslogik frigörs från gränssnittskod, gränssnitt blir planeringsbara och framtida utbyggnader behöver inte längre drivas igenom i motvind mot befintligheten. Målet är inte kosmetisk modernisering, utan ett system som ger verksamheten luft för nya krav igen.

Tjänster och servrar som del av samma arkitektur

Många företagsystem behöver idag inte bara en klient, utan även bakgrundstjänster, Windows- eller Linux-tjänster och REST-servrar. Just därför planerar vi dessa delar inte som en efterhandsmontering, utan som del av samma arkitektur. En tjänst som bara senare på något sätt läggs till blir nästan alltid ett specialfall.

När data ska bearbetas distribuerat, gränssnitt tillhandahållas, exporter köras, importer övervakas eller uppgifter tidsstyrt utföras i bakgrunden, måste det tekniska ansvaret vara tydligt från början. Vilka delar kör i klienten, vilka i tjänsten, vilka på servern, hur blir fel synliga, hur blir tillståndsändringar spårbara, hur hålls facklogiken konsekvent? Dessa frågor besvarar vi tidigt, så att enskilda byggstenar blir ett robust helhetssystem.

Det är särskilt avgörande i multiplattformsprojekt. En desktopklient på Windows, macOS eller Linux får fackligt inte mena något annat än en tillhörande REST-server eller en bakgrundstjänst. Därför tänker vi alltid datamodell, processer, behörigheter, integrationer och drift tillsammans. Så uppstår en arkitektur där klienter, tjänster och servrar talar samma språk.

Vår princip

Teknik är för oss inget trossystem. Avgörande är att arkitektur, teamförmåga, drift och framtida utbyggnader passar företaget. Det är inte den mest högljudda plattformen som vinner, utan den som gör att risk, underhållbarhet och tillväxt kan styras på ett förnuftigt sätt.

Vissa uppgifter löser vi medvetet med Delphi, eftersom etablerad businesslogik, högpresterande klienter och multiplattformsförmåga kommer till sin rätt där. Andra krav passar bättre med C#, med tjänster, med en portal eller med en kombination av båda. God arkitektur uppstår inte ur mode, utan ur tydlighet: vilket ansvar har vilken systemdel, vilken livslängd är att vänta, hur stort är teamet, hur kritisk är driften och vilka utbyggnader kommer realistiskt under de kommande åren?

Det är precis där professionell mjukvaruutveckling börjar för oss. Vi vill inte bara leverera något som fungerar idag, utan skapa en teknisk grund som även senare är spårbar, möjlig att ta över och ekonomiskt förvaltbar.

Vanliga frågor om teknik och arkitektur

Teknologiska beslut måste passa teamet, verksamhetslogiken och driften. Just därför reder vi inte ut dessa frågor abstrakt, utan alltid utifrån det konkreta systemet.