Referencedatamodelprojektet. DDV integrationsmetoden. Version oktober 2012

Størrelse: px
Starte visningen fra side:

Download "Referencedatamodelprojektet. DDV integrationsmetoden. Version 1.0 23. oktober 2012"

Transkript

1 Referencedatamodelprojektet DDV integrationsmetoden Version oktober 2012

2 ISBN: --- Titel: Udgiver: DDV integrationsmetoden DANVA Vandhuset Godthåbsvej Skanderborg Udarbejdet af: Peter Huber, Strand & Donslund A/S i samarbejde med DDV projektgruppen.

3 Indholdsfortegnelse 1 Indledning Projektets anledning og baggrund Udarbejdelsen af integrationsmetoden Indhold 4 2 Anvendelse af integrationsmetoden 5 3 Arkitekturbeskrivelser for processer Aktøroverblik Formål Aktøroverblik (diagram) Aktørbeskrivelse (skabelon) Informationsstrømsgruppebeskrivelse (skabelon) Trin Tjekliste Procesoverblik Formål Procesoverblik (diagram) Procesgruppebeskrivelse (skabelon) Trin Tjekliste Den enkelte proces set udefra Formål Den enkelte proces set udefra(diagram) Procesbeskrivelse (skabelon) Trin Tjekliste Den enkelte proces indefra Formål Den enkelte proces set indefra (diagram) Aktivitetsbeskrivelse (skabelon) Trin Tjekliste 17 4 Arkitekturbeskrivelser for Information Informationsoverblik Formål Informationsoverblik (diagram) Begrebsbeskrivelse (skabelon) Trin Tjekliste Informationsmodeller Formål Informationsmodel (diagram) Begrebsbeskrivelse (skabelon) Relationsbeskrivelse (skabelon) Attributbeskrivelse (skabelon) 25 I

4 4.2.6 Trin Tjekliste 26 5 Arkitekturbeskrivelser for Applikation Domæneoverblik Formål Domæneoverblik (diagram) Domænebeskrivelse (skabelon) Trin Tjekliste Integrationsmønstre Formål Integrationsmønsterbeskrivelse (skabelon) Trin Tjekliste Domæneflow Formål Domæneflow (diagram) Domæneflowbeskrivelse (skabelon) Trin Tjekliste Datasnitflader Formål Datasnitfladebeskrivelse (skabelon) Recordstruktur (hjælpediagram) Trin Tjekliste 38 Appendiks A: Sammenhæng til OIO EA 39 II

5 Revisionshistorik Ver. Dato Ændret af: Ændringsbeskrivelse Peter Huber Peter Huber Peter Huber Peter Huber Peter Huber Dokument oprettet på basis af de to første arbejdsmøder vedr. arbejdsgange hhv. data jf. projektplanen. Dokument opdateret på basis af 3. arbejdsmøde vedr. arbejdsgange hhv. data jf. projektplanen 29/6 samt sidste justeringer på arbejdsmødet 4/7 = Høringsversion vedr. arbejdsgange og data til udsendelse 4/7 Dokument suppleret på basis af de to første arbejdsmøder vedr. dataservice hhv. valg af integrationsmønstre. Dokument opdateret på basis af 3. arbejdsmøde vedr. dataservice hhv. 2. og sidste møde vedr. valg af integrationsmønstre 28/8. Høringsversion udelukkende vedr. kapitel 5. De modtagne høringssvar vedrørende ver. 0.5 er ikke indarbejdet. Indarbejdelse af høringssvar vedr. ver. 0.5 og 0.65 samt justeringer ift. arbejdet med Integrationsmønstre, illustrative eksempler og governance-model. Den enkelte proces hvad og hvordan er omdøbt til de mere mundrette Den enkelte proces set udefra hhv. indefra. Sammenhængen til OIO EA reolen illustreret bedre. Figur 2 er opdateret og ny figur 3 tilføjet om anvendelsen af metoden. Endelig projektleverance. III

6 1 Indledning 1.1 Projektets anledning og baggrund DANVAs Digitale Vandselskab (DDV) har igangsat Referencedatamodelprojektet. Projektet skal i overordnede termer beskrive rammerne og principperne for den fremadrettede digitaliseringsindsats i Det Digitale Vandselskab. Alt arbejde med standardisering og datamodellering i DANVA regi afventer resultaterne af dette projekt. Projektets scope i relation til metode- og arkitekturleverancer er afgrænset som angivet i tilbuddet fra Strand & Donslund. Leverancerne i projektet er jf. dette tilbud: DDV principper - Udarbejdelse af en række principper der kan bruges som redskab til at sikre retning i digitaliseringsarbejdet i sektoren og til at støtte beslutningsprocessen i forbindelse med tværgående governance, og i de enkelte projekter der følger integrationsmetoden DDV integrationsmetode Udarbejdelse af en struktureret beskrivelse af en fremgangsmåde til digitaliseringsopgaver i sektoren der behandler de fire primære aspekter: Analyse af arbejdsgange, Datamodellering, Specifikation af data-service samt Valg af integrationsmønstre. DDV integrationsmønstre Udarbejdelse af et katalog over integrationsmønstre som danner grundlag for konkrete integrationsløsninger i sektoren. Et integrationsmønster egner sig typisk til brug ud fra givne omstændigheder som gives af arbejdsgangen, det konkrete informationsbehov mv. Illustrative eksempler Udarbejdelse af illustrative eksempler på de resultater som brug af integrationsmetoden leder frem til. DDV governancemodel Udarbejdelse af en governance model der skal sikre overensstemmelse mellem resultaterne i de fremtidige modeller og standarder på den ene side, og de rammer og principper der etableres i projektet på den anden side. Anbefalingsleverancer de anbefalingsleverancer der efterspørges i afsnit 2.8 i DANVAs projektbeskrivelse er indarbejdet i de andre leverancer. Dette dokument udgør anden leverance: DDV integrationsmetoden som bliver vejledende for arbejdet med at udarbejde en rammesættende forretnings- og it-arkitektur i DDV regi. Nedenfor refereres til betegnelserne for de andre fremhævede leverancer ovenfor. Målgruppen er især alle der skal udarbejde DDV-arkitekturen (deltagere i DDV-projekter, i projekter i det enkelte selskab eller i samarbejde blandt selskaberne), leverandører samt konsulenter. Det anbefales at læse de to illustrative eksempler sideløbende med denne metodebeskrivelse. Alle der skal benytte DDV-arkitekturen (selskaber, leverandører, samarbejdspartnere, lignende brancher og initiativer) kan med fordel læse først læse eksemplerne, og materiale der udarbejdes ifm. implementeringen. DDV integrationsmetoden er struktureret beskrivelse af en fremgangsmåde (paradigme/metodik) til udarbejdelse af DDV-arkitektur og dermed understøtte digitaliseringsopgaver i sektoren. Metoden behandler fire primære aspekter: Side 1 af 40

