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

Referencedatamodelprojektet. Overblik over DDV Governance-modellen

Referencedatamodelprojektet. Overblik over DDV Governance-modellen Referencedatamodelprojektet Overblik over DDV Governance-modellen Version 1.0 23. oktober 2012 ISBN: --- Titel: Udgiver: Overblik over DDV Governance-modellen DANVA Vandhuset Godthåbsvej 83 8660 Skanderborg

Læs mere

Referencedatamodelprojektet. DDV arkitekturprincipper. Version oktober 2012

Referencedatamodelprojektet. DDV arkitekturprincipper. Version oktober 2012 Referencedatamodelprojektet DDV arkitekturprincipper Version 1.0 22. oktober 2012 ISBN: --- Titel: Udgiver: DDV principper DANVA Vandhuset Godthåbsvej 83 8660 Skanderborg Udarbejdet af: DDV projektgruppen

Læs mere

Informationsforvaltning i det offentlige

Informationsforvaltning i det offentlige Informationsforvaltning i det offentlige 1 Baggrund Den omfattende digitalisering af den offentlige sektor i Danmark er årsag til, at det offentlige i dag skal håndtere større og større mængder digital

Læs mere

Big data Datawarehouse i forsyningsselskaber

Big data Datawarehouse i forsyningsselskaber Big data Datawarehouse i forsyningsselskaber Det digitale Vandselskab i DANVA(DDV) v. Dorte Skræm, DANVA Hvordan kan vi gøre DDV operationel - kort redegørelse for Referencedatamodelprojektet - hvad kan

Læs mere

Metodehåndbog. Processer. Udarbejdet i fællesskab mellem KL og KOMBIT

Metodehåndbog. Processer. Udarbejdet i fællesskab mellem KL og KOMBIT Metodehåndbog Processer Udarbejdet i fællesskab mellem KL og KOMBIT Indhold Introduktion... 3 Procesmodellering... 3 Qualiware... 4 Notation for Processer... 4 Pool... 5 Lane... 6 Aktivitet... 6 Hændelse...

Læs mere

OIO Enterprise Arkitektur

OIO Enterprise Arkitektur OIO Enterprise Arkitektur FAQ Version 1.0 Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Strategi Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag

Læs mere

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

Arkitekturprincipper for Sundhedsområdet

Arkitekturprincipper for Sundhedsområdet Arkitekturprincipper for Sundhedsområdet - Ved anskaffelse af nye systemer Version 0.91 DIGITAL SUNDHED SAMMENHÆNGENDE DIGITAL SUNDHED I DANMARK Nationale principper ved anskaffelse af it-systemer At indføre

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

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering Den fælleskommunale Rammearkitektur - en arkitektur for den kommunale digitalisering Fundament Vision & Strategi Logik Rammearkitektur Fysik Udvikling/Implementering 2 13.10.2014 Fælles it-arkitekturstyring

Læs mere

UML til kravspecificering

UML til kravspecificering UML til kravspecificering UML mini-kompendium - til brug i forbindelse med modellering af kravspecifikationer. Copyright 2006 Teknologisk Institut, IT-Udvikling Aktivitetsdiagram 2/9 Aktion Aktionsnavn

Læs mere

It-arkitekturprincipper. Version 1.0, april 2009

It-arkitekturprincipper. Version 1.0, april 2009 It-arkitekturprincipper Version 1.0, april 2009 Fælles it-arkitekturprincipper Som offentlig it-chef, projektleder eller professionel, der arbejder med digitalisering, skal du træffe mange valg i en hektisk

Læs mere

System Arkitekt Practitioner

System Arkitekt Practitioner System Arkitekt Practitioner Kompetencebeskrivelsee DISAC Danish IT Society s Architectural Certification DANSK IT 2012 1 IT arkitekt Practitioner System Arkitekt Denne certificering repræsenterer det

Læs mere

CCS Formål Produktblad December 2015

CCS Formål Produktblad December 2015 CCS Formål Produktblad December 2015 Kolofon 2015-12-14

Læs mere

