...
- 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
- enas om vad piloten är
- tydliggöra mål, scope och användningsfall
- påbörja struktur för utvärderingskriterier och arbetssätt
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å:
- Tekniskt lärande
- 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