Visjonsnotat Cerebrum

Om dokumentet

Bakgrunn: Cerebrum er i dag sammensatt av mange tett integrerte moduler og det går med betydelige ressurser i å håndtere kompleksiteten dette medfører. Modulene i Cerebrum er svært varierte og omhandler ulike aspekter av virksomheten. De tette integrasjonene og funksjonsspennet i modulene gjør at Cerebrum konstant er i behov av endring og at endringer i Cerebrum er kostbare. Med ny integrasjonsarkitektur kommer også nye føringer for hvordan Cerebrum skal integrere, samt andre føringer som affekterer Cerebrum.

Formål: Formålet med dette dokumentet er å belyse de endringer som må til for å gjøre Cerebrum mer fremtidsrettet - både for Cerebrums egen del og i kontekst integrasjonsarkitektur. Integrasjonsarkitekturen vil adressere funksjonalitet som Cerebrum dekker i dag, i andre systemer. For å tjenesteorientere Cerebrum så vurderes også de ulike modulene som er en del av tjenesten i dag. 

Resultatmål: 

• Beskrive dagens situasjon 
  • I forhold til integrasjoner med andre systemer
  • I forhold til de ulike modulene
• Beskrive de endringer som må til i Cerebrum for å være i henhold til ny integrasjonsarkitetur
• Beskrive de funksjoner Cerebrum i dag dekker som ikke er i kjernefunksjonen IdM - Identity Management

Cerebrum i dag

Cerebrum har i dag mange roller. I integrasjonsarkitektursammenheng er dette rollene:

1. Identity Management system (IdM), Brukeradministrasjonsystem (BAS).
2. ESB/integrasjonsnav
3. Moduler for andre data og funksjonalitet, som ikke har andre steder å være

Cerebrum følger i dag mye en hub-and-spoke-modell, der Cerebrum er den sentraliserte komponenten, hub-en, som frakter data mellom IT-systemer. Dette gjør at Cerebrum integrerer med mange systemer. Hvilke data som fraktes hvordan, er spesialtilpasset hver integrasjonspartner.

Cerebrum er blitt en kompleks løsning grunnet all funksjonalitet som over tid er integrert i systemet og som i for liten grad er blitt behandlet som adskilte elementer. I mange av integrasjonene settes Cerebrumdata sammen med data fra andre systemer. Siden integrasjonene er tilpasset hvert enkelt system, krever endringer detaljkunnskap om systemene som det integreres mot. Dette medfører at Cerebrumutviklere må bruke mye ressurser på systemer de ikke skal arbeide videre med ("pugg og glem"), kompetanseoppbyggingen har derfor en kortvarig verdi. Antallet skreddersydde integrasjoner gjør også at ingen kjenner til alt Cerebrum gjør, og videreutvikling tar derfor lenger tid.

En del moduler i Cerebrum har lite eller ingenting med IdM å gjøre. Noen eksempler er funksjonalitet for utskriftsdata, VoIP, DNS-data og hostpolicies. Funksjonalitet har blitt lagt til fordi det var:

• i noen tilfeller, og i et kortsiktig perspektiv, en fordel å gjenbruke rettighetsmodellen i bofh for å delegere tilganger 
• det var "ingen bedre plasser", og det var en kultur på Usit for å samle funksjonalitet i et sentralisert verktøy. Man forutså ikke hvor ressurskrevende kompleksitetshåndtering i et slikt "massehåndteringsverktøy" kom til å bli

Eksempler

Totalt har Cerebrum mer enn 50 integrasjoner mot over 30 forskjellige systemer. Noen eksempler på hub-and-spoke-integrasjoner som går via Cerebrum:

• SAPUiO til ePhorte: ePhorte må bli provisjonert med ansatte og ansattdata. All denne informasjonen kommer fra SAPUiO. Cerebrum får dette fra SAPUiO, modifiserer informasjonen noe, legger til identitetsinformasjon, og sender den videre til ePhorte. Integrasjonen er skreddersydd.
• Fronter: Fronter trenger mye studierelatert informasjon i tillegg til student-data, for eksempel kull, fag, emner, studiegrupper og fagpersoner og deres tilhørigheter. All denne informasjonen befinner seg i FS. Cerebrum henter dette fra FS, gjør endringer i Cerebrum basert på dette, før Fronter får informasjonen.
• DNS: DNS-data hentes fra hostmaster sine maskiner og importeres til Cerebrum. Deretter kan hostmaster og andre interessenter, som lokal IT, modifisere informasjonen gjennom bofh, før BIND-filer eksporteres til DNS-maskinene. DNS har minimalt med IdM å gjøre, men en av årsakene til at denne integrasjonene er blitt lagt til Cerebrum/bofh er på grunn av bofhd sin rettighetsstruktur for å delegere tilganger til lokal IT. Et eksempel på sammenblanding av roller i et system, som kompliserer systemet.
• AD: Cerebrum overfører brukerkontoer og grupper til AD. Integrasjonen er skreddersydd og gjøres fra Cerebrum sin side. For å løse dette inneholder Cerebrum en del data og tilpasninger som er AD-spesifikke.

