Forklaring av prinsipper for integrasjonsarkitektur

Prinsipper for integrasjonsarkitektur, med forklaring og oppsummering av konsekvenser.

Brukerorientert: Arkitekturen skal endres i takt med brukerbehov

Arkitekturen er formgivende for tjeneste- og systemlandskapet, som igjen skal gjenspeile hva brukerne trenger. Stadige endringer er normaltilstanden. Derfor må arkitekturen være fleksibel, slik at den kontinuerlig kan tilpasses brukermassens skiftende behov. Brukerinteressene ivaretas og prioriteres av et prioriteringsråd (Prioriteringsråd).

Ettersom anskaffelser skal være kompatible med arkitekturen vil arkitekturen være formgivende for tjeneste- og systemlandskapet. Arkitekturen skal besørge at anskaffelser ivaretar brukernes behov. Prioriteringsråd skal opptre på vegne av brukermassen, og ta beslutninger når behov må prioriteres opp mot hverandre.

Konsekvens:

  • Prioriteringsråd skal prioritere mellom fagområder pva. UiOs brukermasse.
  • Prioriteringsråd vil behandle saker der fagavdelinger mangler myndighet eller oversikt til selv å kunne ta en beslutning
  • Prioriteringsråd vil behandle saker som eskaleres som følge av alle typer uenighet relatert til integrasjonsarkitektur
  • Prioriteringsråd vil behandle tvister mellom IT og eier ved nye anskaffelser og kan godkjenne avvik fra arkitekturen
  • Prioriteringsråd vil eskalere til SKAIT i spørsmål utover deres delegerte myndighetsområde
  • Erfaringer skal deles. Det skal gis feedback både på hva som er bra, og hva som ikke fungerer - eller hva som kunne vært bedre.

Tjenesteorientert: Integrasjoner skal benytte løse koblinger

Integrasjonsgrensesnitt skal utformes slik at tjenester og bakenforliggende systemer kan flyttes og byttes ut uten at konsumenter av tjenesten må gjøre endringer i sin ende, og omvendt.

At to entiteter er løst koblet betyr at de to entitetene samhandler, men man kan endre den ene komponenten uten at dette medfører at man må gjøre endringer i den andre. Det omvendte av løse koblinger er tette koblinger, og disse fordrer at det gjøres endringer, ofte kostbare, i begge entiteter. Ofte må begge byttes om den ene byttes. Løse og tette koblinger er ideelle tilstander, i praksis vil det være grader av løs kobling. Løse koblinger er det mest grunnleggende verktøyet man har for å gjøre integrasjoner endringsdyktige.

Konsekvens:

  • Prinsippet om løse koblinger legger føringer på hvilken programvare UiO skal anskaffe, samt hvordan vi organiserer arbeidet med integrasjon.
  • Ved alle innføringer og endringer av integrasjoner skal det gjøres en faglig vurdering av hvorvidt ønsket løsning er i henhold til prinsippet om løse koblinger.
  • Det er eiers ansvar at integrasjonsgrensesnittet er løst koblet til bakenforliggende system, slik at dette kan endres med minst mulig forstyrrelse for konsumentene av tjenestens data.

Tilgjengelig: Autoritative data skal tilbys gjennom åpne grensesnitt

Eier har ansvar for at data som flere har behov for tilgjengeliggjøres for virksomheten. 'Åpne grensesnitt' betyr her at det skal velges en bransjestandard og leverandøruavhengig teknologi. For tiden er Web Services det teknologisk foretrukne valget av grensesnitt. Eier er også ansvarlig for at delte data er komplette og riktig formatert, og at oppetid og responstid er tilpasset behovet.

Eier er ansvarlig å tilgjengliggjøre sine autoritative data når det finnes planer for bruk av disse, ikke fra dag 1. Fra dag 1 skal det derimot være dokumentert hvilke grove kategorier av data systemet er autoritativt for, slik at man unngår å komme i en situasjon hvor det anskaffes et annet system som produserer til forveksling like data.

