Teknologier

Vi väljer tekniker inte efter trend, utan efter driftverklighet, livslängd, integrationsbehov och teamets förmåga. Avgörande är inte buzzwordet, utan om systemet senare förblir rent driftbart, utbyggbart och möjligt att ta över.

När vilken inriktning är rimlig

Delphi-modernisering i praktiken

När en gammal Delphi-applikation fortfarande är fackligt värdefull moderniserar vi inte blint. Vi analyserar först hur systemet faktiskt fungerar, vilka processer det bär, var dataflöden bryts och vilka arv som bromsar driften. Ur detta växer en moderniseringsväg som inte bara ser ren ut på papper, utan som håller i vardagen.

I många äldre, vidareutvecklade applikationer ligger det egentliga värdet inte i gränssnittet, utan i år av domänlogik, specialregler, undantag och erfarenhetskunskap. Den substansen kastar man inte bort lättvindigt. Vi separerar ansvar tydligt, strukturerar om databasen, ersätter gamla åtkomstvägar, skapar nya REST-gränssnitt och kompletterar vid behov klienter för Windows, macOS och Linux på samma verksamhetsmässiga grund. På så sätt uppstår inget hårt avbrott, utan en begriplig vidareutveckling med 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, affärslogik frigörs från gränssnittskod, gränssnitt blir planeringsbara och framtida utbyggnader behöver inte längre drivas igenom mot det befintliga. Målet är inte kosmetisk modernisering, utan ett system som ger företaget utrymme för nya krav igen.

Tjänster och servrar som del av samma arkitektur

Många företagsystem behöver i dag 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 ett efterhandsbygge, utan som en del av samma arkitektur. En tjänst som bara senare på något sätt tillkommer blir nästan alltid ett specialfall.

Om data ska bearbetas distribuerat, gränssnitt tillhandahållas, exporter köras, importer övervakas eller uppgifter schemaläggas och köras i bakgrunden måste det tekniska ansvaret vara klarlagt 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 domänlogiken konsistent? De här frågorna 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 verksamhetsmässigt 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 det möjligt att styra risk, underhållbarhet och tillväxt på ett rimligt sätt.

Vissa uppgifter löser vi medvetet med Delphi, eftersom väletablerad affärslogik, högpresterande klienter och multiplattformsförmåga får spela ut sina styrkor 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 kan förväntas, hur stort är teamet, hur kritisk är driften och vilka utbyggnader kommer realistiskt under de kommande åren?

Precis där börjar för oss professionell mjukvaruutveckling. Vi vill inte bara leverera något som fungerar i dag, utan skapa en teknisk grund som även senare är begriplig, övertagbar och ekonomiskt möjlig att förvalta.

Vanliga frågor om teknik och arkitektur

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