Høringssvar vedr. Serviceinterface for Person

Høringssvar vedr. Serviceinterface for Person Høringssvar vedr. Serviceinterface for Person 1. Indledning... 3 1.1 Arkitekturmæssige overvejelser... 3 2. Konkrete ændringsforslag... 5 2.1 Variable attributnavne... 5 2.2 Registeroplysninger fra akkreditiv...

Læs mere

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

Er standardisering en forudsætning for at systemer kan tale sammen?

Er standardisering en forudsætning for at systemer kan tale sammen? HVORFOR STANDARDER? Er standardisering en forudsætning for at systemer kan tale sammen? Nej, men standardisering reducerer den kompleksitet, der er ved at integrere systemer væsentligt. Så i praksis vil

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

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

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

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

Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS

Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS NOTAT Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS (Bilag til dagsordenspunkt 10, Arkitekturrapport for KITOS) Lars Nico Høgfeldt, Odense Kommune Generel indledning

Læs mere

Når selskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng.

Når selskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng. IT Når selskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng. Fra strategi til resultater i forsyningssektoren 2 Når selskaber har en klar IT-strategi og anskaffer

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

Vejledning om risikovurdering af IT-projekter

Vejledning om risikovurdering af IT-projekter Vejledning om risikovurdering af IT-projekter 1. Indledning Gennemførelsen af IT-projekter er forbundet med risiko. Nogle risici har institutionerne selv indflydelse på. Andre risici er det ikke muligt

Læs mere

Governance - borgervendt selvbetjening

Governance - borgervendt selvbetjening Governance - borgervendt selvbetjening KL netværksmøde, april 2014 /Anna Sofie Almegaard 1 Hvad sker i Københavns Kommune Historien bag Organisering og samarbejde Governance overblik over løsninger, principper,

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

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

1 Begrebsmodel for Ydelsesindeks

1 Begrebsmodel for Ydelsesindeks 1 Begrebsmodel for Ydelsesindeks Ydelsesindeks skal indeholde metadata om tildelte ydelser, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres et tværgående

Læs mere

Metodehåndbog. Forretningsbeslutninger og forretningsregler Beslutningsmodellen. Udarbejdet i fællesskab mellem KL/KOMBIT

Metodehåndbog. Forretningsbeslutninger og forretningsregler Beslutningsmodellen. Udarbejdet i fællesskab mellem KL/KOMBIT Metodehåndbog Forretningsbeslutninger og forretningsregler Beslutningsmodellen Udarbejdet i fællesskab mellem KL/KOMBIT Indholdsfortegnelse Introduktion... 3 Beslutningsmodellering af forretningsregler...

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

REFERENCEARKITEKTUR FOR OPSAMLING AF HELBREDSDATA HOS BORGEREN. Pia Jespersen Thor Schliemann

REFERENCEARKITEKTUR FOR OPSAMLING AF HELBREDSDATA HOS BORGEREN. Pia Jespersen Thor Schliemann REFERENCEARKITEKTUR FOR OPSAMLING AF HELBREDSDATA HOS BORGEREN Pia Jespersen Thor Schliemann OVERSIGT Noget om hvad en Referencearkitektur er Den konkrete Referencearkitektur for opsamling af helbredsdata

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

Vejledning i informationssikkerhedspolitik. Februar 2015

Vejledning i informationssikkerhedspolitik. Februar 2015 Vejledning i informationssikkerhedspolitik Februar 2015 Udgivet februar 2015 Udgivet af Digitaliseringsstyrelsen Publikationen er kun udgivet elektronisk Henvendelse om publikationen kan i øvrigt ske til:

Læs mere

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat. Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012

Læs mere

Bilag 1: Ekstrakt af forretningsarkitekturanalyse af digital understøttelse af tværgående komplekse patientforløb