7 Analyse af processer Beskrivelse af information Specifikation af Domæner med Datasnitflader Valg af integrationsmønstre Hver af de fire dele af metoden beskrives overordnet med: De trin, der gennemføres Dokumentationsstandarder og skabeloner Tjeklister Integrationsmetoden er beskrevet kompakt med fokus på hvad der skal gøres i et DDV-projekt og på at standardisere resultaterne på tværs af DDV-projekter. Den skal således ikke ses som en lærebog, der giver detaljerede anvisninger på hvordan de enkelte trin udføres. Indholdet baseres på anerkendte standarder og best practice i den offentlige og private sektor, og med erfaringer fra udlandet. En fælles metode er nødvendig for at skabe en fælles arkitektur og dokumenterede fælles standarder. Den grafiske notationsstandard BPMN ( Business Proces Model and Notation ) fra OMG (se benyttes til beskrivelse af forretningsproces og til information benyttes klassediagrammer fra den grafiske notationsstandard UML ( Unified Modeling Language ) ligeledes fra OMG. OIO EA benyttes som referenceramme for at arbejde systematisk inden for Enterprise Arkitekturtankegangen. Integrationsmetoden vejleder i udarbejdelse af DDV-arkitektur som angivet i OIO EA reolen med de af DANVA valgte navne på de enkelte arkitekturbeskrivelser: Læs mere i Appendiks A. Figur a: DDV-arkitekturbeskrivelserne vist i OIO EA reolen med tekst Side 2 af 40

8 Figur 1b: DDV-arkitekturbeskrivelserne i OIO EA reolen med ikoner og indlemmet i grafikken fra målbilledet. Digitaliseringsstyrelsen beskriver på hylderne i OIO EA reolen således: Fra venstre til højre sker der en klassificering af arkitektur-produkter fra det strategiske hen imod det mere teknologi-orienterede. Fra top til bund sker der en ændring af ejerskabet i en organisation. Leverancer fra et enterprise arkitektur projekt fordeler sig normalt således: På det konceptuelle niveau er ejerskabet normalt forankret hos topledelsen i organisationen. Dokumenterne på dette niveau beskriver overordnede, strategiske beslutninger. På det logiske niveau er ejerskabet forankret hos de ansvarlige for den daglige ledelse i organisationen. Dokumenterne på dette niveau beskriver de generelle design man opererer ud fra. På det fysiske niveau er ejerskabet forankret hos de operationelt ansvarlige i organisationen, og herunder hos de leverandører man benytter til at levere løsninger. Integrationsmetoden tager udgangspunkt i DDV principperne. De arkitekturbeskrivelser der hedder overblik udarbejdes og vedligeholdes i DDV regi. Alle andre vedligeholdes efter metoden beskrevet i dette dokument af en DDV udpeget ansvarlig part. DDV Governance-modellen beskriver hvordan de DDV arkitekturbeskrivelser, der frembringes ved bruge af denne integrationsmetode, håndteres og styres, og hvordan nye arkitekturbeskrivelser kan indlemmes i DDV arkitekturen, dvs. blive lagt i DDV EA reolen som gældende. Endvidere udarbejdes i DDV regi vision, målbillede og principper, men fremgangsmåden er ikke beskrevet i metoden (markeret med parentesen i figur 1a). Der henvises til fx ea.oio.dk.. På det fysiske niveau er vist Side 3 af 40

9 hvor fx fysiske datamodeller og fysiske udveklinger hører hjemme (antydet med grå skift). De kan således kobles til indholdet af DDV arkitekturen på logisk niveau. DDV arkitekturen dækker ikke teknologisøjlen, og dækker Applikationssøjlen med logiske applikationer kaldet domæner med udgangspunkt i de opstillede DDV arkitekturprincipper. 1.2 Udarbejdelsen af integrationsmetoden Udarbejdelsen af denne integrationsmetode er sket i projektgruppen ved arbejdsmøder fra juni til september 2012 om de enkelte emner som angivet i revisionshistorikken (side III). DDV principperne er benyttet om udgangspunkt sammen med OIO EA og det af Strand & Donslund foreslåede metodeapparat. Metoden er gennem iterationerne redigeret af Strand & Donslund. Undervejs er der foretaget høringer blandt en række selskaber og leverandører, hvorfra høringssvarene er indarbejdet. Erfaringerne fra projektets arbejde med illustrative eksempler og konkrete integrationsmønstre er ligeledes indarbejdet. 1.3 Indhold Med DDV-arkitekturen som en fælles rammesættende forretnings- og it-arkitektur er der foretaget en fokusering og udvælgelse af relevante dele af OIO EA, og der benyttes navne på de enkelte arkitektur-beskrivelser der passer til arbejdet i DDV regi. Appendiks A beskriver nøjere sammenhængen til OIO EA rammeværket. Kapitel 3 og 4 beskriver forretningsarkitekturens bestanddele (delt i processer og information), mens kapitel 5 beskriver den fælles måde at dokumentere den standardiserede it-arkitektur på. Side 4 af 40

10 2 Anvendelse af integrationsmetoden Når der udarbejdes arkitekturbeskrivelser efter metoden kan der arbejdes top-down (fra forretningsarkitekturen mod it-arkitekturen) og bottom-up (fra it-arkitekturen mod forretnings-arkitekturen) og oftest som en kombination heraf. Der bør arbejdes i projekter eller arbejdsgrupper med en kombination af arbejdsmøder/workshops sammen med renskrivning/efterbearbejdning og reviews/høringer. Selvom den nuværende situation forretnings- og it-mæssigt kan modelleres, anbefales fremadrettet fokus (ofte kaldet To-Be ) for de beskrivelser der udformes og færdiggøres efter denne metoden, og som godkendes efter DDV Governancemetoden. Undervejs kan der være behov for på skitse-facon at vise hvordan en proces eller et system fungerer i dag. Efterhånden som DDV arkitekturen opbygges, vil eksisterede arkitekturbeskriver ( As-Is )danne grundlag for forbedringsønsker og forslag ( To-Be ), som tegnes som justeringer/udbygning af de eksisterende beskrivelser med markering af ændringerne. DDV Governance-modellen beskriver hvordan DDV-arkitekturen udbygges og hvem der godkender den. Figur 2 og 3 illustrerer de to retninger. Læs mere i eksemplerne. Side 5 af 40

11 Figur : Udarbejdelse af forretningsarkitekturen top-down og bottom-up Figur : Udarbejdelse af it-arkitekturen top-down og bottom-up Side 6 af 40

12 3 Arkitekturbeskrivelser for processer Forretningsarkitekturen i DDV skal for at sikre sammenhænge indeholde beskrivelser af selskabets forretning, sådan at digitalisering og it-understøttelsen kan beskrives systematisk og præcist. Forretningsarkitekturen består udover de strategiske elementer, som fx principper, af processer og information. I metoden fokuseres gennem udarbejdelsen af arkitekturdokumenter på processer både overordnet (konceptuelt) og i yderligere detalje for at sætte rammerne mere præcist (logisk) som angivet i Figur. Arkitekturprodukterne her hører til Forretnings-søjlen i OIO EA rammeværket. I projektbeskrivelsen blev de omtalt kort som arbejdsgange. Figur : Arkitekturbeskrivelser for Forretningen, det enkelte selskab Side 7 af 40

13 3.1 Aktøroverblik Formål Aktøroverblikket er et højniveau-perspektiv på et selskabs omgivelser og dem, som selskabet direkte samarbejder med, aktørerne. Det dokumenterer den fælles forståelse af branchen både visuelt og i form af beskrivelser. Aktørerne navngives og den information, der flyder mellem selskaber og aktøren, identificeres, grupperes og navngives ligeledes. Navnene på aktører benyttes, når der tegnes (se nedenfor). Aktører er den delmængde af selskabets interessenter der udveksler data med selskabet i de processer som DDV standardiserer. Aktøroverblikket viser også hvor den fælles rammesættende DDV-arkitektur er udbygget Aktøroverblik (diagram) Diagrammet (jf. Figur ) er en uformel eller semi-struktureret grafisk fremstilling bestående af følgende symboler: Overblikket kan af praktiske årsager tegnes i flere diagrammer frem for ét stort. Aktøroverblikket vedligeholdes i DDV regi. Det udstilles i en klikbar/navigerbar udgave på DDVs portal, der bringer de enkelte beskrivelser frem. Aktører indgår i forretningsprocesserne (se afsnit og 3.4.2) Side 8 af 40

14 3.1.3 Aktørbeskrivelse (skabelon) Aktører beskrives med følgende skabelon: Rollenavn Navn på rolle som aktør(er) har ift. selskabet. Rollenavnet skrives med stort begyndelsesbogstav Eksempler kunne være Kunde, Kortleverandør, Kommune, Forsyningssekretariat, SKAT, Ejer, Selskabsbestyrelse Beskrivelse Evt. eksempler Evt. ekstern definition Metadata Kort beskrivelse af aktøren i form som et ordbogsopslag. Her kan nævnes konkrete eksempler. Hvis der findes ekstern beskrivelse kan denne med fordel refereres. Fx en international definition eller henvisning til en opgave i FORM som rollen deltager i. Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Informationsstrømsgruppebeskrivelse (skabelon) Informationsstrømsgrupper beskrives med følgende skabelon: Betegnelse Beskrivelse Består af Navn på informationsstrømsgruppen med stort begyndelsesbogstav. Helst et samlet navneord. Kort beskrivelse af informationsstrømsgruppen i form som et ordbogsopslag. Her listes de enkelte informationsstrømme som gruppen består af. Hver med en kort beskrivelse i form som ordbogsopslag. Metadata Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Bemærk: der er ingen beskrivelse af dataindhold (datafelter) på dette niveau. Side 9 af 40

15 3.1.5 Trin Aktører kan enten identificeres top-down ud fra en helhedsbetragtning, eller ved at der i overblikket mangler en aktør, som indgår i en bestemt proces, der ved at blive beskrevet/indlemmet (bottom-up), jf. Figur. Efter identifikation beskrives aktøren og informationsstrømsgrupperne vha. skabelonerne ovenfor. Evt. tilføjes en informationsstrøm til en eksisterende informationsstrømsgruppe. Aktøroverblikket er rimeligt stabilt og udvikler sig mest i form af tilføjelser, når der beskrives/indlemmes nye processer i DDV-arkitekturen Tjekliste Når aktøroverblikket udarbejdes eller ændres skal følgende tjekkes: Er beskrivelsen forretningsmæssigt retvisende? Repræsenterer beskrivelsen den ønskede fælles forretningsmæssige ramme? Er metoden overholdt? Giver diagrammet en god visualisering af aktørerne med en for læseren læsevenlig og støttende strukturering? Er (de nye) aktører navngivet sigende og beskrevet dækkende? Er aktørerne navngivet ensartet? Er evt. eksterne referencer angivet entydigt og korrekt? Er (de nye) informationsstrømsgrupper navngivet sigende og beskrevet dækkende? Er Informationsstrømmene i hver gruppe navngivet sigende og beskrevet dækkende? Der er følgende sammenhæng til andre arkitekturbeskrivelser: I DDV beskrevne processer (set udefra og indefra nedenfor) skal aktørerne altid være i aktøroverblikket. I DDV beskrevne processer (set udefra og indefra nedenfor) skal vigtige informationsstrømme være i den relevante informationsstrømsgruppe i aktøroverblikket. 3.2 Procesoverblik Formål Procesoverblikket er et højniveau-perspektiv på selskabets forretningsprocesser passende grupperet. Det dokumenterer den fælles forståelse i branchen både visuelt og i form af beskrivelser. Procesgrupper, procesundergrupper og processer navngives og fungerer først og fremmest som en indholdsfortegnelse og en knagerække så de mere detaljerede procesbeskrivelser (set udefra og indefra nedenfor) kan hægtes op og ses i den rette sammenhæng. Side 10 af 40

16 Procesoverblikket viser også hvor den fælles rammesættende DDV-arkitektur er udbygget, og hvor den ikke er det. Procesoverblikket er ikke et organisationsdiagram eller organisatorisk opdelt, og kan derfor bruges af alle selskaber som reference Procesoverblik (diagram) Diagrammet (jf. Figur ) er en uformel eller semi-struktureret grafisk fremstilling bestående af følgende symboler: Procesoverblikket vedligeholdes i DDV regi. Det udstilles i en klikbar/navigerbar udgave på DDVs portal med de enkelte procesgruppers indhold og definitioner, og med link videre til de mere detaljerede beskrivelser (udefra og indefra perspektiverne nedenfor) Procesgruppebeskrivelse (skabelon) Procesgrupper beskrives med følgende skabelon: Navn Beskrivelse Består af Metadata Navn på procesgruppen Kort beskrivelse af procesgruppen i form som et ordbogsopslag. Procesundergrupper med liste af processer eller blot liste af processer hvis der ikke er brug for undergrupper. Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Trin Procesgrupper, procesundergrupper og processer kan enten identificeres top-down ud fra en helhedsbetragtning, eller ved at der i procesoverblikket mangler en proces, der ved at blive beskrevet/indlemmet (bottom-up), Side 11 af 40

17 jf. Figur. Der kan være behov for at justere antallet af procesundergrupper, hvis antallet af processer i en procesgruppe bliver stort. Efter identifikation beskrives procesgruppen og evt. procesundergruppe vha. skabelonen ovenfor. Procesoverblikket er rimeligt stabilt og udvikler sig mest i form af tilføjelser, når der beskrives/indlemmes nye processer i DDV-arkitekturen. Der kan ved større tilføjelser eller ved væsentlig udvidelse af et selskabs opgaver være behov for at foretage en ombrydning af procesoverblikket Tjekliste Når procesoverblikket udarbejdes eller ændres skal følgende tjekkes: Er beskrivelsen forretningsmæssigt retvisende? Repræsenterer beskrivelsen den ønskede fælles forretningsmæssige ramme? Er metoden overholdt? Giver diagrammet for læseren en god visualisering af et selskabs procesgrupper med en læsevenlig og støttende strukturering? Er (de nye) procesgrupper navngivet sigende og beskrevet dækkende? Er procesgrupperne navngivet ensartet? Er evt. nye procesundergrupper navngivet sigende og beskrevet dækkende? Er evt. procesundergrupper navngivet ensartet? Er (de nye) processer navngivet sigende? Er processerne navngivet ensartet? Der er følgende sammenhæng til andre arkitekturbeskrivelser: De DDV beskrevne processer (udefra og indefra) skal være i procesoverblikket. 3.3 Den enkelte proces set udefra Formål Denne beskrivelse viser hvad den enkelte proces gør forretningsmæssigt. Det dokumenterer den fælles forståelse i branchen både visuelt og i form af beskrivelser. Fokus er omgivelserne for og essensen af den enkelte forretningsproces ud fra et helhedsperspektiv og med angivelse af: Igangsættende hændelse(r) Evt. opdeling i delprocesser Det normale slutresultat De normale informationsstrømme til og fra aktørerne Side 12 af 40

18 Beskrivelsen holdes fri af hvordan processen er it-understøttet, og kan ses mere som en overordnet beskrivelse af en forretningsservice Den enkelte proces set udefra(diagram) Diagrammet benytter (jf. Figur ) BPMN og hver aktør og selskabet er repræsenteret med en BPMN pool og der benyttes følgende få udvalgte BPMN symboler til grafisk at beskrive processen: Den enkelte proces redigeres i et BPMN værktøj. DDV Governance-modellen beskriver hvordan en ny beskrivelse godkendes. Diagram og udfyldte skabeloner udstilles i en klikbar/navigerbar udgave på DDVs portal Procesbeskrivelse (skabelon) Processer beskrives med følgende skabelon: Navn Navn på processen (er i diagrammet) Side 13 af 40

19 Hændelse(r) Beskrivelse Startbetingelse(r) Slutresultat(er) Evt. delprocesser Informationsstrømme Rammer Evt. andre interessenter Målepunkter Hændelser der udløser processen (er i diagrammet) Kort beskrivelse af processen i form som et ordbogsopslag. Kort beskrivelse af evt. delprocesser i form som ordbogsopslag af hver delproces. Hvad skal være opfyldt for at processen kan starte fx afhængighed af andre processers gennemførelse. Resultater af processen (er i diagrammet) Hvilken information udveksles med hvilke aktører (er i diagrammet) Her beskrives de rammer som processen er underlagt fx lovgivning, bekendtgørelser, branchevedtagne procedurer etc. Angivelse af interessenter for denne specifikke proces og hvad deres interesse er. Det er især vigtigt at få listet interessenter, der ikke indgår i processen som medvirkende aktører. (Se eksempel i separat dokument) Eventuel angivelse af sundhedsmål/kvalitetsmål som ønskes opstillet i fælles regi og som det den specifikke proces kunne måles på. (Se eksempel i separat dokument). Vigtighed Hvor vigtig/kritisk er processen for forretningen, selskabet på en skala fra 1 til 5 Evt. bemærkninger om hvilke bindinger der er til andre processers gennemførsel (se eksempel i separat dokument) Metadata Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Trin Processer kan enten identificeres top-down og udvælges til beskrivelse fra procesoverblikket eller ved at behovet opstår (bottom-up), jf. Figur. Processen illustreres med BPMN diagram og beskrives vha. skabelonen ovenfor. Er der tale om udvidelser af en eksisterende beskrivelse justeres diagram og skabelon i stedet Tjekliste Når den enkelte proces i udefra-perspektivet beskrives eller ændres skal følgende tjekkes: Side 14 af 40

20 Er beskrivelsen forretningsmæssigt retvisende? Repræsenterer beskrivelsen den ønskede fælles forretningsmæssige ramme? Er metoden overholdt? Er BPMN anvendt korrekt? Giver diagrammet for læseren en god visualisering processen set overordnet dvs. udefra med fokus på hvad frem for hvordan Svarer diagrammet til beskrivelsen? Er starthændelser, evt. mellemresultat(er) og slutresultater navngivet ensartet? Er processen beskrevet dækkende vha. skabelonen? Er evt. delprocesser navngivet ensartet? Er evt. delprocesser navngivet sigende? Er evt. delprocesser beskrevet dækkende i processkabelonen? Der er følgende sammenhæng til andre arkitekturbeskrivelser: Den enkelte proces skal være i at finde i procesoverblikket Processens aktører skal være i aktøroverblikket Processens vigtigste informationsstrømme er vist samlet i aktøroverblikket. Den enkelte proces kan være konkretiseret (se indefra-perspektivet nedenfor). Selvom processen evt. er opdelt i delprocesser, anbefales ét samlet procesdiagram med udefra-perspektivet for at bevare helhedsbilledet og undgå suboptimering. 3.4 Den enkelte proces indefra Formål Beskrivelsen viser hvordan den enkelte proces gennemføres forretningsmæssigt. Det dokumenterer den fælles forståelse i branchen både visuelt og i form af beskrivelser. Fokus er på nedbrydning af processen fra udefra-perspektivet i et passende antal aktiviteter i et koordineret flow. Både hovedveje og biveje skal vises. Igangsættende hændelser, input, output og slutresultatet fra udefra-perspektivet skal være respekteret, men der vil typisk være flere detaljer, idet der kan være behov for at tilføje mindre vigtige igangsættende hændelser og ikke så normale slutresultater. Kun hvis der er meget sjældne informationsstrømme kan de også gemmes på dette beskrivelsesniveau. Beskrivelsen holdes ligesom i udefra-perspektivet fri for detaljer om hvordan processen er it-understøttet. Men procesforløbet udgør de væsentligste forretningsmæssige rammer for it-understøttelsen, som beskrives itarkitekturmæssigt jf. kapitel Den enkelte proces set indefra (diagram) Diagrammet benytter også (jf. Figur ) BPMN. Hver aktør er ligesom i udefra- perspektivet repræsenteret med en BPMN pool, men selskabets pool evt. opdeles yderligere i svømmebaner, fx en generisk/fælles opdeling ud fra kompetencer eller forretningsområder, men må ikke afspejle organisationsstrukturen, som netop varie- Side 15 af 40

21 rer fra selskab til selskab. Der benyttes de samme symboler som i angivet i afsnit Endvidere kan der være brug for følgende ekstra BPMN symboler: Samme overvejelser vedrørende værktøj og præsentation som for udefra-perspektivet for den enkelte proces jf. afsnit Aktivitetsbeskrivelse (skabelon) Aktiviteter i processen beskrives med følgende skabelon: Navn Evt. Aktør Formål Evt. startbetingelse Forløb Navn på aktiviteten (er i diagrammet) Hvem eller hvilken kompetence udfører aktiviteten (kan ses i navnet på svømmebanen i diagrammet hvis sådanne benyttes) Kort formålsbeskrivelse for aktiviteten i form som et ordbogsopslag, som angiver hvad der opnås ved at udføre aktiviteten (evt. et resumé af Forløb). Hvad skal være opfyldt for at aktiviteten kan starte Kort beskrivelse af forløbet af aktiviteten på punktform som en række trin, der transformerer input til output. Side 16 af 40

22 Normalforløbet og eventuelle fejlforløb skal dækkes med brug af forretningsområdets begreber og terminologi Slutresultat Involverede begreber Metadata Resultatet af aktiviteten = output Hvilken information oprettes/læses/opdateres/slettes i form af vigtige begreber fra Informationsoverblikket (se nedenfor) opstillet som en liste. Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Trin Først tegnes forløbet som en række aktiviteter. Der kan enten arbejdes top-down og der designes en passende flow eller bottom-up, hvor der er fokus på især at dække forretningsmæssige aktiviteter svarende til visse dataintegrationer fra it-arkitekturen, jf. Figur. Aktiviteterne beskrives vha. skabelonen ovenfor. Der bør fortrinsvis arbejdes på den ønskede situation (To-Be), men det kan være nødvendigt også at skitsere As-Is Tjekliste Når indefra-perspektivet for den enkelte proces udarbejdes eller ændres skal følgende tjekkes: Er beskrivelsen forretningsmæssigt retvisende? Repræsenterer beskrivelsen den ønskede fælles forretningsmæssige ramme? Er metoden overholdt? Er BPMN anvendt korrekt? Er forløbet forretningsmæssigt tegnet korrekt? Spørgsmålet gælder for hhv. As-Is (nuværende) og To-Be (fremtidig) version, hvis begge er tegnet. Er forløbet effektivt fremadrettet? (To-Be version) Giver diagrammet en god visualisering processens forløb som en række aktiviteter set inde fra selskabet dvs. med fokus på forretningsmæssigt hvordan Hvis der er benyttet svømmebaner, er de navngivet systematisk og ens på tværs af processerne? Er diagrammet i balance med udefra-beskrivelsen for den samme proces? Dvs. starthændelser, evt. mellemresultat(er), informationsstrømme og slutresultater fra udefra-perspektivet kan genfindes i indefra-perspektivet? Er evt. delprocesser med egne BPMN underdiagrammer anvendt passende? Er der balance mellem evt. BPMN underdiagrammet og delprocessers input og output i overdiagrammet Er aktiviteterne og evt. delprocesser navngivet ensartet? Side 17 af 40

23 Er aktiviteterne og evt. delprocesser navngivet sigende? Er hver aktivitet beskrevet dækkende vha. skabelonen? Der er følgende sammenhæng til andre arkitekturbeskrivelser: Den enkelte proces skal også være beskrevet med udgangspunkt i udefra-perspektivet og være i overensstemmelse hermed Evt. benyttede forretningsobjekter i BPMN diagrammet skal være at finde i informationsoverblikket og de tilhørende begrebsbeskrivelser. Involverede begreber angivet i aktivitetsskabelonerne skal også være at finde i informationsoverblikket Side 18 af 40

24 4 Arkitekturbeskrivelser for Information Forretningsarkitekturen består udover de strategiske elementer, som fx principper, af processer (med metode som beskrevet i kapitel 3) og information. Der fokuseres i metoden gennem udarbejdelsen af arkitekturdokumenter på information overordnet (konceptuelt) og i yderligere detalje for at sætte rammerne mere præcist (logisk) som angivet i Figur. Arkitekturprodukterne her hører til Informations-søjlen i OIO EA rammeværket. I projektbeskrivelsen blev de omtalt kort som data. Figur : Arkitekturbeskrivelser for Information i det enkelte selskab Side 19 af 40

25 En god kilde til modelleringshåndværket er fx God praksis for informationsmodellering 4.1 Informationsoverblik Formål Informationsoverblikket er et højniveau-perspektiv på et selskabs information. Det dokumenterer den fælles forståelse af branchen både visuelt og i form af beskrivelser. De vigtigste begreber og deres relationer angives med det sigte at understøtte de væsentligste forretningsobjekter inden for de områder, der beskrives i DDV-arkitekturen. Informationsoverblikket viser hvordan information struktureres overordnet. Begreber inddeles i informationsområder og med overvejende fokus på forretningsmæssig betydning af begreberne. Begreber og relationer mellem dem navngives forretningsmæssigt og fungerer først og fremmest elementer på disse oversigtskort så mere detaljerede beskrivelser i form af informationsmodellerne kan ses i den rette sammenhæng. Overblikket holdes fri af it-understøttelsen og beskriver dermed et mere idealiseret og simplere billede. Informationsoverblikket viser også hvor den fælles rammesættende DDV-arkitektur er udbygget, og hvor den ikke er det. Fx kan ikke-udbyggede dele blot være antydet med gråtonet grafik Informationsoverblik (diagram) Overblikket består af et diagram (jf. Figur ). Det anvendte diagram er en simpel UML model (klassediagram) med følgende få symboler: Overblikket kan af praktiske årsager oftest bedst tegnes i flere diagrammer frem for ét stort. Informationsoverblikket vedligeholdes i DDV regi. Det udstilles i en klikbar/navigerbar udgave på DDVs portal, der bringer de enkelte beskrivelser frem. Side 20 af 40

26 4.1.3 Begrebsbeskrivelse (skabelon) Begreber i informationsoverblikket beskrives med følgende skabelon: Navn Entydigt navn på begrebet (er i diagrammet) Tilhører Definition Formål Eksempler Evt. ekstern definition Informationsindhold Informationsmodeller Evt. alias(ser) Metadata Entydigt navn på informationsområdet som begrebet tilhører (er i diagrammet) Kort præcis beskrivelse i form af et ordbogsopslag. Hvorfor kan dette begreb ikke undværes? Vil ofte indeholde formuleringer som stamdata for.... Et par eksempler på konkrete forretningsobjekter, der hjælper med at forstå begrebet. Hvis der findes ekstern beskrivelse kan denne med fordel refereres. Det kunne være en international definition eller en dansk reference fx i branchen eller i fællesoffentligt regi. Opsummering af informationsindhold struktur for det pågældende begreb med fokus på at forstå begrebet. Det kan være udvalgte attributter eller gruppe af informationer. Liste over de informationsmodeller der detaljerer begrebet. Dokumentation af andre betegnelser for begrebet evt. med markering af at de ikke bør bruges fremadrettet. Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Bemærk: der er ingen struktureret beskrivelse af dataindhold (felter/attributter) på dette niveau Trin Begreber kan enten identificeres top-down ud fra en helhedsbetragtning, eller ved at der i overblikket mangler en vigtigt begreb, som benyttes i en bestemt informationsmodel eller proces, der ved at blive beskrevet/indlemmet (bottom-up), jf. Figur. Dernæst visualiseres begreberne og deres sammenhæng med relationer på diagramform. Begreberne opdeles i passende informationsområder for at give bedre overblik og samhørighed. Side 21 af 40

27 Efter identifikation beskrives hvert begreb vha. skabelonen ovenfor. Er der tale om udvidelser justeres diagram(mer) og skabeloner passende Tjekliste Når informationsoverblikket udarbejdes eller ændres skal følgende tjekkes: Er beskrivelsen forretningsmæssigt retvisende? Repræsenterer beskrivelsen den ønskede fælles forretningsmæssige ramme? Er metoden overholdt? Giver diagrammet for læseren en god visualisering af de vigtigste begreber inden for hvert informationsområde ( emne ) med en læsevenlig og støttende strukturering og sammenhæng? Er (de nye) informationsområder navngivet sigende? Er (de nye) begreber navngivet sigende og beskrevet dækkende? Er begreberne navngivet ensartet? Er evt. eksterne referencer angivet entydigt og korrekt? Er (de nye) relationer navngivet sigende? Der er følgende sammenhæng til andre arkitekturbeskrivelser: DDV beskrevne proces kan referere til begreber som grafiske objekter jf. symbolerne i afsnit DDV beskrevne aktiviteter refererer til begreber fra informationsoverblikket Informationsoverblikket detaljeres og konkretiseres i informationsmodellerne (se nedenfor). 4.2 Informationsmodeller Formål Informationsmodellerne viser detaljer om de enkelte enheder af information, som benyttes som grundstof i de enkelte forretningsprocesser. Informationsmodellerne dokumenterer den fælles forståelse i branchen både visuelt og i form af beskrivelser. Fokus er på nedbrydning af Informationsoverblikket til mere detaljerede logiske modeller med alle nødvendige informationsstrukturer. Informationen inddeles i de samme områder som informationsoverblikket med krav om attributkomplethed ift. den information der udveksles gennem de standardiserede snitflader, således at al information skal kunne findes i de relevante informationsmodeller. Det sikres jf. tjeklisterne når snitflader kontrolleres. Beskrivelsen af informationsstrukturerne i detaljer skal omfatte al information, der (kan) udveksles eksternt og mellem domænerne (Disse defineres i kapitel 5 som en logisk og leverandøruafhængig opdeling af systemlandskabet med det formål at standardisere dataintegrationer). Alle forretningsdata i en dataudveksling skal være defineret i informationsmodellerne, hvor der plukkes fra. Informationsmodellerne sikrer at der er samme syn på information på tværs, og at data er velstruktureret og beskrevet én gang, som et bindeled mellem forretning og it når digitaliseringen af processerne forbedres. Side 22 af 40

28 De eksisterede fysiske DANVA datamodeller (DANDAS, DANVAND, D&V) skal løftes til informationsmodel niveau, og relevante begrebsafklaringer løftes helt til informationsoverblikket, hvor jf. afsnit 4.1, netop betydning af begreberne er i fokus. Fx begrebet Ledning. Se fx Informationsmodellerne er således stadig blot rammesættende i modsætning til krav om fysisk tabellagring, men det er vigtigt at fx nøgler til dataudveksling fremgår af informationsmodellen Informationsmodel (diagram) Diagrammet benytter også (jf. Figur ) UML. Der benyttes de samme symboler som i angivet i afsnit Endvidere er der for at kunne udtrykke strukturerne præcist brug for følgende ekstra symboler: Den enkelte informationsmodel redigeres i et UML værktøj. DDV Governance-modellen beskriver hvordan en ny beskrivelse godkendes. Diagram og udfyldte skabeloner udstilles i en klikbar/navigerbar udgave på DDVs portal. Skabelonerne nedenfor angiver det indhold der skal beskrives. Et begreb kan præsenteres i portalen sammen med en tabel med attributterne og en liste med de relationer, som begrebet indgår i. I praksis kan tabellen med attributter være en god erstatning for at vise attributter direkte i diagrammet. Det anbefales (som minimum) at vise begrebets nøgle i selve diagrammet, men ikke fremmednøgler som det er praksis i de fysiske modeller. Side 23 af 40

29 4.2.3 Begrebsbeskrivelse (skabelon) Begreber i informationsmodellen beskrives med følgende skabelon: Navn Definition Formål Nøgle Attributter Metadata Entydigt navn på begrebet (er i diagrammet). Kort præcis beskrivelse. Der kan henvises til samme begreb i Informationsoverblikket for at undgå gentagelser. Hvorfor kan dette begreb ikke undværes? Vil ofte indeholde formuleringer som stamdata for.... Der kan henvises til samme begreb i Informationsoverblikket for at undgå gentagelser. Nøgle der benyttes eksternt ved udveksling af data i datasnitflade Liste af attributter, som er beskrevet i skabelonen nedenfor. Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Relationsbeskrivelse (skabelon) Relationer i informationsmodellen beskrives med følgende skabelon: Navn Definition Formål Metadata Entydigt navn på relationen (er i diagrammet). på formen <Begreb1><udsagsord><Begreb2> Evt. også navngivning af den anden læseretning igen på formen <Begreb2><udsagsord2><Begreb1> Kort præcis beskrivelse. Beskrivelse af formålet med relationen. Også gerne Hvorfor kan denne relation ikke undværes? Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Relationer er den logisk afløser for de fysiske modellers fremmenøgler. Relationerne kan med fordel listes som en tabel hørende til et begreb i informationsmodellen når de udstilles i portalen. Side 24 af 40

30 4.2.5 Attributbeskrivelse (skabelon) Attributter i begreber i informationsmodellen beskrives med følgende skabelon: Navn Definition Formål Kilde Værdisæt Evt. standardiserede værdier Evt. aliasser Metadata Navn på attributten (kan være vist i diagrammet). Navnet er som minimum entydigt inden for begrebet. Kort præcis beskrivelse. Beskrivelse af formålet med attributten på dette begreb. Hvor stammer denne attribut fra (Kunden, <ekstern part>, <proces> etc.). Hvis attributten er beregnet/afledt kan der angives (eller henvises) til formel mv. Datatype skal standardiseres (fx med udgangspunkt i de nuværende modeller) evt. min og max værdier Kodeliste med oversættelser til læsbar tekst Evt. reference til ekstern definition. Dokumentation af andre betegnelser for attributten evt. med markering af at de ikke bør bruges fremadrettet Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Attributterne kan med fordel listes som en tabel hørende til et begreb i informationsmodellen, når de udstilles på samme måde som de eksisterende modeller udstilles Trin Begreber kan enten identificeres og udfoldes modelmæssigt ud fra informationsoverblikket (top-down), eller ved at der i overblikket mangler en begreb, som benyttes i en bestemt proces eller datasnitflade, der ved at blive beskrevet/indlemmet (bottom-up), jf. Figur. Efter identifikation detaljeres informationsstrukturen i mindre begreber, relationer, bi-begreber og relationsbegreber og visualiseres i UML diagrammerne. Opdelingen i diagrammer med passende emner overvejes løbende. Det er vigtigt at se på tværs sådan at der ikke opstår lokale begreber, som egentlig hører hjemme i et andet diagram. I stedet modelleres en relation til begrebet i det andet diagram. Side 25 af 40

31 Begreber og relationer beskrives vha. skabelonerne ovenfor. Undervejs overvejes behovet for at generalisere og specialisere begreber. Når strukturerne er ved at falde på plads beskrives hver enkelt attribut vha. skabelonen ovenfor. Arbejdes der med en eksisterende model er der fokus på at lave udvidelser fortrinsvis ved knopskydning i form af nye begreber, relationer, bi-begreber, specialiseringer og attributter Tjekliste Når informationsmodellen udarbejdes eller ændres skal følgende tjekkes: Er beskrivelsen forretningsmæssigt retvisende? Repræsenterer beskrivelsen den ønskede fælles forretningsmæssige ramme? Bemærk: Et selskab kan efter behov i egen udgave af modellerne struktureret tilføje egne udvidelser tydeligt udskilt i separate UML symboler (typisk med specialisering). Sådanne udvidelser kan evt. senere indlemmes i de fælles modeller jf. DVD Governance-modellen, og det pågældende selskab kan reducere egne modeludvidelser. Er metoden overholdt? Er UML anvendt korrekt? Giver diagrammet en god visualisering af begreberne inden for område med en læsevenlig og støttende strukturering? Er (de nye) begreber navngivet sigende og beskrevet dækkende e, og i overensstemmelse med informationsoverblikket hvor relevant fx for hovedbegreberne, der jo netop går igen? Er (de nye) relationer navngivet sigende og beskrevet dækkende, og i overensstemmelse med informationsoverblikket hvor relevant? Er (de nye) attributter navngivet sigende og beskrevet dækkende? Er generalisering/specialisering anvendt passende for de beskrevne begreber? Der er følgende sammenhæng til andre arkitekturbeskrivelser: Informationsmodellerne refererer til informationsoverblikket. DDV Domæner og Datasnitflader vil referere til informationsmodellen og dens attributter. DDV beskrevne forretningsaktiviteter i processerne kan referere til begreber fra informationsoverblikket Begreberne i informationsoverblikket er detaljeret i informationsmodellerne Figur 6 viser sammenhængen mellem Forretnings- og Informationsbeskrivelserne, mens Figur 9 viser sammenhængen til Applikations-beskrivelserne. Side 26 af 40

32 Figur : Sammenhæng fra Informationsbeskrivelserne til Forretning. Side 27 af 40

33 5 Arkitekturbeskrivelser for Applikation It-arkitekturen i DDV skal beskrive de fælles rammer og krav som formuleres i DDV regi. It-arkitekturen beskriver it-understøttelsen af forretningsarkitekturen, som har metode som beskrevet i kapitel 3 og 4. I metoden for it-arkitekturen i dette kapitel fokuseres ligeledes både overordnet (konceptuelt) og i yderligere detalje for at sætte rammerne mere præcist (logisk) som angivet i Figur. Arkitekturprodukterne her hører til Applikationssøjlen i OIO EA rammeværket. I projektbeskrivelsen blev de omtalt kort som dataservices og valg af integrationsmønstre. Figur : Arkitekturbeskrivelser for Applikationer Side 28 af 40

34 5.1 Domæneoverblik Formål Domæneoverblikket er et højniveau-perspektiv på et selskabs applikationer set generaliseret som domæner. De udgør en logisk, systematisk og leverandøruafhængig opdeling af systemlandskabet med det formål at standardisere dataintegrationer. Domæneoverblikket dokumenterer den fælles standardiserede applikationsopdeling overordnet både visuelt og i form af beskrivelser. Den mere mundrette betegnelse domæne er valgt frem for det mere præcise applikationsdomæne. Hvert domæne dækker en velafgrænset del af datastrukturen i informationsmodellerne. Et domæne er master for en række af de forretningsinformationer, der registreres i selskabet. Denne sammenhæng beskrives konceptuelt, dvs. på overbliksniveau i DDV-regi (se afsnit nedenfor). Domæneoverblikket fungerer som en knagerække for de mere detaljerede beskrivelser af logiske dataudvekslinger i DDV-arkitekturen. Domænerne sætter således grænserne, sådan at it-arkitekturen i DDV beskriver datasnitflader mellem domænerne. Dataintegrationerne mellem domæner beskrives som dataudvekslinger vist i et domæneflow (se afsnit 5.3 nedenfor). Domænerne illustreres, navngives, kategoriseres og beskrives som beskrevet i dette afsnit af metoden. Domæneoverblikket viser også hvor den fælles rammesættende DDV-arkitektur er udbygget på it-siden, og hvor den ikke er det, og kan benyttes ved planlægning af nye arkitekturprojekter Domæneoverblik (diagram) Diagrammet (jf. Figur ) er en uformel, semi-struktureret grafisk fremstilling bestående af følgende symboler og anden hjælpegrafik, der visualiserer domænerne, deres sammenhæng og fællestræk: Overblikket kan af praktiske årsager tegnes i flere diagrammer frem for ét stort. Domæneoverblikket vedligeholdes i DDV regi. Det udstilles i en klikbar/navigerbar udgave på DDVs portal, der bringer de enkelte beskrivelser frem. Side 29 af 40

35 5.1.3 Domænebeskrivelse (skabelon) Domænerne beskrives med følgende skabelon Navn Navn på domænet. Navnet skrives med stort begyndelsesbogstav Eksempler kunne være SRO og GIS Beskrivelse Masterdata Kort beskrivelse af domænet i form som et ordbogsopslag. Evt. forkortelser skal forklares. Her angives fra informationsoverblikket hvilke data, som domænet dækker for ud fra en masterdata-tankegang. Har domænet ansvaret for et helt informationsområde kan dette angives, ellers skal de enkelte begreber i informationsområdet listes. Andre domæner skaffer sig data gennem dataudvekslinger gennem de standardiserede snitflader. Stikord / Søgeord Metadata Her angives ord som kendetegner domænet og som kan hjælpe med at finde hvilket domæne, der håndterer hvad. Det anbefales at liste fx funktionalitet. DDV-integrationsmetoden er ikke en kravspecifikationsmetode, men at have en fortegnelse med søgbare stikord vil gøre domænerne lettere at anvende og forstå. Der anvendes samme metodik der er anvendt for i Forretningsreferencemodellen, FORM, på Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Trin Domæner identificeres fortrinsvis top-down ud fra en helhedsbetragtning. I sjældnere tilfælde vil en konkret beskrivelse af en dataudveksling føre til navngivning af et nyt domæne, når det opdages at der slet ikke er noget eksisterende, passende domæne. Efter identifikation beskrives domænet vha. skabelonen ovenfor. Der skal eventuelt justeres ift. hvad andre domæner dækker af data for at have et entydigt og veldefineret masterdata set-up. Domæneoverblikket forventes at være rimeligt stabilt og udvikler sig mest i form af tilføjelser, når der beskrives/indlemmes nye processer i DDV-arkitekturen. Domæner kan i første omgang være skitserede for så at blive mere håndfast, når de første dataintegrationer beskrives. Domæneoverblikket er under DDV governance og ændrer sig som besluttet og fortrinsvis ud fra forretningsmæssige overvejelser. Fx kan det komme på tale at opdele et domæne i to, når der er behov for at standardisere en dataintegration, der før var internt i ét domæne. Side 30 af 40

36 Bemærk at en systemleverandør kan have en løsning, der dækker to domæner fx SRO og GIS. DDV arkitekturen stiller krav om at når der udveksles data mellem løsningen og andre løsninger, skal det foregå som foreskrevet i arkitekturen gennem standardiserede snitflader for at løsningen kan leve op til arkitekturen, således at løsningen skal udstille alle DDV arkitekturens snitflader for de pågældende domæner Tjekliste Når domæneoverblikket udarbejdes eller ændres skal følgende tjekkes for diagram og udfyldte skabeloner: Er beskrivelsen forretningsmæssigt og teknisk forståelig? Er beskrivelsen it-mæssigt retvisende? Er der angivet brugbare og forståelige søgeord? Repræsenterer domænerne den ønskede fælles it-mæssige ramme? Er metoden overholdt? Giver diagrammet en god visualisering af domænerne med en for læseren læsevenlig og støttende strukturering og en forståelig, korrekt gruppering.? Er (de nye) domæner navngivet sigende og beskrevet dækkende? Er domænerne navngivet ensartet? Der er følgende sammenhæng til andre arkitekturbeskrivelser: I Domæneflow (se afsnit 5.3 nedenfor) benyttes kun domæner fra domæneoverblikket. Et domæne har ansvaret for et udsnit af Informationsoverblikket i form af hele eller dele af informationsområderne. 5.2 Integrationsmønstre Formål Samlingen af integrationsmønstre giver et overblik over de i DDV godkendte metoder og teknologier at udveksle data på, og er dermed en vigtig del af den fælles rammesættende it-arkitektur. Et mønster angiver en væsentlig og ønsket måde at integrere på, og kan være opdelt i en række teknologivarianter, der rummer forskellige tekniske standarder for samme mønster, fx SOAP og REST i et servicemønster. Side 31 af 40

37 5.2.2 Integrationsmønsterbeskrivelse (skabelon) Integrationsmønstre beskrives med følgende skabelon: Navn Ikon Beskrivelse Navn på integrationsmønstret. En repræsentativ illustration af integrationsmønsteret som kan benyttes til en oversigtstegning og i præsentationer Kort beskrivelse af integrationsmønstret i form som et ordbogsopslag. Er der tale om et ikke (længere) anbefalet mønster markeres dette tydeligt. Anvendelse Virkemåde Overvejelser Teknologivarianter Referencer Metadata Her dokumenteres de anvendelsesscenarier, som mønsteret er velegnet til at understøtte Her dokumenteres hvordan mønsteret virker uden at gå i for mange tekniske detaljer. Her angives hvilke specifikke overvejelser der gør sig gældende for valg og brug af mønsteret. Herunder fordele og ulemper fx vedr. sikkerhed, tilgængelighed og muligheder for hosting. Teknologivarianter herunder protokoller og standarder fx inden for og uden for firewall. Her angives evt. overvejelser specifikt for denne teknologivariant fx vedr. sikkerhed, tilgængelighed og hosting. Henvisninger til eksterne beskrivelser og eksempler på implementeringer. Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Fortegnelsen over DDV integrationsmønstre vedligeholdes i DDV regi. Det udstilles i en klikbar/navigerbar udgave på DDVs portal, der bringer de enkelte beskrivelser frem Trin Integrationsmønstre identificeres typisk top-down, men med øje for udbuddet af metoder og teknologi. Efter identifikation beskrives mønsteret vha. skabelonen ovenfor. Samlingen af integrationsmønstre er ret stabil og udvikler sig mest sammen med de forskellige teknologistandarder og nye generationer af teknologien. Det er således vigtigt i DDV regi at orientere sig vedr. den teknologiske udvikling mht. integrationer. Side 32 af 40

38 5.2.4 Tjekliste Når integrationsmønstrene udarbejdes eller ændres skal følgende tjekkes: Er beskrivelsen teknisk forståelig? Er beskrivelsen it-mæssigt retvisende? Repræsenterer beskrivelsen den ønskede fælles it-mæssige ramme? Er metoden overholdt? Dækker mønstrene de ønskede måder at integrere på i praksis? Er mønstrene og evt. teknologivarianter beskrevet så man i praksis kan vælge mellem dem til en konkret snitflade Der er følgende sammenhæng til andre arkitekturbeskrivelser: Integrationsmønstrene med teknologivarianter benyttes når der for hver datasnitflade skal vælges en standardiseret måde at integrere på (se afsnit 5.4 nedenfor). 5.3 Domæneflow Formål Domæneflows viser hvordan forretningsprocesserne it-understøttes med dataintegrationer mellem DDV domænerne. Det dokumenterer den fælles forståelse i branchen både visuelt som diagrammer og i form af beskrivelser. Fokus er på at vise datasamspillet mellem domæner ved at afbilde brugen af snitflader. Beskrivelsen er ikke en kravspecifikation og holdes fri af detaljer om brugergrænseflader, forretningslogik mv. Et domæneflow viser it-understøttelsen typisk af en enkelt forretningsproces fra indefra perspektivet. I forretningsprocessen set indefra tegnes den teknologifri, logiske og ideelle proces, hvor domæneflowet viser itunderstøttelsen i form af dataudvekslinger mellem domæner fra domæneoverblikket. Antallet af domæner, der kommer i brug afhænger af processens formål og af inddelingen i domæner fra domæneoverblikket. I visse situationer eksempelvis pga. teknologiske afhængigheder kan det give en bedre forståelse at understøtte et forretningsproces med flere domæneflows, som så til gengæld kan genbruges til at understøtte flere forretningsprocesser, fx en replikering af data mellem to domæner, når et sådant integrationsmønster vælges Domæneflow (diagram) Diagrammet benytter (jf. Figur ) BPMN på den særlige måde at hvert domæne er repræsenteret med en BPMN pool, da dataintegrationer mellem domæner er den primære fokus. Afhængig af domænerne kan der være behov for at vise eksterne parters systemer som pool, når der leveres eller modtages data eksternt. Se eksempel 2 til illustration. Side 33 af 40

39 Der benyttes de samme BPMN-symboler som til den enkelte proces set indefra (jf. afsnit og 3.4.2). Da det nu er en it-mæssig beskrivelse har følgende to symboler dog en ændret betydning: Beskednavn Beskedpil Som vist på Figur benyttes BPMN symbolet beskedpil i domæneflows til dataudvekling mellem to domæner. Beskednavnet er hæftet på beskedpilen, der viser hvilken primær retning data flyder. Der tegnes ikke to beskeder selvom fx et servicekald er initieret med parametre som input. Figur : Symbolbrug i domæneflow vist blot mellem to domæner. Det enkelte domæneflow redigeres i et BPMN værktøj og bruger BPMN som foreskrevet. DDV Governancemodellen beskriver hvordan en ny beskrivelse godkendes. Diagram og udfyldte skabeloner udstilles i en klikbar/navigerbar udgave på DDVs portal Domæneflowbeskrivelse (skabelon) Domæneflowet beskrives med følgende skabelon: Navn Beskrivelse Evt. forudsætninger Understøttede processer Navn på domæneflowet Kort beskrivelse af domæneflowet i form som et ordbogsopslag inklusive formål. Kort beskrivelse af hvad der skal være opfyldt før flowet kan udføres, fx at et andet navngivet domæneflow er gennemført først. Her angives hvilken (eller hvilke) forretningsproces(ser) fra indefra- perspektivet, der understøttes af dette domæneflow. Side 34 af 40

40 Snitflader Hvilke snitflader benyttes (er vist i diagrammet i form af dataudvekslinger mellem domæner) Datasnitflader beskrives som angivet i afsnit 5.4. En datasnitflade kan benyttes i flere domæneflows. Metadata Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Trin Domæneflow kan enten identificeres top-down og udformes som ønsket it-understøttelse af den enkelte proces set indefra. Alternativt kan domæneflowet optegnes ved at generalisere fra en konkret systemintegration, som ønskes standardiseret (bottom-up), jf. Figur. Top-down beskrives med udgangspunkt i domæneoverblikket og de enkelte domæners dataindhold et flow af aktiviteter og dataudvekslinger, der understøtter forretningsprocessen. Der kan evt. tegnes både en gældende og flere alternativer til kommende versioner. Efter beslutning vælges det flow som standardiseringen fremover skal bygge på. Arbejdes der bottom-up skal der ligeledes tages stilling til om domæneflowet også fremadrettet er den ønskede it-understøttelse, eller om der skal tegnes et forslag til en forbedret version. Samarbejdet mellem domæner i form af en sekvens af aktiviteter i flowet og dataudvekslinger illustreres med BPMN diagram og beskrives vha. skabelonen ovenfor. Er der tale om udvidelser af en eksisterende beskrivelse justeres diagram og skabelon i stedet Tjekliste Når et domæneflow beskrives eller ændres skal følgende tjekkes: Er beskrivelsen teknisk forståelig? Er beskrivelsen it-mæssigt retvisende? Repræsenterer beskrivelsen den ønskede fælles it-mæssige ramme? Er metoden overholdt? Er BPMN anvendt korrekt? Giver diagrammet for læseren en god visualisering af hvordan domænerne samarbejder integrationsmæssigt i den givne sammenhæng? Svarer diagrammet til beskrivelsen? Er domæneflowet beskrevet dækkende vha. skabelonen? Er der kun anvendt domæner, der findes i domæneoverblikket? Er navngivningen af dataudvekslinger forståelig og logisk? Vender dataudvekslingerne rigtigt ud fra det ansvar for data som de enkelte domæner har? Er det en passende it-understøttelse af forretningsprocessen med de givne domæner? Side 35 af 40

41 Er koblingen til den it-understøttede forretningsproces fra indefra-perspektivet forståelig? Der er følgende sammenhæng til andre arkitekturbeskrivelser: Det enkelte domæneflow understøtter en (eller evt. flere) forretningsproces(ser) i indefraperspektivet Flowets pools skal være navngivne domæner i domæneoverblikket. De enkelte dataudvekslinger er beskrevet i detaljer som datasnitflader (se afsnit 5.4nedenfor) 5.4 Datasnitflader Formål Beskrivelsen dokumenterer indholdet af de enkelte dataintegrationer mellem domæner på logisk niveau inklusive de nøgler, der udveksles. Datasnitfladerne er den mest detaljerede del af DDVs it-arkitektur. Hver datasnitflade beskriver én standardiseret dataudveksling mellem to domæner. Behovet for den og konteksten er vist i (mindst) et domæneflow Datasnitfladebeskrivelse (skabelon) Hver datasnitflade beskrives med følgende skabelon: Navn Beskrivelse Input Navn på datasnitfladen (er vist i dataobjektet i domæneflowet) Kort beskrivelse af formålet med denne datasnitflade. Inputparametre når datasnitfladen anvendes fx søgekriterier til en søgning eller nye værdier til attributter i en opdatering. Indholdet skal referere til informationsmodellerne i form af attributter betegnet præcist på formen informationsmodel::begreb.attribut Output Output/resultat beskrevet som en logisk record-struktur, som har en simpel hierarkisk struktur. Indholdet kommer fra informationsmodellerne i form af attributter betegnet præcist på formen informationmodel::begreb.attribut eller gennemløb af relationer der giver en nøgle til et eller flere relaterede objekter fx at liste nøgler for en kundes fakturaer for en given periode. Record-strukturen kan illustreres i et UML diagram (se afsnit 0 nedenfor) Side 36 af 40

42 Integrationsmønster Udvekslingsformat Evt. links til fysisk dokumentation Metadata Det valgte integrationsmønster inkl. eventuelle teknologivarianter. Det valgte udvekslingsformat blandt de gængse for det valgte integrationsmønster og evt. teknologivariant. For specialiserede domæner kan det være en speciel XML standard. Når snitfladen er dokumenteret fysisk kan snitfladebeskrivelsen benyttes til at gemme reference/henvisninger hertil fx reference til XML skemaer for en service eller en kommasepareret fil for en dokumentudveksling. Metadata for beskrivelsen: Status (gældende, forslag) Version Udarbejdet af Ændringslog Den enkelte datasnitflade beskrivelse redigeres som skabelon. DDV Governance-modellen beskriver hvordan en ny beskrivelse godkendes. Udfyldte skabeloner og evt. hjælpediagrammer udstilles i en klikbar/navigerbar udgave på DDVs portal Record-struktur (hjælpediagram) Diagrammet benytter få UML symboler til at beskrive strukturen af en dataudveksling. Samme overvejelser vedrørende værktøj og præsentation som for informationsmodellerne Trin Hver dataudveksling, der figurerer i et domæneflow, skal være beskrevet som en datasnitflade. En snitflade kan genbruges i flere domæneflows. Side 37 af 40

43 Snitfladen beskrives fuldstændigt vha. skabelonen ovenfor. De data der indgår som felter skal vælges fra de relevante informationsmodeller. Integrationsmønstret vælges ud fra de overvejelser der er noteret under de enkelte integrationsmønstre jf. skabelonen i afsnit Tjekliste Når beskrivelsen af datasnitfladen udarbejdes eller ændres skal følgende tjekkes: Er beskrivelsen teknisk forståelig? Er beskrivelsen it-mæssigt retvisende? Repræsenterer beskrivelsen den ønskede fælles it-mæssige ramme? Er metoden overholdt? Er alle data beskrevet i informationsmodellerne som attributter og relationer? Er henvisninger til informationsmodellerne korrekte og fuldstændige? Er UML anvendt korrekt i evt. hjælpediagram? Er det valgt et passende integrationsmønster og eventuelle teknologivarianter. Der er følgende sammenhæng til andre arkitekturbeskrivelser (illustreret på Figur 9): Hver datasnitflade beskriver en dataudveksling i et (eller flere) domæneflow(s) Dataindholdet i en snitflade skal stamme fra informationsmodellen. Det valgte integrationsmønster stammer fra listen med integrationsmønstre Figur : Sammenhæng fra Applikationsbeskrivelserne til Forretning og Information. Side 38 af 40

44 Appendiks A: Sammenhæng til OIO EA De orange pile på Figur viser hvor den beskrevne metode kan benyttes til at fylde indhold i DVD arkitekturen. Endvidere markeres projektets leverancer, og med orange skravering udstrækningen af DDVs rammesættende it- og forretningsarkitektur. Figur og 12 viser mere præcist hvor DDV arkitekturbeskrivelserne dækker. Figur : DDV-integrationsmetodens rækkevidde skitseret ved projektets start Figur : Fokus på arkitekturdokumenterne med OIO EAs betegnelser Side 39 af 40

PLAN OG UDVIKLING GIS-STRATEGI 2012-2016

PLAN OG UDVIKLING GIS-STRATEGI 2012-2016 PLAN OG UDVIKLING GIS-STRATEGI 2012-2016 Indhold 1 INDLEDNING 3 2 STRATEGIGRUNDLAGET OG HANDLINGSPLAN 5 3 VISION 6 4 PEJLEMÆRKER OG PRINCIPPER 8 4.1 TEKNOLOGI 8 4.1.1 Principper 8 4.2 KOMMUNIKATION 9 4.2.1

Læs mere

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem Arkitekturrapport: Kommunernes Ydelsessystem 1 Indholdsfortegnelse Baggrund for projekt... 3 Resultat af gennemført arkitekturanalyse... 5 Anvendelse af forretningsservices... 9 Baggrund for projekt Baggrund

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

Grunddataprogrammet. Ibrugtagningsplan for modelregler for grunddata

Grunddataprogrammet. Ibrugtagningsplan for modelregler for grunddata Grunddataprogrammet Ibrugtagningsplan for modelregler for grunddata 1 Ibrugtagningsplan for modelregler for grunddata Version: 0.5 Status: Godkendt 2 Versionshistorik Version Dato Status Bemærkninger 0.1

Læs mere

Supermarkedsmodellen for design af brugergrænseflade

Supermarkedsmodellen for design af brugergrænseflade Supermarkedsmodellen for design af brugergrænseflade Denne note er skrevet frit efter Peter Huber, som på et kursus i Efteruddannelsescenteret fortalte om supermarkedsmodellen til design af brugergrænseflader.

Læs mere

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering OI OXML som obligatorisk, åben standard - uddybende vejledning 1 Om dette dokument Dette dokument beskriver anbefalet praksis for at anvende OIOXML som åben, obligatorisk standard. IT- og Telestyrelsen

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Januar 2014 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

Strategi 2013-2017 Danmarks Miljøportal

Strategi 2013-2017 Danmarks Miljøportal Strategi 2013-2017 Danmarks Miljøportal Introduktion Danmarks Miljøportal (DMP) har ansvaret for en digital infrastruktur på miljøområdet, der gør det muligt for myndigheder og offentlighed at få nem adgang

Læs mere

FORRETNINGSSTRATEGI SUNDHED.DK

FORRETNINGSSTRATEGI SUNDHED.DK FORRETNINGSSTRATEGI SUNDHED.DK INDHOLD 01 Om dokumentet 3 02 Sundhed.dk s forretning 4 02.1 Mission og vision 4 02.2 Sundhed.dk s position og marked 4 02.3 Sundhed.dk s fundament og leverancer 5 02.4 Målgrupper

Læs mere

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER Kommunernes it-arkitekturråd 8. maj 2014 AGENDA Væsentligste observationer og konklusioner Relevans for kommuner STRATEGI OG ARKITEKTUR Analysen giver et bud

Læs mere

Scope dokument for Advisservice

Scope dokument for Advisservice 18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.

Læs mere

En mere effektiv vandsektor

En mere effektiv vandsektor En mere effektiv vandsektor - Vækst, effektivisering og udvikling. v. Direktør Carl-Emil Larsen, DANVA DANVA Godthåbsvej 83 8660 Skanderborg T: 7021 0055 E:danva@danva.dk www.danva.dk Kort om DANVA Brancheforening

Læs mere

Ejerfortegnelse Løsningsarkitektur Bilag C Processer Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi 2012 2015

Ejerfortegnelse Løsningsarkitektur Bilag C Processer Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi 2012 2015 Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltningg og genbrug af ejendomsdataa under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet Ejerfortegnelsen Løsningsarkitektur

Læs mere

Den nye fælles offentlige kravspecifikation. v/ projektleder Anna Schou Johansen

Den nye fælles offentlige kravspecifikation. v/ projektleder Anna Schou Johansen Den nye fælles offentlige kravspecifikation v/ projektleder Anna Schou Johansen Mål og visioner for kravspecifikationen Øget intern og ekstern sammenhæng Effektivisere indkøb og systemopbygning Optimering/effektivisering

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

Professionel Udvælgelse i byggeriet Skabeloner

Professionel Udvælgelse i byggeriet Skabeloner Professionel Udvælgelse i byggeriet Skabeloner Vejledning i anvendelsen af skabeloner til brug for udvælgelse, herunder prækvalifikation i byggeriet Marts 2013 Byggeriets Evaluerings Center SOLIDARISK

Læs mere

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt.

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. 8. april 2013 19-Partskontakt => Kontaktdata Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. I de oprindelige oplæg med visionen

Læs mere

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7 OIO Serviceprincipper Version: 1.1 Status: i høring i PF for GD1 og GD2 Oprettet: 4. juni 2014 Dato: 4. juni 2014 Dokument historie Version Dato Beskrivelse

Læs mere

Bilag 1 Tidsplan Version 0.9 05-05-2014 0

Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 ETAPER I UDVIKLINGSPROJEKTET... 3 2.1.1 ETAPE I - AFKLARING... 3 2.1.2 ETAPE II ANALYSE, DESIGN,

Læs mere

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder.

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder. It-strategi 1.0 Indledning Flere og flere forretningsprocesser i kommunerne stiller krav til it-understøttelse, og der er store forventninger til at den offentlige sektor hænger sammen inden for it-området.

Læs mere

Arkitekturrapport: KITOS - Kommunens It-Overbliks System

Arkitekturrapport: KITOS - Kommunens It-Overbliks System Arkitekturrapport: KITOS - Kommunens It-Overbliks System Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af projektets it-arkitekt.

Læs mere

Digital strategi, indsatsområde 1, delprojekt 1, Generiske sagsbehandlingsbegreber

Digital strategi, indsatsområde 1, delprojekt 1, Generiske sagsbehandlingsbegreber HØRINGSDOKUMENT Fra: Til: Resumé: David Rosendahl Høringsparter Arbejdsgruppen har identificeret de overordnede og tværgående begreber i sagsbehandlingsprocessen og struktureret og defineret disse generiske

Læs mere

BILAG 1 KRAVSPECIFIKATION ØKONOMI OG LØN

BILAG 1 KRAVSPECIFIKATION ØKONOMI OG LØN BILAG 1 KRAVSPECIFIKATION ØKONOMI OG LØN VEJLEDNING Kravspecifikationen af de udbudte løn- og økonomisystemer udgøres af: Bilag 1 kravspecifikation A (fælles) Bilag 1 kravspecifikation B (løn) Bilag 1

Læs mere

Introduktion til Støttesystem Organisation

Introduktion til Støttesystem Organisation Introduktion til Støttesystem Organisation 1. Om dokumentet Dette dokument formidler et overblik over Støttesystemet Organisation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse

Læs mere

Bilag: Resultat af spørgeskemaundersøgelse

Bilag: Resultat af spørgeskemaundersøgelse Bilag: Resultat af spørgeskemaundersøgelse Hvad er din titel? Student senior it-konsulent It-udviklings- og digitaliseringskonsulent Projektleder IKT-driftchef Projektleder enterprise architect Systemadministrator

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

ZEBRANET. Serviceorienteret Arkitektur. Enterprise Architecture Trends og Perspektiver. Allan Bo Rasmussen Zebranet ApS abr@zebranet.

ZEBRANET. Serviceorienteret Arkitektur. Enterprise Architecture Trends og Perspektiver. Allan Bo Rasmussen Zebranet ApS abr@zebranet. Enterprise Architecture Trends og Perspektiver E-BUSS konference 14. september 2007 Allan Bo Rasmussen Zebranet ApS abr@zebranet.dk ZEBRANET Serviceorienteret SOA og Enterprise Architechture Definitioner

Læs mere

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

Læs mere

Opsamling på kommunal høring. Vejle & Roskilde Den 18. Juni 2013

Opsamling på kommunal høring. Vejle & Roskilde Den 18. Juni 2013 Opsamling på kommunal høring Vejle & Roskilde Den 18. Juni 2013 Dagsorden Velkommen Høringsprocessen frem til udbuddet på KY Resultater fra høringen Udbudsmaterialet kapitel 1 4, 5 og 6 Temaer: EDSH, opgavelisten,

Læs mere

Innovationens Syv Cirkler

Innovationens Syv Cirkler Innovationens Syv Cirkler Med denne gennemgang får du en kort introduktion af Innovationens Syv Cirkler, en model for innovationsledelse. Dette er en beskrivelse af hvilke elementer der er betydende for

Læs mere

Vejledning til proces for design af gevinstdiagram

Vejledning til proces for design af gevinstdiagram Januar 2014 Indhold 1. FORMÅL... 3 FORMÅLET MED DENNE PROCESVEJLEDNING... 3 2. GEVINSTDIAGRAM... 3 2.1. AKTIVITE TER... 4 DEFINER MÅLSÆTNINGER... 5 IDENTIFICER GEVINSTER... 5 IDENTIFICER RESULTATER, FORANDRINGSEVNER

Læs mere

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

Læs mere

Fremtidsmodel (Blueprint) - Vejledning

Fremtidsmodel (Blueprint) - Vejledning Fremtidsmodel (Blueprint) - Vejledning Januar 2014 Indhold 1. FORKLARING PÅ CENTRALE BEGREBER... 3 2. HVAD ER FREMTIDSMODELLEN (BLUEPRINT)... 4 3. FORMÅLET MED FREMTIDSMODELLEN... 4 4. HVEM MODTAGER FREMTIDSMODELLEN...

Læs mere

Arkitekturrapport: Ejendomsskatte- og Ejendomsbidragsløsningen. Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af

Arkitekturrapport: Ejendomsskatte- og Ejendomsbidragsløsningen. Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af Arkitekturrapport: Ejendomsskatte- og Ejendomsbidragsløsningen Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapporten ejes af projektets

Læs mere

Pixibog business casen kort fortalt... 2. 1: Projektbasis... 3. 2: Leverancen... 4. 3: Milepæle og tidsplan... 6. 4: Ressourcer... 7. 5: Økonomi...

Pixibog business casen kort fortalt... 2. 1: Projektbasis... 3. 2: Leverancen... 4. 3: Milepæle og tidsplan... 6. 4: Ressourcer... 7. 5: Økonomi... Pixibog business casen kort fortalt... 2 1: Projektbasis... 3 1.1: Projektidentifikation...3 1.2: Projektansvarlige...3 2: Leverancen... 4 2.1: Mål og rammer...4 2.2: Fremgangsmåde...5 2.3: Risikoanalyse

Læs mere

En midlertidig organisation der etableres for at levere en eller flere leverancer til opnåelse af forandringsevne

En midlertidig organisation der etableres for at levere en eller flere leverancer til opnåelse af forandringsevne Sammenfattende definitioner Definition og beskrivelse Vision En portefølje er en samling af projekter/mer, som vurderes samlet med henblik på at optimere sammensætning og prioritering af strategiske indsatser

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2 UC Effektiviseringsprogrammet Projektgrundlag Business Intelligence version 1.2 9. september 2014 1 Stamdata Stamdata Projektnavn (forventet): Projektejer: Projekttype: Business Intelligence It-chef Hans-Henrik

Læs mere

7. Forslag om optagelse af standarden OVF i OIO Kataloget (B)

7. Forslag om optagelse af standarden OVF i OIO Kataloget (B) Et emne, som allerede har affødt en del debat, er den obligatoriske brug af elektronisk kommuni kation, som blandt andet sidestiller en e mailhenvendelse med en henvendelse modtaget med pa pirpost, hvilket

Læs mere

It-delstrategi for administrativ it-anvendelse

It-delstrategi for administrativ it-anvendelse Administrativ DELSTRATEGI 2011-2015 NOTAT It-delstrategi for administrativ it-anvendelse 9. september 2011 Indholdsfortegnelse 1. Formål...2 2. Baggrund...2 3. Vision...3 4. Strategisk retning...3 4.1.

Læs mere

Anvendelse af dobbelthistorik i GD2

Anvendelse af dobbelthistorik i GD2 Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:

Læs mere

Kommissorium for Domænebestyrelsen for Bygninger, Boliger og Forsyning

Kommissorium for Domænebestyrelsen for Bygninger, Boliger og Forsyning Kommissorium for Domænebestyrelsen for Bygninger, Boliger og Forsyning Introduktion Besluttet af Styregruppen for Tværoffentligt Samarbejde, marts 2008 I forlængelse af den fællesoffentlige strategi for

Læs mere

Rollebeskrivelser. Programroller ift. den fællesstatslige programmodel

Rollebeskrivelser. Programroller ift. den fællesstatslige programmodel Rollebeskrivelser Programroller ift. den fællesstatslige programmodel Indholdsfortegnelse Rollebeskrivelser... 1 1. Programprofiler... 3 1.1. Formand for programbestyrelse/programejer... 3 1.2. Programleder...

Læs mere

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning Rollebeskrivelser i den fællesstatslige programmodel - Vejledning August 2013 Indhold 1. LÆSEVEJLEDNING... 1 2. FORMAND FOR PROGRAMBESTYRELSEN (PROGRAMEJER)... 2 3. PROGRAMLEDER... 3 4. FORANDRINGSEJER...

Læs mere

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning Rollebeskrivelser i den fællesstatslige programmodel - Vejledning Januar 2014 Indhold 1. LÆSEVEJLEDNING... 1 2. FORMAND FOR PROGRAMBESTYRELSEN (PROGRAMEJER)... 2 3. PROGRAMLEDER... 3 4. FORANDRINGSEJER...

Læs mere

GD1/GD2 - Model for supplerende forretningsbeskrivelser

GD1/GD2 - Model for supplerende forretningsbeskrivelser Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Bilag 11 - Fælles arkitekturramme for GD1-GD2-GD7 GD1/GD2 - Model for supplerende forretningsbeskrivelser Udbudsoption vedrørende supplerende forretningsbeskrivelser.

Læs mere

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU)

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Foranalyse Projekt: PDM-kerne Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Projektdeltagere: 1. Indledning og baggrund Mogens Sandfær (MS), Danmarks Tekniske Universitet (DTU) Jørgen

