STORM

Service- og Teknologireferencemodellen (STORM)

STORM (Service- og teknologi referencemodel) er et rammeværk til beskrivelsen af de offentlige it-services og teknologiservices. STORM er grundlaget for et fælles sprog til beskrivelsen af it-systemer i den offentlige sektor og giver mulighed for genbrug og sammenligning af it-beskrivelser. På samme måde som FORM beskriver det offentliges opgaver, er STORM udviklet til at give en overordnet klassifikation og beskrivelse af de it-systemer, der bruges i den offentlige forvaltning. STORM definerer og beskriver lagene i den offentlige it-portefølje, og STORM tilbyder en kategorisering af it-services.

STORMEt it-system i det offentlige vil altid understøtte en eller flere forvaltningsopgaver i FORM. STORM anvendes til konsistent at klassificere og beskrive it-systemerne, så specifikke egenskaber ved de enkelte it-lag defineres entydigt, herunder blandt andet hvilket teknisk fundament it-systemet er baseret på.

Figuren illustrerer, hvordan STORM klassificerer løsninger/it-services.

Med version 2.2 af STORM er de væsentligste ændringer at lagdelingen fra STORM er understøttet via OIO-EA rammen og den fælles metamodel, og derfor ikke længere er en selvstændig kvalitet ved STORM rammeværket. Derudover er de øverste niveauer i STORM it-service kataloget blevet revideret, for at sikre en mere logisk sammenhæng til hvad it-løsningstyper rent faktisk kaldes i den daglige offentlige praksis. For illustration af lagdelingen henvises der til beskrivelsen af metamodellen ovenfor.

På it-service niveau er disse løsningstyper fortsat opdelt i funktions- eller komponentdel. For eksempel indeholder ’Sikkerhed og overvågning’ følgende kategorier:

  • 549 Adgangskontrol
  • 650 Kryptering
  • 652 Indtrængningsforebyggelse
  • 653 Indtrængningsopdagelse
  • 654 Hændelsreaktion
  • 655 Revisionsspor og analyse
  • 656 Certificering og akkreditering
  • 657 ISO27001 / DS484
  • 658 Virusbeskyttelse

Ændringen i det overordnede niveau har medført, at en række it-services er blevet flyttet rundt, så de ligger i de rigtige kategorier i den nye struktur. Der er dog forsøgt at sikre gennemsigtighed i forhold til version 2.1.1 af STORM ved at nummereringen på nederste niveau er bibeholdt. Vi har dog også valgt at tilføje og slette enkelte it-services, enten fordi vi fandt at de manglede eller fordi vi mente at de var for detaljerede i den funktionelle beskrivelse. En mere detaljeret gennemgang af ændringer vil blive publiceret som en ændringslog til version 2.2 af STORM.

Ønsker man at anvender korte koder, kan man fremadrettet referere til en løsnings-/it-servicetype ved at angive et bogstav (fx ’V’ hvis man tager afsæt i figur 4.1) og hvis man også ønsker den ekstra detalje, som beskrives på it-serviceniveau, så kan man tilføje denne ved at tilføje it-servicenummeret. Eksempelvis kan  man med ’V 549’ referere til en it-service i løsningstypekategorien ’Sikkerhed og overvågning’, der funktionelt understøtter adgangskontrol.

Som nævnt er de ny løsningstypekategorier udtryk for, hvordan man rent faktisk kategoriserer systemer den daglige offentlige praksis og kategorierne er blevet valideret op mod en række it-analyser gennemført i det offentlige, og de arkitekturbeskrivelser vi har kunnet finde rundt omkring. På den baggrund kan løsningstyperne langt hen ad vejen opfattes som COTS, altså standard it-systemer man kan gå ud og købe.

Der er dog en enkelt undtagelse, nemlig kategorien Specialsystemer. Kategorien tager højde for at der både nu, og formentlig også i mange år fremover vil eksistere systemer, som er specialudviklet til at understøtte en eller flere forretningsprocesser.

Typisk kunne der være tale om ældre systemer, men også systemer som er så specialiserede at de aldrig kan falde i en standardsystem-kategori er omfattet af disse. For både ældre systemer og meget specialiserede systemer er det dog vigtigt at uddybe beskrivelsen med information om hvilke forretningsservices, der understøttes, da det fortæller hvad systemet kan. Og for ældre systemer, der ofte kan være monolitter med rigtig meget forskellig funktionalitet, anbefales det at man fx opmærker den primære løsningstype i en tilsvarende kategori hvor der findes relevante standardsystemer, men udnytter muligheden for at opmærke sekundære løsningstyper til at beskrive delfunktionalitet i løsningen. Altså fx beskrive at ’Specialsystemet’ også ud over meget andet kan journalisere og gennemføre betalinger. Der henvises til dokumentationsmodeller nedenfor for hvordan man kan registrere disse oplysninger.

Leave a Comment