IT-ARKITEKTURPRINCIPPER 2018

IT-ARKITEKTURPRINCIPPER 2018

5 It-arkitekturmål 5 Arkitekturprincipper Følg eller forklar Fælleskommunale arkitekturprincipper og -regler

IT-ARKITEKTURMÅL Billigere it Sammenhængende it Mere robust og sikkert it Leverandøruafhængighed Større fleksibilitet

5 OVERORDNEDE ARKITEKTURPRINCIPPER Forretningsbehov Forretningsbehov bør drive og definere løsningerne Komponentisering og lagdeling Standard integrationer Fælles teknologivalg Fælles data og begreber Komponentopdelt og lagdelt arkitektur foretrækkes Vi bruger gængse og standardiserede integrationsmønstre Samme opgave løses i samme it-system De fælles autoritative data skal anvendes af løsninger

Forretningsbehov Forretningsbehov bør drive og definere løsningerne Der vælges it-løsninger, som ud fra en funktionel tilgang, bedst muligt opfylder de forretningsmæssige behov, men som samtidigt er i overensstemmelse med Odense Kommunens it-strategi, følger de øvrige arkitekturprincipper, og leder frem mod det ønskede målbillede. Begrundelse Vellykket digitalisering opnås, når de forretningsmæssige behov tilgodeses i vid udstrækning. Samtidig er det også nødvendigt at sikre, at de tværgående processer understøttes fleksibelt og effektivt, så der ikke opstår enkeltstående løsninger og suboptimering. Konsekvenser Nye it-løsninger skal kunne bringes til at indgå i it-arkitekturen, og prisen herfor skal indregnes i den samlede investering der skal tænkes i hele processer. I forbindelse med overvejelse om indførelse af nye it-løsninger, skal der derfor - afhængig af omfang og art - ske en it-arkitekturmæssig helhedsvurdering af det planlagte tiltag. Projekter skal tage udgangspunkt i forretningsbehov og ikke i teknologi.

Komponentisering og lagdeling Komponentopdelt og lagdelt arkitektur foretrækkes Løsninger skal være komponentopbygget og med en lagdelt arkitektur baseret på godkendte tekniske standarder. Der indkøbes og bygges løsninger med henblik på genbrug. Begrundelse Hele eller dele af løsningen skal kunne indgå i samspil med andre løsninger i Odense Kommune. It-løsningens informationer og funktionalitet skal være tilrettelagt, så de vigtigste dele af systemets forretningslogik (funktionalitet) på enkel vis kan udstilles og indgå i andre sammenhænge, eller kan udskiftes/erstattes med andre komponenter. Konsekvenser Princippet indebærer i det lange løb et opgør med brugen af silosystemer, hvor ét system dækker alle funktioner inden for en organisation. I stedet sammensættes løsninger/komponenter målrettet de enkelte områder og data udveksles mellem de enkelte systemer. Inden genudbud af it-systemer, overvejes det hvorvidt systemet i udgangspunkt består af flere komponenter som realiseres selvstændigt.

Standard Integrationer Vi bruger gængse og standardiserede integrationsmønstre It-Integration mellem systemer skal ske i form af integrationsmønsteret for serviceorienteret arkitektur (SOA) eller hændelsesdrevet arkitektur (EDA). It-løsninger anvender fælles standarder og datamodeller. Begrundelse Integrationer mellem systemer giver mulighed for at skabe it-systemer der understøtter sammenhængende og effektive arbejdsgange for brugerne på tværs af systemer. Ved at benytte fælles standarder og datamodeller er integrationen enklere, og it-systemer mere sikre. Konsekvenser Løsningen skal have et veldokumenteret og tilgængeligt API som udstiller funktionalitet og data. Væsentlige forretningsmæssige hændelser skal meddeles til omkringliggende systemer. Ved den konkrete realisering af integrationsløsninger tilstræbes det naturligvis, at der anvendes de til enhver tid gældende standarder, som anbefales af den autoritative myndighed, f.eks. Digitaliseringsstyrelsen, KL eller Sundhedsdatastyrelsen. Integration mellem systemer sker point-to-point. SAS benyttes kun til integration med legacy systemer.

