Manifest: Styr på byggeklodserne DigITalisér 2010

Hvorfor skal vi have styr på byggeklodserne? Data, funktionalitet og processer konvergerer. Derfor kan ingen IT applikation betragtes isoleret. IT applikationer eksistere ikke på deres egne præmisser. De skal understøtte organisatoriske mål der rækker udover den enkelte applikations eller afdelings funktionsområde. Det er derfor nødvendig at vurdere applikationer i konteksten af den samlede organisations mål og formåen. Dette kræver at alle applikationer overholder fælles standarder for data, integration, procesunderstøttelse og brugergrænseflade. En applikations formål er at bibringe en organisation en kapacitet eller en formåen. Hvis IT applikationen enten ikke bibringer en formåen der bidrager med værdi der understøtter den fælles målsætning, eller hvis IT applikationen duplikerer formåen der allerede eksisterer, skal den ikke anskaffes. Applikationer må kun anvendes til det formål de er anskaffet.

Byggeklodserne Applikationer består af en række byggeklodser der hver især kan gavne den organisatoriske formål. Byggeklodserne er: Et datagrundlag Forretningsregler Stamdata Transaktionsdata Afledte (beregnede data) Applikationslogik De services applikationen skal levere Interne services Eksterne services Brugergrænseflade Grænseflader til andre systemer Defineret for hvert ”lag” i applikationen Brugerlag Bruger- grænse- flade 1 2 3 4 5 6 7 8 9 * # Applikationslag inkl. Integration Funktion som Service Funktion som Service MasterData Forvaltning Applikationslogik MetaData Forvaltning Datalag inkl. Integration MasterData services TransaktionsData Services MetaData Services MasterData TransaktionsData MetaData

Applikations Livscyklus Basalt set er der altid tre hovedfaser i en applikations liv:   Konstruktion eller anskaffelse Drift og vedligeholdelse Afvikling Etablering Konstruktion Implementering Drift Afvikling Udvidelse af funktionalitet Rettelse af systemfejl Platformsskift System- integration Ændring af forretningsregel Byggeklodserne skal understøtte alle faser:   Kun 10 til 20 procent af applikationens omkostninger er anskaffelse Rettelser og udvidelser er ofte besværlige fordi regler administreres i koden System integration bliver selvstændige udviklingsprojekter Afviklingen er ofte langvarig pga. hårde bindinger af data og integration

Datalaget Datalaget bør indeholde tre komponenter, der er logisk, men ikke nødvendigvis fysisk adskilt: MasterData (Fælles grunddata) MetaData (Parameterstyrede forretningsregler) TransaktionsData (Oprationelle data) Applikationen skal være i stand til at hente alle MasterData fra en autoritativ kilde. Applikationen må derfor ikke stille krav om, at MasterData kun skal vedligeholdes lokalt. Hvis MasterData vedligeholdes lokalt skal applikationen enten være autoritativ kilde til andre systemer eller synkronisere lokale opdateringer med en sådan. Applikationen skal være i stand til at eksportere sine transaktionsdata uden at dette kræver udvikling af specielt API. Dette inkluderer beregnede/afledte transaktionsdata og nødvendige referencer til både MasterData og Metadata. Applikationens MetaData (forretningsregler) skal være parameterstyret. Variable såsom grænseværdier, formelværdier eller konstante skal vedligeholdes i et lokalt MetaData lag. der skal kunne in- og eksportere til og fra en autoritativ kilde. Alternativt er applikationen autoritativ kilde til andre systemer. MasterData TransaktionsData MetaData MasterData services MetaData Services MasterData Forvaltning MetaData Forvaltning Applikationslogik Funktion som Service Brugergrænseflade TransaktionsData Services

Applikationslaget Applikationslaget indeholder tre komponenter der er funktionelt adskilt: Administration af MasterData (Option) Administration af MetaData Applikationslogik Administration af MasterData er en option, der kun skal findes såfremt der ikke findes en autoritativ kilde til MasterData i systemlandskabet ,eller hvis en kritisk forretningsproces fordrer, at MasterData skal kunne vedligeholdes lokalt. Administration af MetaData må i nogen udstrækning ske lokalt (ellers er applikationen redundant). Fælles MetaData (f.eks. momskoder, kontostruktur, o.l.) bør som MasterData findes i én fælles autoritativ kilde. Applikationslogikken skal indenfor rimelighedens grænser være parameterstyret. Al funktionalitet bør udstilles som services der kan integreres som komponenter i servicebaserede kompositte applikationer. MasterData TransaktionsData MetaData MasterData services MetaData Services MasterData Forvaltning MetaData Forvaltning Applikationslogik Funktion som Service Brugergrænseflade TransaktionsData Services