Læs mere

SPORBESKRIVELSE FOR ØKONOMISTYRINGSSPORET

SPORBESKRIVELSE FOR ØKONOMISTYRINGSSPORET SPORBESKRIVELSE FOR ØKONOMISTYRINGSSPORET Sporbeskrivelse for Dokumentkontrol Revisionshistorik Ændringer: Ændrings dato Hvad er der blevet ændret 11062008 Dokument oprettet Distribution Dette dokument

Læs mere

Dokumentationsguide for dansk Bankkonto

Dokumentationsguide for dansk Bankkonto Dokumentationsguide for dansk Bankkonto OIOXML dokumentationsguide for dansk Bankkonto Denne guide er udarbejdet af Peter Neergaard Jensen, IT- og Telestyrelsen, i regi af Kernekomponentgruppen under XML-projektet

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Fælles UC Videoplatform 08-05-2014

UC Effektiviseringsprogrammet. Projektgrundlag. Fælles UC Videoplatform 08-05-2014 UC Effektiviseringsprogrammet Projektgrundlag Fælles UC Videoplatform 08-05-2014 Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen Produkt: Projektgrundlag, ver. 27/8-2013 1 Stamdata Stamdata

Læs mere

Bilag 2A Sådan forretningsmodellerer vi i ATP

Bilag 2A Sådan forretningsmodellerer vi i ATP Bilag 2A Sådan forretningsmodellerer vi i ATP Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 SÅDAN FORRETNINGSMODELLERER VI I ATP... 4 2.1 FORRETNINGSMODELLERING I KONTEKST AF FORRETNINGSARKITEKTUREN...

