I 2011 blev OIO EA, FORM og STORM samlet i Digitaliseringsstyrelsen, og der har siden pågået et arbejde med at sikre sammenhængen i disse værktøjer. I Et fælles overblik over it-arkitekturen (udkast) (publiceret 17/1-2013) giver Digitaliseringsstyrelsen en første samlet præsentation af arbejdet med at skabe sammenhæng mellem it-arkitekturværktøjer, og præsenterer den samlede model for overbliksarbejdet. Herunder også de ændringer som arbejdet har medført i de bagvedliggende modeller, herunder OIO EA, FORM og STORM.

Digitaliseringsstyrelsen har lagt udkastet ud til kommentering i en såkaldt beta-version, og Digitaliseringsstyrelsen inviterer interessenter til at kommentere på det foreliggende arbejde. At det er en beta-version indikerer, at der er tale om det foreløbige arbejde og den foreløbige vejledning, som vi ønsker at afprøve hos potentielle brugere af modellen. Styrelsen inviterer alle interesserede til at indsende kommentarer, både til vejledning og model.

Dokumentet giver ikke en detaljeret beskrivelse af OIO EA, FORM og STORM, men fokuserer på at beskrive den nye sammenhæng, samt opstille eksempler for en faktisk benyttelse. Dog indeholder dokumentet beskrivelser af værktøjerne i det omfang arbejdet med at skabe sammenhæng mellem værktøjerne også har medført ændringer i indholdet af OIO EA, FORM og STORM.

Dokumentet er præsenteret nedenfor i en lettere redigeret udgave (tilpasset web).

Formål
Det overordnede formål for arbejdet med it-arkitekturværktøjerne er at sikre overblik, sammenhæng ogeffektiv systemudvikling i det offentlige. It-arkitekturværktøjerne skal dermed understøtte it-projektledere, it-chefer, it-arkitekter og udviklere, herunder også eksempelvis Statens IT-projektråd, Digitaliseringsstyrelsen, KL og Statens It, som alle har en rolle i vurderingen af og styringen af den offentlige digitalisering. Fokusområder for arbejdet beskrevet i dette dokument kan opsummeres til:

• Skabe sammenhæng mellem OIO EA, FORM og STORM
• Forbedre og understøtte sammenhængen til den faktiske benyttelse af produkter, altså at beskrive værktøjerne og mulighederne i en samlet og sammenhængende benyttelseskontekst
• At imødekomme ønsker til forbedringer til de enkelte værktøjer

Tidligere har de enkelte værktøjer især været velegnede til at beskrive delelementer af EA i en bestemt kontekst, fx det offentliges opgaver via FORM, applikationer og teknologi via STORM og arkitekturleverancer via OIO EA. Med arbejdet, der præsenteres nedenfor, sættes de enkelte dele ind i én model, hvor fokus er på at beskrive relationerne mellem delene.

Metamodelarbejdet er inspireret af det arbejde der er pågået i The Open Group omkring Archimate standarden, samt forskellige offentlige parters arbejde med it-porteføjlestyring på baggrund af FORM og STORM.

Metamodel

Under overskriften Et samlet overblik har Digitaliseringsstyrelsen introduceret en metamodel, som samler og fokuserer på sammenhænge mellem de eksisterende it-arkitekturværktøjer OIO-EA, FORM og STORM. OIO EA danner den samlede overordnede ramme for arbejdet med opdelingen i Strategi, Forretning, Information, Applikation, Teknologi og Styring.

Metamodellen skal sikre at man fra forskellige perspektiver kan finde relevante informationer på baggrund af en ensartet og sammenhængende dokumentation.

Klassifikation
Til beskrivelsen af elementerne i rammen kommer FORM, STORM, OIO XML og også fremadrettet Grunddatabeskrivelserne i spil.

