Den fælleskommunale Rammearkitektur

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Starte visningen fra side:

Download "Den fælleskommunale Rammearkitektur"

Transkript

1 Høringsversion, Publiceret 4. november 2013 Bilag 2: Introduktion til den fælleskommunale rammearkitektur. Bilag til dagsordenspunkt 7: Arkitekturfaglig introduktion til rammearkitekturen. Introduktion til Den fælleskommunale Rammearkitektur - en arkitektur for den kommunale digitalisering HØRINGSVERSION

2 Indholdsfortegnelse En kommunal it-anskaffelse i nær fremtid Indledning Baggrund og mandat Dokumentation af Rammearkitekturen Læsevejledning Rammearkitekturens fundament Governance Arkitekturmål Arkitekturprincipper Den Fælleskommunale Rammearkitektur Formål Anvendelseseksempel Rammearkitekturens infrastruktur Rammearkitekturens kravmateriale Hvordan påvirker det digitaliseringsprojekterne? Fordele ved Rammearkitekturen Kommunale fordele Fordele for beslutningstagere Fordele for leverandører Paradigmeskift ift. kommunal it-arkitektur Den nuværende arkitektur Transformationen Den kommunale forretning beskrives i form af byggeblokke Brugerflader tilpasses arbejdsprocessen på tværs af byggeblokke Kommunikation mellem it-løsninger/aktører via hændelsesbeskeder Datakilden har ansvaret for at bevare historik Styr på kaos Nuværende it-landskab med mange dialekter Rammearkitektur med fælles definitioner Rammearkitekturens strukturering Overblik Den logiske og den fysiske Rammearkitektur Den logiske Rammearkitektur Opdeling af den kommunale forretning i byggeblokke Hvordan finder vi byggeblokkene? Byggeblokkene relaterer sig til hinanden Integrationer i Rammearkitekturen...21 Side 2/29

3 7.5 Procesmønstre i Rammearkitekturen Byggeblok konceptet Opbygningen af en byggeblok Byggeblokke i en fagkontekst Fælles byggeblokke Domæne- og fagspecifikke byggeblokke Fysisk implementering af Rammearkitekturen De fysiske systemer spejler sig i byggeblokkene Flere leverandører flere platforme En forretningsbyggeblok flere leverandører Et system - flere byggeblokke Implementeringsstrategi...28 Side 3/29

4 En kommunal it-anskaffelse i nær fremtid I Blåbjerg Kommune er igangsat opførelsen af en Multihal, som dels skal kunne anvendes af kommunens borgere og foreninger til sportsaktiviteter m.v., dels skal indeholder andre af kommunens kulturelle aktiviteter såsom musikskole, billedskole og musikalske øvelokaler. Lene har som kommunens projektleder fået til opgave at etablere it-understøttelse hertil i form af en digital selvbetjeningsløsning til brug for bookning af sportsfaciliteter, lokaler m.v. samt en administrationsdel til at understøtte de forskellige administrative rutiner. Lene er glad for denne opgave, for det er blevet meget nemmere og mere overskueligt end det var i gamle dage. Lene går ind på og får her hjælp til store dele af opgaven. Der er metodevejledninger til selve udbudsprocessen, en oversigt over hvad der findes af specificerede moduler i Rammearkitekturen, overblik over hvilke af disse kommunen har anskaffet en implementering af (lokalt eller som en fælleskommunal anskaffelse), dokumentation af de regler it-løsningen skal leve op til (eksempelvis lovkrav ift. musikskoler) samt andet kravmateriale til direkte anvendelse i udbuddet. Lene finder her en kommunal implementering af en række af de moduler (personer, kommunens foreninger, fakturering, kortbetalinger mv.), som løsningen skal bygges på. Der er også en specifikation af er bookningsmodul, men hverken kommunen eller andre kommuner har p.t. anskaffet en fysisk implementering af denne. Lene kan derfor koncentrere indsatsen omkring de mere specifikke krav til løsningen - herunder lokale regler som f.eks. at det kun er godkendte foreninger, som kan booke lokaler mv. Specifikation af krav til Booking samt resten af kravmaterialet henter Lene fra Rammearkitekturen hhv. henviser hertil. Herved får Lene et tydeligt kravmateriale, hvori det fremgår, hvad der er generelle krav styret af Rammearkitekturens krav og infrastruktur, hhv. hvad der er specifikt for det konkrete udbud. Firmaet Inova er blevet indbudt til at byde på opgaven. Dette er en hel del nemmere end det var i gamle dage. Inova har tidligere leveret løsninger både til Blåbjerg Kommune og andre kommuner, så de kan genkende en hel del af kravmaterialet, og er fortrolige med dette. Inova kan af udbudsmaterialet se, hvad der skal udvikles it-understøttelse til, og hvad der allerede findes i Rammearkitekturen og skal genbruges derfra. Af materialet fremgår det, at der gennem Serviceplatformen er adgang til de øvrige moduler og den deri implementerede funktionalitet og data. I gamle dage var data ofte leverandørejede og svært tilgængelige, men nu er det relativt nemmere for nye leverandører at komme ind på markedet med en god konkurrencemæssig pris, fordi infrastrukturen er åben og ikke ejes af en enkelt leverandør. Inova kan derfor koncentrere sig om at levere et attraktivt tilbud med en god løsning i forhold til den nye it-understøttelse, fordi de kun skal levere den funktionalitet, som kommunen ikke allerede har implementeret andet sted eller som kan trækkes fælleskommunalt. Der er defineret nogle klare snitflader og den lovgivning og de regler, som løsningen skal efterleve, fremgår eksplicit af materialet. Inova har indgivet det mest attraktive tilbud, og får tildelt opgaven ift. den nye Multihal. Projektets arkitekt, Jens går ind på og downloader herfra det nødvendige materiale til brug for det endelige løsningsdesign bl.a. henter Jens herfra konkrete XML-snitflader til de forskellige moduler, som løsningen skal anvende. Specifikation og dokumentationskrav til Booking og en række ikke-funktionelle krav som f.eks. sikkerhed hentes ligeledes fra Rammearkitekturen. Jens og hans kollegaer kan herefter koncentrere sig om designet af selve løsningen herunder en velfungerende selvbetjeningsløsning. I forbindelse med udvikling og test af løsningen benytter projektgruppen sig af Serviceplatformen, hvor services til modulerne er implementeret i test- og produktionsmiljøer m.v. Der er her en god og sammenhængende infrastruktur, som medvirker til en hurtigere og mere effektiv og sikker integration, end tilfældet var i gamle dage, hvor der ofte skulle bruges megen tid på udvikling og test af de forskellige snitflader. Side 4/29

5 Opdelingen i overskuelige moduler og stort genbrug af eksisterende moduler medfører, at projektet bliver mere overskueligt styringsmæssigt, hvorfor Inova er i stand til at levere den ønskede løsningen til den aftalte deadline i god tid før Multihallens åbning. 1. Indledning Kommunerne er i fuld gang med at opbygge de nødvendige værktøjer og kompetencer til en aktiv, tværgående arkitekturstyring. Kommunernes fremadrettede digitale landskab skal udvikles, så det godt og effektivt understøtter de kommunale kerneopgaverne, og så tempoet i digitaliseringen bliver væsentligt højere, end det er i dag. Kommunerne vil have sammenhængende, forandringsrobust og effektivt it udviklet på et konkurrencepræget og innovativt flerleverandørmarked. 1.1 Baggrund og mandat Digitaliseringen af den kommunale sektor intensiveres og breder sig til stadig flere opgaveområder. Digitalisering skal transformere den kommunale opgavevaretagelse og være med til at sikre, at vi leverer stadig bedre service for færre ressourcer. Samtidigt har rammerne for kommunernes digitalisering ændret sig efter salget af KMD i Traditionelt har KMD leveret langt størsteparten af kommunernes it og har fortsat en monopolrolle på det kommunale it-marked. Med Den Fælleskommunale Digitaliseringsstrategi besluttede KL s bestyrelse en række indsatser for at etablere Et konkurrencepræget kommunalt it-marked, hvor kommunerne kan købe attraktive it-systemer til fornuftige priser. Strategien fastsatte 5 overordnede målsætninger for den kommunale arkitektur. Den Fælleskommunale Rammearkitektur, som der gives en introduktion til i dette dokument, er en af de helt afgørende indsatser til understøttelse af strategien og realisering af de 5 arkitekturmål. 1.2 Dokumentation af Rammearkitekturen Introduktionsdokumentet her indgår i den samlede dokumentationen af Den Fælleskommunale Rammearkitektur som illustreret i nedenstående figur: Der er omkring Rammearkitekturen et fundament i form af to rammesættende dokumenter: Den Fælleskommunale Digitaliseringsstrategi Besluttet af KL s bestyrelse Side 5/29