Konsekvens:

  • Det er eiers plikt å tilgjengeliggjøre sine data, og foretrukket teknologi er Web Service. Kommer ikke systemet med egne, eller disse er ufullstendige, må anskaffer påregne kostnader for å få utviklet Web Service
  • Eier er ansvarlig for dataenes kvalitative innhold. Delte data må kunne behandles maskinelt, det er derfor essensielt at datakvaliteten er pålitelig. Dette betyr at det stilles krav til eier om at data er komplett og riktig formatert.
  • Eier er ansvarlig for at å sørge for et nivå av tilgjengelighet som er tilpasset behovet. Dette betyr at det stilles krav til eier om responstid og oppetid.
  • Eier er ikke pliktig til å lage ferdige, spesialtilpassede uttrekk mht. konsumentens ønsker, men er ansvarlig for å tilby alle delte data i funksjonelle uttrekk
  • Eier står fritt til å gjøre arbeidet selv eller sette det bort til tredjepart (USIT er i denne situasjonen en tredjepart på linje med kommersielle aktører)
  • Tjenester og systemer skal kun tilby autoritative data. Unntaket for dette er typiske nøkler eller ID-er man benytter for å kunne identifisere entiteter (f.eks, fødselsnumre, brukernavn, gruppe-ID-er, mm.)
  • Eier er ansvarlig for å forklare hvordan dataene skal tolkes mht. innhold (semantikk, semantiske meta-data) i sitt system. Det er foretrukket at dataens semantikk blir i størst mulig grad bevart, men om konsument benytter dataene i en kontekst som endrer dataens semantiske innhold, står konsument ansvarlig for dataens innhold i sin tjeneste

Oversiktlig: Tjenester skal registreres og dokumenteres

UiOs tjenesteportefølje (Service Portfolio) skal ha oppdaterte og fullstendige opplysninger om UiOs tjenester. Dette gir god oversikt over eksisterende tjenester, noe som forenkler prosessen med å integrere nye og endre eksisterende tjenester, samt forhindrer at vi anskaffer flere tjenester som produserer til forveksling like autoritative data, uten at det er tydelig hva som er lagret hvor.

Konsekvens:

Eier skal dokumentere/registrere/lenke opp følgende i tjenesteporteføljen:

  • Hvem som er ansvarlig og hvem som forvalter tjenesten 
  • Hvilke kontaktpunkter som skal benyttes
  • Kontrakter som SLA og databehandleravtale
  • Integrasjonsgrensesnitt, autoritative data og deres kategorier og betydning
  • USIT er ansvarlige for tjenesten SP og skal inneha rollen porteføljeansvarlig som har ansvar for og overseer porteføljen.

Etterrettelig: Tilganger skal registreres

Access Manager er programvare for å standardisere hvordan tilgangsforvaltere oppretter, fornyer og avvikler tilgang til data. Motivasjonen for en sentral tjeneste for avtaler mellom systemer er å gi økt brukervennlighet og etterrettelighet, samt effektivisere tilgangsprosessen.

Informasjonsbehandling og -utveksling er lovregulert gjennom lovverk som forvaltningsloven, personopplysningsloven, eForvaltningsforskriften osv. Access Manager hjelper UiO med å oppfylle lover og forskrifter for statlige virksomheter.

Konsekvens:

  • Det er eiers ansvar å gi tilgang til sine data
  • Tilgangskontroll skal gis gjennom en brukervennlig selvbetjeningsløsning, slik at eier selv kan gi tilganger uten krav om dyp teknisk IT-kunnskap.
  • ​Det er USIT's ansvar at et slikt brukergrensesnitt for å gi tilganger til data foreligger.
  • For sammensatte uttrekk gjennom UiOs ESB er USIT delegert myndighet til å inngå databehandleravtaler pva. produsentene.

Fleksibel: Kost-/nyttevurderinger kan legitimere avvik

Arkitekturen har som mål å kutte kostnader, få ned leveringstid, bedre endringsevne, og øke nytteverdi og brukerkvalitet. Det finnes derfor tilfeller der formkrav bør bortfalle,

Et eksempel på dette er at leverandørspesifikk integrasjon mellom systemer iblant kan være et bedre valg enn åpne alternativer.

Konsekvens:

  • Kost/nytte må her sees i hele livsløpet til en tjeneste
  • Begrunnelsen for avviket skal dokumenteres i tjenesportefølje
  • Tilstrekkelig fleksibilitet til at regler ikke står i veien for at man kan velge de totalt sett beste løsningene
  • Kravet om å tilgjengeliggjøre autoritative data bortfaller aldri, så lenge andre kan vise til et behov for disse dataene
  • Unntak gjør at vi lærer hva som fungerer og hva som ikke gjør det, og gir oss mulighet til å endre arkitekturen så den gir de riktige incentiver og virker etter intensjon

