Hoppa till huvudinnehållet
FromNine
Meny

Programvara och moln

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

SaaS-produkter, e-tjänster för invånare och personal och de system som verksamheten vilar på: byggda så att de klarar tillgänglighetskraven, är säkra redan i grundinställningarna och kan skötas av organisationens egna utvecklare i många år efter lanseringen.

För programvaruföretag och offentliga organisationer i Finland vars användare möter tjänsten på finska, svenska och ofta engelska.

Berätta om ditt projektLäs om modernisering
Verksamhets­system och SaaS: skikten i tjänstenFyra skikt ovanpå varandra. Uppifrån och ned: det tillgängliga gränssnittet som människor använder, domänmodulerna som innehåller reglerna, plattformstjänsterna för kundseparering och identitet och längst ned det säkra leveransflödet.01Tillgängliga gränssnitt02Domänmoduler och regler03Kundseparering, identitet, data04Säkert leveransflöde
  1. 01Domänmodeller för regelstyrt arbete som handläggning av ärenden
  2. 02EN 301 549 och WCAG 2.2 AA inbyggt redan i de första skisserna
  3. 03Beslutslogg och dokumentation som gör att dina utvecklare kan ta över

01 Utmaningar

Typiska skäl till att ett system ska byggas om

  1. 01

    En liten ändring tar månader

    Systemet gör sitt jobb, men kärnan är så skör att ingen vill röra den. Även små justeringar kräver långa regressionstester och väntan på nästa releasefönster.

  2. 02

    E-tjänsten fungerar inte för alla

    Skärmläsaren går vilse, den svenska versionen ligger efter den finska och på mobilen faller layouten isär. Användarna klagar innan tillgänglighetsgranskningen ens har gjorts.

  3. 03

    Kundanpassningar krockar

    Produkten har vuxit genom specialversioner för enskilda kunder. Releaserna har blivit förhandlingar, och en del kunder har fastnat på gamla versioner.

  4. 04

    Leverantören tog kunskapen med sig

    Ingen skrev ned varför systemet ser ut som det gör. De som byggde det har gått vidare, och det enda som återstår är koden.

  5. 05

    Säkerhets­frågorna hopar sig

    Anbudsförfrågan kräver en SBOM, en rutin för sårbarheter och belägg inför cyberresiliensförordningen. Inget av det finns färdigt.

02 Leveranser

Det här levererar vi

  1. 01 Utveckling av SaaS-produkter

    En kodbas som betjänar många kunder samtidigt: en genomtänkt modell för kundseparering, inställningar i stället för specialkod och releaser som når varje kund på en gång.

    Det här gör vi

    • Val av modell för kundseparering: delad, poolad eller isolerad per kund
    • Strategi för konfiguration och funktionsflaggor
    • Integration med mätning och fakturering
    • Releasetåg med utrullning som tar hänsyn till varje kund

    Det här får du

    • Utformning av kundseparering och isolering
    • Konfigurationsmodell med skyddsräcken
    • Releaseprocess med återställning per kund

  2. 02 Domändesign för komplicerade regler

    När reglerna är själva produkten, som i ärendehantering, prövning av rätt till förmåner eller beräkningar som följer lagstiftningen, modellerar vi domänen noggrant. Valet mellan modulär monolit och mikrotjänster görs medvetet, och oftast vinner monoliten i början.

    Det här gör vi

    • Event storming med de sakkunniga i verksamheten
    • Avgränsade kontexter och modulgränser
    • Regler som görs uttryckliga och testbara
    • Arkitekturbeslut dokumenterade för de stora valen

    Det här får du

    • Domänmodell och kontextkarta
    • Modulär kodbas med gränser som kontrolleras
    • Körbara specifikationer för de viktigaste reglerna

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

    Gränssnitten byggs på ett designsystem med tillgängliga komponenter och har flera språk från första versionen. För en finländsk tjänst betyder det finska och svenska som hålls i takt med varandra och identifiering med Suomi.fi-identifikation när tjänsten kräver det.

    Det här gör vi

    • Designsystem med tillgängliga komponenter
    • Innehåll skrivet på klarspråk
    • Tester med hjälpmedel tillsammans med verkliga användare
    • Arbetsflöde för båda språkversionerna och för översättning

    Det här får du

    • E-tjänst på ett återanvändbart designsystem
    • Rapport om tillgänglighet och underlag för tillgänglighetsutlåtandet
    • Arbetsflöde för innehåll och översättning

  4. 04 Kvalitetsarbete och säker utveckling

    Automatiska tester på de nivåer där de gör nytta, kontraktstester mellan tjänsterna och prestandatester före lansering, i en utvecklingsprocess som vilar på OWASP ASVS, SBOM och kontroll av 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

    • Automatiska testsviter i leveransflödet
    • Rapport om säkerhetsverifieringen
    • Process för sårbarheter som är förberedd för cyberresiliensförordningen

  5. 05 Modernisering steg för steg

    Det gamla systemet ersätts bit för bit bakom en fasad som styr varje funktion rätt, medan verksamheten går som vanligt. Mer om detta under modernisering av äldre system.

    Det här gör vi

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

    Det här får du

    • Ordning för moderniseringen med milstolpar för verksamheten
    • Fasad och nya moduler i produktion
    • Avstämda data vid varje övergång

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

    Programvara som organisationen kan äga själv: begriplig kod, beslutslogg, driftinstruktioner och en överlämningsplan som görs upp när projektet startar och inte i sista stund.

    Det här gör vi

    • Parprogrammering med dina utvecklare under bygget
    • Arkitekturbeslut som förvaras med koden
    • Driftinstruktioner och anvisningar för jour
    • Milstolpar för kunskapsöverföringen

    Det här får du

    • Plan för överlämningen med godkännandekriterier
    • Dokumentation i dina egna kodförråd
    • Ett internt team som har fått utbildning

