Technologien für Delphi, C#, Datenbanken und Services

Title (Variante A): Teknologier för företagsprogramvara: Delphi, C#, arkitektur & plattformar
Title (Variante B): Val av teknologier & arkitektur: Delphi-modernisering, C#-tjänster, multiplattform

Meta-Description (Variante A): Vi väljer teknologier efter driftsrealitet: Delphi för långlivad affärslogik & multiplattforms-klienter, C# för REST-tjänster & portaler. Layer-3-arkitektur, integrationer och drift i fokus.
Meta-Description (Variante B): Delphi, C#, REST och plattformar (Windows/macOS/Linux/ARM64) – med arkitektur som förblir underhållbar. Vi rådgiver, moderniserar och integrerar utan onödiga avbrott.

Vi använder inte teknologier efter mode, utan efter driftsrealitet, livslängd, integrationsbehov och teamets förutsättningar. Avgörande är inte buzzwordet, utan om systemet senare förblir rent driftbart, utbyggbart och övertagbart.

• Underhållbarhet över år istället för kortsiktiga trendbyten
• Integration i befintliga företagsystem (REST/API:er, dataflöden, processer)
• Planbar arkitektur (UI, affärslogik, dataåtkomst tydligt separerade)
• Multiplattform och nya målsystem (Windows/macOS/Linux, Windows 11 ARM64)

Teknologi-komponenter

Delphi

Starkt för växlad affärslogik, databasnärlig bearbetning, rapporter och stabila multiplattforms-klienter (Windows, macOS, Linux). Idealisk när befintlig domänfunktionalitet ska fortsätta och moderniseras på lång sikt.

Se Delphi

C#

Starkt för REST-tjänster, integrationer, portaler och moderna backend-tjänster. Lämpligt när gränssnitt, skalning, tydliga servicegränser och anslutning mot befintliga system står i fokus.

Se C#

Arkitektur (Layer-3)

Vi separerar presentation, affärslogik och dataåtkomst så att förändringar förblir planbara. Det minskar sidoeffekter, underlättar testning och gör utbyggnader möjliga utan att „kämpa mot befintlig kod“.

Se Layer-3

Plattformar (inkl. Windows 11 ARM64)

Förutom klassiska x64-mål beaktar vi aktuella plattformar tidigt, så att ny hårdvara och deployment inte senare blir ett särprojekt.

Se ARM64

När vilken riktning är lämplig

Delphi är lämpligt när…

• befintlig domänlogik ska leva vidare och det centrala värdet ligger i funktionaliteten
• komplexa desktopprocesser måste förbli stabila (inkl. offline-/periferianslutning)
• Windows-, macOS- och Linux-klienter ska byggas på en gemensam domänbas
• överlämning till ett team med Delphi-erfarenhet är realistisk eller kan byggas upp

C# är lämpligt när…

• REST-servrar, tjänster eller integrationer står i centrum
• portaler, externa gränssnitt eller identity-/behörighetsmodeller dominerar
• ett driftkoncept med deployment, övervakning och skalning är viktigt
• flera system ska orkestreras via API:er

Hybrid är lämpligt när…

• befintliga applikationer och nya portaler måste samverka
• desktop, tjänster och webben använder samma databas men behöver tydligt separerade ansvar
• modernisering ska ske stegvis (Layer-3 istället för Big-Bang)

Praktisk anmärkning: I många projekt är det inte „språket“ som är flaskhalsen, utan den rena separationen av ansvar, dataflöden och drift. Det är där långsiktig underhållbarhet uppstår.

Delphi-modernisering i praktiken

Om en äldre Delphi-applikation fortfarande har verksamhetsvärde moderniserar vi inte blint. Vi analyserar först hur systemet faktiskt arbetar, vilka processer det bär, var dataflöden bryts och vilka kvarlevor som saktar ner driften. Därifrån skapas en moderniseringsväg som är hållbar i vardagen.

Typiska moderniseringskomponenter

• Separation av gränssnitt, affärslogik och datåtkomst (Layer-3) för planbara ändringar
• Stabilisering och sanering av datåtkomsten där historiskt uppkomna åtkomstvägar skapar problem
• Införande eller utbyggnad av REST-gränssnitt för integrationer och nya frontends
• Stegvis utbyggnad med klienter för Windows, macOS och Linux på samma verksamhetslogiska bas