Læs mere

Fællesskabet der vil noget mere

Fællesskabet der vil noget mere Fællesskabet der vil noget mere Jens Kjellerup Digitaliseringschef Ballerup Kommmune & Bestyrelsen OS 2 - Offentlig Digitaliseringsfællesskab jeh2@balk.dk Tlf. +45 2477 4242 Agenda Digitaliseringslandskabet

Læs mere

Den forretningsorienterede mobile IT strategi

Den forretningsorienterede mobile IT strategi Den forretningsorienterede mobile IT strategi v/ Bo Snitkjær Nielsen bsn@globeteam.com 5. Oktober 2011 Globeteam Virumgårdsvej 17A 2830 Virum Indhold Den forretningsorienterede mobile IT strategi Hvorfor

Læs mere

VandGraf VarmeGraf ElGraf Brugermøde

VandGraf VarmeGraf ElGraf Brugermøde VandGraf VarmeGraf ElGraf Brugermøde Ved Lars Bodin & Jesper Stahl Madsen Program Programændringer og fejlrettelser: Ny VandGraf brugervejledning! Forbedret Lukkeplan v/jsma Brugerdefinerede layout og

Læs mere

Ledelse af digitalisering

Ledelse af digitalisering Ledelse af digitalisering SCKK temamøde om digital forvaltning 7. april 2006 Mikael Skov Mikkelsen Finansministeriet msm@fm.dk - www.e.gov.dk Dagsorden Hvorfor og hvordan ledelse af digitalisering? Den

