Hoppa till huvudinnehållet
FromNine
Meny

Programvara och moln

Verksamhets­system som dina egna team kan fortsätta utveckla.

Vi utvecklar SaaS-produkter, e-tjänster och portaler för invånare och medarbetare samt centrala verksamhetssystem som är tillgängliga, säkra från början och går att förvalta av dina egna team långt efter lanseringen.

För svenska programvaruföretag, myndigheter och kommunalförbund som bygger e-tjänster och SaaS-produkter för användare i Sverige och andra länder.

Berätta om ditt projektLäs om modernisering
Verksamhets­system och SaaS: förmågor i lagerFyra lager staplade på djupet. Uppifrån och ned: det tillgängliga gränssnittet som människor använder, verksamhetsmodulerna som bär reglerna, plattformstjänsterna för kunder, identitet och data samt den säkra byggkedjan underst.01Tillgängliga gränssnitt02Verksamhets­moduler och regler03Kunder, identitet, data04Säker byggkedja
  1. 01Domändriven design för regeltungt arbete som ärendehantering
  2. 02Tillgänglighet enligt EN 301 549 och WCAG 2.2 AA från första skissen
  3. 03Dokumentation och beslutsunderlag som dina team kan ta över

01 Problem

Det här hör vi före en ombyggnad

  1. 01

    Varje ändring tar ett kvartal

    Systemet fungerar, men ingen vågar röra kärnan. Små ändringar kräver stora regressionstester och ett releasefönster.

  2. 02

    Portalen sviker dem den ska tjäna

    Den fungerar inte med skärmläsare, på mobilen eller för den som behöver ett annat språk. Klagomålen kommer före tillgänglighetsgranskningen.

  3. 03

    En kunds ändring förstör för en annan

    SaaS-produkten växte genom anpassningar per kund. Nu är varje release en förhandling, och vissa kunder sitter fast på gamla versioner.

  4. 04

    Kunskapen försvann med leverantören

    Besluten skrevs aldrig ned. Teamet som byggde systemet har gått vidare, och koden är den enda dokumentationen.

  5. 05

    Säkerhets­frågorna kommer från kunder och myndigheter

    Upphandlingsdokumentet kräver en programvaruförteckning (SBOM), en process för sårbarheter och underlag för cyberresiliensförordningen. Ingen har dem klara.

02 Leveranser

Det här levererar vi

  1. 01 Utveckling av SaaS-produkter

    Produkter som är gjorda för att betjäna många kunder från en kodbas: rätt modell för kundseparering, konfiguration i stället för anpassning och releaser som når alla kunder.

    Det här gör vi

    • Val av modell för kundseparering: delad, samlad eller isolerad per kund
    • Strategi för konfiguration och funktionsflaggor
    • Integration för mätning av användning och fakturering
    • Releasetåg med utrullning kund för kund

    Det här får du

    • Design för kundseparering och isolering
    • Konfigurationsmodell med skyddsräcken
    • Releaseprocess med återställning per kund

  2. 02 Domändesign för komplexa regler

    Domändriven design där reglerna är produkten: ärendehantering, bedömning av rätt till stöd, beräkningar med många regler. Vi väljer medvetet mellan en modulär monolit och mikrotjänster och börjar oftast med det förstnämnda.

    Det här gör vi

    • Event storming med verksamhetens experter
    • Avgränsade kontexter och modulgränser
    • Regler som görs uttryckliga och testbara
    • Arkitekturbeslut som dokumenteras för de stora valen

    Det här får du

    • Domänmodell och kontextkarta
    • Modulär kodbas med upprätthållna gränser
    • Körbara specifikationer för de viktigaste reglerna

  3. 03 E-tjänster och portaler för invånare och medarbetare

    Gränssnitt byggda på ett designsystem, tillgängliga från början och flerspråkiga från första release. För en svensk organisation betyder det klarspråk på svenska, inloggning med e-legitimation och de andra språk som dina användare faktiskt talar.

    Det här gör vi

    • Designsystem med tillgängliga komponenter
    • Innehållsdesign i klarspråk
    • Tester med hjälpmedel tillsammans med verkliga användare
    • Översättningsflöde för varje språk

    Det här får du

    • Portal på ett återanvändbart designsystem
    • Rapport om tillgänglighet och kända brister
    • Flöde för innehåll och översättning

  4. 04 Kvalitetsarbete och säker utveckling

    Testautomatisering på rätt nivåer, kontraktstester mellan tjänster, prestandatester före lansering och en säker utvecklingsprocess som bygger på OWASP ASVS, programvaruförteckningar (SBOM) och kontroller i leveranskedjan.

    Det här gör vi

    • Teststrategi och automatisering
    • Kontrakts- och prestandatester
    • Hotmodellering och verifiering mot ASVS
    • Generering av SBOM och regler för beroenden

    Det här får du

    • Automatiserade testsviter i byggkedjan
    • Rapport från säkerhetsverifieringen
    • Process för sårbarhetshantering redo för cyberresiliens­förordningen

  5. 05 Modernisering steg för steg

    Ett äldre system ersätts en förmåga i taget, bakom en styrande fasad, medan verksamheten fortsätter. Se även modernisering av äldre system.

    Det här gör vi

    • Karta över förmågorna i det befintliga systemet
    • Strangler fig-styrning och API-omslag
    • Datamigrering med avstämningsrapporter
    • Parallellkörning för kritiska beräkningar

    Det här får du

    • Moderniseringsordning med verksamhetsmål
    • Fasad och nya moduler i drift
    • Avstämda data vid varje övergång

  6. 06 Förvaltnings­barhet och överlämning

    Programvara som dina team kan äga: läsbar kod, dokumenterade beslut, driftrutiner och en överlämningsplan som avtalas i början, inte upptäcks i slutet.

    Det här gör vi

    • Parprogrammering med dina utvecklare under bygget
    • Arkitekturbeslut som förvaltas tillsammans med koden
    • Driftrutiner och instruktioner för jour
    • Delmål för kunskapsöverföring

    Det här får du

    • Överlämningsplan med acceptanskriterier
    • Dokumentation i dina kodförråd
    • Utbildat internt team

