Teknologiprofil
Oversikt over vår tekniske plattform
Delphi. C#. SQL. API-er.
Teknologier som passer til faglogikk, data og drift.
Teknologi i bilder
Hos oss synliggjøres teknologivalg gjennom målarkitektur.
Det avgjørende er ikke begrepet, men hvordan plattform, tjenester og lag senere samarbeider. Disse skissene gjør retningen håndgripelig.
Felles kjerne for flere mål
Multiplattform blir fornuftig når flere klienter bruker samme forretningslogikk og ikke avviker.
* Brukte plattformnavn og varemerker tilhører de respektive rettighetshaverne.
C# og tjenester som tillegg
Portaler, REST og tjenester kompletterer kjernen der web- og driftslogikk blir mer fremtredende.
Tenk tidlig på målhardware
Plattformskifter som ARM64 hører hjemme i arkitektur og deployment, før de blir et supportproblem.
Egnede tjeneste- og teknologiveier
Viktige utdypninger om dette temaet
Vi bruker ikke teknologier etter moten, men etter driftsrealitet, levetid, integrasjonsbehov og teamets kapasitet. Avgjørende er ikke slagordet, men om systemet senere lar seg drifte ryddig, utvides og overtas.
Sterk for forretningslogikk og multiplattform-klienter
Delphi er sterk der hvor etablert forretningslogikk, database-nære prosesser, rapporter og stabile klienter for Windows, macOS og Linux skal videreføres på lang sikt.
Delphi ansehen
C#
Sterk for REST, tjenester og portaler
C# bruker vi når portaler, moderne backend-tjenester, REST-APIer og integrasjoner skal kobles rent til eksisterende bedriftsystemer.
C# ansehen
Architektur
Layer-3 statt monolithischer Altlast
Vi skiller bevisst brukerflate, forretningslogikk og dataaksess, slik at endringer forblir planbare og nye tjenester ikke må bygges på bekostning av eksisterende systemer.
Layer-3 ansehen
Plattformen
Windows 11 ARM64 gleich mitdenken
I tillegg til klassiske x64-mål tar vi hensyn til aktuelle plattformer som Windows 11 ARM64 tidlig, slik at ny maskinvare og utrulling ikke senere blir et eget prosjekt.
Se ARM64
Når hvilken retning er hensiktsmessig
Delphi er hensiktsmessig når
- eksisterende faglogikk skal videreføres,
- komplekse desktop-prosesser må forbli stabile,
- Windows-, macOS- og Linux-klienter skal bygges på et felles faglig grunnlag.
C# er hensiktsmessig når
- REST-servere og tjenester skal bygges opp,
- API-er og eksterne integrasjoner står i sentrum,
- moderne tjenestearkitekturer ønskes.
Hybrid er hensiktsmessig når
- eksisterende applikasjoner og nye portaler må samarbeide,
- desktop, tjenester og web bruker samme datagrunnlag,
- modernisering skal skje trinnvis og som en Layer-3-struktur.
Delphi-Modernisierung in der Praxis
Når en gammel Delphi-applikasjon fortsatt er faglig verdifull, moderniserer vi ikke blindt. Vi analyserer først hvordan systemet faktisk fungerer, hvilke prosesser det støtter, hvor dataflyter brytes og hvilke restlaster som bremser driften. Av dette oppstår en moderniseringsvei som ikke bare ser ryddig ut på papiret, men som er bærekraftig i hverdagen.
I mange etablerte applikasjoner ligger den egentlige verdien ikke i brukergrensesnittet, men i år med faglogikk, spesialregler, unntak og erfaringskunnskap. Denne substansen kaster man ikke bort lettvint. Vi skiller ansvarsområder klart, reorganiserer databasen, erstatter gamle tilgangsveier, oppretter nye REST-grensesnitt og kompletterer ved behov klienter for Windows, macOS og Linux på samme faglige grunnlag. Slik oppstår ikke et brått brudd, men en etterprøvbar videreutvikling med klar teknisk avgrensning.
Ofte betyr det også å bringe historisk vokste monolitter tilbake i en form som er vedlikeholdbar, testbar og utvidbar. Datatilgangen stabiliseres, forretningslogikk løses ut av brukergrensesnittkode, grensesnitt blir planlagte og framtidige utvidelser trenger ikke lenger å kjempe seg gjennom eksisterende kodebaser. Målet er ikke kosmetisk modernisering, men et system som gir virksomheten rom 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-tjenester og REST-servere. Nettopp derfor planlegger vi disse delene ikke som et ettermontert påbygg, men som en del av samme arkitektur. En tjeneste som først blir lagt til senere, vil nesten alltid bli et særtilfelle.
Når data skal behandles distribuert, grensesnitt gjøres tilgjengelige, eksportkjøringer utføres, importer overvåkes eller oppgaver kjøres tidsstyrt i bakgrunnen, må det tekniske ansvaret være avklart 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 totalsystem.
Dette er særlig avgjørende i multiplattformprosjekter. En desktop-klient på Windows, macOS eller Linux må faglig ikke bety noe annet enn en ledsagende REST-server eller en bakgrunnstjeneste. Derfor vurderer vi datamodell, prosesser, rettigheter, integrasjoner og drift alltid sammen. Slik oppstår en arkitektur der klienter, tjenester og servere snakker samme språk.
Vår grunnsetning
Teknologi er for oss ikke et trossystem. Avgjørende er at arkitektur, teamets evne, drift og fremtidige utvidelser passer til 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 der vokst forretningslogikk, ytelsessterke klienter og multiplattformstøtte får vist sine styrker. Andre krav passer bedre til C#, til tjenester, et portal eller 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 i de neste årene?
Nettopp der begynner for oss profesjonell programvareutvikling. Vi vil ikke bare levere noe som fungerer i dag, men skape et teknisk grunnlag som også senere er etterprøvbart, overtakbart og økonomisk forsvarlig å vedlikeholde.
Ofte stilte spørsmål om teknologi og arkitektur
Teknologiske beslutninger må passe til teamet, fagligheten og driften. Derfor avklarer vi disse spørsmålene ikke abstrakt, men alltid med utgangspunkt i det konkrete systemet.
Wann ist Delphi gegenüber einer kompletten Neuplattform sinnvoll?
Alltid når etablert faglogikk, ytelsessterke skrivebordsprosesser og multiplattformmål skal videreføres økonomisk, i stedet for å erstatte substans uforsiktig.
Wann setzen Sie zusätzlich C# ein?
Først og fremst for portaler, web-backends, REST-tjenester, integrasjoner og tjenesteorienterte arkitekturkomponenter som lar seg godt integrere med eksisterende skrivebordssystemer.
Wie wichtig ist Layer-3 in der Praxis?
Svært viktig. Først den klare separasjonen av UI, forretningslogikk og datatilgang gjør modernisering, tester, tjenester og fremtidige plattformskifter håndterbare.
Involverer dere neue Plattformen wie Windows 11 ARM64 tidlig?
Ja. Ny målmaskinvare og utrullingsveier vurderes tidlig, slik at dette senere ikke blir kostbare spesialprosjekter.
Les flere spørsmål samlet
Disse korte svarene forblir her på siden. På den sentrale FAQ-landingssiden setter vi temaet i tillegg i sammenheng med arkitektur, modernisering, plattformer og drift.
Neste steg
Hvis dere har et konkret spørsmål om modernisering, API eller plattform, bør vi tidlig tydelig definere det tekniske omfanget.
Net-Base vurderer eksisterende systemer, dataflyter, grensesnitt og målplattformer ikke isolert, men i sammenheng med faglogikk, drift og senere videreutvikling.
- Eksisterende tilstand, målbildet og tekniske risikoer vurderes samlet.
- REST, datatilgang, portaler og utrulling blir ikke utsatt som sene følger.
- Dere ser tidlig hvilken vei som er økonomisk og driftsmessig levedyktig.