Principper for IT-arkitektur IT-Arkitektur principperne er en formulering af de generelle principper, der gælder for digitaliseringen i Odense Kommune. Principperne skal sikre, at digitaliseringen i Odense Kommune følger: forvaltningernes behov, Odense Kommunes strategiske digitaliserings grundlag fællesoffentlige krav og standarder, best practice - bl.a. inden for IT-arkitektur Vi skal samtidigt bestræbe os på at gøre brug af og aktivt påvirke nationale standarder og principper. Forudsætning for principperne Odense Kommune prioriterer implementeringen af velafprøvede it-løsninger over forsøgsvis anvendelse af nyeste teknologi. Pilotprojekter og prototyper har dog sin berettigelse i afgrænsede forsøg, hvor der under kontrollerede former kan tages en kalkuleret risiko. Odense Kommune satser på indkøb af standardfagsystemer, som vi selv eller med hjælp fra systemleverandøren eller 3. part integrerer og sammenstiller, så de indgår i sammenhængende arbejdsprocesser. IT-investeringer er andet og mere end teknisk infrastruktur. Det er også en præcis behovsdækning og tæt koblet til den forretningsmæssige kontekst. Derfor betragtes IT og digitalisering som en strategisk investering i en optimal procesunderstøttelse, der skal give maksimal effektivitet og kvalitet i opgaveløsningen. Disse forudsætninger har som konsekvens, at Odense Kommune fokuserer på at understøtte Indkøb af IT-løsninger ud fra et godt forretningskendskab. Borger- og virksomhedsvendte IT-løsninger. Integration mellem IT-løsninger og sammenstilling af informationer (data) på tværs af systemer og portaler, ved hjælp af datawarehouse. Udnyttelse af nye teknologiske muligheder på en innovativ måde i opgaveløsningen. Overholdelse af lovgivning, eksterne krav og standarder. Flerleverandørstrategi, hvor løsningen, der bedst opfylder behovet, vinder. Prioritering, planlægning, gennemføring og evaluering af strategiske digitaliseringsprojekter. Nationale udviklingsprojekter via involvering og kvalificerede bidrag. Brug af principperne Principperne bør bruges i forbindelse med alle anskaffelser og ændringer af it-systemer. Principperne gælder ikke i drift satte systemer, men hvis det skønnes nødvendigt, kan IT-Afdelingen i samarbejde med den systemansvarlige gennemføre særlige tiltag, der har til formål at sikre, at også et eller flere af de nuværende systemer bringes til at overholde principperne. Med den systemansvarlige menes den person, der er ansvarlig for anskaffelsen/ændringen, hvad enten personen er projektejer, systemansvarlig eller it-kontaktperson. Denne person skal i god tid henvende sig til IT- Afdelingen og bede om en arkitekturmæssig vurdering af tiltaget. Vurderingen vil tage udgangspunkt i principperne. IT-Afdelingen har ansvar for at opdatere principperne løbende, så de opfylder kommunens behov for en helhedsorienteret tilgang til it-anvendelse, og så de er opdaterede. De 10 arkitekturprincipper De 10 principper er formuleret efter samme skabelon, idet de alle indeholder afsnittene Princip, r og.

Forretningsbehov i centrum Princip 1: "Forretningsbehov bør drive og definere løsningerne" Forklaring Løsningerne skal give mening for Odense Kommune set som forretning og ikke mindst for dem der ender med at bruge løsningerne. Er der f.eks. en positiv businesscase, når man ser på hele den samlede arbejdsgang? Indførelsen af en ny løsning kan isoleret set være en god idé, der gør at den konkret opgave løses bedre, men samlet set besværliggøre forretningsgangen, da andre opgaver bliver sværere at løse. Det kan f.eks. være fordi, at man i den nye løsningen er nødt til at skrive informationer ud på papir, for manuelt at taste dem ind i en gammel løsning, der bruger informationerne. Bl.a. for at forhindre sådanne situationer i at opstå, vælges der derfor it-løsninger, som ud fra en funktionel tilgang bedst muligt opfylder de forretningsmæssige behov, men som det samtidig er muligt at indpasse i forretningsgangen og it-arkitekturen. Der opnås ingen vellykket digitalisering, hvis ikke 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. 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.