03 Arkitektur

En illustrativ referens­arkitektur

En typisk form för ett verksamhetssystem som ersätter ett äldre: ett tillgängligt gränssnitt, en styrande fasad som skickar varje förmåga till det gamla eller det nya systemet, ett API-lager med tydliga kontrakt och en modulär kärna som är organiserad kring verksamheten.

Kundseparering och konfiguration är uttryckliga plattformstjänster, inte villkor utspridda i koden. Underst kör varje bygge tester och säkerhetskontroller och tar fram en SBOM.

Lager i bilden

Människor
Invånare, kunder och medarbetare, på alla enheter och med hjälpmedel.
Modernisering
Den styrande fasaden, det befintliga systemet och datamigreringen med avstämning.
Plattform
API-lager, identitet, den modulära kärnan, kundseparering och konfiguration samt driftdata.
Säker leverans
Kontrakts- och prestandatester, ASVS-kontroller och en SBOM i varje bygge.
Illustrativt exempel

  1. Människor

    • Invånare, kunder, medarbetare
    • Tillgängligt gränssnitt

  2. Modernisering steg för steg

    • Styrande fasad
    • Befintligt system
    • Migrering med avstämning

  3. Plattform

    • API-lager och kontrakt
    • Identitet och roller
    • Modulär kärna: inflöde, ärenden, fakturering
    • Kundseparering, konfiguration, funktionsflaggor
    • Driftdatabaser

  4. Säker leverans

    • Kontrakts- och prestandatester, ASVS-kontroller, SBOM i varje bygge
Modulär kärna bakom en styrande fasad

Illustrativ arkitektur, inte en kunds system.

Läs diagrammet som text

Huvudflödet går från människor till ett tillgängligt gränssnitt, via en styrande fasad och ett API-lager, till en modulär kärna som är organiserad i avgränsade kontexter.

Fasaden skickar också vissa förmågor till det befintliga systemet, som avvecklas steg för steg. Dess data flyttas via en migrering med avstämning till driftdatabaserna.

Identitetstjänsten betjänar API-lagret. Tjänster för kundseparering och konfiguration ligger under kärnan. Ett band för säker leverans underst omfattar kontraktstester, prestandatester, säkerhetsverifiering och SBOM.

04 Överväganden och begränsningar