Effektiv: Tjenestebuss skal forhindre dobbeltarbeid

I noen sammenhenger er det effektivt å ha et knutepunkt (tjenestebuss) for flere bakenforliggende tjenester. Endringer kan reduseres til å gjøres i, eller i forholdet til, tjenestebuss.

Arkitekturen åpner for at det skal bli enklere for konsumenter å integrere med hver enkelt produsent. Gjennom kravet om at eier kun skal tilby sine autoritative data, så flyttes ansvaret for å flette sammen ulike data til konsumenten. Et eksempel på en slik sammensatt spørring kan være: "Gi meg alle brukere på UiO".  Om spørringen kan gjenbrukes på tvers av tjenester er det lite kostnadseffektivt både teknisk og administrativt at hver konsument må gjøre mer eller mindre overlappende integrasjoner. Tjenestebussen skal komme dette problemet i forkjøpet.

Konsekvens:

  • Tjenestebuss skal benyttes for gjenbruk, jfr. eksempel om "Gi meg alle brukere på UiO"
  • Tjenestebuss skal benyttes ved forenkling, som f.eks. kan være at når data (som passord) skal være konsistente gjennom flere systemer, er det tjenestebussen  som holder orden på hvor dataene finnes og varsler eller distribuerer endringer; tjenestene vet ikke om hverandre, de forholder seg kun til tjenestebussen.
  • USIT, som UiOs sentrale IT-organ, skal være ansvarlige for UiOs tjenestebuss.
  • Sammensatte uttrekk skal behovsprøves - det er nærmest et uendelig antall kombinasjoner av sammensatte data, så behov dikterer hva som blir prioritert
  • Tjenestebussen vil ha egne databehandleravtaler mot produsenter og konsumenter. Idet en databehandleravtale er inngått mellom tjenestebussen og en produsent, så vil tjenestebussen forvalte de data som inngår på vegne av produsenten. At en konsument klarer seg med en databehandleravtale mot tjenestebussen (som gjenbruker sine dataavtaler mot bakenforliggende parter) er altså både gjenbruk og forenkling

Veiledet: Ett enkelt kontaktpunkt for alle henvendelser om integrasjon

Integrasjon er et komplisert emne som involverer store deler av organisasjonen og derfor er tjenesten Kontaktpunkt etablert for å gjøre arkitekturarbeidet brukervennlig.

Integrasjoner er ofte innfløkte og krever kompetanse og deltagelse av mange gruppering: Noe skal utvikles, det skal på plass en databehandleravtale, løsningen skal ha stabil drift, være redundant og skalerbar, rettigheter skal delegeres, dokumentasjon skal produseres, og tjenesteportefølje skal oppdateres med planverk og budsjett. Endringer må koordineres mht. organisasjonens endringskapasitet og gjennomføringsevne. Slike kompliserte leveranser fordrer at noen har oversikt, kompetanse og kapasitet til å veilede. Dette gjøres mest effektivt ved at det er samlet i et enkelt kontaktpunkt.

Kontaktpunkt skal se til at integrasjon gjøres riktig og effektivt på UiO. Kontaktpunkt vil være en støttetjeneste som ikke selv påtar seg ansvaret for integrasjonene, men som har som ansvar å kunne følge opp og eskalere behov. Kompetansen i Kontaktpunkt skal ikke primært være teknisk, men organisatorisk. Kontaktpunkt skal sette innmelder i kontakt med de som kan gi svar. Kontaktpunkt har også et ansvar i å følge opp disse behovene.

Konsekvens:

  • USIT vil ha ansvaret for å tilby funksjonen Kontaktpunkt
  • Kontaktpunkt har kompetanse på semantisk bruk av termer i fagspråk. Kontaktpunkt bidrar derigjennom til at bestiller og leverandør ikke snakker forbi hverandre
  • Kontaktpunkt har kompetanse på retningslinjer, leveransepartnere og ansvarsområder mht. UiOs systempark
  • Kontaktpunkt kan opptre på bestillers vegne videre innover i leveransekjeden
  • Kontaktpunkt kan eskalere saker ved behov

 

Publisert 20. aug. 2015 12:23 - Sist endret 17. nov. 2015 15:19