Systemarkitektur Princip 2: Komponentopdelt og lagdelt arkitektur foretrækkes Der foretrækkes løsninger med en komponentopbygget og lagdelt arkitektur baseret på godkendte tekniske standarder. Hele eller dele af brugergrænsefladen skal kunne indgå i et effektivt samspil med Odense Kommunes løsninger. 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. Princippet indebærer i det lange løb et opgør med brugen af silosystemer, som kræver manuelle arbejdsgange, hvor medarbejdere bærer data fra system til system, fordi systemerne ikke snakker sammen som følge af, at det er for dyrt at integrere dem.

Integrationsmønstre Princip 3: Vi bruger gængse og standardiserede integrationsmønstre Hver gang der udvikles integration imellem it-løsninger skal det overvejes, om integrationen skal ske i form af integrationsmønsteret for serviceorienteret arkitektur (SOA) eller eventdrevet arkitektur (EDA). SOA er vigtig for Odense Kommune, fordi SOA-paradigmet indebærer en række strategiske fordele, når det bruges i de rette sammenhænge: Mulighed for genbrug af services isolation af forandringskomponenter adskillelse af grænseflade og implementering hurtig tilpasning til ændrede vilkår (agilitet) standardiseret samspil med eksterne parter mv. EDA har mange af de samme egenskaber og udmærker sig desuden ved løs kobling imellem afsendersystemer og modtagersystemer (publish/subscriber), hvor systemerne ikke har behov for kendskab til hinandens eksistens. SOA kræver stor grad af modenhed hos både kunde og leverandør. Til en start vil SOA derfor blive taget i brug på nogle få udvalgte nøgleområder, men udbredelsen kan øges i takt med, at der opbygges kompetencer og erfaringer internt og eksternt. EDA er relevant, hvor man ikke ønsker en tætkoblet point-to-point -integration, men en sideordnet ansvarsfordeling imellem systemerne. Når der sker en relevant forretningsmæssige hændelse meddeler systemet det, så andre systemer, der måtte have interesse i information om, at hændelsen er indtruffet, kan reagere på den. EDA-tankegangen kan bl.a. anvendes af fag- og ESDH-systemer til udstilling af advis er. 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, p.t. IT- og Telestyrelsen. Disse standarder omfatter bl.a. OIO REST for webservices og OIO Sag og Dokument (herunder standarden forretningsservice Organisation, som anvendes i APOS).

Dokumentation Princip 4: Dokumenterede arbejdsgangsbeskrivelser og grænseflader foretrækkes Arbejdsprocesser, begreber og grænseflader imellem it-løsninger skal som hovedregel være dokumenterede og defineret i overensstemmelse med relevante domænestandarder inden for det pågældende forretningsområde. Et højt dokumentationsniveau og en høj grad af standardisering af arbejdsgange, informationsenheder og grænseflader imellem systemer giver overblik over forretningsprocesser og tydeliggør dermed potentielle forbedrings- og effektiviseringsmuligheder. Det er vigtigt, at Odense Kommune holder sig ajour med det forretningsorienterede standardiseringsarbejde, der udføres fra centralt hold og drager nytte af dette for at sikre, at der bruges et fælles sprog på tværs af systemerne, hvilket vil lette integrationen af processer og systemer. Konkret kan det betyde at man skal benytte sig af standarderne, som er beskrevet i OIO og af KL - f.eks. KLs arbejdsgangsbank, den Fælles Offentlige Reference Model (FORM), Fællessprog, Sag/Dokument og MedComstandarder inden for sundhedsområdet.

