RIV Tekniska Anvisningar Livscykelhantering för tjänstekontrakt

RIV Tekniska Anvisningar Livscykelhantering för tjänstekontrakt


Version 1.0

ARK_0057

2019-08-28



Utgåvehistorik


Utgåva

Revision Datum

Beskrivning

Ändringarna gjorda av

Definitiv revision fastställd av

1.02019-08-28första version Björn HedmanArkitekturmötet 
1.12019-09-04tagit bort länk till bilag som inte skulle vara medBjörn HedmanBjörn & Ranjdar

Inledning

Livscykelhanteringen och regelverket som beskrivs nedan avser de tjänstedomäner som förvaltas inom Inera (nationella/gemensamma och applikationsspecifika) och avser att förtydliga vad som gäller för slutdatum för support och avveckling. (ofta kallat EndOfLife). Dokumentet avser att beskriva vad som gäller när slutdatum utlysts, bakomliggande skäl för att utlysa slutdatum definieras inte i detalj i reglerna eftersom skälen till detta normalt är domänspecifika men visst stöd för resonemang finns i bilaga 1.

Angivna tidsintervall kan utökas men inte minskas, om en domän regelmässigt förlänger tidsintervall så bör detta tydligt beskrivas för den aktuella domänen så att anslutande parter vet vad som gäller.

Externa förvaltningar (Externa domäner)  är fria att själva definiera regler men det är viktigt att dessa förtydligas

Tjänstekontrakt uppstår

Initiativen att skapa nya Gemensamma/Nationella tjänstekontrakt kommer från olika håll och kan tex. komma från projekt eller förvaltningar och det finns mer eller mindre beskrivna processer och rutiner för detta i form av Ineras programkontor m.m. så därför läggs inte vikt på denna fas i den här beskrivningen. istället fokuseras arbetet på att beskriva vad som gäller när tjänstekontrakt ska avvecklas.

Respektive tjänstekontraktsförvaltning  behöver vara klar över hur beslutsgången ser ut och hur finansiering ska fungera både på kort och lång sikt (skapa resp förvalta tjänstekontrakten)

Tjänstekontrakt förvaltas

Under ett tjänstekontrakts livstid förvaltas detta både i form av att dokumentation uppdateras men också genom mer tekniska förändringar i form av nya versioner.

(med förvaltning avses här endast arbete kring själva tjänstekontrakten, installation och konfiguration i tjänsteplattformar ingår inte i detta arbete)

En ny version kan vara bakåtkompatibel med tidigare version (detta indikeras med underversion ex 1.1) eller så kan den bryta kravet på kompabilitet ( som indikeras som huvudversion ex 2.0).

En ny underversion ersätter alltid tidigare underversioner i publicering (publicering 1.0 -> 1.1)

Det kan dock finnas flera samtidiga huvudversioner publicerade och installerade i tjänsteplattformar. (1.x och 2.x)

Förvaltning innebär också att bevaka utökade behov, frågeställningar och felrapporter.

(Version av) tjänstekontrakt avvecklas

Med avveckling avses här att:

  • Supporten kring den aktuella huvudversionen upphör både gällande felrättningar och rådgivning. Den publicerade statusen ändras. (och eventuella paketeringar tas bort)
  • Virtuella och aggregerande tjänster som baseras på den huvudversionen av tjänstekontrakt avinstalleras i Ineras tjänsteplattform
  • Gemensamt finansierad utveckling ska heller inte ske mot versioner med utlyst slutdatum

Källkod kommer inte nödvändigtvis rensas bort (men kommer inte underhållas eller nödvändigtvis flyttas vid eventuellt byten av källkodssystem) och det finns alltså inget som hindrar fortsatt lokalt användande så länge detta är självständig.

Besluta om avveckling

Ansvarig förvaltning är den part som tar beslut om avveckling. Skäl till avveckling kan variera men bör ha sitt ursprung i faktorer som kostnadsbesparing, regulatoriska krav, minskad komplexitet eller helt enkelt att ingen längre använder en viss version.

Skälen att besluta om avveckling kan såklart vara olika och är upp till domänerna att avgöra men omfattar bland andra:

  • Inget eller litet användande av viss version av TK
  • Komplexitet vid användning av många versioner

Andra faktorer som höga kostnader för support/anslutning m.m borde indikera stor användning som snarare ska utredas kontra levererad nytta än som direkt grund för avveckling.

Så länge ett tjänstekontrakt levererar mer värde än sin kostnad finns det inget egenvärde i att avveckla det.

Annonsera slutdatum (end of life announcement)

När beslut om att avveckla en version har tagits så ska detta meddelas så att eventuella kvarvarande användare kan planera för att uppgradera till nyare version eller lösa informationsförsörjning på annat sätt.

  • Beslutet meddelas dels där tjänstekontraktet är publicerat (rivta.se) samt via nyhetsbrev och andra kontaktvägar så som utskick till förvaltningsobjekt som använder kontrakten.
  • För att parter ska ha en kalkylsäkerhet så ska slutdatum annonseras minst 18 månader innan någon påverkan sker på befintliga installationer, dvs ingen avinstallation sker inom denna period. En förvaltning kan självklart välja att annonsera slutdatum tidigare.
  • Under tiden fram till slutdatum införs inga funktionella förändringar för versioner som avvecklas
    • Rättningar av tekniska fel samt anpassningar till regulatoriska krav kan ske under hela perioden fram till slutdatum om det anses vara rimligare än att påskynda övergång till högre version (om sådan finns)
  • Kunskapsmässig support kring tjänstekontraktsversionen bibehålls under hela tiden fram till slutdatum.

Begränsningar i support runt tjänstekontrakt efter annonsering av slutdatum

Det ska inte ske några tekniska nyanslutningar mot versionen som ska avvecklas.

Förberedelser inför avinstallation i nationella tjänsteplattformen

När slutdatum närmar sig planerar förvaltningen för Ineras tjänsteplattform för avveckling av versionen och kontrollerar då eventuella kvarvarande anslutna parter och verifierar att dessa inte längre använder versionen.

Avinstallation i tjänsteplattform

När slutdatum inträffat och kontroller av användning och konfiguration gjorts så

  • I tjänsteplattformen avinstalleras virtuella tjänster som baseras på den huvudversionen av tjänstekontrakt.
  • Eventuella aggregerande tjänster som baseras på den huvudversionen av tjänstekontrakt avinstalleras.
  • All eventuell kvarvarande addressering till avvecklad version raderas