Læs mere

Governancemodel for kommuner og KL's involvering i Projekter/Løsninger i KOMBIT

Governancemodel for kommuner og KL's involvering i Projekter/Løsninger i KOMBIT 13. maj 2014 NOTAT Governancemodel Governancemodel for kommuner og KL's involvering i Projekter/Løsninger i KOMBIT Resume: Notatet beskriver den fælles governancemodel for kommunerne og KL s involvering,

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

Fælleskommunale arkitekturprincipper, version 1.0

Fælleskommunale arkitekturprincipper, version 1.0 Fælleskommunale arkitekturprincipper, version 1.0 27. februar 2013 Udarbejdet af en arbejdsgruppe af kommunale it-arkitekter under Kommunernes It-Arkitekturråd. Side 1 af 28 Medlemmer af arbejdsgruppen:

Læs mere

Peter Kragh Hansen. Microsoft PowerPoint 2013 DK. ISBN nr.: 978-87-93212-07-7

Peter Kragh Hansen. Microsoft PowerPoint 2013 DK. ISBN nr.: 978-87-93212-07-7 Peter Kragh Hansen Microsoft PowerPoint 2013 DK ISBN nr.: 978-87-93212-07-7 I n d h o l d s f o r t e g n e l s e PowerPoint 2013... 3 Præsentation... 4 Oprettelsen af præsentationer... 5 Skabeloner og