Fælles teknologivalg Princip 5: Følg det strategiske teknologivalg og brug fælleskomponenter De strategiske teknologivalg skal følges for at opnå kvalitet og effektivitet via enkelhed, sammenhæng og stordrift. Fælleskomponenter skal som udgangspunkt altid anvendes, hvor der er behov for den funktionalitet, som de tilbyder. På en række områder er der truffet strategiske teknologivalg. Herunder både standardapplikationer og strategiske platforme og fælleskomponenter. Eksempler på aktuelle standardapplikationer: Microsoft Office til tekstbehandling, regneark og præsentation Notes til mail og kalender ProFile til ESDH ØS Indsigt til Økonomistyring SiteCore CMS til hjemmesider. Eksempler på strategiske systemplatforme: Windows som pc-platform Notes til informationsdatabaser SAS til Data Warehouse WebSphere som portalplatform. Eksempler på fælleskomponenter Odense Kommune arbejder aktivt på at realisere en række fælleskomponenter. Fælleskomponenter er afgrænset funktionalitet, som kan anvendes af flere løsninger, og som stilles bredt til rådighed i organisationen. Der findes både lokale og nationale fælleskomponenter: Data Warehouse LIS-portal APOS AD, TIM TAM ESSO CPR/CVR-opslag NemLogin Dokumentboks/NemSMS. Fælleskompontenter er et vigtigt led i Odense Kommunes arkitekturtilgang. I kraft af en nemmere og mere standardiseret anvendelse og udveksling af informationer og funktionalitet internt, og på tværs af myndigheder, stræber vi efter at aktivt opbygge sammenhæng og understøttelse af arbejdsprocesser. Både for applikationer, systemplatforme og fælleskomponenter skal der træffes beviste og helhedsorienterede systemvalg. Derfor skal der på linie med andre muligheder også overvejes it-løsninger inden for paradigmerne: Grøn it Cloud computing Open source. De strategiske teknologivalg følges af teknologigruppen. Gruppen fører en oversigt over de strategiske valg af software. Det er som udgangspunkt ikke tilladt at tage overlappende komponenter i brug på de områder, hvor der udbydes fælleskomponenter. I forbindelse med anskaffelser og ændringer af it-systemer skal Arkitektur- og konsulentteamet kontaktes for at sikre dette. Arkitektur- og konsulentteamet vedligeholder og publicerer løbende en liste over aktuelle fælleskomponenter. Yderligere informationer 10 ting at have tjek på inden du vælger (open source) software Sikkerhed i Cloud løsning Sådan sender fagsystemer sms'er med NemSMS

IT-sikkerhed Princip 6: Sikkerhed skal indgå i alle it-løsninger Sikkerhedsvurderinger indgår som et vigtigt element i forbindelse med it-anskaffelse og it-anvendelse. Odense Kommune satser målrettet på it-løsninger, hvor sikkerhedsaspektet er tænkt ind fra start til slut. Odense Kommune følger standarder inden for sikkerhed, der muliggør samarbejde på tværs mellem offentlige myndigheder og private aktører. For ethvert it-system skal der udpeges en it-systemansvarlig, som er ansvarlig for at gennemføre risikovurdering og vurdering om beredskabsniveauet samt overvejelser om brugeradministration, support og uddannelse. Vurderingerne skal ikke kun ske ved anskaffelse, men løbende og ved større organisatoriske ændringer.

Datawarehouse Princip 7: Datawarehouse skal bruges aktivt Data fra alle væsentlige fagsystemer stilles til rådighed i Odense Kommunes Datawarehouse, så de kan udnyttes på tværs og sammenstilles i nye sammenhænge. Odense Kommune anvender Datawarehouse til datamining (sammenstilling af data og præsentation af data i nye sammenhænge, herunder også mulighed for udarbejdelse af rapporter). Det betyder, at væsentlige systemer skal kunne aflevere deres data til Datawarehouset. En systematisk udnyttelse af relevante data fra fagsystemer vil bidrage til større kvalitet og effektivitet. Den systemansvarlige for fagsystemet har i samarbejde med Datawarehousefunktionen i IT-Afdelingen ansvaret for, at data fra fagsystemet stilles til rådighed. Udbredelsen af brugen af informationerne sker i de eksisterende faglige netværk. Ved alle nye it-anskaffelser og udbud skal der, som udgangspunkt, indgå krav til aflevering af data til Datawarehouse. Der kan være undtagelser, hvor det ud fra en forretningsmæssig vinkel vurderes, at data ikke skal afleveres. Det forretningsmæssige behov vurderes ud fra kommunens behov for sammenstilling af data.