Vad det innebär för ert företag

• Lägre risk än vid en nyplattform eftersom den verksamhetsmässiga substansen bevaras
• Bättre underhållbarhet och testbarhet genom tydliga ansvarsgränser
• Integrerbarhet utan att behöva „böja“ beståndssystemet

Tjänster och servrar som del av samma arkitektur

Många företagsystem behöver idag inte bara en klient, utan också bakgrundstjänster, Windows- eller Linux-tjänster och REST-servrar. Därför planerar vi dessa delar inte som en efterhandskonstruktion utan som en del av samma arkitektur.

• Tydliga ansvarsgränser: Vad körs i klienten, vad i tjänsten, vad på servern?
• Spårbarhet: Göra fel synliga, logga tillståndsändringar, hålla processer mätbara
• Konsistens: Samma verksamhetslogik och samma regler över klient, tjänst och API
• Drift: Utrullningar, uppdateringar och utbyggnader utan specialfall

Särskilt i multiplattformsprojekt är detta avgörande: En desktopklient på Windows, macOS eller Linux ska inte representera annan verksamhetslogik än en medföljande REST-server eller bakgrundstjänst. Därför utformar vi datamodell, processer, behörigheter, integrationer och drift tillsammans.

Vår princip

Teknologi är inte ett trosystem för oss. Avgörande är att arkitektur, teamets förmåga, drift och framtida utvidgningar 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 meningsfullt sätt.

Nästa steg

Om ni vill klargöra om Delphi, C# eller en hybridansats är lämplig för ert system, fastställer vi det utifrån er konkreta miljö: mål, integrationer, livslängd, team och drift. På denna grund uppstår ett hållbart förslag istället för en arkitektur som bara existerar på bilder.

Ni tar med: översikt över systemet, viktigaste processerna, integrationspunkter, driftsramar.

Ni får: teknologirekommendation, arkitekturskiss (Layer-3/tjänster), prioriteringar och en pragmatisk arbetsmodell.

Vanliga frågor om teknik och arkitektur

När är Delphi lämpligt jämfört med en komplett nyplattform?

När den verksamhetsmässiga substansen ligger i kärnan av applikationen (regler, specialfall, processer) och mjukvaran är stabil i vardagen, är modernisering ofta mer ekonomisk och mindre riskfylld än en Big-Bang-nyutveckling. Förutsättningen är en planbar moderniseringsväg (t.ex. Layer-3, rena datåtkomster, definierade gränssnitt).

När är en nyplattform ändå det bättre valet?

Om centrala krav inte längre kan uppfyllas strukturellt (t.ex. nödvändig skalning, säkerhets-/compliance-krav, arkitekturbrott i datamodellen) eller om det befintliga systemet inte längre är hanterbart funktionellt och tekniskt. Även då kan migrationen ofta säkras stegvis via gränssnitt och parallellt körande tjänster.

Vad innebär Layer-3-arkitektur konkret?

En medveten uppdelning mellan användargränssnitt, affärslogik och dataåtkomst. Det gör förändringar planbara, tester enklare och integrationer renare, eftersom inte varje anpassning ger sidoeffekter i hela applikationen.

Hur integrerar ni befintliga system (ERP, DMS, gränssnitt, databaser)?

Genom klart definierade gränssnitt (typiskt REST/APIs) och spårbara dataflöden. Avgörande är att klargöra ansvarsfördelningen: vilken logik ligger i kärnsystemet, vilken i tjänsterna, vilken i externa system?

Hur undviker ni att tjänster blir „specialfall“?

Genom att tjänster och bakgrundsprocesser planeras som en del av arkitekturen från början: gemensam domänlogik, konsekventa behörigheter, övervakning/loggning, definierade driftsättningar och tydliga felbilder.

Vilken roll spelar Windows 11 ARM64?

ARM64 blir allt mer relevant eftersom nya enhetsklasser och företagshårdvara bygger på det. Den som tidigt tar hänsyn till plattformar undviker senare specialprojekt kring build, deployment, drivrutiner och runtimeberoenden.

Hur går ni tillväga vid teknikval?

Vi börjar med en kort teknisk och funktionell assessment: mål, risker, integrationer, drift och team. Därifrån tar vi fram en rekommendation som både är bärkraftig idag och fortfarande ekonomiskt hållbar om 2–5 år.