FORM understøtter beskrivelsen af forretnings- og strategisøjlerne ved at understøtte kategoriseringen af forretningsservices, -processer og –funktioner, samt ved at vedligeholde reference til informationer om organisering og lovgivning, der understøtter beskrivelsen af aktører og strategi. Hvis man opmærker forretningsservices, -processer og –funktioner kan man altså fra FORM-online finde relateret information om den bagvedliggende lovgivning og finanslov for opgaven, samt information om hvilke parter, der deltager i den opgave i offentligt regi.

OIO XML og Grunddataarbejdet danner grundlaget for beskrivelsen af informationssøjlen via beskrivelser af begrebsmodel og datastandarder. Ved at dokumentere hvilke informationer eller data en forretnings-, applikations- eller teknologiservice er afhængig af, kan man struktureret opsamle informationer om relationer på dataniveau. Fx få overblik over at en forretningsservice kan være afhængig af en applikationsservice, fordi forretningsservices bruger de data som applikationsservicen udstiller.

STORM understøtter beskrivelsen af applikations- og teknologisøjlerne ved at kategorisere applikations- og teknologiservices, samt ved at levere en model til beskrivelsen af it-lagene. Kategoriseringen kan både benyttes til at give information om, hvor mange af den samme ’type’ systemer man har i sin it-portefølje, men med relationen til forretningsservices også benyttes til at danne overblik over hvor man måske mangler it-understøttelsen. Derudover afspejler de forskellige lag – fra den konceptuelle applikation til den fysiske node – en ensartet model til systembeskrivelsen, hvor forskellige aktører kan beskrive deres dele af overblikket.

Fx kan forretningen fortælle, at en forretningsfunktion benytter en ’økonomi- og betalingsservice’, hvorefter it-afdelingen kan detaljere informationen til, at det handler om en specifik installation af fx Navision Stat på en given fysisk server.

Alle disse klassifikationer kan desuden anvendes i forhold til relevante dele af Styring (den liggende, tværgående ”søjle”).

Anvendelse
Eksempler på den faktiske benyttelse af sådan et overblik kunne være:

• En it-supporter har behov for at lukke en teknikservice på grund af vedligehold, og har derfor behov for at finde ud af præcis hvilke forretningsprocesser der berøres af lukningen, så han/hun kan henvende sig til relevante aktører i forretningen.
• For at gennemføre en risikovurdering af hvor vigtige enkelte systemer er for en given forretning er der behov for at finde ud af præcis hvilke forretningsservices der trækker på de enkelte systemer. Hvis forretningsservicen understøtter et forretningskritisk mål, så vil de applikationer og it-services der understøtter denne forretningsservices også være kritiske.
• En lovproces ønsker at undersøge hvilke forretningsopgaver, der findes på baggrund af en given lov.
• En virksomhed ønsker at have et overblik over hvilke opgaver de løser, samt hvilken it-understøttelse der er til opgaveløsningen
• En virksomhed ønsker at få et overblik over hvor mange af en type løsningstyper, de har, og undersøge hvilke forretningsopgaver der bruger disse, men henblik på at vurdere om det kunne være muligt at spare penge på licenser og software.

Modellen tænkes altså både at kunne benyttes som basis for it-porteføljeoverblik, it-governance og også som bedre grundlag for økonomiske beslutninger relateret til it.

OIO rammeværkets hovedelementer

OIO rammeværket er den samlede ramme og struktur som udgør den fællesoffentlige metode til arbejdet med it-arkitektur og enterprise arkitektur.

I de følgende afsnit beskrives de underliggende rammeværk overordnet, samt de justeringer der er foretaget for at understøtte disse overordnede sammenhængstanker. Som tidligere skrevet henvises der til hjemmesider for yderligere oplysninger.

Rammeværket (OIO EA)

Kernen i OIO rammeværket er arkitekturmetoden og arkitekturreolen. Disse definerer til sammen den overordnede struktur – de er så at sige to sider af samme sag, men med hvert sit fokus på henholdsvis aktiviteter i en proces og strukturering af dokumentation i en reol. I forhold til OIO metamodellen er det Arkitekturreolen, der definerer den grundlæggende struktur.

