Gå til hovedindholdet
FromNine
Menu

Software & cloud

Forretnings­software som dine egne teams kan blive ved med at ændre.

Vi udvikler SaaS-produkter, portaler til borgere og medarbejdere og centrale forretningsapplikationer. De er tilgængelige, sikre fra start og kan vedligeholdes af dine egne teams længe efter lanceringen.

For softwarevirksomheder, producenter og offentlige myndigheder der har brugere i Danmark og på andre markeder.

Tal med os om dit projektLæs om modernisering af legacy
Forretningssoftware & SaaS: lagene i løsningenFire lag oven på hinanden. Fra øverst til nederst: den tilgængelige brugerflade som folk bruger, domænemodulerne der rummer reglerne, platformstjenesterne for kunder, identitet og data, og den sikre leverancepipeline nederst.01Tilgængelige brugerflader02Domænemoduler og regler03Kunder, identitet, data04Sikker leverancepipeline
  1. 01Domænedrevet design til regeltungt arbejde som sagsbehandling
  2. 02Tilgængelighed efter EN 301 549 og WCAG 2.2 AA fra det første design
  3. 03Dokumentation og beslutningslog som dine teams kan overtage

01 Problemer

Det hører vi før en genopbygning

  1. 01

    Hver ændring tager et kvartal

    Applikationen virker, men ingen tør røre kernen. Små ændringer kræver store regressionstests og et releasevindue.

  2. 02

    Portalen svigter de mennesker den skal betjene

    Den virker ikke med en skærmlæser, på en mobil eller for brugere der har brug for en anden sprogversion. Klagerne kommer før tilgængelighedsgennemgangen.

  3. 03

    Én kundes ændring ødelægger noget for en anden

    SaaS-produktet voksede med tilpasninger pr. kunde. Nu er hver release en forhandling, og nogle kunder sidder fast på gamle versioner.

  4. 04

    Viden forsvandt med leverandøren

    Beslutninger blev aldrig skrevet ned. Teamet der byggede systemet, er gået videre, og koden er den eneste dokumentation.

  5. 05

    Kunder og myndigheder stiller sikkerhedsspørgsmål

    Udbudsmaterialet beder om en SBOM, en proces for sårbarheder og dokumentation efter forordningen om cyberrobusthed. Ingen har det klar.

02 Leverancer

Det leverer vi

  1. 01 Udvikling af SaaS-produkter

    Produkter designet til at betjene mange kunder fra én kodebase: den rette model for kundeadskillelse, konfiguration i stedet for tilpasning, og releases der når alle kunder.

    Det gør vi

    • Valg af model for kundeadskillelse: delt, samlet eller isoleret pr. kunde
    • Strategi for konfiguration og feature flags
    • Integration til måling af forbrug og fakturering
    • Releasetog med udrulning der tager højde for hver kunde

    Det får du

    • Design af kundeadskillelse og isolation
    • Konfigurationsmodel med faste rammer
    • Releaseproces med tilbagerulning pr. kunde

  2. 02 Domænedesign til komplekse regler

    Domænedrevet design hvor reglerne er produktet: sagsbehandling, berettigelse, beregninger med mange regler. Vi vælger bevidst mellem en modulær monolit og microservices og starter oftest med den første.

    Det gør vi

    • Event storming med fagfolk
    • Afgrænsede kontekster og modulgrænser
    • Regler gjort eksplicitte og testbare
    • Arkitekturbeslutninger skrevet ned for de store valg

    Det får du

    • Domænemodel og kontekstkort
    • Modulær kodebase med håndhævede grænser
    • Kørbare specifikationer for de vigtigste regler

  3. 03 Portaler til borgere og medarbejdere

    Brugerflader bygget på et designsystem, tilgængelige fra start og med plads til flere sprog fra første release. I Danmark betyder det ofte MitID-login, klart sprog og en engelsk version til brugere der ikke læser dansk.

    Det gør vi

    • Designsystem med tilgængelige komponenter
    • Indholdsdesign i klart sprog
    • Test med hjælpemidler sammen med rigtige brugere
    • Proces for oversættelse til hvert sprog

    Det får du

    • Portal på et genbrugeligt designsystem
    • Rapport om overholdelse af tilgængelighedskrav
    • Proces for indhold og oversættelse

  4. 04 Kvalitetssikring og sikker udvikling

    Testautomatisering på de rigtige niveauer, kontrakttests mellem services, performancetests før lancering og en sikker udviklingsproces bygget på OWASP ASVS, SBOM’er og kontrol med forsyningskæden.

    Det gør vi

    • Teststrategi og automatisering
    • Kontrakt- og performancetests
    • Trusselsmodellering og verifikation efter ASVS
    • Generering af SBOM og politik for afhængigheder

    Det får du

    • Automatiserede testsuiter i pipelinen
    • Rapport fra sikkerhedsverifikation
    • Proces for håndtering af sårbarheder, klar til forordningen om cyberrobusthed

  5. 05 Modernisering i små skridt

    Erstat en ældre applikation én funktion ad gangen bag en routingfacade, mens forretningen kører videre. Se også modernisering af legacy.

    Det gør vi

    • Kort over funktioner i den eksisterende applikation
    • Strangler fig-routing og API’er omkring det gamle system
    • Datamigrering med afstemningsrapporter
    • Parallelkørsel af kritiske beregninger

    Det får du

    • Rækkefølge for modernisering med forretningsmilepæle
    • Facade og nye moduler i drift
    • Afstemte data ved hvert skifte

  6. 06 Vedligeholdelse og overdragelse

    Software som dine teams kan eje: læsbar kode, beslutningslog, driftsvejledninger og en plan for overdragelse aftalt ved starten, ikke opdaget til sidst.

    Det gør vi

    • Parprogrammering med dine udviklere undervejs
    • Arkitekturbeslutninger opbevaret sammen med koden
    • Driftsvejledninger og guides til vagtordning
    • Milepæle for vidensoverdragelse

    Det får du

    • Plan for overdragelse med acceptkriterier
    • Dokumentation i dine repositories
    • Et oplært internt team