Brugergrænsefladen Brugergrænsefladen er præsentationslaget oven på de services som applikationen udstiller og andre eventuelle andre services der indgår. Der goder nogle grundlæggende regler for brugergrænsefladen: Den må ikke indeholde forretningslogik eller data Den må ikke afskære brugergrupper fra at anvende applikationen (f.eks. personer med handicaps (døve, farveblinde) Forskellige brugergrænseflader skal tilbyde samme funktionalitet Brugergrænsefladen skal være intuitiv og brugervenlig Hvis brugergrænsefladen er rettet mod borgere skal den være på målgruppens sprog (Dansk, Engelsk, Arabisk, Hindi o.l. efter behov) Import og eksport af information skal ske via åbne standardformater MasterData TransaktionsData MetaData MasterData services MetaData Services MasterData Forvaltning MetaData Forvaltning Applikationslogik Funktion som Service Brugergrænseflade TransaktionsData Services

3. Principper bag manifestet Følgende principper ligger til grund for manifestet MasterData og MetaData (forretningsregler) skal hentes fra en autoritativ kilde eller skal opdatere en autoritativ kilde. Rationale Hvis offentlige myndigheder ønsker at udstille ”sandheden” til borgere, virksomheder andre myndigheder og øvrige interessenter, er det nødvendigt med entydige definitioner af aktiviteter og aktiver. Data der er fragmenteret og vedligeholdt flere steder er ikke entydige. Redundant datafangst skaber fejl. Data og information er et af få aktiver, der kan kopieres og bruges flere gange … samtidigt. Derfor skal opsamling og administrationen af data kun gøres én gang. Arbejdsprocesser er tværgående. Selvom enkeltaktiviteter løses i en del af organisationen skal datagrundlaget være fælles. Fælles data støtter en fælles procesforståelse på tværs af enheder. Applikationer skal dele data og information med andre applikationer. Integration der betinger transformation af MasterData og MetaData cementerer IT arkitekturen i en rigid og ufleksibel struktur der forsinker og fordyrer opdateringer. Applikationer har en endelig levetid. Derfor må MasterData eller MetaData ikke ligge indlejret i applikationen (hverken i koden eller i database). Indlejrede data besværliggør og fordyrer udskiftning, fejlfinding, opdatering og afvikling.

3. Principper bag manifestet Applikationen skal still al funktionalitet og alle data til rådighed gennem standardisere services. Rationale Applikationer skal være agile. IT systemer skal facilitere arbejdsprocesser. Når en arbejdsproces ændrer sig må rigide IT systemerne ikke være en barriere. Ved at anvende standardiserede services kan applikationer tilpasses fleksibelt ved at inkludere eksterne services fra andre applikationer. Det er billigere at genbruge end at bygge parallel funktionalitet. Derfor skal applikationer udbyde deres funktionalitet i services der kan genbruges indgå i nye avancerede kompositte applikationer. Applikationer skal kunne fjernes fra systemlandskabet uden at der skal ændres i andre systemer. Ved at udbyde funktionalitet og data i standardiserede services, er det transparent for et klientsystem, at applikationen der udbyder en service er udskiftet, hvis den nye applikation overholder servicespecifikationen. Enkeltprojekter skal ikke bære ansvaret for manglende IT understøttelse af fælles MasterData, MetaData, ufleksibel proces-understøttelse eller efterfølgende omkostninger til integration.

3. Principper bag manifestet Applikationer skal fungere sammen og tage højde for integration til omverdenen og andre applikationer fra begyndelsen. Al integration skal være løst koblet. Rationale Applikationer der administreres og optimeres til aktiviteter i én forretningsmæssig silo har en høj risiko for at suboptimere den fulde forretningsproces. Integration er uundgåelig. Applikationer der ikke kan integreres via standardiserede grænseflader vil medføre en skjult ekstraomkostning til efterfølgende integration. Hvis der ikke anvendes en standardiseret integrationsmodel bliver systemlandskabet et virvar af individualiserede integrationer, hvilket forsinker og fordyrer opdateringer og vanskeliggør fejlrettelser. Faste koblede integrationspunkter betyder at en systemopdatering der påvirker integrerede data udløser udviklingsprojekter i samtlige integrationspunkter og systemer der modtager data. Idriftsættelse af nye systemer bliver hurtigere og mere smertefri, fordi et nyt system eller en opdatering sjældent påvirker andre systemer direkte.

Leverancer og forudsætninger - Flere byggeklodser For at sikre at et projekt kan levere applikationer der lever op til kravene i dette manifest skal så vel IT arkitekturen som projektet sikre en række forudsætninger og leverancer. IT arkitektoniske forudsætninger En global datamodel med entydige definitioner (MasterDate og MetaData) Politikker og regler for datamodellering Politikker og regler for dataintegration Politikker og regler for applikationsarkitektur En integrations arkitektur med skabeloner og standarder for servicekonstruktion En MasterData arkitektur med klare autoritative kilder En MetaData arkitektur med adskillelse af lokale og globale forretningsregler Obligatoriske projektleverancer i analysefasen En datamodel for applikationen der er synkroniseret med den globale datamodel En kortlagt forretningsproces for hele værdikæden En kravspecifikation En applikations arkitektur der er synkroniseret med de fælles politikker