OIO arkitekturmetoden en procesorienteret metoderamme, der definerer en række aktiviteter, dokumentationsopgaver og dokumentationstyper. Metoden er delt op i en række aktivitetsområder: Strategi, Forretning, Teknik, Gap analyse, Forandring, Krav, Trends og Styring.

OIO arkitekturreolen er en dokumentationsramme. Det vil sige en strukturering (klassifikation) af de produkter, der produceres og anvendes i de projekter, der anvender arkitekturmetoden. Arkitekturreolen er delt op i fem lodrette ”søjler”: Strategi, Forretning, Information, Applikation og Teknologi. Disse er alle delt op i tre niveauer – konceptuelt, logisk, fysisk, hvor detaljeringsgraden typisk er højest på det fysiske niveau. Desuden er der den vandrette og tværgående ”søjle” Styring, der bl.a. omfatter styring vedr. projekter, governance, økonomi, sikkerhed, krav og kontrakter.

Forretningsreferencemodellen (FORM)

FORM er den fællesoffentlige forretningsreferencemodel. Kernen i FORM er et opgavekatalog over det offentliges opgaver, både i forhold til borgere og virksomheder, vedrørende internationale relationer og samfundsforhold, og endelig vedrørende de interne administrative opgaver. Opgavekataloget er et analyse- og struktureringsredskab, som skaber overblik og et fælles sprog på tværs af den offentlige sektor.

Tværoffentlige projekter og enkelte myndigheder kan anvende modellen, når de skal beskrive og analysere it-investeringer, samarbejde på tværs af myndighedsskel – og i fællesskab understøtte moderniseringen og digitaliseringen af en samlet borgervendt og effektiv offentlig sektor. FORM er velegnet til brug i analyser og som et overblik på tværs af en helt koncern, et domæne/sektor eller hele den offentlige sektor.

Koblingen mellem det fælles sprog og myndighedernes eller domænernes egne klassifikationssystemer sker ved, at de enkelte myndigheder refererer egne lokale klassifikationer op mod FORM. Det er fx sket for det kommunale område, hvor der er oprettet referencer mellem FORM og KLE (KL’s journalplan). Således etableres et fælles sprog eller referencepunkt, der giver mulighed for sammenhæng samt mulighed for udveksling af data og oplysninger i en fælles referenceramme, også i forhold til andre myndigheder som har refereret deres lokale klassifikationer til FORM.

Figuren beskriver konceptuelt den overordnede struktur i FORM, hvor opgaver er struktureret i Serviceområder, Hovedområder, Opgaveområder og Forvaltningsopgaver, hvor detaljen i information bliver større og større jo længere man bevæger sig ned i hierarkiet.

FORM indeholder på øverste niveau 34 serviceområder og på nederste niveau over 1.300 forvaltningsopgaver. For at understøtte fremsøgning af de korrekte emner eller opgaver er der koblet omkring 11.000 søgeord til FORM, og emner og opgaver kan derved fremsøges via kendte termer og populærbetegnelser. Disse søgeord kan også bruges af portaler og hjemmesider til at understøtte deres interne søgning.

FORM vedligeholder også relationer til hvilken den lovgivning, der er grundlaget for opgaven, samt opgavens relation til finansloven. Endelig er der i FORM beskrevet relationen til de udførende offentlige myndigheder.

Der er udarbejdet en informationsmodel for FORM som kan ses i figur 3.1. I informationsmodellen indgår også forvaltningshandlinger. Der findes nærmere beskrivelser af hvordan disse kan benyttes til at udarbejde mere specifikke forretningstjenester, da FORM altid vil bevæge sig på et mere overordnet niveau, der ikke kan understøtte alle detaljer i den offentlige forretning. Et eksempel kunne være forskellen mellem den tjeneste der handler om at udlevere pas og den tjeneste der handler om at inddrage pas. Her beskriver FORM opgaven eller emnet pas, men ikke de to forskellige handlinger, der kan foretages i forhold til pas.

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.