Ulemper

Hva vi har erfart fra tilstanden til Cerebrum i dag:

• Cerebrum har blandet sammen rollene IdM og ESB, som gir en økt kompleksitet.
• Cerebrum har skreddersydde integrasjoner som standard. Dette gjør at utviklerene må ha oversikt over mye detaljer. Hvilket igjen gjør oss sårbare mht. turn-over av personell.
• Cerebrum inneholder mange tilpasninger for en rekke konsumenter.
• Cerebrum inneholder flere moduler som ikke har med IdM å gjøre.
• Cerebrum har tatt over for mye funksjonalitet og data til en del konsumenter (supply push), og gjør mye av det konsumenten selv burde tatt seg av (end user pull).

Cerebrum i fremtiden

Vi ønsker å gjøre Cerebrum enklere og mer effektiv å utvikle og tilpasse. For å få til dette, ønsker vi å gå tilbake til hva Cerebrum egentlig er, et rent IdM-system. En erfaring vi har fra Cerebrum i dag, er at vi må holde roller og funksjonalitet adskilt. Vi ønsker derfor å rendyrke Cerebrum som et IdM-system, og i ettertid holde et strengt skille på at Cerebrum bare skal videreutvikles for IdM-relatert funksjonalitet.

• Cerebrum vil bli rendyrket som en ren IdM-løsning, som følger den nye integrasjonsarkitekturen.
• Rollen som ESB/integrasjonsnav vil gradvis bli flyttet over til andre tjenester, i samråd med retningslinjene til den nye integrasjonsarkitekturen. Forprosjektet har utarbeidet et Visjonsnotat ESB, som omhandler tanker rundt dette.
• Cerebrum-moduler som ikke har direkte med IdM å gjøre vil bli gradvis flyttet over til andre, mer passende tjenester, i samråd med retningslinjene til den nye integrasjonsarkitekturen.
• Det defineres en grensegang mellom Cerebrum og konsumenter. Cerebrum skal i utgangspunktet bare forholde seg til IdM-relaterte data og funksjonalitet, og skal ikke inneholde logikk og funksjonalitet som tilhører andre systemer.

Hva som må gjøres:

• Cerebrum må utvikle et åpent grensesnitt, et Webservice API, for IdM-data. Dette kan konsumenter bruke for å hente ut og sende inn IdM-relaterte data. Webservicen skal følge retningslinjene til ny integrasjonsarkitektur. Det er viktig å poengtere at denne webservicen bare skal omhandle IdM-funksjonalitet, for å holde tjenesten mer atomær, dette i henhold til ny integrasjonsarkitektur.
• Så mye som mulig av funksjonalitet som ikke er relatert til IdM skilles ut av Cerebrum.

Hvordan komme dit

En eventuell rendyrking av Cerebrum som en IdM-løsning vil ta tid, og må skje gradvis. Vår anbefaling er å dele prosessen i tre faser, fordelt over flere år. For hver enkelt integrasjon og modul må det bli tatt en kost/nytte-vurdering for om den den skal fases ut, flyttes til et annet system eller beholdes i Cerebrum som i dag.

Fase 1

• Cerebrum utvikler første versjon av sitt Webservice API. Dette gjøres i sammenheng med (videre)utvikling av en integrasjon med Cerebrum, så vi vet vi dekker de grunnleggende behovene.
• Alle andre, eksisterende integrasjoner blir fremdeles gjort på gamlemåten. Disse integrasjonene registreres i Service Portfolio og markeres som teknisk gjeld.
• Konsumenter blir invitert til å se på det nye API-et for å eventuelt se om det kan bli tatt i bruk.

Fase 2

• Webservice API-et videreutvikles etterhvert som nye konsumenter kommer til og ny behov blir meldt inn.
• Webservicen tar i bruk Access Manager, når denne er på plass.
• Ved behov for videreutvikling av eksisterende integrasjoner gjøres en kost/nytte-vurdering på om den skal over på ny integrasjon gjennom Cerebrum WS.
• Alle nye integrasjoner skal i utgangspunktet bruke Cerebrum WS. Det kan likevel gjøres en kost/nytte-vurdering av om en konsument må integrere på gamlemåten.

Fase 3