Tekniska överväganden och begränsningar

  • Modulär monolit först

    Så hanterar vi det

    Vi börjar med tydliga moduler i en driftsättningsbar enhet och bryter ut tjänster bara där skalning, releasetakt eller teamens ansvar kräver det.

    Begränsningar och beroenden

    Mikrotjänster löser organisatoriska problem lika mycket som tekniska. Utan team som äger dem ger de högre kostnader och fler sätt att fallera.

  • Tillgänglighet är ingenjörsarbete

    Så hanterar vi det

    Tillgängliga komponenter, automatiska kontroller i byggkedjan och manuella tester med hjälpmedel före varje större release.

    Begränsningar och beroenden

    Automatiska verktyg hittar bara en del av bristerna. Full överensstämmelse kräver manuella granskningar och helst tester med användare med funktionsnedsättning.

    Innehåll och dokument som redaktörer lägger till efter lanseringen måste hålla samma nivå. Vi utbildar redaktörerna, men vi styr inte vad de publicerar.

  • Modernisering tar den tid som datan tar

    Så hanterar vi det

    Datamigreringen planeras per förmåga, övas och stäms av, och verksamheten godkänner varje övergång.

    Begränsningar och beroenden

    Kvaliteten på de gamla data sätter ofta takten. Att städa dem är lika mycket en uppgift för verksamheten som en teknisk uppgift.

  • Regler för programvaru­produkter

    Så hanterar vi det

    SBOM, sårbarhetshantering och säkra standardinställningar ingår i vår vanliga byggkedja, som förbereder produkter för cyberresiliensförordningen.

    Begränsningar och beroenden

    Om och hur förordningen gäller för din produkt är en juridisk fråga. Vi tar fram det tekniska underlaget; dina jurister gör bedömningen.

05 Så arbetar vi

Så arbetar vi

Korta cykler, verkliga användare tidigt och överlämningen planerad från första veckan.

  1. 01

    Kartlägg verksamheten

    Event storming med dem som kan reglerna och en karta över de förmågor som finns i dag.

    ResultatKontextkarta och de första arkitekturbesluten

  2. 02

    Leverera en tunn skiva

    En förmåga hela vägen, genom fasaden och i drift med verkliga användare.

    ResultatFungerande del i drift

  3. 03

    Väx förmåga för förmåga

    Varje release flyttar en förmåga, dess data och dess användare, med avstämning och återställning förberedda.

    ResultatReleaseplan per förmåga

  4. 04

    Lämna över

    Dina utvecklare parprogrammerar med våra, tar över jouren och äger färdplanen när kriterierna för överlämning är uppfyllda.

    ResultatGodkänd överlämning

06 Mänsklig kontroll

Där människor behåller kontrollen

I verksamhetssystem betyder kontroll att veta vem som ändrade vad, vem som godkände det och hur det kan ångras.

  • Produktägarna bestämmer omfattningen

    Din produktägare sätter prioriteringarna och godkänner varje leverans. Vi ger råd, produktägaren bestämmer.

  • Konfigurationen har en ägare

    Kundinställningar och funktionsflaggor ändras genom en process med spårbarhet, av roller som du utser.

  • Övergångar godkänns

    Varje flytt från gammalt till nytt system godkänns av verksamheten, med en övad återställning.

  • Besluten skrivs ned

    Dokumenterade arkitekturbeslut visar vad som valdes, av vem och varför, så att framtida team kan ompröva dem med full insyn.

07 Tekniker

Tekniker vi arbetar med

Serversida
  • Java och Kotlin
  • .NET
  • TypeScript och Node.js
  • Python
Gränssnitt
  • React och Next.js
  • Angular
  • Designsystem med tillgängliga komponenter
  • Mobilappar, native och plattformsoberoende
Data
  • PostgreSQL
  • SQL Server och Oracle (befintliga miljöer)
  • Händelseströmmar
  • Sökmotorer
Kvalitet och säkerhet
  • Playwright och kontraktstester
  • Last- och prestandatester
  • SAST, DAST och skanning av beroenden
  • SBOM i CycloneDX eller SPDX

Att vi listar en teknik beskriver vår tekniska erfarenhet. Det innebär inte ett partnerskap med leverantören eller att leverantören står bakom oss.

08 Exempel

Ett illustrativt exempel

Illustrativt exempel

En e-tjänsteportal för ett kommunalförbund