6 Fælleskommunale arkitekturprincipper, som udspringer af digitaliseringsstrategien. Godkendt af Kommunernes it-arkitekturråd Derudover understøttes Rammearkitekturen af følgende: Implementering af Rammearkitekturen. Dokumentet er under udarbejdelse og indeholder strategi og vejledninger i forhold til implementering af Rammearkitekturen og de dertil hørende byggeblokke. Byggeblokkonceptet. Indeholder en detaljeret beskrivelse af byggeblokkonceptet inkl. eksempler på hvorledes disse skal dokumenteres. Dokumentet er under review, mens etablering af et bibliotek til specifikation af de vedtagne byggeblokke udestår. Forretningskrav. Indeholder konkrete fælleskommunale krav til brug i kravmateriale. Omfatter både krav i forhold til anvendelse og implementering af byggeblokke, og krav i forhold til en række øvrige primært ikke-funktionelle krav f.eks. sikkerhed og serviceprincipper. Forretningskrav vil løbende blive udarbejdet og udstillet via Forretningsregler. Opbygges til at indeholde de forskellige lovkrav og andre regler, som de enkelte byggeblokke m.v. skal efterleve. Også forretningsregler vil løbende blive udarbejdet og udstillet via Procesmønstre og arbejdsgange. Dokumentet er under løbede udarbejdelse og vil komme til at indeholde en række generiske procesmønstre, f.eks. i relation til Sag & Dokument, til brug for udvikling og anvendelse af de fælles byggeblokke m.v. Derudover vil der også være dokumentation af de konkrete arbejdsgange. Herunder også Arbejdsgangsbanken. Metodehåndbog. Er under udarbejdelse og indeholder metodevejledning til de forskellige fælleskommunale arkitekturaktiviteter, f.eks. gennemførelse af en udbudsproces, implementering af sikkerhed samt dokumentation og test af en byggeblok implementering. Generelt vil alt materiale være tilgængelig via og de dertil knyttede biblioteker. Det vil være her, hvor man i forhold til hver enkelt byggeblok kan se, hvilke der er specificeret og godkendt, hvilke der findes en eller flere implementeringer af samt hvilke den enkelte kommune har implementeret lokalt eller som en del af en fælleskommunal anskaffelse. 1.3 Læsevejledning Udover dette indledende kapitel består introduktionen til Rammearkitekturen af 8 kapitler. Beslutningstagere, projektledere og andre som har ansvaret for it-anskaffelser i kommunen bør alle læse kapitel 2, 3 og 4. Heri gives en introduktion til Rammearkitekturens fundament i form af arkitekturmål og arkitekturprincipper, en kort introduktion til Rammearkitekturen og dens bestanddele, samt en oversigt over de væsentligste fordele Rammearkitekturen giver både på den kommunale side og hos leverandørerne. Endvidere er der en introduktion til nogle væsentlige paradigmeskift, som Rammearkitekturen vil betyde i forhold til den enkelte kommunes it-understøttelse. Den resterende del kapitel 5 til 9 - er skrevet med kommunernes forretnings- og it-arkitekter som målgruppe. I disse kapitler er fokus på Rammearkitekturens strukturering og indhold Side 6/29

7 herunder opdelingen i en logisk og fysisk del. Byggeblok konceptet gennemgås i hovedtræk med opdeling i fælles byggeblokke, domænespecifikke byggeblokke samt byggeblokke inden for det enkelte fagområde. Endvidere beskrives krav til struktur og indhold i en byggeblok. Endelig er der en introduktion til det fysiske design i forbindelse med implementering af Rammearkitekturens byggeblokke. Side 7/29

8 2. Rammearkitekturens fundament 2.1 Governance Den fælleskommunale arkitekturstyring og Rammearkitektur er forankret i Kommunernes It- Arkitekturråd, der er et rådgivende organ, som sammen med ledelserne i KL og KOMBIT har et hovedansvar for at udvikle og udbrede Rammearkitekturen. Arkitekturrådet har en afgørende rolle i at sikre, at arkitekturstyringen er drevet af de helt centrale forretningsmæssige behov i kommunerne, og at Rammearkitekturen er operationel og kan anvendes bredt., Arbejdet med Den Fælleskommunale Rammearkitektur er rammesat af to nøgledokumenter: Den Fælleskommunale Digitaliseringsstrategi. Heri er der bl.a. defineret fem arkitekturmål, som alle udspringer af de overordnede målsætninger i de fælleskommunale og fællesoffentlige digitale strategier. Fælleskommunale arkitekturprincipper. Med udgangspunkt i de fem arkitekturmål er der fælleskommunalt udarbjdet et sæt arkitekturprincipper, som er vigtige for at nå de fem arkitekturmål. Principperne er godkendt af Kommunernes It-Arkitekturråd. 2.2 Arkitekturmål Der er i Den Fælleskommunale Digitaliseringsstrategi opstillet fem arkitekturmål, som it-arkitekturstyringen og Rammearkitekturen skal realisere for kommunerne: 1. Sammenhængende it. Kommunens borgere (og medarbejdere) mødes ikke med behovet for genindtastning af data, som allerede er kendte af andre systemer. Systemerne har en datasammenhæng og en dataudvekslingsarkitektur, som skaber sammenhæng mellem it-løsningerne. 2. Genbrug. En kommune skal ikke betale fuld pris for den samme funktionalitet to gange, da det skal være let for it-løsninger at benytte og genbruge funktioner eller data i andre (kommuners) it-løsninger. En større del af den fremtidige kommunale systemportefølje modulopbygges af fælleskomponenter. Samtidig skal der sikres en incitamentsstruktur, der gør det attraktivt for leverandørerne at udvikle genbrugelig funktionalitet. 3. Byg til forandring. Kommunens it-løsninger skal være lette at tilpasse, når der f.eks. kommer ny lovgivning, der ændrer processen eller når kommunerne vil forandre opgaveløsningen, så it-omkostningerne ikke bliver en bremse på forandring. 4. Flere leverandører. Når kommunen baserer sine løsninger på åbne standarder og udskiftelige komponenter, kan de skifte leverandører uden tekniske barrierer. 5. Driftsstabilitet. Kommunens it-løsninger skal være driftsstabile, pålidelige, attraktive og sikre, så borgere og medarbejdere kan have tillid til og vil tilslutte sig den digitale opgaveløsning. 2.3 Arkitekturprincipper Med udgangspunkt i de fem arkitekturmål er der fælleskommunalt vedtaget et sæt arkitekturprincipper, som er vigtige for at nå de fem arkitekturmål. Principperne er defineret i Side 8/29

9 relation til OIO-EA områderne strategi, forretning og teknik og består af nedenstående 17 principper: Strategi: A1 Der arbejdes mod en fælles Rammearkitektur. A2 A3 Arkitekturen skal sikre mod leverandør- lock-in. It-sikkerhed tænkes ind i løsninger fra starten. Forretning: B1 Forretningsservices genbruges på tværs af it-løsninger. B2 B3 B4 B5 B6 B7 B8 B9 Arbejdsgange er dokumenterede på tværs af forretnings-domæner. Brugere inddrages aktivt i behovsafklaring og udviklingsforløb. It-løsninger udfordrer og effektiviserer eksisterende arbejdsgange og regler. Der anvendes altid et standardiseret begrebsapparat. Der er defineret entydigt ejerskab af data og processer. Enhver betydelig forretningshændelse meddeles omverden. Fælles autoritative reference- og grunddata anvendes. Adskil der foranderlige fra det uforanderlige. Teknik: C1 Data udstilles via åbne snitflader og kan genbruges. C2 C3 C4 C5 Alle objekter er uafhængige af systemet, hvor de er skabt. Data identificeres entydigt. It-løsninger er skalerbare efter formål. It-løsninger er robuste overfor egne og andre systemers nedbrud. Se detaljeret beskrivelse af arkitektur-principperne på Side 9/29

10 3. Den Fælleskommunale Rammearkitektur 3.1 Formål Rammearkitekturen er den fælleskommunale vej til sammenhængende, fremtidssikret og effektiv it-understøttelse udviklet på et flerleverandørmarked. Dermed er Rammearkitekturen et vigtigt og afgørende element i forhold til det igangværende monopolbrud. Målet er, at kommunerne selv bliver herrer over, hvornår de forskellige itsystemer skal udskiftes/anskaffes, og hvem kommunerne får til at gøre dette. Rammearkitekturen skal her være med til at sikre, at kommunernes it-landskab bygges med en åbenhed, der gør, at kommunerne reelt bliver i stand til at kunne vælge den bedste og billigste leverandør. 3.2 Anvendelseseksempel Når en kommune skal i gang med et byggeprojekt eksempelvis en skole er der en række forhold, der skal være på plads inden byggeriet kan påbegyndes. Er dette ikke på plads kommer skolebyggeriet ikke til at fungere. For det første skal kommunens krav til skolebyggeriet fremgå tydeligt at udbudsmaterialet, f.eks. størrelse på klasseværelser, krav til lydisolering og sikkerhed, krav til materialer samt krav til adgangsforhold. Herunder også krav til skolen, fastsat gennem lovgivning eller gennem lokale forhold, f.eks. gennem en lokalplan. For det andet skal der være infrastruktur ind til den grund, hvor skolen skal bygges, f.eks. vand, varme, strøm og kloakering. Sådan er det også når kommunen skal indkøbe et nyt it-system, f.eks. et nyt it-system til brug for skolens administration og planlægning, kommunikation med elever og forældre, kommunikation med andre offentlige myndigheder etc. Her skal kommunen også sørge for, at kravmateriale og infrastruktur er på plads, inden udbud kan gå i gang. Og her vil kommunen kunne hente hjælp i Den Fælleskommunale Rammearkitektur. Ligesom en samlet byplan understøtter byggeriet af en skole, giver Rammearkitekturen kommunen beskrivelse af de krav, der er fælles for alle kommuner, og den giver kommunen en fælles infrastruktur, som alle kommunens it-systemer kan trække på. I forhold til infrastrukturen skal skolesystemet bruge adgang til en række fælles moduler, f.eks. Person, Adresser, Institutioner og Sager. Disse fremfindes og udpeges gennem Rammearkitekturen. Derudover er der de fælles krav, som it-systemet skal leve op til i forhold til sikkerhed, regler, sammenhæng til andre it-systemer mv. Herunder krav om modtagelse og kommunikation af hændelser, f.eks. når en elev forlader skolen uden for de normale tidspunkter eller når en elev flytter til kommunen/skoledistriktet. Disse krav ligger også i Rammearkitekturen, som nogle kravformuleringer, som kommunen selv kan lægge ind i det relevante udbudsmateriale. Side 10/29