• All videreutvikling av integrasjoner foregår gjennom Cerebrum WS.
• Gamle integrasjoner kan fremdeles foregå på gamlemåten der det er hensiktsmessig. Enten fordi det ikke er behov for videreutvikling, eller fordi det vil koste for mye å flytte dem ut.

Moduler som må vurderes

Det er stor forskjell på hvor enkelt det er å skille ut moduler. Noen moduler har liten integrasjon mot IdM data, som DNS og Subnet, og vil være enklere å skille ut enn der IdM data er i bruk, som f.eks. VoIP og E-post. Der hvor IdM-data er integrert vil det være en større kartleggingsjobb med hvordan dagens tette koblinger kan erstattes med løse. Tanken er at modulene skal bruke Cerebrum WS for sine koblinger med IdM-data.

Det må vurderes for hver enkelt modul hvor den mest naturlig hører hjemme. For moduler som ikke har en passende plassering kan det vurderes å sette opp en nedstrippet Cerebrum for dette. Gjenbruk av Cerebrum må i så fall utredes, da det er uklart om det er hensiktsmessig og hvor mye arbeid som kreves for å få til dette.

Vi kan ikke skille ut funksjonalitet uten å tilby samme funksjonalitet gjennom en annen tjeneste. Når funksjonaliteten er skilt ut er det naturlig om ansvaret for tjenesten flyttes nærmere brukerne av funksjonaliteten.

Cerebrum-moduler som kan vurderes å fases ut:

• DNS - administrasjon av DNS-data for UiO sine domener. Det finnes mer egnede administrasjonsløsninger for DNS-data på markedet som vil kunne ta over denne funksjonaliteten. Det er behov for rettighetsdelegering av DNS-data, som må utredes hvordan kan løses i ny tjeneste.
• Subnet - adminstrasjon av UiO sine subnett. Denne modulen kan sannsynligvis flyttes til samme tjeneste som DNS-modulen.
• Host - lagring av maskindata. Denne modulen kan sannsynligvis flyttes til samme tjeneste som DNS-modulen. Maskindata brukes av ulike moduler, så DNS-tjenesten må da ha god integrasjonsstøtte.
• Hostpolicy - administrasjon av CFengine sine hostpolicies, koblet mot maskiner. Denne modulen har behov for et administrasjonsgrensesnitt, kommunikasjon med CFengine og en rettighetsmodell for delegering til blant anne lokal IT.
• Utskriftskvote - oversikt over utskriftskvotene til studenter. Denne funksjonaliteten er allerede på vei ut i sammenheng med ny utskriftsprosjekt.
• VoIP - lagring og administrasjon av UiO sine VoIP-data. Vi antar at det finnes eksisterende løsninger for å administrere VoIP-data på markedet.
• E-post - automatikk og administrasjon av UiO sine e-postadresser og tilhørende metadata om e-postkontoer. E-postfunksjonalitet er tett tilknyttet Cerebrum, og det er ikke sikkert at alle e-postdata skal ut av Cerebrum. Dette må utredes. Brukere sine e-postadresser er IdM-relaterte og er gjerne hensiktsmessig å beholde, mens hvilken server e-postkontoer ligger på ikke er en del av en IdM-løsning. Mer av e-postfunksjonaliteten bør flyttes til e-postsystemet, så Cerebrum ikke administrerer data som er spesifikke for et spesifikt e-postsystem, som Exchange.
• Exchange - lagring av Exchange-relaterte data på blant annet grupper. Den samme vurderingen som for E-post gjeld også for Exchange.
• ePhorte (roller og tilgangskoder) - automatikk og administrasjon av roller og tilgangskoder for ePhorte. Siden det pågår et prosjekt for å få på plass en ny arkivløsning ser det ut til å vere mest hensiktsmessig å la denne modulen bestå i Cerebrum frem til den nåværende versjonen av ePhorte fases ut.
• Disker - automatikk og administrasjon av disker, tilhørende maskiner og brukerkvoter på disse. Behovet for denne funksjonaliteten kan vurderes sammen med IT-drift.
• Fronter - Dette er i utgangspunktet en integrasjon, men grunnet kompleksiteten til Fronter inneholder Cerebrum logikk for å automatisk bygge og vedlikeholde egne grupper for Fronter. Det pågår en aktivitet for å integrere direkte mellom FS og Fronter, som det er hensiktsmessig at Cerebrum deltar i for å sikre seg at den eksisterende funksjonaliteten videreføres.

Felles for mange moduler, er behovet for en rettighetsstruktur for å kunne delegere tilganger. Det synes derfor hensiktsmessig med en egen tjeneste som håndterer rettigheter og rettighetsstruktur.