03 Arkitektur

En illustrativ referens­arkitektur

När ett nytt verksamhetssystem tar över efter ett gammalt ser lösningen ofta ut så här. Användarna möter ett tillgängligt gränssnitt. Bakom det avgör en fasad om en funktion ska hanteras av det gamla eller det nya systemet, och ett API-skikt med fasta kontrakt leder in till en modulär kärna som är indelad efter verksamhetens områden.

Kundseparering och konfiguration sköts av egna plattformstjänster i stället för villkor som sprids ut i koden. Varje bygge går genom tester och säkerhetskontroller och lämnar efter sig en SBOM.

Skikten i bilden

Användare
Invånare, kunder och personal, på alla slags enheter och med hjälpmedel, på finska eller svenska.
Modernisering
Den styrande fasaden, det befintliga systemet och datamigreringen med avstämning.
Plattform
API-skikt, 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. Användare

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

  2. Modernisering steg för steg

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

  3. Plattform

    • API-skikt och kontrakt
    • Identitet och roller
    • Modulär kärna: mottagning, ä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 ett kundsystem.

Läs diagrammet som text

Bilden visar hur användarna når ett tillgängligt gränssnitt, som via en styrande fasad och ett API-skikt leder till en modulär kärna med avgränsade kontexter.

En del funktioner skickar fasaden fortfarande till det gamla systemet, som avvecklas stegvis. Dess uppgifter flyttas över till driftdatabaserna genom en migrering som stäms av.

API-skiktet använder identitetshanteringen, och under kärnan finns tjänster för kundseparering och konfiguration. Längst ned ligger bandet för säker leverans: kontraktstester, prestandatester, säkerhetsverifiering och SBOM.

04 Överväganden och gränser