Fælles teknologivalg Samme opgave løses i samme it-system De strategiske teknologivalg skal følges for at opnå kvalitet og effektivitet via enkelhed, sammenhæng og stordrift. Den samme arbejdsopgave skal løses ved samme arbejdsproces med samme it-løsning uanset hvor i Odense Kommune opgaven udføres. Begrundelse På en række områder er der truffet strategiske teknologivalg. Herunder både standardapplikationer og strategiske platforme og fælleskomponenter. For at nedbringe drift og anskaffelses omkostninger og drage fordel af fælles udvikling skal eksisterende platforme og komponenter benyttes. Konsekvenser Det er ikke tilladt at tage overlappende komponenter i brug på de områder, hvor der udbydes fælleskomponenter eller der eksisterer andre komponenter med samme funktionalitet. I forbindelse med anskaffelser og ændringer af it-systemer skal det forinden være undersøgt om der allerede eksisterer lignende systemer, på dele af opgaven.

Fælles data og begreber De fælles autoritative data skal anvendes af løsninger Autoritative klassifikationer, data og begreber skal anvendes af it-løsningerne. Begrundelse Brug af fælles begreber og fælles data sikrer, at data er opdaterede, pålidelige og entydige. Dette giver lettere integrationer mellem systemer og overflødiggør dobbelt administration. Konsekvenser Nationale og fælleskommunale klassifikationer som KLE, STORM, FORM, SKS, IM Kontoplan skal anvendes. Fælles data som f.eks. CPR, CVR, BBR, DAR, FMK skal anvendes på tværs af systemer, direkte fra kilden. Fælles begrebsrammer som SNOMED, FS-III og socialebegreber.dk skal benyttes af itløsningerne. Odense Kommunes egne autoritative data som f.eks. kontoplan og AMMO benyttes såfremt der ikke findes nationale autoritative data. Identificeres der behov for autoritative klassifikationer på tværs af løsninger kan disse vedligeholdes i ét system, eller trækkes ud og vedligeholdes i egen løsning. It-løsninger skal benytte og udstille objekternes originale UUID er til identifikation på tværs af systemer.

FÆLLESKOMMUNALE ARKITEKTURPRINCIPPER OG -REGLER Princip 1: Arkitektur styres på rette niveau efter fælles rammer (styring) AR 1.1: Styr arkitekturen på rette niveauer og sammenhængende AR 1.2: Optimér arkitektur efter projektets og de fælles mål AR 1.3: Anvend fælles ramme for beskrivelse af arkitekturen AR 1.4: Sørg for review af projektets arkitektur AR 1.5: Hav tilstrækkelige kompetencer til arkitektur-arbejdet AR 1.6: Der er defineret entydigt ejerskab af byggeblokke (FK) Princip 2: Arkitektur fremmer sammenhæng, innovation og effektivitet (strategi) AR 2.1: Anvend og udbyg den fællesoffentlige arkitektur AR 2.2: Anvend åbne og internationale standarder AR 2.3: Undgå afhængighed af leverandører og proprietære teknologier AR 2.4: Byg med udgangspunkt i brugeren og forberedt til forandring AR 2.5: Stil data og løsninger til rådighed for private AR 2.6: Adskil det foranderlige fra det uforanderlige (FK) Princip 3: Arkitektur og regulering understøtter hinanden (jura) AR 3.1: Tag højde for juridiske bindinger i forhold til deling og genbrug af data og it-løsninger AR 3.2: Bidrag til digitaliseringsklar lovgivning Princip 4: Sikkerhed, privatliv og tillid sikres (sikkerhed) AR 4.1: Opfyld krav til informationssikkerhed og privatlivsbeskyttelse AR 4.2: Anvend fælles arkitektur for informationssikkerhed August 2018

FÆLLESKOMMUNALE ARKITEKTURPRINCIPPER OG -REGLER Princip 5: Processer optimeres på tværs (opgaver) AR 5.1: Design sammenhængende brugerrejser AR 5.2: Optimér tværgående processer efter fælles mål AR 5.3: Betydelige forretningshændelser skal kunne meddeles omverdenen (FK) Princip 6: Gode data deles og genbruges (information) AR 6.1: Del og genbrug data AR 6.2: Anvend fælles regler for dokumentation af data AR 6.3: Giv data den kvalitet som efterspørges AR 6.4: Udstil oplysninger om datakilder, begreber og datamodeller Princip 7: It-løsninger samarbejder effektivt (applikation) AR 7.1: Design og udstil snitflader efter fælles integrationsmønstre og tekniske standarder AR 7.2: Byggeblokke genbruges på tværs af it-løsninger (FK) Princip 8: Data og services leveres driftssikkert (infrastruktur) AR 8.1: Levér data og services i henhold til aftalte servicemål August 2018