Dokumentation der – afledt af forretningens strategier – fastlægger principper og politikker for brug af it i forretningen, med rationale og implikationer for disse.
Beskrivelse
Dokumentation af it-principper, inddelt i emner – fx applikationer og integrationer, service-orientering, information og data, teknologi, it-organisation, og generel tilgang til arkitektur.
I en EA sammenhæng er det i sær vigtigt at topledelsen beslutter principper på overordnet, generelt niveau.
Principper bør som minimum beskrives med rationale og implikationer. I en konkretisering vil dette bidrage til at præcisere hvordan det skal fortolkes i den givne sammenhæng.
Principper bør prioriteres og på overordnet niveau bør der typisk ikke være mere end 5-15 stykker. Bedst er det hvis de er så enkelt formuleret at de kan huskes udenad.
Er der mange principper vil det være en god idé at ordne dem hierarkisk i temaer.
Rationale
Principper er det samme som gode erfaringer.
Rationalet for at benytte sig af principper er, at det er et enkelt styringsinstrument. Hvis der er opsat principper for et område, så skal der god argumentation til, for at gå i mod princippet.
Implikationer
Udfordringen er, at principperne kan være formuleret, så de er svært at relatere til i det konkrete projekt. Derfor bør styringsmekanismen være, at hvert projekt selv fortolker om princippet skal finde anvendelse efter parolen – følg eller forklar.
Projektet skal frembringe en liste over principper og forklare hvordan de følger princippet og hvordan de evt. afviger. Dermed bidrager projektet med at gøre principperne stærkere eller svagere. Hvis man fraviger dette, vil principper være som skåltaler – uden nogen egentlig betydning.
På længere sigt vil principperne blive uddybet med alle projekters eksempler – og det er af uvurderlig værdi.
Eksempler
Dokumentation
Eksempel for X-købing Kommune:
It-princip: Alt data er som udgangs-punkt tilgængelig for alle.
Rationale: Jo bedre informerede medarbejderne er, jo bedre beslutninger tager de.
Konsekvenser: Det skal sikres at registerloven overholdes. Medarbejderne skal instrueres godt i hvilke politikker der er for omgang med data.
Versionering
Fællesoffentlige principper overordnet / generelt og versioneret indenfor et domæne: Dette eksempel er hentet fra de fællesoffentlige principper og fra referencearkitektur for stedbestemt information – begge dele kan du finde andetsteds her i arkitekturguiden. Her er udvalgt et generelt princip, som er konkretiseret i referencearkitekturen.
I det overordnede fællesoffentlige principper er nummer 4: “Data og services bør genbruges.”
I referencearkitekturen er dette præciseret i princip 2: “Geoobjekter indtastes kun én gang og tilgås ved kilden (Datagenbrug)”.
Styringsramme for myndighed
Eksempel fra SKATs arkitekturarbejde der belv udmøntet i 10 principper
Princip 1:
Brugergrænseflader skal være udskiftelige, adskilt fra resten af en IT-løsning, og skal kunne afvikles i flere relevante portaler.
Det betyder f.eks., at TastSelvs funktioner kan anvendes af brugere af andre portaler, eksempelvis VIRK.DK, og grafisk kan opdateres uden konsekvenser for den bagvedliggende funktionalitet.
Princip 2:
Services integreres til processer, forankret i ToldSkats procesmodel, bl.a. via procesmoduler, der kan styre procestrin og informationsudveksling, inkl. roller, ansvar, status og deadlines.
Det betyder f.eks., at når virksomheder skal kontrolleres, så sammensættes udsøgningsservices fra Datawarehouse med services fra et sagssystem (ESDH), som danner et brev med henblik på underretning af virksomheder.
Princip 3:
Brugbare funktioner, som er relevante for forretningen, skal tilgås som services. Services kan uanset teknologi skaleres, genbruges og sammenstilles til nye løsninger.
Det betyder f.eks., at servicen “angiv.moms”, der kommer fra DR, vil kunne genbruges af andre interne og eksterne IT-løsninger, så unødvendig nyudvikling undgås.
Princip 4:
Informationer fra grundsystemer udstilles som services – og evt. af ToldSkat Datawarehouse som kopi af hensyn til økonomi, performance eller historik.
Det betyder f.eks., at servicen “hent.personoplysninger” fra CSR-P, enkelt vil kunne gen-bruges af flere IT-løsninger, hvilket medfører at færre specielforbindelser skal vedligeholdes.
Princip 5:
Services skal udstilles i ToldSkats og OIOs servicekatalog, forankret i ToldSkats og OIOs begrebsmodel, med servicekvalitet og vilkår for anvendelse.
Det betyder f.eks, at ToldSkat har overblik over tilgængelige services og deres servicekvalitet. I OIOs servicekatalog kan eksterne få overblik over de services ToldSkat udstiller eksternt.
Princip 6:
Løsninger skal kunne rapportere til ToldSkats kvalitetssystem om f.eks. driftsforstyrrelser, servicekvalitet og ressourceforbrug, iht. ITIL mv.
Det betyder f.eks., at TastSelv vil rapportere, hvis to ud af ti brugere afvises i forbindelse med selvangivelse.
Princip 7:
Udviklingsmiljø og dokumentation, bl.a. procesmodel, begrebsmodel, use cases, program-kode og fysisk datamodel, skal via åbne grænseflader være tilgængeligt for ToldSkat og an-dre leverandører.
Havde ToldSkat adgang til brugbar arkitekturviden omkring hele systemkomplekset, ville ToldSkat i højere grad kunne sikre, at IT-ydelser blev indkøbt til markedspris.
Princip 8:
Systemkomplekset skal opdeles i områder der kan drives, vedligeholdes og optimeres uafhængigt af hinanden. Områderne skal defineres ud fra ToldSkats proces- og begrebsmodel.
Det betyder f.eks., at ToldSkat, f.eks. vedrørende afregning, vil kunne samle servicen “opret.konto” i et systemområde med én skattekonto.
Princip 9:
Løsninger skal genbruge ToldSkats løsningsmodeller og fælles infrastruktur til forskellige behov, bl.a. adgangskontrol og bruger-rollestyring (sikkerhedsmoduler), sagsbehandling (ESDH), kapitalforvaltning, Datawarehouse, samt omlægning af ældre mønstre (TS Tele, delt database, filer mv.).
Det betyder f.eks., at ToldSkat ved udvikling af ligningsområdet, vil kunne genbruge standardservices fra ESDH.
Princip 10:
Arkitekturen afklares iht. ToldSkats projektmodel og arkitekturprincipper, så den understøtter løsningens, ToldSkats og fælles-offentlige forretningsmål, samt relevante OIO-standarder mv., indenfor det økonomiske råderum.
Det betyder f.eks., at man inden færdiggørelse af et projektoplæg/-beskrivelse, har haft den krævede sparring, så projektet er optimeret både forretningsmæssigt og arkitektonisk.