11 3.3 Rammearkitekturens infrastruktur Rammearkitekturen struktureres i moduler (kaldet byggeblokke 1 ) med mulighed for, at forskellige leverandører kan udvikle og levere drift af disse. Byggeblokkene defineres og implementeres med åbne snitflader, der sikrer sammenhæng på tværs af disse. Der stilles gennem Rammearkitekturen en række generelle krav til byggeblokkene og disses egenskaber. Dette sikrer sammen med andre fælles krav en sammenhængende infrastruktur i kommunen - på trods af at de enkelte byggeblokke leveres af forskellige leverandører og driftes på forskellige platforme. Ligeledes kan en byggeblok leveres af en leverandør i den ene kommune og af en anden i en anden kommune. 3.4 Rammearkitekturens kravmateriale Som et led i Rammearkitekturen stilles der strenge krav til leverandører om, at de forskellige itsystemer skal være åbne og kunne tale samen med de andre systemer. Dette fordrer nogle tværgående krav, som skal stilles til alle de forskellige it-løsninger. Til brug for udbud af it-løsninger findes der i Rammearkitekturen formuleret en række præcise krav, som kommunen kan og skal benytte sig af i forbindelse med anskaffelser af it-løsninger. 3.5 Hvordan påvirker det digitaliseringsprojekterne? Der stilles krav til de enkelte digitaliseringsprojekter om, at de skal vurdere deres anvendelse af Rammearkitekturen (følg eller forklar dokumenteret i en Arkitekturrapport ) - herunder vurdere deres bidrag til en evt. udbygning af Rammearkitekturen i form af nye byggeblokke, dokumentation af forretningsregler mv. Disse overvejelser dokumenteres i en arkitekturrapport, som stilles til rådighed for Kommunernes it-arkitekturråd. Rammearkitekturen understøtter dette arbejde gennem en række vejledninger og skabeloner samt ved at stille anden relevant information til rådighed for projekterne, herunder: Et færdigt kravmateriale som forventes at dække mindst 60 % af det samlede kravmateriale. Dvs. krav i relation til brug af infrastruktur, anvendelse af standarder, kendte forretningsregler, en række ikke-funktionelle krav mv. I Rammearkitekturen kan projektet få et overblik over, hvilke byggeblokke der findes, samt over hvilke leverandører der har en implementering af disse. Rammearkitekturen giver her også et overblik over hvilke byggeblokke, der findes en implementering af i den enkelte kommune. En række metodeanvisninger til udfyldelse af det resterende kravmateriale, gennemførelse af udbudsprocessen, arkitekturprincipper til måling af de enkelte tilbud op mod hinanden mv. Et fælles arkitektursprog med semantisk definition af begreber og anden fælles information. Har projektet behov for at skulle specificere nye byggeblokke eller behov for at få dokumenteret forretningsregler, som ikke allerede findes i Rammearkitekturen, er der også hjælp at hente hertil i form af skabeloner, beskrivelse af governance processer mv. 1 Termen Byggeblok anvendes i forhold til inddeling af den kommunale forretning i moduler. Byggeblokken beskriver dele af forretningen omkring et centralt forretningsobjekt med de dertil hørende forretningsregler, processer, informationer mv. Konceptet er beskrevet nærmere i kapitel 8. Side 11/29

12 3.6 Fordele ved Rammearkitekturen Rammearkitekturen er en genvej, når man formulerer krav til og anskaffer it-løsninger. Den kommunale forretning er omfattende og kompleks. Vi bruger Rammearkitekturen til at overskue funktionalitet og reducere kompleksiteten. Vi skaber et tværgående overblik over sammenhængende i de kommunale opgaver som et grundlag for en sammenhængende og effektiv digitalisering. Det gavner både kommunen og it-leverandører. 3.7 Kommunale fordele Rammearkitekturen er et middel til opfyldelse af de fælleskommunale arkitekturmål: 1. Sammenhængende it. Kommunens borgere og medarbejdere mødes ikke med behovet for genindtastning af data, som allerede er kendte af andre systemer, fordi Rammearkitekturen sikrer grundlaget for, at it-systemerne har en datasammenhæng og en dataudvekslingsarkitektur, som skaber sammenhæng mellem de forskellige itløsninger. Kommunens medarbejdere kan gennem Rammearkitekturens infrastruktur etablere et godt og tværgående overblik over f.eks. en borger eller en sag, fordi der er sikret tværgående adgang til de byggeblokke, som er relevante for den pågældende opgave. 2. Genbrug. Kommunen skal ikke betale fuld pris for den samme funktionalitet to gange, fordi rammearkitekturens infrastruktur gør det let for it-løsninger at benytte og genbruge funktioner eller data i andre it-løsninger. Rammearkitekturen understøtter genbrug, hvilket bl.a. betyder færre indtastninger og at data vil være behæftet med færre fejl. Rammearkitekturen gør det lettere for kommunen at anskaffe nye it-systemer. Kommunen kan genbruge kravmateriale og hente de vigtige infrastrukturforbindelser fra rammearkitekturen. 3. Byg til forandring. Kommunens it-løsninger bliver pga. Rammearkitekturens infrastruktur, tydeliggørelse af regler og lovgivning, byggeblokke implementeret i løst koblede moduler m.v. lettere at tilpasse, når der f.eks. kommer ny lovgivning, der ændrer processen, eller når kommunerne vil forandre og effektivisere opgaveløsningen. It-omkostningerne bliver lavere og dermed ikke en bremse for forandring. 4. Flere leverandører. Rammearkitekturen tilbyder en åben infrastruktur, som bygger på de forskellige vedtagne standarder nationalt og internationalt. Herved bliver det nemmere for nye leverandører at tilbyde it-løsninger til det kommunale it-marked. Når kommunen baserer sine it-løsninger på Rammearkitekturens brug af åbne standarder og krav om udskiftelige moduler (byggeblokke), ejerskab til kildekoden m.v., kan kommunen skifte leverandører uden tekniske barrierer, eksempelvis når en it-løsning skal genudbydes. 5. Driftsstabilitet. Rammearkitekturen bygger på nogle veldefinerede integrations- og driftsmønstre, som bl.a. implementeres gennem Serviceplatformen, som har krav til høj driftsstabilitet på tværs af de forskellige leverandører og it-systemer. Der er således fokus på driftsstabilitet i og omkring Rammearkitekturen. 3.8 Fordele for beslutningstagere For beslutningstagerne i digitaliseringen repræsenterer Rammearkitekturen en struktur, der understøtter mere klare beslutningsoplæg om digitalisering, effektivisering og bedre opgaveløsning. Side 12/29

13 Rammearkitekturen indebærer en samlet forretningsarkitektur, der gør det lettere at få overblik over både de manuelle og de digitale dele af kommunernes opgaveløsning til gavn for kvaliteten af beslutningerne. Rammearkitekturen har derfor potentiale til at blive en generel anvendt ramme for udviklingen af den kommunale sektor, såvel opgavemæssigt som itmæssigt. 3.9 Fordele for leverandører For it-leverandørerne betyder Rammearkitekturen en forenkling. Leverandørerne vil i højere grad modtage kommunernes krav i samme struktur, således leverandøren kan koncentrere sig om de krav, som er specifikke for opgaven. Dette mindsker leverandørens ressourceforbrug til afgivelse af tilbud mv. Leverandøren vil møde kommunernes krav i en Fælleskommunal kravspecifikation, som er struktureret efter Rammearkitekturen, og som vil lette opgaven både for kommuner og leverandører. Rammearkitekturen sikrer, at kommunens it-løsninger fremstår som en samlet infrastruktur for leverandøren med standardiserede snitflader mv. Denne fælles infrastruktur og en mere enkel ramme for kravformulering vil tilsammen understøtte en åbning af det kommunale marked for flere it-leverandører, og dermed fremme bedre og billigere it-løsninger til kommunerne. Med tiden vil det være en markedsfordel at være Rammearkitekturcompliant. Side 13/29

14 4. Paradigmeskift ift. kommunal it-arkitektur 4.1 Den nuværende arkitektur En af hovedudfordringerne ved det nuværende it-landskab er, at mange it-systemer er opbygget som silo-løsninger, der varetager en isoleret opgave, og hvor data er låst til systemet. Kommunerne mærker det bl.a. ved, at de skal betale dyrt for etablering af snitflader og adgang til egne data, og at det er svært smidigt at skabe automatisering af processer på tværs af systemer. Kommunens medarbejdere må udføre unødvendigt manuelt arbejde som eks. genindtastning af data, og kommunernes ledelse har svært ved at få adgang til den relevante ledelsesinformation. En kommune har mange it-systemer til at understøtte sin forretning. Der er ikke noget galt i, at der er mange systemer, blot kommunen ikke skal betale for den samme funktionalitet mange gange, og at systemerne kan understøtte tværgående processer på en effektiv måde. Den traditionelle måde at foretage indkøb af it-systemer på, er ofte at gennemføre et udbud med krav til det fagområde, it-systemet skal understøtte. Leverandørerne kan konkurrere på pris mens funktionaliteten er fast og integration et tilkøb. Når man skal foretage genudbud, er det stadig den samme funktionalitet, men ofte en ny leverandør og nye integrationer. 4.2 Transformationen Det kommunale it-landskab har været kendetegnet ved en hovedleverandør (KMD), som traditionelt har leveret langt størsteparten af kommunernes it og en række andre mindre systemer fra andre leverandører. KMD har her arbejdet med deres egen rimelig komplette arkitektur med store interne sammenhænge, men historisk uden den ønskede åbenhed udadtil. Dermed har kommunerne ofte stået med problemer, når der skulle skabes sammenhæng mellem itsystemer fra forskellige leverandører. Ud fra de fælleskommunale arkitekturmål med sammenhængende it, flerleverandørstrategi, fokus på genbrug mv. vil it- landskabet blive struktureret i en fleksibel arkitektur bestående af en række byggeblokke implementeret i komponenter og/eller it-systemer leveret af forskellige leverandører. Disse byggeblokke er et paradigmeskift i forhold til den traditionelle måde, at betragte itsystemer og det kommunale it-marked på. Kommunerne beskriver byggeblokkene og tager ansvar for deres samspil tager ansvar for arkitekturen. Når et fagområde skal understøttes digitalt, kan det gøres ved at udpege, hvilke byggeblokke der skal bruges i løsningen, og hvordan disse skal fungere i en sammenhængende løsning. It-understøttelsen vil, som i dag, understøtte den kommunale forretning, men fremover vil dette ske i form af en modulær arkitektur, som understøtter fleksibilitet, innovation og øget konkurrence på det kommunale it-marked. Side 14/29

