Mandat versjon 0.2, "2015-08-07" (UTKAST)
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 systemer som har mange integrasjoner knyttet til seg.
Alle som anvender data fra IT-systemer ved UiO (konsument) må forholde seg til ny integrasjonsarkitektur, men 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 IT-systemene er avhengig av å utveksle data med andre IT-systemer. Etablering og endring av integrasjoner mellom IT-systemer ved UiO er per i dag unødvendig 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 ikke 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 sikre at:
- UiO får en bedre endringsevne og kan møte nye behov
- Kostnaden ved integrasjon blir lavere
- Kvaliteten på integrasjoner blir høyere
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 endringsevne og fortløpende kunne møte nye teknologiske behov, vil ikke UiO være istand til å nå målet om å være et forskningsuniversitet av høy internasjonal standard.
Resultatmål og leveranser
Den nye integrasjonsarkitekturen skal være basert på en tjenesteorientert og distribuert modell. Den skal 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. UiO's nye integrasjonsarkitektur skal realiseres innenfor rammene av UiO's prinsipper for integrasjonsarkitektur, gjennom følgende 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 må ha et brukervennlig grensesnitt med støtte for tilgangskontroll for å gi korrekte tilganger til forvaltere. Prosjektet skal vurdere ulike løsninger og innføre en av disse. OAuth2 skal vurderes som protokoll for tilgangsstyring av tjenester. AM skal innføres i organisasjonen ved at alle nye integrasjoner bruker AM og at det gjøres fortløpende kost/nyttevurderinger for eksisterende integrasjoner.
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 tilhører primært forretningssiden da tjenestene denne inneholder skal understøtte prosesser i forretningen. Prosjektet skal formulere noen krav/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 integr.asjonsarkitektur og i så fall komme med en anbefaling
Webservice
Webservice (WS) er den valgte teknologien for å realisere den nye integrasjonsarkitekturen. 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 protoype 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å både velge løsning for realisering, og innføre valgt løsning.
- Kartlegge behov i organisasjonen.
- Utrede tekniske alternativer.
- Identifisere marketsledende og framtidsrettede produkter.
- Implementere produkt og tekniske valg.
Enterprise Service Bus
I den nye integrasjonsarkitekturen innføres ikke en Enterprise Service Bus (ESB) som et sentralt punkt for alle integrasjoner. Det anbefales at integrasjoner går via ESB kun dersom det er 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å både velge løsning for realisering, 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 Webservice
- 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.
Single Point of Contact
Det skal etableres et Single Point of Contact (SPoC) som sentralt kontaktpunkt for henvendelser rundt integrasjoner. SPoC skal basere seg på de innspill som kom i forprosjektet, og være operativt iløpet av prosjektperioden. Prosjektet skal utrede behovene SPoC skal dekke og lage rutiner. Prosjektet skal også vurdere om det er hensiktsmessig å samle flere behov for SPoC på samme sted.
Change Advisory Board
Change Advisory Board (CAB) er et prioriteringsorgan som skal prioritere mellom ulike forretningsområder basert på gjeldene strategiske føringer fra UiOs ledelse. I kontektsen integrasjonsarkitektur så skal CAB prioritere integrasjonsendringer. CAB vil være et naturlig organ for andre prioriteringer, men for prosjektet så er skopet kun integrasjon. I tilfeller der en systemeier må prioritere hva ressurser skal brukes på, og i hvilken rekkefølge, så skal CAB være det korrekte nivået for denne prioriteringen. CAB vil også være eskaleringsnivået til SPoC der SPoC ikke har myndighet til å fatte beslutning. Prosjektet skal utrede funksjonen CAB i lys av ny integrasjonsarkitektur og levere anbefalinger rundt identifisere behov. Målgruppen for anbefalingene er ledelsen på UiO.
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 tilpassed de ulike aktørene som må forholde seg til integrasjoner.
Rammer
Tidsramme:
Direkte kostnader:
Timeverk/årsverk:
Andre rammer:
Hovedmilepæler og ressursestimat
Fase 1
- Når Access Manager er klar til bruk
- Når behov for tjenesteportefølje er meldt inn.
- Når standard og retningslinjer for Webservice er klar til bruk.
Fase 2
- Når meldingskø er klar til bruk
- Når ESB er klar til bruk
- Når Cerebrum er tilpasset ny integrasjonsarkitektur
- Når anbefalinger rundt autentisering og autorisasjon for brukere er klare
Fase 3
- Når CAB er etablert
- Når SPOC er etablert
- Når en komplett integrasjonsveiledning er tilgjengelig