Alle UH:IntArk sine prinsipper samlet på en side

TODO: Endre ved overgang til Uninetts docusaurus

Brukerorientert

Arkitekturen skal endres i takt med brukerbehov.

Bildet kan inneholde: grafikk, svart og hvit, symbol, utklipp.

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.

Ettersom anskaffelser skal være kompatible med arkitekturen vil arkitekturen være formgivende for tjeneste- og systemlandskapet. Arkitekturen skal sørge for 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 på vegne av sektoren.
  • 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 TBD 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.

Se også

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 teoretiske 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 vi 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 om ø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.

Se også

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 for å tilgjengeliggjøre sine autoritative data når det finnes planer for bruk av disse, men ikke fra dag én. Fra dag én 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 API-er, 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 med henhold til 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. Tredjepart kan både være interne ressurser i sektoren og kommersielle aktører.
  • Tjenester og systemer skal kun tilby data de er autoritative for. 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 med tanke på til innhold (semantikk, semantiske metadata) 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.

Se også

Oversiktlig

Tjenester skal registreres og dokumenteres.

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

Tilbudte data skal lenkes opp fra tjenestekatalog og registreres i et felles tjenesteregister for data. Dette vil i første omgang gjelde tjenester tilknyttet Sikker Datadeling.

Oversikten gjelder på sektorielt nivå, og ikke bare per institusjon.

TBD: Forholdet med Dataporten vil bli avklart i prosjekt Datadeling.

Konsekvens

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

  • Hvem er ansvarlig, og hvem forvalter tjenesten
  • Hvilke kontaktpunkter skal benyttes
  • Kontrakter, som SLA og databehandleravtale
  • Integrasjonsgrensesnitt, autoritative data og deres kategorier og betydning
  • Eier har ansvar for at grensesnitt er registrert i institusjonens API-katalog.

Se også

Etterrettelig

Tilganger skal registreres.

