2026-04-24

Agenda

• Del A
  • Intro deltagare
  • Kort om förväntningar på dagen, bordet runt för de olika organisationerna
• Del B
  • Kort om förväntningar på piloten, bordet runt för de olika organisationerna
  • Förhållande mellan pilot och det "ordinarie" arbetet som sker inom SIB
  • Mål, avgränsningar, förutsättningar, utvärderingskriterier
• PAUS
• Del C
  • Milstolpar och tidplan
  • Förväntningar på varandra - vad krävs för att det här ska lyckas?
• Nästa steg
  • Organisera arbetsgrupp
  • Nästa aktivitet
  • ...

Noteringar: 

1. Syfte med mötet

• Se agenda ovan

2. Det vi är överens om

2.1 Definition av pilot

• Piloten är:
  • produktion (skarpt läge)
  • i liten skala
  • MVP-baserad
• Piloten ska:
  • användas för lärande
  • inte vara perfekt
  • vara avsiktligt avgränsad

2.2 Syfte med piloten

• Testa SIB steg 1 i praktiken
• Säkerställa att:
  • avtal går att använda
  • tekniskt mönster fungerar
  • dokumentation räcker

Viktigt:

• Fokus är inte att optimera
• Fokus är att validera att helheten fungerar

2.3 Vad vi testar

• Att det går att:
  • ansluta aktörer
  • tillämpa avtal och processer
  • använda federationslösningen i produktion
• Testet omfattar:
  • teknik
  • avtal
  • processer (hela “paketet”)

2.4 Vad vi INTE testar (avgränsningar)

• Skalbarhet (fullt ut)
• Flera kontexter / chaining
• Komplett driftoptimering
• Full ekosystemutbredning

Dock:

• Vi ska kunna resonera om skalbarhet

2.5 Användningsfall styr piloten

• Vi är överens om att:
  • alla förväntningar ska täckas av användningsfall
  • inget utanför ska inkluderas implicit

Kärn-use case:

• En aktör kan:
  • erbjuda avtal
  • erbjuda teknik
  • erbjuda processer
  • ansluta medlemmar

2.6 Produktion som mål

• Piloten ska köras i produktion
• Det innebär:
  • riktiga system
  • riktiga användare
  • riktiga konsekvenser

2.7 Miljöer

• Minimum:
  • QA
  • Produktion
• Sandbox:
  • inte nödvändig initialt
• Viktigt:
  • Miljön (särskilt VOK) måste leva vidare efter piloten

2.8 SLA och drift

• SLA i piloten:
  • definieras som överenskommelse mellan parter
• Viktiga delar:
  • resolver-svar och giltighetstider
  • cache-strategier
  • incidenthantering

2.9 Två typer av lärande

Vi är överens om att skilja på:

1. Tekniskt lärande
2. Administrativt/organisatoriskt lärande

Detta behöver hanteras separat i arbetet

2.10 Arbetsformer (riktning)

• Små, tvärfunktionella team
• Workshops (inte bara dokumentation)
• Iterativt arbete
• Rätt kompetens in vid rätt tillfälle

3. Öppna / Utestående frågor 

3.1 Pilotens exakta scope

• Är VOK rätt avgränsning?
• Är det tillräckligt representativt för framtida behov?

3.2 SLA-frågan

• Var ska SLA definieras långsiktigt?
  • federationsnivå?
  • AO?
  • medlem?
• Hur ska resolver- och cache-policyer standardiseras?

3.3 Miljöstrategi

• Behövs fler miljöer längre fram?
• Hur ser övergången till bredare utrullning ut?

3.4 Testomfattning

• Vilka testfall ska ingå exakt?
• Hur mycket ska vara:
  • funktionellt
  • icke-funktionellt (robusthet, störning)

3.5 Ekosystemperspektiv

• Hur säkerställer vi att:
  • lösningen fungerar i verkligt ekosystem?
  • leverantörer kan delta?

3.6 Arbetsformer (konkretisering)

• Hur organiseras arbetet praktiskt?
• Hur separerar vi teknik vs administration i genomförandet?

4. TODOs

4.1 Alla deltagare

• Gå igenom utvärderingskriterier
  • ur sin egen roll
  • samt bidra till andra roller

4.2 Gemensamt

• Ta fram:
  • utvärderingskriterier (lärandemål)
  • aktivitetsplan

4.3 Användningsfall

• Förtydliga och dokumentera:
  • befintliga use case
  • eventuella luckor

4.4 Test

• Vidareutveckla:
  • testfall (funktionella och icke-funktionella)

4.5 DIGG

• Planera:
  • lasttester / störningstester (robusthet)

4.6 Struktur & dokumentation

• Strukturera upp:
  • var dokumentation ska ligga
  • hur den används (undvika “Confluence overload”)

4.7 Nästa möte

• Fokus:
  • utvärderingskriterier
  • aktivitetsplan
• Förberedelse:
  • genomlästa kriterier
  • initiala inspel per roll