03 Arkitektur

En illustrativ referencearkitektur

En typisk form for en forretningsapplikation der erstatter en ældre: en tilgængelig frontend, en routingfacade der sender hver funktion til det gamle eller det nye system, et API-lag med klare kontrakter og en modulær kerne organiseret efter domænet.

Kundeadskillelse og konfiguration er tydelige platformstjenester, ikke betingelser spredt ud i koden. Nedenunder kører hvert build tests og sikkerhedskontroller og producerer en SBOM.

Lagene i tegningen

Brugere
Borgere, kunder og medarbejdere, på alle enheder og med hjælpemidler.
Modernisering
Routingfacaden, den eksisterende applikation og datamigreringen med afstemning.
Platform
API-lag, identitet, den modulære kerne, kundeadskillelse og konfiguration, driftsdata.
Sikker leverance
Kontrakt- og performancetests, ASVS-kontrol og en SBOM i hvert build.
Eksempel

  1. Brugere

    • Borgere, kunder, medarbejdere
    • Tilgængelig frontend

  2. Modernisering i små skridt

    • Routingfacade
    • Eksisterende applikation
    • Migrering med afstemning

  3. Platform

    • API-lag og kontrakter
    • Identitet og roller
    • Modulær kerne: modtagelse, sager, fakturering
    • Kunder, konfiguration, feature flags
    • Driftsdatabaser

  4. Sikker leverance

    • Kontrakt- og performancetests, ASVS-kontrol, SBOM i hvert build
Modulær kerne bag en routingfacade

Illustrativ arkitektur, ikke en kundes system.

Læs diagrammet som tekst

Hovedruten går fra brugerne til en tilgængelig frontend, gennem en routingfacade og et API-lag til en modulær kerne organiseret i afgrænsede kontekster.

Facaden sender også nogle funktioner til den eksisterende applikation, som udfases trin for trin. Dens data flyttes gennem en migrering med afstemning til driftsdatabaserne.

Identitet betjener API-laget. Tjenester for kundeadskillelse og konfiguration ligger under kernen. Et bånd for sikker leverance nederst dækker kontrakttests, performancetests, sikkerhedsverifikation og SBOM’er.

04 Hensyn og begrænsninger