01Utgångsläge
Ett kommunalförbund som sköter en gemensam verksamhet åt sina medlemskommuner har e-tjänster som byggts av olika leverantörer. Inloggningen fungerar olika i varje tjänst, flera av dem brister i tillgänglighetsgranskningen och varje ändring görs flera gånger.
02Det här skulle vi bygga
En portal på ett gemensamt designsystem, med inloggning via e-legitimation, innehåll och inställningar per medlemskommun i konfiguration och ett gemensamt releasetåg.
03Här beslutar människor
Varje medlemskommun godkänner innehåll och inställningar för sina invånare; förbundets produktägare beslutar om gemensamma funktioner.
04Det här skulle vi mäta
Tillgänglighetsbrister per release, ledtid för en ändring i alla medlemskommuner och andel ändringar som görs en gång i stället för en gång per kommun.

09 Branscher

I din bransch

  • Offentlig sektor

    Ärendehantering och e-tjänster för myndigheter, regioner och kommuner som uppfyller DOS-lagen, har inloggning med e-legitimation och kopplas till gemensamma lösningar inom Ena.

  • Finansiella tjänster

    Kundportaler och backofficesystem för banker och försäkringsbolag, med tydlig spårbarhet och releaseprocesser som klarar kraven på ändringshantering.

  • Tillverkningsindustri

    Produktkonfiguratorer, serviceportaler och SaaS-produkter för tillverkare av maskiner och utrustning, kopplade till affärssystem och fältservice.

Sverige

Tillgänglighet och e-legitimation från första release

Tillgänglighetslagen (2023:254) har gällt sedan den 28 juni 2025 för bland annat e-handelstjänster och banktjänster till konsumenter. Post- och telestyrelsen (PTS) är huvudsaklig marknadskontrollmyndighet, och från den 1 januari 2027 har Digitaliseringsmyndigheten den rollen. Offentliga aktörer omfattas av lagen (2018:1937) om tillgänglighet till digital offentlig service, med Digg som tillsynsmyndighet, och publicerar en tillgänglighetsredogörelse. Cyberresiliensförordningen gäller i hela EU med skyldigheter som börjar gälla i etapper.

Från den 1 december 2026 ska offentliga aktörers e-tjänster för enskilda godta e-legitimationer från det svenska godkännandesystemet på tillräcklig tillitsnivå. Den statliga e-legitimationen Sverige-id är godkänd på tillitsnivå 4, vid sidan av BankID och Freja+. Vi håller sådana krav i konfiguration och tydligt avgränsade moduler, så att en ny marknad blir en release och inte en förgrening av koden. Underlag om tillgänglighet och säkerhet tas fram i byggkedjan, redo för frågorna i en upphandling enligt LOU.

Frågor om verksamhets­system och SaaS

Ska vi bygga eget eller konfigurera en plattform?

Konfigurera en plattform där din process ligger nära standard, och bygg där processen är det som skiljer din verksamhet från andra eller där ingen plattform passar reglerna. Vi arbetar med Salesforce, SAP och Odoo och med egen kod, så vi har inget skäl att driva ett visst svar. Tjänsten Arkitektur och rådgivning gör valet uttryckligt.

Kan ni garantera att vår portal är tillgänglig?

Vi bygger enligt EN 301 549 och WCAG 2.2 AA, testar automatiskt och manuellt och levererar en rapport om tillgänglighet med eventuella kända brister, som underlag för din tillgänglighetsredogörelse. Vi lovar inte noll brister; vi lovar att hitta dem, redovisa dem och åtgärda det som ligger inom vårt uppdrag.

Kan ni modernisera utan en storslagen engångsmigrering?

Ja, och vi rekommenderar det. En styrande fasad gör att vi kan flytta en förmåga i taget medan det befintliga systemet fortsätter att fungera, med data som stäms av i varje steg.

Kan vårt eget team ta över programvaran?

Det är grundplanen. Kriterierna för överlämning avtalas i början, dina utvecklare parprogrammerar med våra under bygget, och beslutsunderlag och driftrutiner ligger i dina kodförråd.

Vad innebär cyberresiliens­förordningen för vår produkt?

Om du släpper ut programvara med digitala element på EU-marknaden kan den medföra skyldigheter om säker design, sårbarhetshantering och dokumentation. Vi tar fram det tekniska underlaget: SBOM, en sårbarhetsprocess och säkra standardinställningar.

Berätta vad som måste fungera medan det förändras

Vi föreslår den första förmågan att flytta och vad ditt team skulle äga när arbetet är klart.

Berätta om ditt projektLäs om modernisering