Myndighedsudøvelse dokumenteres Princip: Overbliksdannelse og dokumentation af myndighedsudøvelse Al myndighedsudøvelse dokumenteres på én af følgende måder: 1. Der anvendes det ESDH-system, der tilbydes som generel løsning i Odense Kommune, Profile ESDH. 2. I de tilfælde, hvor et fagsystem har tæt tilknyttet ESDH-lignende funktionalitet, kan dette anvendes, under forudsætning af, at systemet udstiller tilstrækkelig oversigtsinformation og metadata på en standardiseret måde, så et samlet overblik over kommunes aktiviteter med borgeren kan skabes. Al myndighedsudøvelse skal som følge af lovkrav dokumenteres, hvilket sker i formelle ESDH-lignende systemer. Ét system kan dog ikke løse opgaven alene, men samtidig er det et højt prioriteret ønske, at der er sammenhæng imellem systemerne. Dette er begrundelsen for principperne a) og b) ovenfor. I nationalt perspektiv er det et faktum, at der eksisterer flere ESDH-lignende systemer i den kommunale IT-portefølje, og at rollen for ESDH de senere år har ændret sig meget, så ESDH ikke længere ses som systemet til alt, men derimod opfattes som en komponent rettet mod mere specifikke anvendelser. Disse forhold er indarbejdet i FESD 2 referencearkitekturen og i standarderne under OIO Sag og Dokument. Princippet indebærer, at relevante informationer fra systemer med ESDH-lignende funktionalitet skal kunne gøres tilgængelige til brug for ovennævnte formål. Kriterierne for, hvad der er relevant at gøre tilgængeligt, fastlægges i samarbejde mellem systemejeren og IT-afdelingen, Arkitektur- og konsulentteamet. Det afgørende er derfor, at systemerne kan: 1. Udstille deres information, og/eller 2. Aflevere informationer til Datawarehouse Konkret skal der skabes sammenhængende service til borgere og virksomheder hvilket kræver sammenhæng på de indre linier: Kommunens medarbejdere skal let kunne få overblik over en borgers, en virksomheds eller en matrikels mellemværender med kommunen på tværs af den organisering, som kommunens behandling af borgeren er opdelt i. Et middel hertil er sammenstillingsstrategien beskrevet i notatet "Det digitale Ansvar"2. Heri indgår elementer som portaler rettet mod bestemte brugere i bestemte sammenhænge, f.eks. en borgersagsportal SOA-forretningskomponenter, der kan vise/opdatere en afgrænset del af et fagsystem/esdh-system en informationsmæssig infrastruktur med mulighed for at foretage opslag i centrale registre: CPR, CVR, BBR etc. et solidt teknisk, sikkerhedsmæssigt og driftsmæssigt fundament i form af: den tekniske platform under portalerne sikkerhedsmæssige procedurer og komponenter (identitets- og adgangsstyring (IAM), ISO27001/logning) driftsprocedurer (ITIL), herunder change management, support, overvågning og beredskab Et væsentligt element i dette arbejde udføres af KOMBIT med kommunerne som aktive deltagere. KOMBIT arbejder i disse år med at sikre konkurrenceudsættelse af KMD's monopolområder, herunder etablering af snitflader fra og til KMD's fagsystemer. "Det digitale ansvar" kan læses på http://www.odense.dk/itarkitektur

Registrering af systemer Princip 9: Alle it-systemer skal registreres Der skal for alle it-systemer være registreret drifts- og kontaktinformation. Det primære formål for at registrere drifts- og kontaktinformation er at opretholde en sikker og veldokumenteret drift. Registreringen skal danne grobund for en serviceorienteret arkitektur (SOA), der kan bevirke sammenhængende processer og genbrug af løsninger. Den IT-systemansvarlige har ansvaret for, at IT-systemet er i overensstemmelse med lovgivningen og kommunens interne retningslinjer, herunder kommunens IT-arkitektur og drift. Den systemansvarlige skal sikre at systemer er registreret i Odense Kommunes it-systemdatabase. I de tilfælde hvor der skal installeres software på Odense Kommunes PC'er, skal registreringen i it-systemdatabasen suppleres med informationer om dette.

Brugervenlighed 10: Slutbrugerens behov skal tilgodeses mest muligt Slutbrugeren af et system kan både være en medarbejder i Odense kommune, eller en borger. Der bør derfor Brugerinvolvering kan medvirke til opnåelse af et mere succesfuldt resultat, bedre kvalitet og træfsikkerhed. Brugerens behov er vigtig for en fornuftig anvendelse af it-systemet, og implementering af it-systemet. Derfor skal brugervenligheden prioriteres. Det er i den daglige brug, at et it-system skal vise sit værd. De mere overordnede analyser af forretningsbehovet, som princip 1 lægger op til, bør suppleres med helt pragmatiske overvejelser, hvor itløsninger vælges, tilpasses eller udvikles på en måde, så slutbrugerne er en del af processen og bliver tilfredse med resultatet. repræsentanter for slutbrugere inddrages i udvikling og anskaffelse af de it-systemer de skal bruge der prioriteres it-systemer med en brugervenlig brugergrænseflade der kan med fordel arbejdes med prototyper, demonstrationer og tilpasninger til slutbrugernes behov.