15 4.3 Den kommunale forretning beskrives i form af byggeblokke Et væsentligt paradigmeskift med Rammearkitekturen er, at den kommunale forretning beskrives i form af byggeblokke, som de forskellige forretningsprocesser så benytter i forbindelse med udførelse af de forskellige kommunale processer. I eksemplet ovenfor har forretningsanalysen afdækket fire centrale forretningsobjekter (A, B, C og D), som i et eller andet omfang er relateret til hinanden. Omkring hvert af disse centrale objekter defineres en byggeblok, som skal indeholde en række karakteristika (nærmere beskrevet i kapitel 8). Paradigmeskiftet består dels i at forretningen opdeles og beskrives efter denne standard, dels i at de tværgående forretningsprocesser, og implementeringen af disse i brugerflader, beskrives i form af deres brug af disse byggeblokke. Implementeringen af konkrete it-løsninger tager udgangspunkt i denne beskrivelse. Den er populært sagt et spejlbillede af den logiske beskrivelse af den kommunale forretning. Når et forretningsområde skal anskaffe ny it-understøttelse, gøres dette i den ideelle verden ved at identificere og udpege de byggeblokke, som it-understøttelsen skal bygges ud fra. I den praktiske verden vil alle byggeblokke næppe være identificeret og beskrevet på forhånd. Arbejdet vil derfor også ofte skulle omfatte forretningsanalyse med identifikation og beskrivelse af de manglende byggeblokke. En byggeblok skal ikke opfattes statisk. Man vil kunne tilføre den mere og mere funktionalitet uden at ændre på det grundlæggende forretningsobjekt. Det kan være automatiske processer (partshøring i Sag), nye integrationer (beskedintegration) eller nye brugergrænseflader (Apps). Byggeblokkes funktionalitet udvikles dynamisk. Det kan medvirke til at øge konkurrencen mellem de leverandører, der implementerer byggeblokken. Byggeblokkens implementering skal kunne udveksle forretningsobjekter med andre implementeringer af den samme byggeblok. To implementeringer skal kunne samvirke i en distribueret implementering, så forretningsobjekter både kan være tilgængelige for centrale og lokale implementeringer. 4.4 Brugerflader tilpasses arbejdsprocessen på tværs af byggeblokke Omkring mange af de nuværende it-løsninger er der tale om et fagsystem med en brugerflade bygget til netop dette fagsystem. Har aktøren behov for at se data fra et andet fagsystem, skal aktøren logge ind på brugerfladen til det pågældende system. Der er således en tæt binding mellem fagsystemet og de dertil hørende data, og så den brugerflade der skal anvendes til at vedligeholde disse data. Side 15/29

16 I forbindelse med Rammearkitekturen gøres der grundlæggende op med denne arkitektur jf. ovenstående illustration. It-systemer opbygges her som en løst koblet arkitektur med en arkitekturmæssig adskillelse mellem brugerflader og de enkelte implementeringer af byggeblokke. Brugerflader opbygges målrettet de enkelte aktørers arbejdsopgaver, uafhængigt af om dette kræver adgang til og opdatering af data i implementeringer af flere forskellige byggeblokke. 4.5 Kommunikation mellem it-løsninger/aktører via hændelsesbeskeder Et andet paradigmeskift med Rammearkitekturen er, at kommunikation mellem forskellige aktører og forskellige it-løsninger i højere grad end i dag overgår til at være baseret på kommunikation af hændelsesbeskeder mellem it-løsninger. Dette mønster kaldes EDA (Event Driven Architecture). Når en byggeblok forretningsmæssigt ændrer indholdet i sit forretningsobjekt, udsender byggeblokken en besked med den pågældende forretningshændelse. Andre processer kan abonnere på disse beskeder, således at de kan gå i gang med at løse opgaver, som er afhængige af det første forretningsobjekts ændrede status. Den byggeblok, der afsender beskeden, interesserer sig ikke for hvem der abonnerer på denne forretningshændelse. Herved opnås en løs kobling, som er meget velegnet til at sikre kommunikation på tværs af flere leverandører og/eller driftsplatforme. 4.6 Datakilden har ansvaret for at bevare historik Et tredie paradigmeskift med Rammearkitekturen er, at de enkelte byggeblokke skal huske deres egen historiske udvikling. Hvornår er hvad blevet ændret i byggeblokkens egne objekter? Formålet hermed er, at byggeblokken skal være i stand til gennem sine udstillede services at kunne oplyse om, hvad der var registreret ift. byggeblokkens forretningsobjekt på et givet tidspunkt. En af de væsentlige fordele herved er, at det er den ansvarlige byggeblok for et givet forretningsobjekt, som har ansvaret for denne historik. Derved slipper alle anvendere af denne for at skulle gemme en lokal kopi af forretningsobjektet af hensyn til dokumentationen bag eksempelvis en afgørelse på en ansøgning eller en beregning af en boligydelse. Side 16/29

17 5. Styr på kaos 5.1 Nuværende it-landskab med mange dialekter Det er en kaotisk it-verden vi lever i. snart 50 års udvikling af mainframe-løsninger, webapplikationer, klient-server-løsninger, silosystemer, knopskydninger og specialtilretninger på tværs af kommuner, amter, regioner og staten. Mange, mange velmenende arbejdstimer er lagt i, at få alt det her til at hænge nogenlunde sammen. Det er lykkedes til en vis grad, men mange ville sikkert sige, at det ville være dejligt, hvis vi kunne starte helt forfra. Det kan vi naturligvis ikke og det er heller ikke nødvendigt. Tegningen herover illustrerer nogle af de mange it-systemer, der findes i det kommunale landskab. Store og små. Mange af dem indeholder nogenlunde de samme informationsobjekter de gør det bare ikke på den samme måde. For illustrationens skyld, signalere farverne den samme information og faconen at det alligevel ikke er helt det samme. Det er det, der gør at systemerne ikke rigtigt kan tale sammen. Nogle forsøger det, men de misforstår hinanden, da de ikke har en ensartet definition at læne sig op ad. Hver især har de analyseret forretningen og hver især er de kommet frem til deres eget (proprietære) resultat. 5.2 Rammearkitektur med fælles definitioner Rammearkitekturen skal, en gang for alle, sikre at alle har samme udgangspunkt for forståelsen af den kommunale forretning. Ovenstående illustrerer et fremtidigt systemlandskab med samme forståelse af de samme objekter. Det er illustreret ved at elementerne har samme facon. Side 17/29

18 Ydermere er der sket det, at nogle helt er forsvundet ud af it-systemerne. I stedet for at bygge funktionaliteten selv, anvendes nu fælleskommunale støttesystemer som sikrer den funktionalitet, som, i de nuværende systemer, er bygget igen og igen. Der er derfor etableret 3 væsentlige indsatsområder: Etablering af en fælleskommunal Rammearkitektur, som på logisk niveau definerer, strukturer og sætter rammer for den it, der fremover skal bygges Etablering af fælles infrastruktur og udvikling af støttesystemer til fælles anvendelse for alle kommuners it-systemer. Etablering af et styringsorgan i form af Arkitekturrådet, hvor væsentlige problemstillinger af fælleskommunal karakter, kan drøftes. Side 18/29

19 6. Rammearkitekturens strukturering den overordnede definitions- og struktureringsmodel. 6.1 Overblik En rammearkitektur er, som navnet siger, de fælles rammer, vi sætter op for alle, der skal arbejde med kommunale processer og kommunal it. Det er populært sagt den spillebane og de spilleregler, der vil gælde for at være med til at levere it til kommunerne fremover. Rammearkitekturen etableres som en fælles spillebane for, at kommunerne kan opnå bedre, billigere, sammenhængende og forandringsrobuste it-systemer, leveret af et bredt udsnit af leverandører. Ydermere vil kommunerne i fællesskab løbende anskaffe sig flere og flere fælles fysiske itkomponenter, som kan anvendes af alle, ligesom der etableres en fæles serviceplatform og et fælles testmiljø. 6.2 Den logiske og den fysiske Rammearkitektur Det er helt essentiel at skelne mellem den logiske Rammearkitektur med logiske byggeblokke, og en fysisk realisering af byggeblokkene. Det logiske niveau er et specifikationsniveau, og logiske byggeblokke eksisterer kun på papir de logiske byggeblokke skaber det nødvendige overblik for at udvikle sammenhængende it på det fysiske niveau. Den logiske byggeblok indkapsler og holder styr på ansvarsfordelingen hvem der har ansvaret for at definere regler, informationer og processer for dette afgrænsede område. Den logiske byggeblok danner udgangspunkt for byggetegningen af elementerne i et fysisk itsystem eller fysiske komponenter. Der findes kun én logisk byggeblok for hvert centralt forretningsobjekt og de centrale forretningsobjekter er gensidigt udelukkende, så det enkelte forretningsobjekt optræder kun én gang i hele den kommunale forretning. Der er således en og samme beskrivelse, alle forholder sig til. Den samme logiske byggeblok kan udmærket eksistere i flere fysiske udgaver. Den kan være en del af et it-system, eller en fysisk byggeblok kan være et selvstændigt it-system. Der kan være Side 19/29

20 fysiske komponenter som bruges lokalt i kommunen, og komponenter der indgår i centrale servicebureau-løsninger. Rammearkitekturen deles op i et logisk niveau, som beskriver og definerer - og et fysisk niveau, som viser relationen mellem logikken og de fysiske applikationer og systemer. Rammearkitekturen er derfor en måde: Logisk at tænke og forstå sin forretning strukturere sin forretning mht. informationsansvar, regler og processer opsætte spilleregler og principper for dem, der vil levere til det kommunale marked analysere forretningsbehov metodisk kommunikere med omverdenen i et ensartet, forståeligt sprog kunne fokusere på en mindre del af forretningen, uden at miste helheden Definere begreber, regler og processer. Specificere det, der skal bygges, således at alle leverandører anvender samme grundlæggende model. Fastholde definitioner, regler, processer og beslutninger. Fysisk at strukturere den it, som skal understøtte forretningen sikre at de udviklede it-systemer kan kommunikere på tværs af leverandører sikre en styret migrering fra gammelt til nyt Side 20/29

