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.

Transkript

1 Et fælles overblik over it-arkitekturen UDKAST Baggrund 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. Status Dette dokument giver en første samlet præsentation af arbejdet med at skabe sammenhæng mellem itarkitekturvæ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. Dette lægges hermed 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. Så alle kommentarer, både til vejledning og model er meget velkomne. 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. For detaljerede beskrivelser af OIO EA henvises der til og for FORM og STORM henvises der til 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 itprojektledere, 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.

2 Metamodelarbejdet er inspireret af det arbejde der er pågået i The OpenGroup ( omkring Archimate standarden, samt forskellige offentlige parters arbejde med it-porteføjlestyring på baggrund af FORM og STORM. Et samlet overblik Metamodel Figur 1 viser den samlede 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. Figur 1: Metamodel 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

3 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. & [GRUNDDATA IKON] 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 itunderstøttelse der er til opgaveløsningen

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

5 Strategi Forretning Information Applikation Teknologi Implementerbart Overordnet Konceptuel Logisk Fysisk Mål og strategi Principper Forretningsregler Processer Workflow Logiske datamodeller Fysiske datamodeller Forretningsstruktur Applikationsstrategi Forretningsobjekter Applikationsstruktur Applikationsdesign, kode Teknologistrategi Teknologistruktur Teknologikatalog Styringsrammer Trends og projektgrundlag Gap analyse og forandring Sikkerhed Governance Kontrakter, budget, drift Figur 2: Arkitekturreol 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 analyseog 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.

6 Figur 3 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 forvaltningsopgaver. For at understøtte fremsøgning af de korrekte emner eller opgaver er der koblet omkring 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. Figur 3: FORM 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

7 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. Figur 3.1: FORM informationsmodel

8 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å. Figur 4 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. STORM løsningstyper / it-services Kontor og visualisering Kontorunderstøttelse Løsninger med fokus på generelle applikationer til understøttelse af kontoropgaver, fx tekstbehandling, regneark, præsentation. Web og kommunikation Kommunikation Løsninger der understøtter kommunikation, fx mail, telefon, chat, videokommunikation, sms. Omfatter fx beskedfordeling og digital post. Opgave- og processtøtte ESDH og journalisering Løsninger med fokus på lagring, fremsøgning samt workflow i forbindelse med sager og dokumenter. Økonomi og ressourcer Økonomi og betaling Løsninger der understøtter økonomi, herunder regnskab, budget, ud- og indbetalinger og inddrivelse. Omfatter også e- handelsløsninger. Informations- og data mangement BI, forretningsanalyse og ledelsesinformation Løsninger der understøtter analyse af forskellige generelle typer af forretningsopgaver, fra statistisk analyse over simuleringer til ledelsesinformation. Infrastruktur og sikkerhed Integration og basal infrastruktur Løsninger til generel understøttelse, fx operativsystemer, servere, servicebus, netværk og databaser Skanning, kopiering og print Løsninger med fokus på at indskanne, kopiere og printe dokumenter og lignende materialer. Hjemmesider og portaler Løsninger til at redigere, organisere og vise indhold på nettet. Specialsystemer Løsninger udviklet til at løse forvaltnings- eller forretningsspecifikke opgaver, som ikke helt eller delvist kan understøttes af standardsystemer, Fx laboratoriesystemer Løn, personale og HR Løsninger med fokus på alt der har med personalet at gøre. Kan fx omfatte timeregistrering, lønbehandling, aftaler, personalesager mv. Master data og registre Løsninger med fokus på vedligehold og registrering af information (data). Omfatter fx grunddataregistre som person, indkomst, virksomhed, organisation, bygning, retskilder. Bruger- og rettighedsstyring Løsninger med fokus på styring af brugere og deres rettigheder, samt sikring af privatlivet. Omfatter identity management og fuldmagt. Design, visualisering og grafik Løsninger med fokus på at skabe visuelle produkter, herunder visning af data. Omfatter billed- og videobehandling og CAD. Selvbetjening og indberetning Løsninger med fokus på brugernes løsning af veldefinerede og strukturerede opgaver (interaktivt). Omfatter blanketter og formularer til fx indberetning og ansøgning. Processtyring Løsninger med henblik på at modellere og styre processer, der er vigtige for forretningen. Herunder procesmodellering, forretningsregler, projektstyring og planlægning. Lagerstyring og logistik Løsninger der understøtter styring af fysiske ressourcer, herunder bygninger, lager, transport og logistik. Søgning og opmærkning Løsninger med fokus på opmærkning (indeksering / metadatadata) og fremsøgning (søgemaskiner). Omfatter klassifikation og metadata. Sikkerhed og overvågning Løsninger med fokus på sikker og stabil drift af it-løsninger. Fx overvågning, logning, firewall, virusfilter. E-læring It-management Kundehåndtering GIS Løsninger med fokus på at understøtte indlæringsprocesser, herunder fx planlægning, undervisning, øvelser, dialog, organisering af materialer. Løsninger til styring og monitorering af it-porteføljen, fx CMDB, servicedesk, monitoreringssystemer. Løsninger til at understøtte styring af kunderelationer, CRM Customer Relations Management. Omfatter fx borgerkontakt og callcenter. Geografisk informationsløsninger. Løsninger med fokus på stedbestemte og rumlige data samt evt. visualisering. Figur 4: STORM løsningstyper På it-service niveau er disse løsningstyper fortsat opdelt i funktions- eller komponentdel. Som det fremgår af figur 3.1 indeholder Sikkerhed og overvågning følgende kategorier:

9 V Sikkerhed og overvågning 549 Adgangskontrol 650 Kryptering 652 Indtrængningsforebyggelse 653 Indtrængningsopdagelse 654 Hændelsesreaktion 655 Revisionsspor og analyse 656 Certificering og akkreditering 657 ISO27001 /DS Virusbeskyttelse Figur 4.1: STORM it-servicetyper Æ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 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.

10 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. Figur 5: Grunddata overordnet begrebsmodel 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 i figur 6 og figur 7 beskrevet som UML diagrammer. Figur 6 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.

11 Bør tegnes i eget diagram kaldet Forretning primær primær4 FORM Hierarki primær Løsning 1..1 udstiller/tilbyder4 Forretningsservice 3 realiserer bruges af4 3 bruges af Forretningsproces Forretningsfunktion bruges af4 Rolle bruges af4 Aktør bruges af4 3 bruges af 3 bruges af består af4 udstiller4 Applikationsinterface -Vises ja/nej -Type har 1.. Applikationsservice -Modelstatus 1 realiserer4 3 bruger STORM Hierarki X primær 3 primær 0..1 Applikationskomponent -Modelstatus bruger Figur 6: Løsningsrelationer 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). Figur 6.1 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: 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 itlø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.

12 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. "FOA kontaktperson" afhænger af4 Løsning "Platform" Arkitektur Artefakt primær4 1 OIO EA dokumenttype [1] -Alternativt navn[0..1] -Kort beskrivelse[1] -Funktionalitet[1] -Rationale/Værdi[1] -Krav til anvendelse[1] -Anvendelsestype[1] -Løsningsarkitektur[1] -Arkitekturtegning URL[1..3] -Video URL[1..2] -Status[1] -Tidspunkt for ibrugtagning[1] -Tilslutningskrav[1] -Sprog[] -Afhængighed - platform[1] -Afhængighed - andre løsninger[1] -Krav til tekniske standarder[1] -SLA[1] -Ejer-information[1] -Kontaktinformation[1] -Link - projekthjemmeside[1] -Link - hjemmeside[1] -Link - teknisk dokumentation[1] -Link - kildekode[1] -Link - community[1] -Link - referenceimplementering[1] -Link - SLA information[1] -Link - driftsstatus [1] primær4 sekundær4 3 udvikler understøtter4 anvendes til FORM Hierarki STORM Hierarki X 999 Opmærk så dybt som muligt Relation til Myndighed, Finanslov, Lovgivning Figur 6.1: Løsningsoverblik