RIV Tekniska Anvisningar Livscykelhantering för tjänstekontrakt
Version 1.2
ARK_0057
2022-09-15
| RIV Tekniska Anvisningar Livscykelhantering för tjänstekontraktVersion 1.2 ARK_0057 2022-09-15 |
Utgåvehistorik
Utgåva | Revision Datum | Beskrivning | Ändringarna gjorda av | Definitiv revision fastställd av |
1.0 | 2019-08-28 | första version | Björn Hedman | Arkitekturmötet |
1.1 | 2019-09-04 | tagit bort länk till bilaga som inte skulle vara med | Björn Hedman | Björn & Ranjdar |
1.2 | 2022-09-15 | Utökat beskrivningar och strukturerat om. Lagt till Bilaga 1 med förslag till tillämpningar kring hantering av uppgradering till ny majorversion | Joakim Lundin Björn Hedman |
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 end of life).
Utöver att användas av tjänstedomänernas förvaltningar så kan även informationsförsörjningstjänster och gemensamma (nationella) tillämpningar följa samma modell. Detta för att hantera sin användning av tjänstekontrakt och avveckling av stöd för versioner och skapa en tydlighet för de parter som ingår i sammarbetet. I dessa fall så leder avvecklingen av en version inte nödvändigtvis till att stöd i tjänsteplattformar avvecklas eftersom andra tillämpningar kan ha fortsatt användning av versionen. Det är viktigt att påpeka att parter som tar bort stöd för en viss version också måste uppdatera detta i tjänsteadresseringskatalogen TAK.
Dokumentet beskriver vad som gäller när slutdatum utlysts, men bakomliggande skäl för att utlysa slutdatum, och ta beslut om avveckling, definieras inte i detalj i reglerna. Detta eftersom skälen till detta normalt är domänspecifika.
Observera att det här finns ett visst fokus på livscykeln utifrån tjänstekontraktets förvaltning och dess tillgänglighet i nationella tjänsteplattformen NÄR ett beslut om avveckling har tagits. Processen för beslut om avveckling kan se olika ut beroende på hur utbredd användning som finns för ett visst tjänstekontrakt. Det är heller inget självändamål utifrån domänerna eller tjänsteplattformen att ha så få versioner som möjligt. För specifika tillämpningar kan det dock finnas vinster i att begränsa antalet parallella majorversioner givet att det kan vara svårt att skapa vettiga tjänster om informationstillgången varierar kraftigt. |
Nedan angivna tidsintervall kan utökas men inte minskas, om en domän regelmässigt förlänger tidsintervall så bör detta tydligt beskrivas i en policy 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 dokumenteras tydligt.
Olika typer av nya versioner: I denna dokumentation kommer versionstyperna benämnas Major/Minor eftersom det är ett vedertaget språkbruk i branchen. I språkbruket på andra platser kan begreppen “huvudversion” och “underversion” användas. När ett tjänstekontrakt behöver förändras så ändras versionen antingen i form av en minorversion om ändringen anses vara bakåtkompatibel. Om den inte anses vara bakåtkompatibel så blir det en ny majorversion. För mer information om versionshantering inom RIV-TA hänvisas till RIV Tekniska Anvisningar Översikt (Kapitel 8.2) |
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 för att skapa nya tjänstekontrakt och förvalta dessa ska fungera, både på kort och lång sikt .
Med förvaltning avses här endast arbete kring själva tjänstekontrakten samt också att bevaka utökade behov, frågeställningar och felrapporter. Installation och konfiguration i tjänsteplattformar samt anslutning av aktörer ingår inte i detta arbete. |
Under ett tjänstekontrakts livstid förvaltas detta både i så mån att dokumentation uppdateras och rättas men också genom mer tekniska förändringar i form av nya versioner med schemaförändringar.
En ny version kan vara bakåtkompatibel med tidigare version och släpps då som en minorversion (ex 1.1) eller så kan den bryta kravet på kompabilitet genom att släppas som en ny majorversion( ex 2.0).
En ny minorversion ersätter alltid tidigare minorversioner i publicering (publicering 1.0 -> 1.1) samt i Ineras tjänsteplattform även om den installerade basen hos andra parter kan bestå av en mix av versioner.
Det är också viktigt att påpeka att det kan finnas flera samtidiga majorversioner publicerade och installerade i tjänsteplattformar. (1.x och 2.x) |
Med avveckling avses här att:
Supporten kring den aktuella majorversionen 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 majorversionen 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.
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 ett tjänstekontrakt.
Komplexitet vid användning av flera samexisterande versioner
Så länge en version av ett tjänstekontrakt tillför mer värde än det kostar att förvalta finns det inget egenvärde i att avveckla det.
Andra faktorer som höga kostnader för support/anslutning med mera borde indikera stor användning som snarare ska utredas i relation till levererad nytta än som direkt grund för avveckling. |
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 senare huvudversion eller lösa informationsförsörjning på annat sätt.
Beslutet meddelas dels där tjänstekontraktet är publicerat (rivta.se) samt andra kontaktvägar som domänförvaltningen använder.
För att parter ska ha en möjlighet att bedöma en ny investering i en viss version, samt ge alla existerande användare en rimlig chans att anpassa sina lösningar, så ska slutdatum annonseras minst 18 månader innan någon avveckling sker på befintliga centrala installationer. En förvaltning kan självklart välja att annonsera slutdatum med längre framförhållning.
Under tiden fram till slutdatum införs inga funktionella förändringar för den majorversion 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.
Det ska inte ske några tekniska nyanslutningar till central infrastruktur mot den version som ska avvecklas.
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.
När slutdatum inträffat och kontroller av användning och konfiguration gjorts så görs följande:
I tjänsteplattformar avinstalleras eventuella virtuella tjänster som baseras på den majorversionen av tjänstekontrakt.
Eventuella aggregerande tjänster som baseras på den majorversionen av tjänstekontrakt avinstalleras.
All eventuell kvarvarande addressering (TAK) till avvecklad version raderas.