21 7. Den logiske Rammearkitektur På det logiske niveau beskrives forretningen (forvaltningen) på forretningens præmisser. Der tænkes så at sige forretning helt uden at tænke på it og systemer, men udelukkende på hvilke opgaver, der skal løses, det sprog der anvendes, de regler, der gælder og de processer, der understøtter opgavevaretagelsen. Herudover beskrives, hvilke situationer (forretningshændelser) der skal reageres på og hvilke forretningshændelser der meddeles omverdenen (eks. ydelsessag, kontanthjælp oprettet ) I Rammearkitekturen sættes ligeledes retningen for, hvordan forretningen ønskes udviklet udmøntet i vision og strategi. Det er primært forretningsudviklere og politikere, der her kan beskrive, hvor den kommunale forretning skal bevæge sig hen. Analyseres et forretningsområde det kunne være bevilling, beregning og udbetaling af ydelser (Ydelsesområdet) vil der være et samspil af processer, informationer og regler, som tilsammen udgør den funktionalitet, som brugeren har behov for. Forretningsområdet opdeles i en række byggeblokke. Byggeblokkene anvendes af de tværgående processer, hvor de i forening løser opgaverne. 7.1 Opdeling af den kommunale forretning i byggeblokke Rammearkitekturens grundlæggende strukturering, opdeler den kommunale forretning i en række byggeblokke, hvor den enkelte byggeblok er defineret ud fra et centralt forretningsobjekt. Denne byggeblok har ansvaret for og løser alle opgaver relateret til dette specifikke forretningsobjekt. Denne strukturering giver overblik og en høj grad af fokus på det præcise indhold i de enkelte dele af opgaveløsningen og en entydig placering af ansvaret, også i forholdet til afgrænsning mellem projekter, leverandører etc. Det helt grundlæggende struktureringselement i Rammearkitekturen er således byggeblokkene. At arbejde med byggeblokke giver en kæmpe fordel, da det er muligt at få opdelt det uoverskuelige i mindre, overskuelige enheder. Når byggeblokken skal defineres og beskrives, sker det med fokus på denne mindre del af forretningen og dermed kan det gøres meget præcist og mere fuldendt. Byggeblokken kan også have en mindre eller større grad af færdiggørelse og kan stadig bruges i beskrivelsen af de processer, der skal understøtte forretningen. Der kan således arbejdes parallelt med beskrivelserne. Byggeblokkene har alle samme grundlæggende struktur og metaegenskaber. De indeholder alle noget central information (et centralt forretningsobjekt), de har alle en række processer, som udstilles, de kan alle kommunikere deres informationer og de kan alle udstede beskeder til omverdenen. Byggeblokkene findes således inden i de it-systemer vi arbejder med, i større eller mindre grad. Ser vi f.eks. på et typisk ESDH-system vil det, som minimum, indeholde byggeblokkene Sag, Dokument, Klassifikation og Organisation. De forskellige systemer på markedet gør det i dag lidt forskelligt, hvilket er årsagen til, at de ikke er så gode til at snakke sammen. Når leverandørerne fremover anvender Rammearkitekturens byggeblokke, når de designer ESDHsystemer, vil de alle anvende samme grundlag, hvilket vil gøre at de alle forstår det samme ved Sag, Dokument osv. Det er muligt at de ikke i deres databasestrukturer ser helt sådan ud, men det gør heller ikke noget, hvis blot de kan kommunikere med omverdenen i Sag-sprog, Dokument-sprog osv. Leverandørerne behøver derfor ikke at begynde helt forfra med at kode nye systemer for at blive Rammearkitekturcompliant. De kan eksempelvis bygge små oversættere, der kan oversætte fra deres interne sprog til Rammearkitekturens. Side 21/29

22 7.2 Hvordan finder vi byggeblokkene? Vi ønsker at få opdelt vores kommunale forretning i et antal byggeblokke, der er gensidigt udelukkende, for at undgå at det samme skal defineres flere gange med fare for inkonsistens. Forretningsobjekter er (i normaliseret form) pr. definition gensidigt udelukkende og derfor anvender vi centrale forretningsobjekter, som kernen i vores byggeblokke. I den kommunale forretning arbejder vi med en række indlysende forretningsobjekter som Person, Virksomhed, Ejendom, Sag, Dokument osv. Det er elementer vi alle bruger i vores fagkontekst igen og igen. Efterhånden som flere fagområder analyseres og dokumenteres, vil der opstå flere byggeblokke. Som minimum skal den dog normalt have et centralt forretningsobjekt. Det er vigtigt at forstå, at når et fagområde, som f.eks. skoleområdet, afdækkes, opstår der nye byggeblokke. De fagsystemer, der bygges/indkøbes skal leve op til byggeblokkens egenskaber om at stille sine data og operationer til rådighed og at meddele omverdenen, når der sker en ændring i data. 7.3 Byggeblokkene relaterer sig til hinanden Byggeblokkene relaterer sig også til hinanden qua deres forretningsobjekters forretningsmæssige relationer. På UML-klassemodellerne arbejder vi med blå objekter, som, fra en byggebloks kontekst, er noget den relaterer sig til, men ikke ejer. Byggeblokkene er pr. definition selvstændige enheder og derfor ved en byggeblok, som udgangspunkt ikke, at den indgår som blåt objekt i en anden byggeblok. Men byggeblokken, der relaterer sig til et andet objekt er naturligvis interesseret i, hvis det relaterede objekt ændrer sig. Derfor vil det være naturligt, at det system, der forvalter en byggeblok, opsætter et abonnement på de ændringer, der måtte være i et relateret objekt. 7.4 Integrationer i Rammearkitekturen Det leder os naturligt hen til de måder byggeblokkene kan kommunikere med hinanden og med omverdenen i det hele taget. Byggeblokkene er jo stadig logiske, så de kan kun kommunikere på tegnebrættet, men de fysiske it-systemer, der bygges, skal leve op til Side 22/29

23 byggeblokkenes egenskaber, og derfor skal de kunne kommunikere på samme måder for at være helt compliant med Rammearkitekturen. Kald-integration: En proces kan kalde en byggebloks operation og få svar. Dette er traditionelt SOA. Dette integrationsmønster giver en hård binding mellem processer og byggeblokke, men kan være nødvendig i nogle tilfælde. Eksempelvis kan forretningen have regler om at flere byggeblokkes informationer SKAL være på plads, før en given transaktion kan afsluttes (ofte omtalt som commit scope ). Hændelsesbeskedintegration: Når en proces er færdig med sit arbejde og dermed har ændret på sit forretningsobjekt, sendes en besked om, at opgaven er løst. Og gør så ikke mere. Andre brugere kan abonnere på disse beskeder, således at de kan gå i gang med at løse de opgaver, som er afhængige af det første forretningsobjekts status. Det kan eksempelvis være byggeblokken Person, hvor adresserelationen ændres pga. en flytning. Mange processer er interesserede i, når Personer flytter, da de så skal udføre en opgave. Det er vigtigt at pointere at den, der afsender beskeden ikke ved, hvem der abonnerer på den. Dette mønster kaldes EDA (Event Driven Architecture). Mønstret giver en høj grad af løs kobling og er fortrinligt, når en end-to-end-proces går på tværs af flere leverandører eller driftsplatforme. Meddelelsesbeskedintegration: En særlig type beskeder er meddelelser, hvor der i en proces, sendes en meddelelse til en anden proces. Eksempelvis kan et beregningssystem sende en udbetalingsanmodning til et udbetalingssystem. Mønstret er ligeledes karakteriseret ved løs kobling og minder om hændelsesbeskeder, blot med den drejning at afsendersystemet sender en besked til nogen, hvor man i EDA blot meddeler at noget er sket Dialogintegration: Den sidste mulighed er byggeblokkene blot integreres ved at deres (eventuelle) brugergrænseflader udstilles sammen. Integrationsformen kan være yderst praktisk at anvende i et portalrammeværk, men giver en relativt hård binding mellem rammeværket og de byggeblokke, der udstiller grænsefladen. 7.5 Procesmønstre i Rammearkitekturen Byggeblokkene indgår i de tværgående processer, som eksempelvis fagsystemer repræsenterer. Efterhånden som de forskellige fagområdet afdækkes, vil vi finde gode procesmønstre, som kan bruges igen og igen. Ved at gøre dem til en del af Rammearkitekturen, kan vi fastholde, forbedre og genbruge dem. Procesmønstrene kan ofte findes ved, at tænke i analogier til andre kendte forretninger. Eksempelvis kan man, et stykke hen ad vejen, argumentere for at eksempelvis Pensionsberegning og udbetaling ligner en lønproces, med beregning (og omberegning) og Side 23/29

24 udbetaling af løn til en ansat. På den måde, kan der ofte lånes af kendte, velfungerende forretninger og deri finde et velafprøvet mønster. Disse generelle mønstre kan beskrives som et fælles grundlag i Rammearkitekturen og dermed sikre en ensartethed på tværs af sammenlignelige forretningsområder. Et eksempel på et Sagoprettelses- og effektuerings mønster, ses på figuren herunder. Den beskriver den samlede proces omkring modtagelse af en ansøgning, placering af sagen, fremfinding af oplysninger, afgørelse, effektuering af bevillingen m.m. Dette mønster beskriver sammenhængen mellem sagens tilstande (iflg. standarden), forretningens processer og de dokumenter, der håndteres undervejs. Mønstret fastholder et sprogbrug og en struktur i de forretningsområder, der benytter sig af det. Side 24/29

25 8. Byggeblok konceptet 8.1 Opbygningen af en byggeblok Sammenfatter vi ovenstående beskrivelse, har alle byggeblokke disse egenskaber: Den skal stå til rådighed for andre (altså levere en service). Den skal definere den informationsmængde, som hører til eget forretningsobjekt. Den skal beskytte sit eget objekt og respektere andres. Den skal huske de ændringer, der er sket tidligere og kunne registrere ændringer, der endnu ikke er trådt i kraft (have bitemporale egenskaber). Den skal kunne kommunikere med omverdenen på et standardiseret sprog. Fortælle omverdenen, hvis der sker en forandring (andre er afhængige af den) og reagere på forandringer (hændelser) i omverdenen. Udstille sine data til andre. Udstille sin brugergrænseflade for andre (hvis der er en sådan). Sammenfatter vi ovenstående behov for kan vi definere hvad en beskrivelse af en forretningsbyggeblok skal indeholde: En beskrivelse og definition af det centrale forretningsobjekt. En beskrivelse af relationerne til andre forretningsobjekter uden for byggeblokkens egen verden. En beskrivelse af de processer, som byggeblokken kan håndtere (dens virkemåde). En beskrivelse af de beskeder (forretningsbeskeder) den kan sende til omverdenen (og som andre kan abonnere på). En beskrivelse af de beskeder, der kan igangsætte processer i byggeblokken (hvad den selv skal abonnere på). En beskrivelse af de operationer byggeblokken stiller til rådighed (hvad kan man bede den om). Beskrivelser af de snitflader byggeblokken stiller til rådighed (definition af byggeblokkens sprog ). En beskrivelse af den eventuelle brugergrænseflade byggeblokken stiller til rådighed. Når først en sådan byggeblok er velbeskrevet, kan den bruges igen og igen i it-projekterne. Beskrivelsen af netop denne isolerede information og funktionalitet er grundlagt og kan uddybes løbende. 8.2 Byggeblokke i en fagkontekst I Rammearkitekturen definerer vi en række fælles byggeblokke, som det helt grundlægende fundament, men der er mange flere end dem. Side 25/29