Læs mere

Best practice for kommunale landingssider for affald

Best practice for kommunale landingssider for affald Best practice for kommunale landingssider for affald København den 1. april 2015 Indholdsfortegnelse 1 Baggrund og formål... 3 1.1 Formål og proces... 3 2 Generelle anbefalinger... 4 2.1 Navigation og

Læs mere

Overordnede principper og best practice

Overordnede principper og best practice Overordnede principper og best practice Version 1.0, april 2009 Fællesoffentlige it-arkitekturkrav Fællesoffentlige it-arkitekturkrav Overordnede principper og best practice Udgivet af: IT- & Telestyrelsen

Læs mere

Sammenhængende Digital Sundhed i Danmark. Direktør Otto Larsen otl@sst.dk www.sdsd.dk september 2007

Sammenhængende Digital Sundhed i Danmark. Direktør Otto Larsen otl@sst.dk www.sdsd.dk september 2007 Sammenhængende Digital Sundhed i Danmark Direktør Otto Larsen otl@sst.dk www.sdsd.dk september 2007 Organisation Dannet i Juni 2006 Aftale mellem regeringen, regionerne, kommunerne Bestyrelse 3:2:1 Budget

Læs mere

Strategisk lederkommunikation

Strategisk lederkommunikation Strategisk lederkommunikation Introduktion til kommunikationsplanlægning Hvorfor skal jeg lave en kommunikationsplan? Med en kommunikationsplan kan du planlægge og styre din kommunikation, så sandsynligheden