Tekniske hensyn og begrænsninger

  • Modulær monolit først

    Sådan håndterer vi det

    Vi starter med klare moduler i én udrullelig enhed og skiller kun services ud, hvor skalering, releasetakt eller teamejerskab kræver det.

    Begrænsninger og afhængigheder

    Microservices løser organisatoriske problemer lige så meget som tekniske. Uden teams til at eje dem giver de flere omkostninger og flere måder at fejle på.

  • Tilgængelighed er udviklingsarbejde

    Sådan håndterer vi det

    Tilgængelige komponenter, automatiske kontroller i pipelinen og manuel test med hjælpemidler før hver større release.

    Begrænsninger og afhængigheder

    Automatiske værktøjer finder kun en del af problemerne. Fuld overholdelse kræver manuelle gennemgange og helst test med brugere med handicap.

    Indhold og dokumenter som redaktører tilføjer efter lanceringen, skal leve op til samme standard. Vi træner redaktørerne, men vi styrer ikke hvad de udgiver.

  • Modernisering tager den tid dataene tager

    Sådan håndterer vi det

    Datamigrering planlægges pr. funktion, øves og afstemmes, og forretningen godkender hvert skifte.

    Begrænsninger og afhængigheder

    Kvaliteten af de gamle data sætter ofte tempoet. At rense dem er lige så meget en forretningsopgave som en teknisk opgave.

  • Regulering af softwareprodukter

    Sådan håndterer vi det

    SBOM’er, håndtering af sårbarheder og sikre standardindstillinger er en del af vores standardpipeline, som gør produkter klar til forordningen om cyberrobusthed.

    Begrænsninger og afhængigheder

    Om og hvordan forordningen gælder for dit produkt, er et juridisk spørgsmål. Vi leverer den tekniske dokumentation, og dine jurister foretager vurderingen.

05 Sådan arbejder vi

Sådan arbejder vi

Korte cyklusser, rigtige brugere tidligt og overdragelsen planlagt fra første uge.

  1. 01

    Kortlæg domænet

    Event storming med dem der kender reglerne, og et kort over de funktioner der findes i dag.

    ResultatKontekstkort og de første arkitekturbeslutninger

  2. 02

    Lever en tynd skive

    Én funktion hele vejen igennem, via facaden og i drift med rigtige brugere.

    ResultatEn fungerende skive i drift

  3. 03

    Voks funktion for funktion

    Hver release flytter en funktion, dens data og dens brugere, med afstemning og tilbagerulning klar.

    ResultatReleaseplan pr. funktion

  4. 04

    Overdrag

    Dine udviklere arbejder sammen med vores, overtager vagtordningen og ejer roadmappen, når kriterierne for overdragelse er opfyldt.

    ResultatGodkendt overdragelse

06 Menneskelig kontrol

Hvor mennesker har kontrollen

I forretningssoftware betyder kontrol at vide hvem der ændrede hvad, hvem der godkendte det, og hvordan det kan rulles tilbage.

  • Produktejeren bestemmer indholdet

    Din produktejer sætter prioriteterne og godkender hver leverance. Vi rådgiver, produktejeren beslutter.

  • Konfiguration har en ejer

    Kundeindstillinger og feature flags ændres gennem en proces med revisionsspor, af de roller du udpeger.

  • Skift bliver godkendt

    Hver flytning fra gammelt til nyt system godkendes af forretningen, med en tilbagerulning der er øvet.

  • Beslutninger bliver skrevet ned

    Arkitekturbeslutninger viser hvad der blev valgt, af hvem og hvorfor, så fremtidige teams kan tage dem op med viden om baggrunden.

07 Teknologier

Teknologier vi arbejder med

Backend
  • Java og Kotlin
  • .NET
  • TypeScript og Node.js
  • Python
Frontend
  • React og Next.js
  • Angular
  • Designsystemer med tilgængelige komponenter
  • Native og cross-platform mobilapps
Data
  • PostgreSQL
  • SQL Server og Oracle (eksisterende landskaber)
  • Hændelsesstrømme
  • Søgemaskiner
Kvalitet og sikkerhed
  • Playwright og kontrakttests
  • Belastnings- og performancetests
  • SAST, DAST og scanning af afhængigheder
  • SBOM i CycloneDX eller SPDX

At vi nævner en teknologi, beskriver vores tekniske erfaring. Det betyder ikke et partnerskab med leverandøren eller at leverandøren anbefaler os.

