(It-)principper

Beskrivelse

Dokumentation af it-principper, der understøtter de vigtigste egenskaber ved den fremtidige arkitektur.

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

Principperne må gerne inddeles i emner - fx efter OIO EA reolens overordnede struktur eller i underemner som applikationer og integrationer, service-orientering, information og data, teknologi, it-organisation og generel tilgang til arkitektur.

I en EA sammenhæng er det isæ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. 

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.

Løsaningsprojekter bør frembringe en liste over relevante principper og forklare hvordan de følger disse eller hvordan de eventuelt 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.

 

Permanent URL til denne artikel: http://arkitekturguiden.digitaliser.dk/node/186