Læs mere

Bilag 2.2 Kompetencer, analyser og udbudsplan. Gør tanke til handling VIA University College

Bilag 2.2 Kompetencer, analyser og udbudsplan. Gør tanke til handling VIA University College Bilag 2.2 Kompetencer, analyser og udbudsplan Gør tanke til handling VIA University College Formål I dette notat findes anbefalinger til den samlede kreds af ansvarlige for indkøb på de 7 University Colleges

Læs mere

Guide til integration med NemLog-in / Brugeradministration

Guide til integration med NemLog-in / Brugeradministration Guide til integration med NemLog-in / Brugeradministration Side 1 af 9 21. januar 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør)

Læs mere

Helsinge Vandværk s.m.b.a.

Helsinge Vandværk s.m.b.a. Helsinge Vandværk s.m.b.a. Årsberetning 1. juli 31. december af 12. april 2011 Intern overvågning af indgåelse af aftaler 1 I overensstemmelse med bestemmelserne i Vejledning olm internt overvågningsprogram

Læs mere

Den danske kvalitetsmodel Arbejdsmiljø i Handicap, psykiatri og udsatte

Den danske kvalitetsmodel Arbejdsmiljø i Handicap, psykiatri og udsatte Den danske kvalitetsmodel Arbejdsmiljø i Handicap, psykiatri og udsatte Dansk Kvalitetsmodel Kort om kvalitetsmodellen Dansk kvalitetsmodel på det sociale område udfoldes i et samarbejde mellem Danske

Læs mere

Delprojekt: Branding af den attraktive kommunale arbejdsplads