Tekniska avvägningar och gränser

  • Först en modulär monolit

    Så hanterar vi det

    Systemet börjar som en enda driftsättningsenhet med tydliga moduler. Tjänster bryts ut först när skalning, releasetakt eller teamens ansvar gör det motiverat.

    Gränser och beroenden

    Mikrotjänster är lika mycket en organisationsfråga som en teknisk fråga. Saknas teamen som ska äga dem blir resultatet högre kostnader och fler felkällor.

  • Tillgänglighet kräver arbete

    Så hanterar vi det

    Komponenterna är tillgängliga från början, leveransflödet kontrollerar automatiskt och inför varje större release testar vi manuellt med skärmläsare och andra hjälpmedel.

    Gränser och beroenden

    Verktygen hittar bara en del av bristerna. För full överensstämmelse behövs manuell granskning och helst tester med personer med funktionsnedsättning.

    Det redaktörerna publicerar efter lanseringen, på finska eller svenska, måste hålla samma nivå. Vi utbildar dem, men innehållet ansvarar organisationen för.

  • Datan sätter takten

    Så hanterar vi det

    Migreringen planeras funktion för funktion, repeteras och stäms av, och verksamheten godkänner varje övergång.

    Gränser och beroenden

    Hur rena de gamla uppgifterna är avgör ofta tidtabellen. Att städa dem kräver verksamhetens kunskap lika mycket som teknisk.

  • Krav på programvaru­produkter

    Så hanterar vi det

    SBOM, rutiner för sårbarheter och säkra grundinställningar ingår som standard i vårt leveransflöde, och det gör produkten redo för cyberresiliensförordningen.

    Gränser och beroenden

    Om förordningen omfattar just din produkt är en juridisk bedömning. Vi står för det tekniska underlaget; organisationens jurister drar slutsatsen.

05 Arbetssätt

Så arbetar vi

Korta varv, riktiga användare tidigt och en överlämning som planeras redan första veckan.

  1. 01

    Lär känna domänen

    Workshoppar med dem som kan reglerna och en förteckning över vad dagens system faktiskt gör.

    ResultatKontextkarta och de första besluten

  2. 02

    Börja smalt

    En enda funktion byggs hela vägen genom fasaden och tas i bruk av riktiga användare.

    ResultatEn första funktion i drift

  3. 03

    Bygg ut en funktion åt gången

    Med varje release flyttar en funktion med sina data och användare, och avstämning och återgång finns förberedda.

    ResultatReleaseplan funktion för funktion

  4. 04

    Överlämning

    Dina utvecklare arbetar i par med våra, tar över jouren och blir ägare till färdplanen när kriterierna är uppfyllda.

    ResultatGodkänd överlämning

06 Mänsklig kontroll

Där människor behåller kontrollen

Kontroll över ett verksamhetssystem är att veta vem som ändrade något, vem som sa ja och hur ändringen kan backas.

  • Produktägaren prioriterar

    Det är din produktägare som bestämmer ordningen och tar emot varje leverans. Vi kommer med förslag, produktägaren avgör.

  • Inställningar ändras spårbart

    Kundinställningar och funktionsflaggor kan bara ändras av de roller du har utsett, och varje ändring lämnar spår.

  • Ingen övergång utan ja

    Verksamheten godkänner varje flytt från gammalt till nytt, och återgången är repeterad innan dess.

  • Besluten skrivs ned

    Beslutsloggen visar vad som valdes, av vem och med vilka motiv, så att nästa team kan ompröva besluten med full kännedom.

07 Teknik

Tekniker vi arbetar med

Serversidan
  • Java och Kotlin
  • .NET
  • TypeScript och Node.js
  • Python
Gränssnitt
  • React och Next.js
  • Angular
  • Designsystem med tillgängliga komponenter
  • Mobilappar, plattformsspecifika eller plattformsoberoende
Data
  • PostgreSQL
  • SQL Server och Oracle i 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

Teknikerna nämns för att visa vilken erfarenhet vi har. Det betyder inte att vi är partner till tillverkarna eller att de har gått i god för oss.

08 Exempel

Ett illustrativt exempel

Illustrativt exempel

En tvåspråkig e-tjänst för en samkommun

01Utgångsläge
En samkommun tar emot ansökningar från invånare och företag i flera medlemskommuner. Ansökningarna kommer som PDF-blanketter per e-post, den svenska blanketten släpar ofta efter den finska och blanketterna klarar inte tillgänglighetsgranskningen.
02System
En e-tjänst på ett gemensamt designsystem med identifiering via Suomi.fi-identifikation, Suomi.fi-fullmakter för den som ansöker för ett företags räkning och finsk och svensk text som publiceras samtidigt. Ansökningarna går direkt till ärendehanteringssystemet.
03Mänsklig kontroll
Handläggarna godkänner innehållet och blanketternas logik på båda språken; produktägaren beslutar om gemensamma funktioner. Beslut i ärendena fattas av tjänsteinnehavare, inte av e-tjänsten.
04Det här skulle vi mäta
Antal tillgänglighetsbrister per release, ledtiden för en ändring och andelen ändringar där den svenska versionen publiceras samma dag som den finska.