Sikker Datadeling (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. Sikker Datadeling hjelper oss med å oppfylle lover og forskrifter for statlige virksomheter.

Sikker Datadeling skal dekke tilgang til Web Services og Meldingskø (MQ)

TBD: Forholdet mellom Sikker Datadeling og Dataporten behandles i prosjekt Datadeling.

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.
  • TDB: ​Det er Units og/eller hver institusjons ansvar at et slikt brukergrensesnitt for å gi tilganger til data foreligger.
  • TBD: For sammensatte uttrekk gjennom sektorens ESB er Unit delegert myndighet til å inngå databehandleravtaler på vegne av institusjonene.

Se også

Fleksibel

Avvik er tillatt, så lenge det følger IntArks formål.

Tjenester og datadeling bør avvike fra IntArks krav og føringer hvis det er hensiktsmessig for sektoren eller institusjonen, som helhet.

IntArk skal gjøre datadeling enklere i sektoren, med formål om å blant annet gi bedre endringsevne, økt nytteverdi og bedre brukerkvalitet. Noen ganger kan IntArks krav være til hinder for formålet, for eksempel av økonomiske hensyn.

Merk at arkitekturen prioriterer hensynet til sektoren eller institusjonen over enkelttjenester. Selv om et valg kan være til det beste for sektoren, vil det kunne være til ulempe for en enkelttjeneste isolert sett.

Et eksempel er at det kan være hensiktsmessig å bruke en leverandørspesifikk integrasjon, hvis for eksempel kostnadene ved å innføre en løsere kobling blir høyere enn konsekvensene og risikoen for institusjonen ved å låse seg til en leverandør.

Konsekvens

  • Kost/nytte må her sees i hele livsløpet til en tjeneste, og i perspektiv av sektoren som helhet.
  • Avvik skal vurderes aktivt, og det er institusjonen og sektoren sine behov som helhet som bør ligge til grunn for avviket.

  • Begrunnelsen for avvik skal dokumenteres i tjenesteportefølje. TBD: Har vi dette i forvaltinga?

  • Kost-/nyttevurderinger kan legitimere avvik.
  • 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/avvik 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 insentiver og virker etter intensjon.

Effektiv

Unngå dobbeltarbeid ved å gjenbruke tjenester og innføre fellestjenester.

Sektoren og institusjonen bør gjenbruke tjenester, og vurdere innføring av nye tjenester for å forenkle integrasjonsarbeidet.

TBD: Vi bør diskutere kva vi gjer med dette prinsippet. Referansearkitekturen svarer kanskje delvis ut bakgrunnen for dette prinsippet, ved å definere rollene "domeneansvarlig" og "begrepseier". Vil desse rollene kunne svare ut behovet for sammenstilte data? Bør vurderast, og deretter oppdatere dette prinsippet.

IntArk har en distribuert styringsmodell, der konsumenter og tilbydere i utgangspunktet skal snakke direkte med hverandre. Arkitekturen gir samtidig konsumenten ansvaret for å flette sammen data fra flere tilbydere. Noen ganger er det mer hensiktsmessig å tilby data på vegne av flere tilbydere i en tjeneste.

Det kan være nyttig å tilby fellestjenester for sammenstilte data som mange konsumenter har behov for, eller for å hjelpe små konsumerende tjenester med kompliserte operasjoner eller uttrekk.

Merk at selv om en fellestjeneste tilbys, betyr det ikke at konsumenter bør pålegges å bruke denne tjenesten.

Et eksempel på en sammensatt spørring er "Gi meg alle personer hos institusjonen". Svaret involverer gjerne data fra Felles Studentsystem, HR-system og eventuelt andre personregister, for eksempel for gjester. Det kan fort bli lite kostnadseffektivt både teknisk og administrativt at hver konsument må gjøre mer eller mindre overlappende integrasjoner.

TBD: Korleis vert ansvaret for slike sentraliserte tjenester? Korleis heng det saman med "teknisk plattform"?

De sentraliserte tjenestene kalles ofte et "knutepunkt", eller en konseptuell "tjenestebuss". Merk at det i IntArk ikke er snakk om et spesifikt tjenestebuss-system - arkitekturen legger seg ikke opp i om dette støttes av ett eller flere tjenester.

  • Vert dei ein del av drifta av den tekniske plattformen?
  • Bør vi sei noko om dette på sektorielt nivå? Det inkluderer noko rundt det juridiske også.

Konsekvens

  • TBD: Teknisk plattform? Tjenestebuss?
  • Tjenestebuss skal benyttes for gjenbruk, for  eksempel "Gi meg alle personer hos institusjonen".
  • Tjenestebuss skal benyttes ved forenkling, som for eksempel kan være at når data (som passord) skal være konsistente gjennom flere systemer, er det tjenestebussen som holder orden på hvor data finnes og varsler om eller distribuerer endringer; tjenestene vet ikke om hverandre, de forholder seg kun til tjenestebussen.
  • TBD: Unit er ansvarlig for en sentral tjenestebuss, men hver enkelt institusjon kan ha sin egen, sentrale tjenestebuss. Eller heiter det "teknisk plattform"?
  • 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.

Se også

Veiledet

Du skal få hjelp og veiledning i ditt integrasjonsarbeide.

Du som er involvert i datadeling skal få nok hjelp og veiledning til å enkelt kunne følge IntArk og integrere.

Integrasjonsarbeid er ofte komplisert, og involverer mange deler av en institusjon og andre i sektoren, både teknisk og organisatorisk. For at gjøre det enklere å integrere skal IntArk hjelpe deg på veien.

I IntArk har vi ett felles kontaktpunkt for alle integrasjonsrelaterte spørsmål. Kontaktpunktet har nok innsikt både organisatorisk og teknisk til å hjelp deg, eller finne frem til de som kan hjelpe deg videre.

TBD: Endre navn til "Integrasjonsknutepunkt"?

Integrasjoner er ofte innfløkte og krever kompetanse og deltagelse av mange grupperinger: 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 med henhold til 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 ett enkelt kontaktpunkt.

Kontaktpunktet skal se til at integrasjon gjøres riktig og effektivt hos institusjonen. Kontaktpunktet 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 saker etter behov. Kompetansen i kontaktpunktet skal ikke primært være teknisk, men organisatorisk. Kontaktpunktet skal sette innmelder i kontakt med de som kan gi svar. Kontaktpunktet har også et ansvar i å følge opp disse behovene.

TBD: Prosjekt Datadeling vurderer om vi skal ha ett felles kontaktpunkt for hele sektoren, og/eller om det ligger til hver enkelt institusjon.

Det finnes veiledninger og annen dokumentasjon sentralt.

TBD: Kontaktpunktet er e-postadressen: integrasjon@uio.no

Konsekvens

  • TBD: Unit har ansvaret for at funksjonen «Kontaktpunkt» fungerer. Dette er ett felles kontaktpunkt.
  • TBD: Hver enkelt institusjon har ansvaret for å ha et sentralt kontaktpunkt for intergrasjonsrelaterte henvendelser.
  • Kontaktpunktet har kompetanse på semantisk bruk av termer i fagspråk og bidrar til at bestiller og leverandør ikke snakker forbi hverandre.
  • Kontaktpunktet har kompetanse på retningslinjer, leveransepartnere og ansvarsområder som brukes i sektoren.
  • Kontaktpunktet kan opptre på bestillers vegne videre innover i leveransekjeden.
  • Kontaktpunktet kan eskalere saker ved behov.
Publisert 15. des. 2020 14:19 - Sist endret 17. aug. 2021 23:39