Delprojekt: Branding af den attraktive kommunale arbejdsplads Delprojekt: Branding af den attraktive kommunale arbejdsplads 1. Baggrund Delprojektet Branding af den attraktive kommunale arbejdsplads udspringer af det oprindelige projekt 11 om attraktive arbejdspladser.

Læs mere

PROJEKTBESKRIVELSE INFORMATIONER FOR AFLEVERING TIL DRIFT

PROJEKTBESKRIVELSE INFORMATIONER FOR AFLEVERING TIL DRIFT PROJEKTBESKRIVELSE cuneco en del af bips INFORMATIONER FOR AFLEVERING TIL DRIFT Dato 20. marts 2014 Projektnr. 13 031 Sign. SSP 1 Indledning Dette projekt vil have fokus på at specificere de informationer,

Læs mere

Høringsskabelon regionernes strategi for it-understøttelse af patient empowerment

Høringsskabelon regionernes strategi for it-understøttelse af patient empowerment Høringsskabelon regionernes strategi for it-understøttelse af patient empowerment Høringssvar bedes sendt til helle.hoestrup@regionh.dk senest d. 20. april 2011. Udfyldt af: Lotte Fonnesbæk og Elisabeth

Læs mere

Kontakthierarkier i Digital Post

Kontakthierarkier i Digital Post Kontakthierarkier i Digital Post Denne vejledning beskriver forskellige måder myndigheder kan opbygge den kontaktbrugergrænseflade der møder slutbrugerne i Digital Post Version: 3. Udarbejdet: juli 2015

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Baggrundsinformation

Baggrundsinformation 1. Begreber Baggrundsinformation Sags- og Dokumentindekset skal indeholde sags- og dokumentmetadata, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres

Læs mere

Det danske ERP marked

Det danske ERP marked Det danske ERP marked ComputerCamp seminar 25. marts 2009 Herbert Nathan Indhold Introduktion til HerbertNathan & Co Nogle indledende system begreber ERP-markedet leverandører og trends Hvorfor anskaffe

Læs mere

Intern kommunikation i Faxe Kommune - et oplæg til dialog Indhold: Kommunikation & Kvalitet, august 2009

Intern kommunikation i Faxe Kommune - et oplæg til dialog Indhold: Kommunikation & Kvalitet, august 2009 Intern kommunikation i Faxe Kommune - et oplæg til dialog Indhold: Udgangspunkt og definition Status og udfordringer Løsning og fremtid Åbne spørgsmål Kommunikation & Kvalitet, august 2009 Del 1: Udgangspunkt

Læs mere

PRINCE2 - et strategisk valg

PRINCE2 - et strategisk valg PRINCE2 - et strategisk valg Per Palmkvist Knudsen, IT-direktør JP/Politikens Hus Per Palmkvist Knudsen fører dig gennem en rejse af faldgruber og succeser med PRINCE2, herunder: - Hvordan organiserer

Læs mere

Bilag 3A.7 Brugergrænseflader

Bilag 3A.7 Brugergrænseflader Bilag 3A.7 Brugergrænseflader Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 3 USER EXPERIENCE GUIDELINES (UX-GUIDELINES)... 5 3.1 GENERELLE UX-GUIDELINES... 5 3.1.1

Læs mere

Kontakthierarkier i. Denne vejledning beskriver forskellige måder, man kan præsentere sin myndighed over for borgere og virksomheder

Kontakthierarkier i. Denne vejledning beskriver forskellige måder, man kan præsentere sin myndighed over for borgere og virksomheder Kontakthierarkier i digital post Denne vejledning beskriver forskellige måder, man kan præsentere sin myndighed over for borgere og virksomheder i digital post. Version: 3.0 Udarbejdet: november 2011 Udarbejdet

Læs mere

Branchemodeller Detaljerede procesmodeller for

Branchemodeller Detaljerede procesmodeller for Branchemodeller Detaljerede procesmodeller for A-kasser Kommunal forvaltning Entreprenører Produktionsvirksomhed Fagforbund Rådgivning Skadesforsikring Webshop HVAD ER EN PROCESMODEL (DEL 1)? Leverandør

Læs mere

SUPPLY CHAIN INNOVATION

SUPPLY CHAIN INNOVATION KONKURRENCEKRAFT GENNEM SUPPLY CHAIN INNOVATION VÆRKTØJER Med afsæt i hovedrapporten har dette arbejdshæfte til formål, at belyse, hvordan danske virksomheder kan arbejde med supply chain innovation, gennem

Læs mere

Fælles kommunal rammearkitektur og konkrete støttesystemer

Fælles kommunal rammearkitektur og konkrete støttesystemer Fælles kommunal rammearkitektur og konkrete støttesystemer KL/Kombit og Kommunerne hvad er Kombit? KOMBIT er kommunernes it-fællesskab, hvis forretningsområde er kommunal it og digitalisering. KOMBIT bestiller

Læs mere

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Version 1.10 Versionshistorik Version Dato Opsummerende beskrivelse af ændringer 1.00 2010-10-5

Læs mere

Vejledningen til proces for design af fremtidsmodellen

Vejledningen til proces for design af fremtidsmodellen Vejledningen til proces for design af fremtidsmodellen Januar 2014 Indhold 1. FORMÅL... 3 FORMÅLET MED DENNE PROCESVEJLEDNING... 3 2. FREMTIDSMODELLENS OMRÅDER... 3 2.1. AKTIVITETER... 4 DEFINER OVERORDNEDE

Læs mere

Partneraftale. Formålet med partnerskabsaftalen vil derfor være at skabe en it-governancemodel der kan:

Partneraftale. Formålet med partnerskabsaftalen vil derfor være at skabe en it-governancemodel der kan: Partneraftale Randers Kommune og KMD har pr. 15.01.07 indgået nærværende partneraftale der, gennem et tæt samarbejde om optimal anvendelse af IT- løsninger, skal bidrage til at effektivisere kommunens

Læs mere

IKT programmer for Facilities Management. Vejledning for førstegangskøbere: Præsentation & debat

IKT programmer for Facilities Management. Vejledning for førstegangskøbere: Præsentation & debat DFM Workshop 05.10.09 09 IKT programmer for Facilities Management Vejledning for førstegangskøbere: Præsentation & debat Vejledning til systemkøberen Hvorfor en vejledning? Opbygning, highlights og vigtige

Læs mere

Vejdirektoratet. forprojekt Digitalt Vejnet. Att. Maria Pallisgaard mlp@vd.dk

Vejdirektoratet. forprojekt Digitalt Vejnet. Att. Maria Pallisgaard mlp@vd.dk 15. december 2011 Vejdirektoratet Forprojekt Digitalt Vejnet Att. Maria Pallisgaard mlp@vd.dk ERHVERVS- OG BYGGESTYRELSEN Sag 09/02655 /mli - mli@ebst.dk NB pr. 20-12-2011 ny adresse: mli@mbbl.dk Erhvervs-

Læs mere

Styregruppeformænd i SKAT Kort & godt (plastkort)

Styregruppeformænd i SKAT Kort & godt (plastkort) Håndbogen for Styregruppeformænd i SKAT Kort & godt (plastkort) 80% af alle projekter, hvor der er uigennemskuelighed fejler Lange projekter er mere risikofyldte end korte Transparente projekter har oftere

Læs mere

REFERAT. Koordineringsgruppemøde. 28. november 2014

REFERAT. Koordineringsgruppemøde. 28. november 2014 DATO KONTAKTPERSON MAIL 28-11-2014 Rasmus Fuglsang Jensen rfj@vd.dk REFERAT EMNE Koordineringsgruppemøde TIDSPUNKT 28. november 2014 STED DELTAGERE Videomøde: Femern A/S, København / Vejdirektoratet, Skanderborg

Læs mere

NOTAT. Brugerportalsinitiativet

NOTAT. Brugerportalsinitiativet NOTAT Brugerportalsinitiativet Den 26. januar 2015 Sags ID: SAG-2014-07107 Dok.ID: 1966628 1. Baggrund Der har i de senere år været stort fokus på og investeret i at bringe folkeskolen ind i den digitale

Læs mere

Denne projekthåndbog har til formål at støtte gennemførelsen af projekter i Kulturministeriet.

Denne projekthåndbog har til formål at støtte gennemførelsen af projekter i Kulturministeriet. PROJEKTHÅNDBOG 12. december 2012 I Kulturministeriet anvendes projektarbejdsformen aktivt. Arbejdsformen styrker de innovative processer og bidrager til at øge medarbejdernes ansvar og arbejdsglæde, hvilket

Læs mere

HVAD er metodelære? HVAD er metode? HVAD er metode? HVORFOR metodelære? Strukturering. Strukturering og måleskalaer.

HVAD er metodelære? HVAD er metode? HVAD er metode? HVORFOR metodelære? Strukturering. Strukturering og måleskalaer. Strukturering Dagens program:! Introduktion til metodelære! Strukturering og måleskalaer HVAD er metodelære? Metodelære er læren om og anvendelsen af (arbejds)metoder, som sætter jer i stand til at arbejde

Læs mere

Application Management Service

Application Management Service Application Management Service I dette Whitepaper vil vi beskrive nogle af vores erfaringer med Application Management. De fleste virksomheder har på et tidspunkt lavet, eller fået lavet, en mindre applikation,

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

Håndbog til projektledelse

Håndbog til projektledelse Mere info kontakt Julie Kirstine Olsen Udviklingskonsulent juols@ikast-brande.dk Tlf.: 9960 4153 Mads Ballegaard Konsulent mabal@ikast-brande.dk Tlf.: 9960 4021 Produceret af Håndbog til projektledelse

Læs mere

Sagsnr. 1-23-4-82-2-14 Spørgsmål og svar Udbud af IT Service Management System. 1. Spørgsmål til UDBUDSBETINGELSER + UDBUDSBILAG 1-4

Sagsnr. 1-23-4-82-2-14 Spørgsmål og svar Udbud af IT Service Management System. 1. Spørgsmål til UDBUDSBETINGELSER + UDBUDSBILAG 1-4 Sagsnr. 1-23-4-82-2-14 Spørgsmål og svar Udbud af IT Service Management System 1. Spørgsmål til UDBUDSBETINGELSER + UDBUDSBILAG 1-4 Nr. Spørgsmål Svar Modtaget Besvaret 1.1 Vi det være tilladeligt at udarbejde

Læs mere

Beslutningsoplæg vedr. etablering af et forretningsstrategisk it- og digitaliseringssamarbejde mellem Silkeborg Kommune og Viborg Kommune

Beslutningsoplæg vedr. etablering af et forretningsstrategisk it- og digitaliseringssamarbejde mellem Silkeborg Kommune og Viborg Kommune 01. april 2015 Beslutningsoplæg vedr. etablering af et forretningsstrategisk it- og digitaliseringssamarbejde mellem Silkeborg Kommune og Viborg Kommune Baggrund I forsommeren 2014 indledte Silkeborg Kommunes

Læs mere

UDKAST v.2. Til interessenter i ehandel (udsendes i bred offentlig høring)

UDKAST v.2. Til interessenter i ehandel (udsendes i bred offentlig høring) Sektorstandardiseringsudvalget for ehandel Til interessenter i ehandel (udsendes i bred offentlig høring) UDKAST v.2. Høring over vision, pejlemærker og forretningskrav til ehandel mellem den offentlige

Læs mere

Principper for organisering af it-området i Koncernservice

Principper for organisering af it-området i Koncernservice Bilag 5 til rapport om Koncernservice Principper for organisering af it-området i Koncernservice Projektet har i sit arbejde diskuteret en række principielle forhold vedr. organiseringen af it-området

Læs mere

Agenda. overblik. trafikområdet. 1) Selvbetjeningsløsninger hvad og hvorfor? 2) Bølge 3 aktiviteter og vejsektoren - overblik

Agenda. overblik. trafikområdet. 1) Selvbetjeningsløsninger hvad og hvorfor? 2) Bølge 3 aktiviteter og vejsektoren - overblik Agenda 1) Selvbetjeningsløsninger hvad og hvorfor? 2) Bølge 3 aktiviteter og vejsektoren - overblik 3) Selvbetjeningsløsninger hvor går de hen? 4) Den fællesoffentlige digitaliseringsstrategi overblik

Læs mere