08 Eksempel

Et illustrativt eksempel

Eksempel

En forhandlerportal for en møbelproducent

01Udgangspunkt
En dansk møbelproducent sælger gennem forhandlere i flere EU-lande. Hvert marked har sin egen portal fra sin egen leverandør, de fejler hver især tilgængelighedskontrollen på forskellige måder, og hver ændring laves flere gange.
02Det ville vi bygge
Én forhandlerportal på et fælles designsystem, med indhold, sprog, priser og integrationer pr. land som konfiguration og ét releasetog koblet til ERP-systemet.
03Her beslutter mennesker
Salgsansvarlige i hvert land godkender indhold og konfiguration for deres marked. Produktejeren beslutter fælles funktioner.
04Det ville vi måle
Tilgængelighedsfejl pr. release, tiden fra ønske til ændring i alle lande og andelen af ændringer der laves én gang i stedet for pr. land.

09 Brancher

I din branche

  • Offentlig sektor

    Sagssystemer og borgerportaler der lever op til webtilgængelighedsloven, bruger MitID-login og taler sammen med kommunens og styrelsens fagsystemer.

  • Finansiel sektor

    Kundeportaler og backofficeapplikationer med stærke revisionsspor og releaseprocesser der opfylder kravene til ændringsstyring.

  • Industri & produktion

    Konfiguratorer, serviceportaler og SaaS-produkter til producenter af maskiner og udstyr, koblet til ERP og feltservice.

Danmark

Et nyt marked er en release, ikke en kopi

Et produkt der sælges i Danmark, møder tilgængelighedsloven, hvis krav gælder fra 28. juni 2025 for de produkter og tjenester loven dækker. Forordningen om cyberrobusthed (CRA) er ét regelsæt for hele EU med forpligtelser der træder i kraft i etaper. Danske kunder forventer desuden MitID-login, og offentlige kunder kræver e-faktura via NemHandel. Kunder i andre lande har deres egne sprog, faktureringsregler og identitetsløsninger.

Vi holder forskellene i konfiguration og i klart afgrænsede moduler, så et nyt marked bliver en release i stedet for en kopi af koden. Dokumentation for tilgængelighed og sikkerhed produceres af pipelinen, klar til de spørgsmål udbudsmaterialet stiller.

Spørgsmål om forretningssoftware og SaaS

Skal vi udvikle selv eller konfigurere en platform?

Konfigurér en platform hvor din proces ligger tæt på standard, og udvikl selv hvor processen er det der adskiller dig, eller hvor ingen platform passer til reglerne. Vi arbejder med Salesforce, SAP og Odoo og med specialudviklet kode, så vi har ingen grund til at skubbe på ét svar. Vores ydelse Arkitektur & rådgivning gør valget tydeligt.

Kan I garantere at vores portal er tilgængelig?

Vi bygger efter EN 301 549 og WCAG 2.2 AA, tester automatisk og manuelt og leverer en rapport om overholdelse med de kendte problemer. Vi lover ikke nul problemer. Vi lover at finde dem, rapportere dem og rette det der ligger inden for vores opgave. For offentlige myndigheder gælder webtilgængelighedsloven, som Digitaliseringsstyrelsen fører tilsyn med.

Kan I modernisere uden en big bang-migrering?

Ja, og det anbefaler vi. En routingfacade lader os flytte én funktion ad gangen, mens den eksisterende applikation kører videre, og dataene afstemmes ved hvert skridt.

Kan vores eget team overtage softwaren?

Det er standardplanen. Kriterierne for overdragelse aftales ved starten, dine udviklere arbejder sammen med vores undervejs, og beslutningslog og driftsvejledninger ligger i dine repositories.

Hvad betyder forordningen om cyberrobusthed for vores produkt?

Hvis du bringer software med digitale elementer på EU-markedet, kan det medføre forpligtelser om sikkert design, håndtering af sårbarheder og dokumentation. Vi bygger den tekniske dokumentation: SBOM’er, en proces for sårbarheder og sikre standardindstillinger.

Fortæl os hvad der skal blive ved med at køre, mens det ændres

Vi foreslår den første funktion der skal flyttes, og hvad dit team vil eje til sidst.

Tal med os om dit projektLæs om modernisering af legacy