Introduktion til Den fælleskommunale Rammearkitektur

Introduktion til Den fælleskommunale Rammearkitektur Introduktion til Den fælleskommunale Rammearkitektur - en arkitektur for den kommunale digitalisering Version 1.3 1. Introduktion Den fælleskommunale Rammearkitektur er et løbende udviklingsarbejde, hvor

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

DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR

DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR FDA2017 DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR - FRA VISION TIL PRAKSIS FDA 2017 Agenda Digitaliseringsstrategien og kommunernes udfordringer Rammearkitekturen som et fælles

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

BUDSKABSPAPIR om den fælleskommunale rammearkitektur for it og digitalisering ("rammearkitekturen")

BUDSKABSPAPIR om den fælleskommunale rammearkitektur for it og digitalisering (rammearkitekturen) 1 BUDSKABSPAPIR om den fælleskommunale rammearkitektur for it og digitalisering ("rammearkitekturen") BRUGSVEJLEDNING Budskabspapiret er en hjælp til at sætte ord og sætninger på, når du som kommunal chef

Læs mere

Støttesystemerne. Det er tid til

Støttesystemerne. Det er tid til 1 Det er tid til Støttesystemerne 2 Kombit Digitalisering er afgørende for udviklingen af de kommunale kerneopgaver, hvor bedre borgerservice med færre ressourcer er i centrum. Kommunernes mål er at bevare

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

Programbeskrivelse. 7.1 Sammenhæng og genbrug med rammearkitekturen. 1 Formål og baggrund. Maj 2016

Programbeskrivelse. 7.1 Sammenhæng og genbrug med rammearkitekturen. 1 Formål og baggrund. Maj 2016 Programbeskrivelse 7.1 Sammenhæng og genbrug med rammearkitekturen 1 Formål og baggrund Programmet Sammenhæng og genbrug med rammearkitekturen udgør en del af den fælleskommunale digitaliseringshandleplan.

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

DEN LILLE SKARPE OM RAMMEARKITEKTUREN

DEN LILLE SKARPE OM RAMMEARKITEKTUREN DEN LILLE SKARPE OM RAMMEARKITEKTUREN HVORFOR EN FÆLLESKOMMUNAL RAMME ARKITEKTUR? Digitalisering er afgørende for udviklingen af de kommunale kerneopgaver, fordi Borgerne skal møde en nær og sammenhængende

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 til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 25. april 2013 NOTAT Anvenderkrav til Støttesystemet Klassifikation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk

Læs mere

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 25. april 2013 Klik her for at angive tekst. NOTAT Bilag 14: Anvenderkrav til Støttesystemet Organisation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) kombit@kombit.dk CVR

Læs mere

SAPA overblik på et øjeblik. Kenneth Møller Johansen, KOMBIT

SAPA overblik på et øjeblik. Kenneth Møller Johansen, KOMBIT SAPA overblik på et øjeblik Kenneth Møller Johansen, KOMBIT 1 Om forprojektet for SAPA Hvorfor? Del af Udbudsplanen for monopolområderne (ejes af KL, udføres af KOMBIT) Udbudsplanen skal iværksætte it-projekter,

Læs mere

RACI-model for arkitekturprodukter i den fælleskommunale rammearkitektur

RACI-model for arkitekturprodukter i den fælleskommunale rammearkitektur Bilag 8 til pkt. 9 RACI-model for arkitekturprodukter i den fælleskommunale rammearkitektur INDHOLD Indledning... 2 Definitioner... 3 Fælleskommunale arkitekturmål:... 3 Forretningsprocesmønstre... 4 Fælleskommunale

Læs mere

Fælleskommunale arkitekturprincipper, version 1.0

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

Læs mere

FORSLAG TIL INDSATSOMRÅDER I DEN KOMMENDE STRATEGIPERIODE. EDS Netværksmøde d. 3 og 5. november 2015 v/annie Bekke Kjær

FORSLAG TIL INDSATSOMRÅDER I DEN KOMMENDE STRATEGIPERIODE. EDS Netværksmøde d. 3 og 5. november 2015 v/annie Bekke Kjær FORSLAG TIL INDSATSOMRÅDER I DEN KOMMENDE STRATEGIPERIODE EDS Netværksmøde d. 3 og 5. november 2015 v/annie Bekke Kjær KL har gennemført markedsanalyse på selvbetjeningsløsninger i efteråret 2015: Kommuner

Læs mere

Digitaliseringsstrategi 2011-2014

Digitaliseringsstrategi 2011-2014 Digitaliseringsstrategi 2011-2014 Indholdsfortegnelse: Hørsholm Kommune vil være en digital kommune...3 Hvor skal vi hen...3 Mål for digitalisering...5 Strategiske spor...6 A. Alle ledere og medarbejdere

Læs mere

PARADIGMESKIFTET - en grundfortælling

PARADIGMESKIFTET - en grundfortælling PARADIGMESKIFTET - en grundfortælling MODEL TIL HÅNDTERING AF FREMTIDENS DIGITALE UDFORDRINGER. UDARBEJDET I ET SAMARBEJDE MELLEM SORØ OG RINGSTED KOMMUNE. EXECUTIVE SUMMARY Et paradigmeskift er et skift

Læs mere

NOTAT. Brugerportalsinitiativet

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

Læs mere

Fælles kommunal rammearkitektur og konkrete støttesystemer

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

Læs mere

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

It-delstrategi for administrativ it-anvendelse

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

Læs mere

Arkitekturrapport: Digitalisering på Handicap- og Udsatte Voksne-området

Arkitekturrapport: Digitalisering på Handicap- og Udsatte Voksne-området Arkitekturrapport: Digitalisering på Handicap- og Udsatte Voksne-området Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af

Læs mere

Digitaliseringsstrategi

Digitaliseringsstrategi gladsaxe.dk Digitaliseringsstrategi 2015-2018 Gladsaxe Kommune er med stor fart i gang med at forandre og effektivisere opgaveløsningen og skabe mere velfærd for borgerne ved at udnytte mulighederne gennem

Læs mere

BILAG 14 FORSLAG TIL VISION OG MÅLBILLEDE FOR RAMMEARKITEKTUREN

BILAG 14 FORSLAG TIL VISION OG MÅLBILLEDE FOR RAMMEARKITEKTUREN GOVERNANCE, MÅL OG INDHOLD BILAG 14 FORSLAG TIL VISION OG MÅLBILLEDE FOR RAMMEARKITEKTUREN Forslag vedtaget af SAGERA styregruppen 31.01.17 Vision Målbillede for den fælleskommunale rammearkitektur Rammearkitekturen

Læs mere

Digitalisering i den kommunale sektor. Ken Rindsig, KL

Digitalisering i den kommunale sektor. Ken Rindsig, KL Digitalisering i den kommunale sektor Ken Rindsig, KL Fire spørgsmål Status for digitaliseringsstrategien i Danmark og i hvilken grad felles arkitektur har bidratt til gjennomføringen Kommunesammenslåing

Læs mere

FORSLAG TIL VISION OG MÅLBILLEDE FOR RAMMEARKITEKTUREN

FORSLAG TIL VISION OG MÅLBILLEDE FOR RAMMEARKITEKTUREN GOVERNANCE, MÅL OG INDHOLD FORSLAG TIL VISION OG MÅLBILLEDE FOR RAMMEARKITEKTUREN Proces for udarbejdelse af vision og målbillede for rammearkitekturen Fase 1 (november): Afklaring af vision Workshop om

Læs mere

Fælleskommunale it-arkitekturprincipper

Fælleskommunale it-arkitekturprincipper Fælleskommunale it-arkitekturprincipper Pr. 5. september 2012 Af arbejdsgruppen for fælleskommunale itarkitekturprincipper under Kommunernes It-Arkitekturråd Side 1 af 24 IndholdIndhold... 2 Baggrund...

Læs mere

Vision og strategi for DIGITALISERING & VELFÆRDSTEKNOLOGI for SÆH-forvaltningen

Vision og strategi for DIGITALISERING & VELFÆRDSTEKNOLOGI for SÆH-forvaltningen Vision og strategi for DIGITALISERING & VELFÆRDSTEKNOLOGI for SÆH-forvaltningen 2016-2020 VISION PERSPEKTIVER OVERORDNEDE MÅL ORGANISERING ROLLER OG ANSVAR INDSATSER BAGGRUND I Hjørring Kommune vil vi

Læs mere

Bilag 6 - Kortlægning af udvalgte initiativer og analyser

Bilag 6 - Kortlægning af udvalgte initiativer og analyser Bilag 6 - Kortlægning af udvalgte initiativer og analyser Sekretariatet for arkitekturrådet har i forbindelse med foranalysen af hvordan rammearkitekturen kan bidrage til fælleskommunale standarder for

Læs mere

Bilag 10 - Udkast til strategi for udvikling og udbredelse af den fælleskommunale rammearkitektur