Bilag 1: Ekstrakt af forretningsarkitekturanalyse af digital understøttelse af tværgående komplekse patientforløb Bilag 1: Ekstrakt af forretningsarkitekturanalyse af digital understøttelse af tværgående komplekse patientforløb (Bilag til dagsordenspunkt 2, Orientering om Arkitekturanalyse på sundhedsområdet af komplekse

Læs mere

Bilag 1 - Kommissorium for Kommunernes It-Arkitekturråd

Bilag 1 - Kommissorium for Kommunernes It-Arkitekturråd Besluttet 18. august 2014 Bilag 1 - Kommissorium for Kommunernes It-Arkitekturråd Baggrund Der investeres massivt i digitalisering af den kommunale sektor. Der er forventning og krav om, at digitaliseringen

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

Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7. Etablering af datadistribution på den Fællesoffentlige Datafordeler

Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7. Etablering af datadistribution på den Fællesoffentlige Datafordeler Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7 Etablering af datadistribution på den Fællesoffentlige Datafordeler Version: 0.8 Status: udkast Oprettet: 10.3.2014 Dato: 16. juni 2014 Dokument historie

Læs mere

ENTERPRISE ARCHITECTURE (EA) STRATEGY, BUSINESS AND IT ALIGNMENT

ENTERPRISE ARCHITECTURE (EA) STRATEGY, BUSINESS AND IT ALIGNMENT (EA) STRATEGY, BUSINESS AND IT ALIGNMENT AGENDA HVAD SKAL VI IGENNEM? FØR FROKOST Hvad er Enterprise Architecture (EA) Baggrunden for EA EA Rammeværk(er), den danske vinkel EFTER FROKOST Gennemgang af

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

Nasjonal arkitektur Danske erfaringer. difi.no/arkitektur Klaus Vilstrup Pedersen

Nasjonal arkitektur Danske erfaringer. difi.no/arkitektur Klaus Vilstrup Pedersen Nasjonal arkitektur Danske erfaringer difi.no/arkitektur 31.08.16 Klaus Vilstrup Pedersen Arkitektur Guide (DK) http//arkitekturguiden.digitaliser.dk/ Rammeværk OIO-EA / EIF-EIRA Tjeklister til brug i

Læs mere

KANAL- OG DIGITALISERINGSSTRATEGI 2011 2015. Januar 2011

KANAL- OG DIGITALISERINGSSTRATEGI 2011 2015. Januar 2011 KANAL- OG DIGITALISERINGSSTRATEGI 2011 2015 Januar 2011 Indhold 1 INDLEDNING 2 STRATEGIGRUNDLAGET 2.1 DET STRATEGISKE GRUNDLAG FOR KANAL- OG DIGITALISERINGSSTRATEGIEN 3 VISION - 2015 4 KANAL- OG DIGITALISERINGSSTRATEGIEN

Læs mere

DANSK PROFILERING AF PHMR AFSÆT I TELEMEDICINSKE PROJEKTER OG REFERENCEARKITEKTURER

DANSK PROFILERING AF PHMR AFSÆT I TELEMEDICINSKE PROJEKTER OG REFERENCEARKITEKTURER DANSK PROFILERING AF PHMR AFSÆT I TELEMEDICINSKE PROJEKTER OG REFERENCEARKITEKTURER MedCom 28. Oktober 2013 Thor Schliemann OM REFERENCEARKITEKTURER (I) Tager udgangspunkt i forretningsmæssige målsætninger

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

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

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

Når forsyningsselskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng.

Når forsyningsselskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng. IT Når forsyningsselskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng. Fra strategi til resultater i forsyningssektoren 2 Når forsyningsselskaber har en klar

Læs mere

OIO står for Offentlig Information Online og er det offentliges fællesbetegnelse for it-arkitektur, it-standarder og digital forvaltning.

OIO står for Offentlig Information Online og er det offentliges fællesbetegnelse for it-arkitektur, it-standarder og digital forvaltning. 1 af 6 30-01-2009 12:42 Vejledning Brugervejledning for OIO-katalog over offentlige it-standarder Version 2.0 - April 2008 INDHOLDSFORTEGNELSE Indledning OIO på nettet Standarder og standardisering Offentlig

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

AAU It Services Selma Lagerlöfs Vej 300 9220 Aalborg Ø. Interessenthåndtering. [Skriv projektets navn] [Skriv dato]

AAU It Services Selma Lagerlöfs Vej 300 9220 Aalborg Ø. Interessenthåndtering. [Skriv projektets navn] [Skriv dato] AAU It Services Selma Lagerlöfs Vej 300 9220 Aalborg Ø Interessenthåndtering [Skriv projektets navn] [Skriv dato] Indhold INTRODUKTION TIL INTERESSENTHÅNDTERING... 2 1 STAMDATA... 4 2 INTERESSENTANALYSE...

Læs mere

DECEMBER Vejledning til kommunens snitfladestrategi

DECEMBER Vejledning til kommunens snitfladestrategi DECEMBER 2016 Vejledning til kommunens snitfladestrategi Dette notat introducerer arbejdet med kommunens snitfladestrategi. Snitfladestrategien beskriver kommunens strategiske beslutninger vedr. snitflader

Læs mere

ADK 1.0 KRAVSPECIFIKATION

ADK 1.0 KRAVSPECIFIKATION ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 23-06-2014 MST Oprettelse af integrationskrav 0.2 25-06-2014 HAH Review for forståelighed og stringens.

Læs mere

Høringsnotat - specifikation af serviceinterface for SAG version 1 2

Høringsnotat - specifikation af serviceinterface for SAG version 1 2 N OTAT Høringsnotat - specifikation af serviceinterface for SAG version 1 2 Specifikation af serviceinterface for SAG Version 1.2 (Sag-standard) Den fællesoffentlige styregruppe for Sag og Dokument sendte

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

Sammenfatning opmålingsprojekter

Sammenfatning opmålingsprojekter 22. januar 2014 Sammenfatning opmålingsprojekter cuneco projektnummer: 14 021 Standardiserede og digitaliserede tilbudslister 14 031 Specifikation af data til tilbudsgivning 14 041 Måleregler [FORELØBIG

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

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

Høringssvar vedrørende Specifikation af serviceinterface for person (part)

Høringssvar vedrørende Specifikation af serviceinterface for person (part) IT- og Telestyrelsen Holsteinsgade 63 2100 København Ø Høringssvar vedrørende Specifikation af serviceinterface for person (part) Dette er KLs høringssvar på den offentlige høring om specifikation af serviceinterface

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

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

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø EG Data Inform Byggebasen WCF og webservices Jens Karsø 10 Indholdsfortegnelse Byggebasen Services indledning... 2 Målsætning... 2 Valg af teknologier... 3 Kommunikationsmodel for byggebasen... 3 Services.byggebasen.dk...

Læs mere

Metodehåndbog. Begrebsmodeller, Informationsmodeller og Begrebsdefinitioner. Udarbejdet i fællesskab mellem Udbetaling Danmark/KL/KOMBIT

Metodehåndbog. Begrebsmodeller, Informationsmodeller og Begrebsdefinitioner. Udarbejdet i fællesskab mellem Udbetaling Danmark/KL/KOMBIT Metodehåndbog Begrebsmodeller, Informationsmodeller og Begrebsdefinitioner Udarbejdet i fællesskab mellem Udbetaling Danmark/KL/KOMBIT Indhold Introduktion... 2 Begrebsmodeller, informationsmodeller og

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

Arkitekturrapport:

Arkitekturrapport: <PROJEKTNAVN> Arkitekturrapport: Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af projektets it-arkitekt. Det er projektlederens

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

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

KL ønsker at anmode om tilbud på konsulentbistand til projekt om standardisering af opsætning og behandling af digitale underretninger i kommunerne.

KL ønsker at anmode om tilbud på konsulentbistand til projekt om standardisering af opsætning og behandling af digitale underretninger i kommunerne. Annoncering af opgave vedr. konsulentb i- stand til standardiseret opsætning og b e- handling af digitale underretninger (adviser) i kommunerne. KL ønsker at anmode om tilbud på konsulentbistand til projekt

Læs mere

Tættere offentligt, digitalt samarbejde

Tættere offentligt, digitalt samarbejde Agenda Den fælles offentlige digitaliserings strategi Grunddataprogrammet Standardisering af vej- og trafikdata Ny model for vejreference Stigruppens arbejde Resultat i relation til vejman.dk Tættere

Læs mere

Formål. Brug. Fremgangsmåde

Formål. Brug. Fremgangsmåde Værktøj 5.1 Milepælsplanen Formål Ved at udarbejde en milepælsplan for projektet, deles projektet op i mindre og mere håndterbare bidder. Formålet er bl.a. at sikre, at de mellem- og slutresultater, som

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

PROJEKTBESKRIVELSE DIGITALE TILBUDSLISTER

PROJEKTBESKRIVELSE DIGITALE TILBUDSLISTER PROJEKTBESKRIVELSE DIGITALE TILBUDSLISTER cuneco en del af bips Dato 20. marts 2012 Projektnr. 14 021 Sign. SSP 1 Indledning cuneco gennemfører et projekt, der skal udvikle en standardiseret struktur og

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

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

Overordnet set vurderer Odense Kommune, at både det foreliggende udkast og det bagvedliggende arbejde er af høj kvalitet.

Overordnet set vurderer Odense Kommune, at både det foreliggende udkast og det bagvedliggende arbejde er af høj kvalitet. Høringssvar på Specifikation af Serviceinterface for Sag standard for Specifikation af Serviceinterface for Sag og har flg. bemærkninger. og det bagvedliggende arbejde er af høj kvalitet. MFD, MIB Der

Læs mere

VIDEN FOR VERDEN VORES ORGANISATION / INDSATS 12.1 STRATEGI FOR DET ADMINISTRATIVE OMRÅDE

VIDEN FOR VERDEN VORES ORGANISATION / INDSATS 12.1 STRATEGI FOR DET ADMINISTRATIVE OMRÅDE VIDEN FOR VERDEN VORES ORGANISATION / INDSATS 12.1 STRATEGI FOR DET ADMINISTRATIVE OMRÅDE Marts 2016 FORORD Formålet med strategien for de administrative områder på AAU er at opfylde den overordnede ambition

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

OIO-datastandardisering i sektorerne

OIO-datastandardisering i sektorerne Begrebsafklaring i sektoren -datastandardisering i sektorerne Begrebsafklaring i sektoren -datastandardisering i sektorerne Udgivet af: IT- og Telestyrelsen IT- og Telestyrelsen Holsteinsgade 63 2100 København

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

FORTROLIGT. Leveranceplan for initiativ 8.1: Gode data og effektiv datadeling

FORTROLIGT. Leveranceplan for initiativ 8.1: Gode data og effektiv datadeling Side 1 BILAG 1 UDKAST 12.08.2016 Leveranceplan for initiativ 8.1: Gode data og effektiv datadeling Baggrund Initiativ 8.1 om gode data og effektiv datadeling er en del af den fællesoffentlige digitaliseringsstrategi

Læs mere

Bilag 2: Kravspecifikation - Side 1

Bilag 2: Kravspecifikation - Side 1 Bilag 2: Kravspecifikation - Side 1 Use-Cases Syddjurs Kommune betragter den tværgående sundhedsplatform som en del af en større infrastruktur, hvor data flyder mellem forskellige elementer. Dette dokument

Læs mere

Kommissorium for Kommunernes it-arkitekturråd

Kommissorium for Kommunernes it-arkitekturråd Godkendt 3. oktober 2011 Kommissorium for Kommunernes it-arkitekturråd Baggrund En helt ny æra for it-understøttelsen af den kommunale sektor er indledt med salget af KMD og i forbindelse med den netop

Læs mere

Det er en fin og gennemført opdeling i bogen med de samme spørgsmål der behandles: Hvorfor forebygge? Opsporing og Motivation Indsatser

Det er en fin og gennemført opdeling i bogen med de samme spørgsmål der behandles: Hvorfor forebygge? Opsporing og Motivation Indsatser 4. december 2014 11/030104 LPED Høringsskema Håndbog om forebyggelse på ældreområdet Når du kommenterer på håndbogen vil vi bede dig være særligt opmærksom på følgende spørgsmål i relation til det fagområde

Læs mere

Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering for 1. kvartal 2007

Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering for 1. kvartal 2007 Skatteudvalget SAU alm. del - Bilag 156 Offentligt Notat Skatteministeren Hovedcentret Strategi og Udvikling Projektkontoret Dato 25. maj J. nr. 07-061430 Kvartalsrapport vedr. fase 1 af SKATs systemmodernisering

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

SRO Standardisering I forsyningsvirksomheder Nyt SRO System ikke kun en teknologisk fornyelse

SRO Standardisering I forsyningsvirksomheder Nyt SRO System ikke kun en teknologisk fornyelse Nyt SRO System ikke kun en teknologisk fornyelse V. Finn Asmussen, Københavns Energi Agenda Københavns Energi eller HOFOR Hvorfor standardisering er så vigtig Niveau for SRO standardisering Hvad er standardiseret

Læs mere

Au Aarhus Universitet. Aarhus Universitet Studieordningsgenerator PID Version 1.0

Au Aarhus Universitet. Aarhus Universitet Studieordningsgenerator PID Version 1.0 Aarhus Universitet Studieordningsgenerator PID Version 1.0 Version Dato Version Udarbejdet af Godkendt af Beskrivelse 19-5-2010 0.1 JS Første udkast 25-5-2010 0.2 JS 24-6-2010 1.0 JS SS Side 2 af 9 Indholdsfortegnelse

Læs mere

Arkitekturprincipper for Sundhedsområdet -en ramme for udformning af fremtidens nationale it-arkitektur for sundhedsvæsenet

Arkitekturprincipper for Sundhedsområdet -en ramme for udformning af fremtidens nationale it-arkitektur for sundhedsvæsenet Arkitekturprincipper for Sundhedsområdet -en ramme for udformning af fremtidens nationale it-arkitektur for sundhedsvæsenet SDSDs Arkitekturenhed/L. Stefan Jensen 21-06-2009 Nærværende arkitekturprincipper

Læs mere

Ejendomsdataprogrammet - Matriklen Løsningsarkitektur - Bilag C Processer

Ejendomsdataprogrammet - Matriklen Løsningsarkitektur - Bilag C Processer Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - Matriklen 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

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

PARATHEDSMÅLING. Bedre brug af hjælpemidler

PARATHEDSMÅLING. Bedre brug af hjælpemidler PARATHEDSMÅLING Bedre brug af hjælpemidler Indhold Introduktion til anvendelse af dokumentet 3 Resume af parathedsmålingen 4 Fælles og konkrete mål med implementeringen 6 Organisering og ledelse 9 Medarbejdere

Læs mere

Grunddataprogrammet. Side 1 af 11. Aftale om styringsrammer for grunddatamodellen

Grunddataprogrammet. Side 1 af 11. Aftale om styringsrammer for grunddatamodellen Grunddataprogrammet Side 1 af 11 Aftale om styringsrammer for grunddatamodellen Side 1 af 11 11. oktober 2013 SAR Aftale om styringsrammer for grunddatamodellen Formål Formålet med aftalen er at sikre

Læs mere

Introduktion til Digital Post. Februar 2016

Introduktion til Digital Post. Februar 2016 Introduktion til Digital Post Februar 2016 Hvem skal læse dokumentet? Vejledningen er relevant for dig, hvis du har brug for en introduktion til Administrationsportalen i Digital Post og hvad der skal

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

Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer

Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog, der vejleder kommunerne i det

Læs mere

OIO Enterprise Arkitektur

OIO Enterprise Arkitektur OIO Enterprise Arkitektur OIO relateret til andre metoder og rammeværk Version 1.0 Tekniske og forretningsmæssige X1. Forretningsmæssige X2. Tekniske Strategi Forretning Teknik A1. relaterede udfordringer

Læs mere