Et 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.

Data og objektreferencemodel (Grunddata og OIOXML)

På baggrund af digitaliseringsstrategien og aftale indgået mellem Regeringen og KL er der også kommet stort fokus på de fællesoffentlige grunddata. Sammen med OIO-XML arbejdet, vil Grunddata danne fundamentet for informationssøjlen i metamodellen. Altså informationen om hvilke forretningsopgaver og applikationer der bruger hvilke data, samt information om hvilke applikations- og teknologiservices der stiller hvilke data og informationer til rådighed.

Arbejdet med grunddata og den specifikke sammenhæng i modellen er stadig i en tidlig fase, men figur 5 beskriver de forretningsobjekter som er omfattet af grunddataprogrammet, samt forretningsobjekternes interne relationer.  Denne model vil blive detaljeret yderligere og sikre at der også kan beskrives sammenhæng mellem it-systemer og forretningsopgaver på ’data’-niveau, altså den sammenhæng som ligger i at flere forretningsopgaver er afhængige af de samme data, eller at it-systemer har direkte eller indirekte relationer fordi de benytter de samme datasæt.

Dokumentationsmodeller

For at sikre en ensartet beskrivelse af oplysninger er der udarbejdet to eksempler på  dokumentationsmodeller på baggrund af metamodellen. Dokumentationsmodellerne er beskrevet som UML diagrammer.

Det første diagram her har fokus på at beskrive relationerne mellem løsninger. Altså dokumentationsmodellen, der beskriver sammenhængen mellem forretningsservicen og applikationsservices. Modellen for løsningsrelationer er på nuværende tidspunkt ikke udfoldet til teknologi laget.

I modellen er der fokus på at beskrive mulige relationer, samt kardinaliteten for disse, og igen sikres klassificeringen af elementerne via FORM og STORM. Altså kan en applikationsservice eller et applikationskomponent være af løsningstypen ’x’ eller af it-service typen ’x 999’ og en forretningsservice, en forretningsproces eller en forretningsfunktion, klassificeres via FORM på relevant niveau (som er så dybt som det overhovedet er muligt).

Diagrammet nedenfor viser en dokumentationsmodel for et overblik over en eller flere løsninger. Denne anvendes til at beskrive en it-løsning, herunder henvise til relevant dokumentation for denne.  Modellen er grundlaget for de stamkort, Digitaliseringsstyrelsen har udarbejdet for hvert enkelt af de fællesoffentlige systemer i følgende overblik: http://overblik.digitaliser.dk/loesningsmoenstre.htm.

Udover de informationer, der registreres om selve løsningen, fx navn, kort beskrivelse og funktionalitet, klassificeres en it-løsning også via STORM og STORM, således at det beskrives hvilke forretningsopgaver it-løsningen understøtter. Ideelt set burde dette være beskrevet på forretningsservicesiden – altså en beskrivelse af hvilke applikationer en forretningsservice bruger – men da dokumentationsmodellen i første omgang tager afsæt i beskrivelsen af it-løsninger, har vi på nuværende tidspunkt valgt at lade it-løsningen vedligeholde informationen om hvilke forretningsservices, som den understøtter, i selve løsningsbeskrivelsen.

Løsningsoverblikket lægger også op til at man kan henvise til fx arkitekturtegninger og videobeskrivelser, men forventningen er, at disse beskrivelser vil have en mere frivillig karakter, alt efter den sammenhæng løsningen beskrives i. Løsningsoverblikket er som sagt brugt til at beskrive de fællesoffentlige løsninger, hvor vurderingen var at disse oplysninger fx var med til at sikre genbrug.

It-service klassifikationen er i denne dokumentationsmodel opdelt i en primær løsningstype, og ingen eller mange sekundære løsningstyper. Formålet er at sikre, at man som udgangspunkt fokuserer på at beskrive, hvilken løsningstype it-løsningen ’især’ understøtter, men derefter kan angive mere sekundære løsningstyper, som løsningen også understøtter.