Bilag 10 - Udkast til strategi for udvikling og udbredelse af den fælleskommunale rammearkitektur NOTAT Bilag 10 - Udkast til strategi for udvikling og udbredelse af den fælleskommunale rammearkitektur (Bilag til dagsordenspunkt 12: Strategi for udvikling og udbredelse af rammearkitekturen og kommunikationsstrategi

Læs mere

Data og rammearkitektur på beskæftigelsesområdet

Data og rammearkitektur på beskæftigelsesområdet R E SULTATKONTRAKT Data og rammearkitektur på beskæftigelsesområdet (2.1) Kommunerne ønsker at levere en langt mere effektiv beskæftigelsesindsats, både mere effektiv i betydningen af bedre målopfyldelse

Læs mere

Fordelingen af kommunale gevinster i business casen for initiativet Genbrug af adressedata

Fordelingen af kommunale gevinster i business casen for initiativet Genbrug af adressedata NOTAT MINISTERIET FOR BY, BOLIG OG LANDDISTRIKTER Fordelingen af kommunale gevinster i business casen for initiativet Genbrug af adressedata 18. juli 2012 Sag: /mli-mbbl Baggrund Initiativet Genbrug af

Læs mere

DHUV. Digitalisering på handicap- og udsatte voksneområdet metoder og it-anskaffelse Kommunemøder den 4., 7., 10. og 14.

DHUV. Digitalisering på handicap- og udsatte voksneområdet metoder og it-anskaffelse Kommunemøder den 4., 7., 10. og 14. DHUV Digitalisering på handicap- og udsatte voksneområdet metoder og it-anskaffelse Kommunemøder den 4., 7., 10. og 14. marts 2011 2 Vejledende program 12.45 Baggrund for projektet og formål med dagen

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

Socialanalyse Øget datadeling på socialområdet

Socialanalyse Øget datadeling på socialområdet Socialanalyse Øget datadeling på socialområdet Præsentation af foreløbige resultater til Arkitekturrådet 29. april 2015 v/projektleder Michal Ingvald Sørensen, Arbejdsgange & It-arkitektur, KL Baggrund

Læs mere

Bilag 1: Arkitekturrapport, EDS Hjælpemidler

Bilag 1: Arkitekturrapport, EDS Hjælpemidler Bilag 1: Arkitekturrapport, EDS Hjælpemidler (Bilag til dagsordenspunkt 2, Arkitekturrapporter fra Effektiv Digital Selvbetjening) Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug

Læs mere

Roadmap for VERA Q Q Q Q Rettighed. Klassifikation. Organisation. Beskedfordeler. Serviceplatform

Roadmap for VERA Q Q Q Q Rettighed. Klassifikation. Organisation. Beskedfordeler. Serviceplatform Roadmap for VERA Q3 2015 Rettighed Q2 2015 Klassifikation Q1 2015 Organisation Beskedfordeler Q4 2014 platform Indledning Kommunerne i Vendssyssel ønsker at etablere en moderne infrastruktur til at understøtte

Læs mere

Sager på tværs. MOX giver sammenhængende processer på tværs af it-systemer

Sager på tværs. MOX giver sammenhængende processer på tværs af it-systemer Sager på tværs MOX giver sammenhængende processer på tværs af it-systemer 2 Sager på tværs Vil I gerne gøre det nemmere at sende dokumenter på tværs af jeres kommune? Så er MOX noget for jer! En kommune

Læs mere

KOMBITS UDMØNTNING AF RAMMEARKITEKTUREN. V/ Chefkonsulent Morten Hass

KOMBITS UDMØNTNING AF RAMMEARKITEKTUREN. V/ Chefkonsulent Morten Hass KOMBITS UDMØNTNING AF RAMMEARKITEKTUREN V/ Chefkonsulent Morten Hass Tre budskaber Rammearkitekturen er kommunernes fælles krav og infrastruktur Hvert fælles projekt udbygger rammearkitekturen Når ny fælles

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

Støttesystemet Klassifikation. Klassifikation. Et af de otte Støttesystemer

Støttesystemet Klassifikation. Klassifikation. Et af de otte Støttesystemer 1 Et af de otte Støttesystemer 2 Kombit Støttesystemet Hvad er Støttesystemet? Håndtering af alle typer klassifikationer i samme system Støttesystemet er et centralt register for de klassifikationer, som

Læs mere

Fællesskabet der vil noget mere

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

Læs mere

Digitaliseringsstrategi

Digitaliseringsstrategi Dragør Kommune, november 2015 Justeret november 2016 Digitaliseringsstrategi UDKAST TIL OPDATERING Dragør Kommune 2016 2020 1 Indholdsfortegnelse 0. Forord...3 1. Indledning...3 2. Fællesoffentligt samarbejde

Læs mere

Fra hvidbog til rammearkitektur FDA konferencen v Michael Bang Kjeldgaard

Fra hvidbog til rammearkitektur FDA konferencen v Michael Bang Kjeldgaard FDA2018 2 Fra hvidbog til rammearkitektur FDA konferencen 2018 v Michael Bang Kjeldgaard Agenda Strategi Begreber Indhold Anvendelse Styring 3 4 FDA Rammearkitekturs rolle Understøtte fælles forretningsmål

Læs mere

Kommunale cases: Frederiksberg & VeRA. Marius Hartmann It og forretningsarkitekt Frederiksberg kommune

Kommunale cases: Frederiksberg & VeRA. Marius Hartmann It og forretningsarkitekt Frederiksberg kommune Kommunale cases: Frederiksberg & VeRA Marius Hartmann It og forretningsarkitekt Frederiksberg kommune Frederiksberg Det eksisterende systemlandskab af ikkerammearkitektur kompatible systemer vil være et

Læs mere

Kort om Umbrella. Den 6. oktober 2009. 1. Umbrella

Kort om Umbrella. Den 6. oktober 2009. 1. Umbrella Den 6. oktober 2009 Kort om Umbrella 1. Umbrella Umbrella er et fælleskommunalt samarbejde om udvikling af digitale selvbetjeningsløsninger. De udviklede løsninger skal sikre en videreudvikling af borgerservicen

Læs mere

SAPA ARKITEKTURRAPPORT. Kommunernes it-arkitekturråd 8. maj 2014 DCH & KMJ

SAPA ARKITEKTURRAPPORT. Kommunernes it-arkitekturråd 8. maj 2014 DCH & KMJ SAPA ARKITEKTURRAPPORT Kommunernes it-arkitekturråd 8. maj 2014 DCH & KMJ Indstilling Det indstilles, at arkitekturrådet drøfter, om: - Rapportens omfang og indhold er dækkende - SAPA-løsningens brug af

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

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

Udarbejdelse af strategier for hændelsesorientering

Udarbejdelse af strategier for hændelsesorientering Udarbejdelse af strategier for hændelsesorientering En vejledning til kommunernes og ATP s opgaver Version 1.0 februar 2015 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk

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

INFORMATIONSDAGE ARKITEKTUR ARKITEKTUR. Kaare Pedersen, Projektchef, KL,

INFORMATIONSDAGE ARKITEKTUR ARKITEKTUR. Kaare Pedersen, Projektchef, KL, ARKITEKTUR Kaare Pedersen, Projektchef, KL, kaa@kl.dk Agenda Rammearkitekturprogrammet Det fællesoffentligt arkitekturarbejde HVORFOR ARKITEKTUR? Mindst fire gode grunde 1. Monopolbrud og leverandør lock

Læs mere

Bilag 7: Udkast til fælleskommunale arkitekturprincipper, version 1.0

Bilag 7: Udkast til fælleskommunale arkitekturprincipper, version 1.0 Bilag 7: Udkast til fælleskommunale arkitekturprincipper, version 1.0 (Bilag til dagsordenspunkt 10, fælleskommunale arkitekturprincipper) Pr. 20. februar 2013 (OBS: Korrektur udestår) (Version rettet

Læs mere

Styregruppen for data og arkitektur. Reviewrapport for: Referencearkitektur for deling af data og dokumenter (RAD)

Styregruppen for data og arkitektur. Reviewrapport for: Referencearkitektur for deling af data og dokumenter (RAD) Styregruppen for data og arkitektur Reviewrapport for: data og dokumenter (RAD) Indhold Arkitekturreview (scopereview) af referencearkitektur for deling af data og dokumenter 2 Reviewgrundlag 2 Projektresume

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

Arkitekturrapport: Standard for indbetalinger

Arkitekturrapport: Standard for indbetalinger Arkitekturrapport: Standard for indbetalinger Denne orienteringsrapport udarbejdes for it-projekter med effekt på den fælleskommunale rammearkitektur. Rapporten ejes af projektets it-arkitekt. Det er projektlederens

Læs mere

Arkitekturrapport: Kommunernes Sygedagpengesystem

Arkitekturrapport: Kommunernes Sygedagpengesystem Bilag 3: Arkitekturraport KSD. (Bilag til dagsordenspunkt 7: Arkitekturrapport for Kommunernes Syge-Dagpenge system (KSD)). Arkitekturrapport: Kommunernes Sygedagpengesystem Denne orienteringsrapport udarbejdes

Læs mere

Den fællesoffentlige digitale arkitektur Rammearkitektur (UDKAST) FDA-Talk 30. januar 2018

Den fællesoffentlige digitale arkitektur Rammearkitektur (UDKAST) FDA-Talk 30. januar 2018 1 Den fællesoffentlige digitale arkitektur Rammearkitektur (UDKAST) FDA-Talk 30. januar 2018 AGENDA RUNDT OM FDA RAMMEARKITEKTUR Strategi og styring Indhold og metode Anvendelse og værdi Status og næste

Læs mere

SKI 02.19. Version 1.0

SKI 02.19. Version 1.0 SKI 02.19 Version 1.0 23. maj 2015 1 Indhold Indledning... 3 Snitfladernes etablering og tilgængelighed... 3 Integrations- og anvendervilkår... 3 Beskrivelse af KOMBITs snitfladeoversigt... 4 Faneblad:

Læs mere

Lokal og digital et sammenhængende Danmark. Søren Frederik Bregenov, konsulent, KL Maj konference 21. maj 2015

Lokal og digital et sammenhængende Danmark. Søren Frederik Bregenov, konsulent, KL Maj konference 21. maj 2015 Lokal og digital et sammenhængende Danmark Søren Frederik Bregenov, konsulent, KL Maj konference 21. maj 2015 1 Disposition 1. Det nuværende strategilandskab -Fælleskommunale, fællesoffentlige, fagspecifikke

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

KOMBITs arbejde med it-arkitektur

KOMBITs arbejde med it-arkitektur KOMBITs arbejde med it-arkitektur Fælleskommunal rammearkitektur Mette Kurland, KOMBIT 29.09.2011 KOMBIT/Fælleskommunal rammerarkitektur 1 Rammearkitektur ift. KOMBITs mission Forhandlingskraft Effektivisering

Læs mere

STØTTESYSTEMERNE NØGLEN TIL NYE MULIGHEDER OG FREMTIDENS SAGSBEHANDLING

STØTTESYSTEMERNE NØGLEN TIL NYE MULIGHEDER OG FREMTIDENS SAGSBEHANDLING Bilag 8 seneste version af grundfortællingen Pkt. 11 Grundfortælling om støttesystemer STØTTESYSTEMERNE NØGLEN TIL NYE MULIGHEDER OG FREMTIDENS SAGSBEHANDLING 1 HISTORIEN BAG STØTTESYSTEMERNE KMD har monopol

Læs mere

Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer

Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer UdbudsVejledning Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog,

Læs mere

Kvalitative målepunkter til effektmåling af den fælleskommunale rammearkitektur

Kvalitative målepunkter til effektmåling af den fælleskommunale rammearkitektur Bilag 8 Punkt 13 Kvalitative målepunkter til effektmåling af den fælleskommunale rammearkitektur Juni 2017 Revision. Skat. Rådgivning. Overblik over kvalitative målepunkter # Målepunkt 1 Bedre betingelser

Læs mere

LOKAL OG DIGITAL - ET SAMMENHÆNGENDE DANMARK

LOKAL OG DIGITAL - ET SAMMENHÆNGENDE DANMARK V. PIA FÆRCH (PAH@KL.DK) KONTORCHEF, KL 1 FÆLLESKOMMUNAL DIGITALISERINGSSTRATEGI 2016-2020 UDGANGSPUNKT FOR DEN NYE STRATEGI Den fælleskommunale digitaliseringsstrategi 2011-2015 Fælles beslutnings- og

Læs mere

SAPA - spørgsmål & svar for beslutningstagere

SAPA - spørgsmål & svar for beslutningstagere SAPA - spørgsmål & svar for beslutningstagere Erstatter vi ikke bare et monopol med et andet? Nej. Vi vil kombinere en række forskellige nye og eksisterende it-løsninger, som hver især kræver flere forskellige

Læs mere

Fra specifikation til anskaffelse

Fra specifikation til anskaffelse 10. juni 2015 Fra specifikation til anskaffelse Ny løsning XX www.rammearkitektur.dk Hvordan kommer vi fra papir til den konkrete digitale løsning? Hvordan får kommunen værdi ved at bruge og bidrage til

Læs mere

EDS Lå n til betåling åf ejendomsskåtter processer, regler og informåtion

EDS Lå n til betåling åf ejendomsskåtter processer, regler og informåtion EDS Lå n til betåling åf ejendomsskåtter processer, regler og informåtion Indhold 1. Indledning... 1 Rapportens indhold... 1 2. Kontekst for ansøgning om lån til ejendomsskat... 3 Livssituationer... 3

Læs mere

Aftale om konkretisering af det fælles brugerportalinitiativ for folkeskolen

Aftale om konkretisering af det fælles brugerportalinitiativ for folkeskolen Undervisningsministeriet Finansministeriet KL Ministeriet for Børn, Ligestilling, Integration og Sociale Forhold Økonomi- og Indenrigsministeriet Aftale om konkretisering af det fælles brugerportalinitiativ

Læs mere

Automatisering og datakvalitet i it-systemer

Automatisering og datakvalitet i it-systemer RIGSARKIVETS KONFERENCE 2017 - KVALITET I OFFENTLIGE FORVALTNINGSDATA Automatisering og datakvalitet i it-systemer Hvad betyder kvaliteten, når borgeren skal have adgang til egne sager? Henrik Brix, Favrskov

Læs mere

OS2KITOS. Kommunernes IT OverbliksSystem

OS2KITOS. Kommunernes IT OverbliksSystem OS2KITOS Kommunernes IT OverbliksSystem Formål Leverancer Succeskriterier Moving target, men som de langt hen ad vejen er blevet kommunikeret indtil nu! Idé Fælles kommunal digitaliseringsstrategi Indsatsområde

Læs mere

Evaluering af Kommunernes It-Arkitekturråd. Succeskriterier for arbejdet det første år Plan for evaluering

Evaluering af Kommunernes It-Arkitekturråd. Succeskriterier for arbejdet det første år Plan for evaluering Evaluering af Kommunernes It-Arkitekturråd Succeskriterier for arbejdet det første år Plan for evaluering Phn, 22. februar 2012 Baggrund Sekretariatet iværksætter i 2012 en evaluering af rådets arbejde

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

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

Læs mere

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

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

Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunal støttesystemer 3. september 2013 Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunal støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog, der vejleder

Læs mere

Arkitekturrapport: YDELSESREFUSION

Arkitekturrapport: YDELSESREFUSION Arkitekturrapport: YDELSESREFUSION Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af projektets arkitekt (Erling Hansen).

Læs mere

Introduktion til Klassifikation

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

Læs mere

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform Løsningsbeskrivelse Den fælleskommunale Serviceplatform Januar 2014 1 Indhold 2 Serviceplatformen... 2 3 Hjemmesiden www.serviceplatformen.dk... 3 3.1 Administrationsmodul... 4 3.2 Servicekatalog... 4

Læs mere

Bilag 8: Program for temadag. Bilag til dagsordenspunkt 13: Temadag om arkitekturstyring Revideret pr. 10. september 2013

Bilag 8: Program for temadag. Bilag til dagsordenspunkt 13: Temadag om arkitekturstyring Revideret pr. 10. september 2013 Bilag 8: Program for temadag Bilag til dagsordenspunkt 13: Temadag om arkitekturstyring Revideret pr. 10. september 2013 Tidspunkt Strategisk spor Fælles spor Specialist spor Tidspunkt 10.00-10.15 Velkomst

Læs mere

Programbeskrivelse - Sammenhængende Digital Borgerservice. 1. Formål og baggrund NOTAT

Programbeskrivelse - Sammenhængende Digital Borgerservice. 1. Formål og baggrund NOTAT Programbeskrivelse - Sammenhængende Digital Borgerservice 1. Formål og baggrund Den digitale service skal gøre det lettere at være borger og virksomhed i Danmark. De skal opleve nærhed og sammenhæng i

Læs mere

IT-arkitekturstyring i Syddjurs Kommune

IT-arkitekturstyring i Syddjurs Kommune IT-arkitekturstyring i Syddjurs Kommune Arkitekturprincipper 1. Skab sammenhængende digitale oplevelser for borgere og virksomheder 2. Forretningens behov skal drive og definere løsningerne 3. Understøt

Læs mere

Arkitekturrapport: FÆLLES SPROG III

Arkitekturrapport: FÆLLES SPROG III Bilag 5: Arkitekturrapport fra projektet Fælles Sprog III (Bilag til dagsordenspunkt 6: Arkitekturrapporten). Arkitekturrapport: FÆLLES SPROG III Denne orienteringsrapport udarbejdes for it-projekter med

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

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

Kommissorium for Digital Robust Arkitektur

Kommissorium for Digital Robust Arkitektur Digital Robust Arkitektur Kommissorium for Digital Robust Arkitektur 1. Motivation/baggrund for programmet Arkitekturprogrammet er et program som udspringer af den Fælles offentlige digitaliseringsstrategi.

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

Effektiv digitalisering. - Digitaliseringsstyrelsens strategi 2012-2015. April 2012

Effektiv digitalisering. - Digitaliseringsstyrelsens strategi 2012-2015. April 2012 April 2012 Effektiv digitalisering - Digitaliseringsstyrelsens strategi 2012-2015 Baggrund Danmark står med væsentlige økonomiske udfordringer og en demografi, der betyder færre på arbejdsmarkedet til

Læs mere

It- og digitaliseringsstrategi. Sønderborg Kommune

It- og digitaliseringsstrategi. Sønderborg Kommune It- og digitaliseringsstrategi Sønderborg Kommune 2017-2020 Indhold Baggrund 3 Rammerne 3 Mål og Tema 3 Hvordan arbejder vi med målsætningen? 4 Illustration af elementerne i it- og digitaliseringsstrategien

Læs mere

Politik for Elektronisk Sags- og dokumenthåndtering Godkendt af Styregruppen for edoc

Politik for Elektronisk Sags- og dokumenthåndtering Godkendt af Styregruppen for edoc Politik for Elektronisk Sags- og dokumenthåndtering Godkendt af Styregruppen for edoc Politik for Elektronisk Sags- og Dokumenthåndtering i Region Nordjylland (ESDH) Lovgivning/aftalegrundlag Politikken

Læs mere

ATP s digitaliseringsstrategi 2014-2018

ATP s digitaliseringsstrategi 2014-2018 ATP s digitaliseringsstrategi 2014-2018 ATP s digitaliseringsstrategi samler hele ATP Koncernen om en række initiativer og pejlemærker for digitalisering i ATP. Den støtter op om ATP Koncernens målsætning

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

Læsevejledning til review af støttesystemer, marts 2013

Læsevejledning til review af støttesystemer, marts 2013 Læsevejledning til review af støttesystemer, marts 2013 Kommunerne ønsker en fælleskommunal rammearkitektur, der kan understøtte digitaliseringen og åbne for konkurrence på det kommunale it-marked. Rammearkitekturen

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

Ikast-Brande Kommune Vision for digitalisering og velfærdsteknologi

Ikast-Brande Kommune Vision for digitalisering og velfærdsteknologi Ikast-Brande Kommune Vision for digitalisering og velfærdsteknologi 2016-2020 Godkendt af byrådet den 13.03.2017 Indhold Indledning... 3 Vision... 3 Strategiske fokuspunkter Digital kultur, kompetence

Læs mere

UNDGÅ DÅRLIGE IT-LØSNINGER

UNDGÅ DÅRLIGE IT-LØSNINGER UNDGÅ DÅRLIGE IT-LØSNINGER ARKITEKTURPRINCIPPER 1. Skab sammenhængende digitale oplevelser for borgere og virksomheder 2. Forretningens behov skal drive og definere løsningerne 3. Understøt digitalt samarbejde

Læs mere

Axapoint Reviewkommentar til MOX-specifikation Version 0.76 - udarbejdet af It-arkitekturrådets arbejdsgruppe

Axapoint Reviewkommentar til MOX-specifikation Version 0.76 - udarbejdet af It-arkitekturrådets arbejdsgruppe Axapoint ApS Brunhøjvej 8, st. tv DK-8680 Ry Tel. +45 23 10 83 44 CVR nr. 32 15 37 98 info@axapoint.com www.axapoint.com Bank: Danske Bank. www.axapoint.com MOX-review Axapoint Reviewkommentar til MOX-specifikation

Læs mere

INGER TÆLL OR TIDSF FREM

INGER TÆLL OR TIDSF FREM FREMTIDSFORTÆLLINGER Når jeg står i en særlig livssituation, får jeg automatisk information, råd og vejledning fra min kommune, så jeg ikke behøver kontakte kommunen unødigt. FREMTIDSFORTÆLLING BORGEREN

Læs mere