09 Branscher

I din bransch

  • Offentlig sektor

    Ärendehantering och e-tjänster som uppfyller tillgänglighetskraven i lagen om tillhandahållande av digitala tjänster, fungerar på finska och svenska och ansluter till Suomi.fi-tjänsterna.

  • Finansiella tjänster

    Kundportaler och interna system för banker och försäkringsbolag, med spårbara ändringar och releaser som går igenom ändringshanteringen.

  • Tillverkningsindustri

    Konfiguratorer, serviceportaler och SaaS-tjänster för tillverkare av maskiner och apparater, kopplade till affärssystemet och fältservicen.

Finland

Finländska krav på e-tjänster

Tillgänglighetskraven gäller i Finland genom lagen om tillhandahållande av digitala tjänster (306/2019), som genomför webbtillgänglighetsdirektivet för den offentliga sektorn och kräver ett tillgänglighetsutlåtande, och genom lagen om tillgänglighetskrav för vissa produkter (102/2023). Kraven enligt tillgänglighetsdirektivet tillämpas sedan 28 juni 2025, och sedan 1 januari 2025 är det Traficom som övervakar tillgängligheten i digitala tjänster. Cyberresiliensförordningen är däremot en enda EU-förordning, med skyldigheter som börjar gälla i etapper.

En e-tjänst för en tvåspråkig myndighet ska fungera på finska och svenska, och statliga och kommunala myndigheter ska erbjuda identifiering via Suomi.fi-identifikation i sina lagstadgade tjänster. Användaren identifierar sig till exempel med nätbankskoder, mobilcertifikat eller certifikatkort, och med Suomi.fi-fullmakter kan en person sköta ärenden för ett företag eller en annan person.

Vi lägger språkversioner, identifiering och nationella integrationer i konfiguration och tydligt avgränsade moduler, så att ett nytt språk eller en ny kundgrupp blir en release och inte en ny kodgren. Underlaget om tillgänglighet och säkerhet tas fram av leveransflödet, färdigt för de frågor som ställs i en upphandling.

Frågor om verksamhets­system och SaaS

Ska vi bygga skräddarsytt eller konfigurera en plattform?

Ligger processen nära branschstandard lönar det sig att konfigurera en plattform. Är processen det som gör din organisation unik, eller passar ingen plattform reglerna, är eget bygge rätt. Eftersom vi arbetar både med Salesforce, SAP och Odoo och med egen kod har vi inget att vinna på ett visst svar. Inom arkitektur och rådgivning gör vi valet synligt och motiverat.

Kan ni garantera att vår e-tjänst är tillgänglig?

Vi bygger enligt EN 301 549 och WCAG 2.2 AA, testar både med verktyg och för hand och lämnar en rapport om kända brister. Den fungerar som underlag för tillgänglighetsutlåtandet som lagen om tillhandahållande av digitala tjänster (306/2019) kräver. Att det inte finns en enda brist kan ingen lova; vi lovar att leta upp bristerna, redovisa dem och rätta det som hör till vårt uppdrag.

Kan ni modernisera utan en stor engångsmigrering?

Ja, och vi avråder från en stor övergång på en enda dag. Med en fasad framför systemen flyttar vi en funktion i sänder medan det gamla systemet är kvar i drift, och uppgifterna stäms av efter varje flytt.

Kan vårt eget team ta över programvaran?

Ja, det är planen från början. Vi bestämmer kriterierna för överlämningen när projektet startar, dina utvecklare programmerar i par med våra och beslutslogg och driftinstruktioner sparas i organisationens egna kodförråd.

Vad innebär cyberresiliensförordningen för vår produkt?

Släpper du ut programvara med digitala element på EU-marknaden kan du få skyldigheter kring säker design, sårbarheter och dokumentation. Vi tar fram det tekniska underlaget, bland annat SBOM, en rutin för sårbarheter och säkra grundinställningar.

Vad måste fortsätta fungera medan systemet byts ut?

Berätta det, så föreslår vi vilken funktion som flyttas först och vad ditt team äger när vi är klara.

Berätta om ditt projektLäs om modernisering