Mandat versjon 1.0, "2015-10-01" (FORSLAG)
Prosjektnavn
UiO integrasjonsarkitektur
Roller
Oppdragsgiver
USIT ved IT-direktør Lars Oftedal.
Prosjekteier ved USIT
IT-direktør Lars Oftedal.
Prosjektet omhandler integrasjonsarkitektur for hele UiO. Integrasjonsarkitektur hører inn under IT-arkitektur, som er IT-direktørens ansvarsområde.
Andre aktører
Alle systemeiere ved UiO må aktivt forholde seg til ny integrasjonsarkitektur, systemeiere må derfor involveres i prosjektet. Det er spesielt viktig å involvere ansvarlige for de systemer som inneholder data som det kan være nyttig for mange andre å få tilgang til.
Alle eiere av tjenester som anvender data fra IT-systemer ved UiO må forholde seg til ny integrasjonsarkitektur. Det er et vesentlig mål med ny integrasjonsarkitekturen at tilgang til data skal bli enklere.
Prosjektet skal ha en styringsgruppe bestående av seks personer, hvorav to fra sentrale systemeiere, en representativ konsument, og to fra USIT.
Prosjektet skal ha en bredt sammensatt referansegruppe som styringsgruppen oppnevner.
Prosjektleder
<Navn på prosjektleder hvis vedkommende allerede er utpekt, eventuelt navn på ansvarlig for neste fase>
Bakgrunn og begrunnelse
I en moderne organisasjon som UiO er IT-systemer en komponent i de alle fleste prosesser, og moderne IT-systemer er avhengig av å utveksle data med andre IT-systemer. Etablering og endring av integrasjoner mellom IT-systemer ved UiO er per i dag kostbart og tidkrevende. Dagens situasjon er preget av liten kontroll og oversikt. Konsekvensen er forsinkede prosjekter, uforutsette kostnader og forringet brukeropplevelse. Organisasjonens evne til å tilpasse seg stadig nødvendige og ønskede endringer, inkludert innovasjon, er hemmet - vi er lite endringsdyktige.
De teknlogiske løsningene for integrasjon har utviklet seg over tid. Det mest vanlige har vært periodiske jobber med varierende stabilitet og kvalitet. Det er i dag en forventning om at systemer kommuniserer mer dynamisk med hverandre. I mangel av en definert integrasjonsarkitektur som understøtter dette, har flere systemeiere allerede begynt å etablere egne løsninger.
Arbeidet med nytt integrasjonsarkitektur er forankret i tiltaket "Arkitektur og integrasjonsrammeverk", vedtatt av Universitetsstyret 23.oktober.2012 som en del av «Standardisering og organisering av Universitetets IT-virksomhet». Arbeidet med integrasjonsarkitektur er utført i tråd med føringer fra Direktoratet for forvaltning og IKT (Difi). Difis føringer gjelder alle statelige virksomheter. Prosjektet bygger videre på rapport fra Arbeidsgruppe for Integrasjonsarkitektur, og leveranser fra Forprosjekt for UiO integrasjonsarkitektur.
Formål
Prosjektets formål er å innføre en definert integrasjonsarkitektur som skal gi organisasjonen evne til å etablere og endre integrasjoner smidig og kostnadseffektivt, slik at integrasjoner ikke er til hinder for organisasjonens kontinuerlige behov for endringer. Dette realiseres gjennom styringsregler som gir effektive handlingsrom på det korrekte nivået i organisasjonen, samt støttesystemer for å understøtte arkitekturen. Den nye integrasjonsarkitekturen skal gi UiO god oversikt og kontroll med integrasjoner, og gi en lavest mulig terskel for å etablere, endre, og bruke integrasjoner.
Ny integrasjonsarkitektur skal etterstrebe at:
- UiO får en bedre endringsevne og kan møte nye behov.
- Kostnader ved integrasjoner blir lavere.
- Kvaliteten på integrasjoner blir høyere.
- Arkitekturen bygger på positive incentiver; den skal være fleksibel og gi mulighet for unntakshåndtering.
- UiO vil stå bedre rustet til fremtidige sektorsamarbeid.
Dersom dette ikke gjøres, vil UiO aldri få oversikt og kontroll. Uten kontroll over egne data og hvordan disse flyter, er det bare et tidsspørsmål om når data havner på avveie og kostnaden ved innføring av nye systemer blir for høye. Uten evne til å fortløpende kunne møte nye teknologiske behov, vil ikke UiO være i stand til å nå målet om å være et forskningsuniversitet av høy internasjonal standard.
Behovsanalyse og koordinering ved UiO
Komponenter og leveranser som er beskrevet i mandatet må ansees som et forslag fra USIT, og skal fungere som utgangspunkt for diskusjon med interessenter på UiO utenfor USIT. Det anbefales at prosjektet er fleksibelt i å tilpasse og videreutvikle komponenter og tilhørende delleveranser basert på behov hos interessenter.
Det anbefales at prosjektet har en innledende fase dedikert til å avklare behov og forståelse hos, og sikre innspill fra alle interessenter ved UiO. Forprosjektet har vært begrenset til interessenter ved USIT. Interessentoppfølgingen ved USIT har vært nyttig og nødvendig, og erfaringen er at en bredere interessentoppfølging ved UiO må ansees å være essensielt for lykkes med innføring av ny integrasjonsarkitektur for UiO.
Konsekvenser og kost/nytte
I forprosjektets interessentoppfølging kommer det frem at det er en del skepsis knyttet til i hvilken grad aktiviteter i prosjektet utløser ressursbehov uten at det tildeles ressurser. Det ansees som nødvendig at konsekvenser ved innfasing av alle komponenter er utredet, for å sikre riktig finansiering og prioritering i forkant av innfasing. En slik forankring fordrer at aktiviteten er nøye beskrevet mht. løsning og konsekvens, og vurdert mht. behov, kost/nytte og risiko.
Smidig innfasing av komponenter
Det anbefales at den nye integrasjonsarkitekturen for UiO fases inn gradvis. Alle komponentene i integrasjonsarkitekturen har egenverdi, og kan realiseres over tid, gjennom delprosjekter. Det understrekes imidlertid at integrasjonsarkitekturen er utarbeidet som en helhet, og under forutsetning av at alle komponenter realiseres. En stor del av gevinsten realiseres i det alle komponenter er på plass. En smidig innfasing av komponenter fordrer at både forretning og IT (herunder utvikling og drift) er involvert i prosessen.
Organisk innføring i organisasjon
Det anbefales at den nye integrasjonsarkitekturen fases inn gjennom krav om at alle nye integrasjoner gjøres i henhold til ny integrasjonsarkitektur, samt fortløpende kost/nytte vurderinger av omlegging av eksisterende integrasjoner, ved behov. Positive incentiver skal være primære drivere for innføring i organisasjonen; det skal oppfattes som lønnsomt og lettvint.
Resultatmål og leveranser
Den nye integrasjonsarkitekturen skal være basert på en tjenesteorientert og distribuert modell. UiOs nye integrasjonsarkitektur skal realiseres innenfor rammene av UiO's prinsipper for integrasjonsarkitektur. Under følger en beskrivelse av hvordan de ulike komponentene i integrasjonsarkitekturen kan realiseres gjennom delleveranser:
Access Manager
Access Manager (AM) er en sentral tjeneste for gi oversikt og forvalte tjenesters tilgang i integrasjoner. Forvaltningen av tjenesters tilganger administreres av systemeiere. AM skal bidra til økt overholdelse av lover og regler. AM skal sikre god flyt gjennom en enkel prosess og et brukervennlig grensesnitt.
Prosjektet skal vurdere ulike løsninger og innføre en av disse. OAuth2 skal vurderes som protokoll for tilgangsstyring av tjenester.
Tjenesteportefølje
Tjenesteportefølje (Service Portfolio - SP) er en sentral tjeneste for å holde orden og oversikt over tjenester på UiO, noe som gir verdi både for forretningssiden og IT-siden av organisasjonen. SP skal påse at formkrav etterfølges slik at UiOs tjenester i større grad overholder lover og regler. SP tilhører primært forretningssiden da tjenestene denne inneholder skal understøtte prosesser i forretningen. For integrasjonsarkitekturen er SP en vesentlig komponent, men behovet for en SP igår langt utover behovet i integrasjonsarkitekturen. Det sees derfor ikke som naturlig at etablering og innføring av SP inngår i prosjektet, og leveransen begrenses til å omfatte beskrivelse av integrasjonsarkitekturens behov i en SP.
Tjenesteportefølje er identifisert risiko i prosjektet. Risiko er primært knyttet til at det er flere initiativer som må koordinere seg mht. tjenestekatalog, tjenesteportefølje, veikart. For integrasjonsarkitekturen er den biten av tjenesteporteføljen som kalles et tjenesteregister, mest essensiell. Et tjenesteregister er en søkbar tjeneste over hvilke data som tilbys, samt hvor og hvordan man får tak i dem.
Prosjektet skal beskrive behov til SP i konteksten integrasjonsarkitektur ved å:
- Utrede behovene en integrasjonsarkitektur har i en SP - herunder dokumentasjon av den enkelte tjenestes WS-/API-er.
- Identifisere hvem som er riktig mottaker for krav og behov.
- Vurdere om det er behov for å opprette en spesialisert SP kun for integrasjonsarkitektur og i så fall komme med en anbefaling.
Web services
Web services (WS) er den valgte teknologien for å realisere den nye integrasjonsarkitekturen. Web services er etterspurt på UiO og bransjestandard for informasjonsutveksling. Web services legger grunn for bruk og bygging av skytjenester, både egne, sektors, og tredjeparts.
Prosjektet skal produsere anbefalinger og standarder:
- Standard for API-dokumentasjon og plassering.
- Retningslinjer for versjonering av API-er.
- Rest vs. SOAP - prosjektet skal komme med kjøreregler for hva man støtter av Rest/SOAP.
Prosjektet skal etablere samarbeid med systemeiere for å bestille to konkrete integrasjoner i henhold til integrasjonsarkitekturen. Disse integrasjonene skal brukes til å illustrere, for organisasjonen, hvordan integrasjoner skal gjøres i den nye integrasjonsarkitekturen.
Sentral meldingskø
I den nye integrasjonsarkitekturen anbefales meldingsbasert kommunikasjon, dvs. at integrasjoner realiseres ved at tjenester utveksler korte oppdateringsmeldinger ved behov, framfor omfattende synkroniseringspakker til faste tider. Dette åpner for at endringer i data i en tjeneste kan spres til andre tjenester umiddelbart. Det oppstår imidlertid også et behov for å sikre at meldinger når fram til mottaker. Meldingskø er en sentral komponent som kan påta seg ansvaret for å sikre at meldinger når fram til mottaker. Den kan også rute meldinger til flere mottakere ved å la tjenester abonnere på meldingstyper. Meldingskø kan, men må ikke, være en del av en ESB-komponent.
Prosjektet må velge løsning for realisering, og innføre valgt løsning.
- Kartlegge behov i organisasjonen.
- Utrede tekniske alternativer.
- Identifisere markedsledende og framtidsrettede produkter.
- Implementere produkt og tekniske valg.
Enterprise Service Bus
I den nye integrasjonsarkitekturen innføres en Enterprise Service Bus (ESB), men integrasjoner skal kun gå via ESB dersom det foreligger klare gevinster ved å gjøre det. Det kan feks. være:
- Ved sammensetninger av data fra flere kilder,
- Når flere tjenester ønsker samme type integrasjon som er formålstjenlig å tilby gjennom ESB,
- Gjøre det brukervennlig for konsument ved å la ESB håndtere og skjule kompleksitet,
- Sentral kontroll over integrasjonen - f.eks. ved eksterne leverandører,
Det må foretas en vurdering ved hver enkelt integrasjon. ESB kan realiseres med ferdig programvare eller microservices. ESB-en vil være en organisk tjeneste, eller en samling av tjenester, det er derfor et absolutt krav om en modulær løsning.
Prosjektet må velge løsning og innføre valgt løsning.
Cerebrum
Eksisterende integrasjonsarkitektur skal fases ut. Cerebrum mister dermed sin rolle som integrasjonsnav og skal kun tilby data som systemet er autoritativt for. Nye integrasjoner mot Cerebrum begrenses til integrasjoner mot BAS-funksjonen i Cerebrum. For eksisterende integrasjoner som ikke er BAS-relevant skal det fortløpende foretas kost/nytte vurderinger på om det er hensiktsmessig å bytte de ut. Hver enkelt slik oppgradering realiseres gjennom egne prosjekter, og inngår således ikke i dette prosjektet. Da det kan være i organisasjonens interesse å oppgradere gamle integrasjoner, anbefales det at slike prosjekter hel-, eller delfinansieres sentralt.
Prosjektet skal anbefale en ordning for sentral finansiering. Prosjektet skal levere:
- Åpent grensesnitt basert på resultatet av aktiviteten Web services.
- Pilotere løsning for hendelsesdrevne oppdateringer, hvor Cerebrum interagerer med sentral meldingskø.
- Kartlegge komplekse, sammensatte uttrekk som ESB-en bør overta.
Med unntak av Cerebrums rolle som integrasjonsnav, er rendyrking av Cerebrum som BAS/IdM utenfor skop.
Autentisering og autorisasjon
Et viktig element i integrasjon er brukerautentisering, og -autorisasjon. Autentisering og autorisasjon av tjenester er adressert gjennom aktiviteten Access Manager.
Prosjektet skal levere en anbefaling for brukerautentisering, og vurdere tiltak for å standardisere brukerautorisasjon ved UiO.
Kontaktpunkt for integrasjoner
Det skal etableres et sentralt kontaktpunkt ved USIT for henvendelser rundt integrasjoner. Kontaktpunktet skal basere seg på de innspill som kom i forprosjektet. Det anbefales, om mulig, at kontaktpunktet etableres som en funksjon i eksisterende organisasjon.
Prosjektet skal utrede behovene kontaktpunktet skal dekke, og utarbeide forslag til funksjons-, og bemanningsplan.
Prioriteringsråd for integrasjon
Prioriteringsrådet skal ved behov prioritere integrasjonsendringer på vegne av UiOs ledelse. I tilfeller der en systemeier må prioritere mellom ulike tiltak, og rekkefølge, skal prioriteringsrådet være det korrekte nivået for å avgjøre hva som er riktig prioritering for UiO. Prioriteringsrådet vil også være eskaleringsnivå i alle integrasjonsrelaterte saker der linjeorganisasjonen mangler myndighet til å fatte beslutning. Det anbefales, om mulig, at Prioriteringsrådet sees som en funksjon, som tillegges et eksisterende organ som representerer systemeiere og andre interessenter.
Prosjektet skal utrede funksjonen Prioriteringsråd i lys av ny integrasjonsarkitektur og levere forslag til plan for realisering.
Integrasjonsveileder
Organisasjonen skal ha tilgang til informasjon og veiledning som gjør integrasjonsarkitekturen tilgjengelig og forståelig, og gir lavest mulig terskel for å etablere og benytte integrasjoner.
Prosjektets leveranser vil være:
- Definere og forklare begreper og terminologi.
- Beskrive alle felleskomponentenes funksjon og formål.
- Utrede og foreslå teknologiske standarder.
- Beskrive organisatoriske prosesser, som beslutningslinjer og eskaleringspunkter.
- Veiledende informasjon tilpasset de ulike aktørene som må forholde seg til integrasjoner.
Rammer
Prosjektgruppen har ikke hatt de rette forutsetningen for å gi gode anbefalinger om rammer, med unntak av tidsramme. Det overlates til prosjekteier og prosjektleder å gjøre vurderinger om kostnadsrammer.
Tidsramme: 1.1.2016-31.12.2017
Direkte kostnader:
Timeverk/årsverk:
Andre rammer:
Tidsplan og milepæler
Tidsplanen er overordnet og er ikke å anse som en sterk føring for prosjektet. Det anbefales at prosjektet deles inn i fire faser som utføres sekvensielt. Det anbefales videre at innfasing av de ulike komponentene som utgjør integrasjonsarkitekturen gjøres gjennom delprosjekter dedikert til hver enkel komponent. Delprosjekter i samme fase bør kunne gjennomføres parallellt.
Tidsplan
2016 H1 - Fase 1: Behovsanalyse og koordinering ved UiO
2016 H2 - Fase 2: Access Manager, tjenesteportefølje, Web Service
- Delprosjekt 1: Access Manager
- Delprosjekt 2: Spesifikasjon av behov for tjenesteportefølje
- Delprosjekt 3: Retningslinjer for Web Services
2017 H1 - Fase 3: Meldingskø, ESB, Cerebrum, autentisering og autorisasjon
- Delprosjekt 4: Meldingskø
- Delprosjekt 5: Enterprise Service Bus (ESB)
- Delprosjekt 6: Cerebrum
- Delprosjekt 7: Autorisasjon og autentisering
2017 H2 - Fase 4: Prioriteringsråd, kontaktpunkt, integrasjonsveileder
- Delprosjekt 8: Prioriteringsråd for integrasjoner
- Delprosjekt 9: Kontaktpunkt for integrasjoner
- Delprosjekt 10: Integrasjonsveilder
Milepæler
- M1: Når fase 1 er gjennomført.
- M2: Når Access Manager klar til bruk i organisasjonen.
- M3: Når behov for tjenesteportefølje er meldt inn.
- M4: Når standard og retningslinjer for Webservice er klar til bruk.
- M5: Når fase 2 er gjennomført.
- M6: Når meldingskø er klar til bruk.
- M7: Når ESB er klar til bruk.
- M8: Når Cerebrum er tilpasset ny integrasjonsarkitektur.
- M9: Når anbefalinger rundt autentisering og autorisasjon for brukere er klare.
- M10: Når fase 3 er gjennomført.
- M11: Når Prioriteringsråd for integrasjoner er etablert
- M12: Når Kontaktpunkt for integrasjoner er etablert.
- M13: Når en komplett integrasjonsveileder er tilgjengelig.
- M14: Når fase 4 er gjennomført.