Tjenestebegrepet i moderniseringen
Det gamle bildet: én tjeneste, ett system
Tradisjonelt har vi omtalt hvert brukergrensesnitt og hvert API i FS som en egen tjeneste: Studentweb var en tjeneste, FS-klienten var en tjeneste, Søknadsweb var en tjeneste. På API-siden hadde vi FSWS og FS REST API som egne tjenester. Dette fungerte fint så lenge det var tilnærmet 1:1 mellom system og funksjon — ett grensesnitt gjorde én ting, for én brukergruppe.
Hvorfor det gamle bildet ikke strekker til lenger
Moderniseringen bryter nettopp denne 1:1-koblingen:
- Vi har ett API — FS GraphQL API — som gir tilgang til alle tjenesteområder og all data i FS, uavhengig av hvilken backend som faktisk eier dataene.
- Vi har ett brukergrensesnitt for borgere/personer — Min kompetanse — og ett brukergrensesnitt for ansatte — FS Admin.
- Hva den enkelte faktisk får se og gjøre i disse grensesnittene, avhenger ikke av hvilket system de er logget inn i, men av hvem de er og hvilken tilhørighet de har: hvilket lærested du er student ved, hvilket lærested eller opptaksorgan du er ansatt ved.
Se på disse eksemplene:
- En søker som bare har fullført vgs i Norge, finner sine resultater og kan søke opptak til høyere utdanning og høyere yrkesfaglig utdanning — alt i Min kompetanse.
- En utenlandsk søker uten tidligere utdanning i Norge kan bare søke opptak — også i Min kompetanse, samme grensesnitt.
- En UiO-student med resultater både fra vgs og fra UiO har tilgang til alle sine resultater, kan søke annen utdanning og administrere egne studier — fortsatt Min kompetanse.
Alle tre bruker samme grensesnitt. Forskjellen mellom dem er ikke hvilken «tjeneste» de logger inn i — det er hva de får tilgang til inni den. Det samme gjelder på saksbehandlersiden:
- En ansatt ved Samordna opptak kan bare behandle opptakssøknader i FS Admin.
- En ansatt ved fagskolen Viken kan opprette og vedlikeholde fagskolens utdanninger, og behandle søknader i opptak.
- En ansatt ved UiO har tilgang til det samme som fagskolen Viken, og kan i tillegg følge opp og administrere UiOs studenter.
Med ett API og to grensesnitt holder ikke det gamle tjenestebegrepet lenger som forklaringsmodell. Vi trenger et vokabular som skiller mellom hvor noe skjer, hva som gjøres, og hvem som får lov.
Begrepene, ett om gangen
Brukergrensesnitt
Der en aktør faktisk logger inn og jobber: FS Admin for ansatte, Min kompetanse for søkere og studenter.
API
Den tekniske integrasjonsflaten grensesnittene (og eksterne konsumenter) bruker for å nå funksjonalitet og data: FS GraphQL API. Ingen sluttbruker forholder seg til dette direkte.
Tjenesteområde
En brukerorientert gruppering av hva FS kan gjøre, sett fra forretnings- og brukerbehov. FS dekker tjenesteområdene studieinformasjon, opptak, utdanningsregister og kompetanseregister. Tjenesteområdet er det som styrer navigasjon og tilgangsstyring, og det vi bruker når vi forklarer lærestedene hva FS dekker.
Tjeneste
Innenfor hvert tjenesteområde finnes en rekke tjenester — konkrete aktiviteter en aktør utfører for å oppnå et mål: levere søknad, kvalifisere søknad, tildele plass, administrere utdanningstilbud. En tjeneste ligger på nivå med en brukerhistorie, ikke på systemnivå. Tjenestene samsvarer med oppgaver, aktiviter og hendelser i prosesser, og tjenestene kan inngå i en eller flere ulike studieadministrative prosesser.
Flere tjenester kan være steg i samme prosess — kvalifisering, poengberegning, rangering og plasstildeling er alle steg i prosessen behandle opptakssøknad. Der studienivå eller utdanningstype gir ulike kvalifiseringskrav, er det variasjon i regelsettet tjenesten bruker, ikke en ny tjeneste. Aktiviteten er den samme, uansett studienivå.
Tilgangsprofil
Hvilke tjenester en aktør faktisk ser og kan bruke, avgjøres av tilgangsprofilen deres: rolle, tilhørighet (lærested/opptaksorgan) og i noen tilfeller utdanningshistorikk. Det er tilgangsprofilen — ikke systemet — som forklarer hvorfor to personer i samme grensesnitt ser forskjellig funksjonalitet.
Domene
For utviklere: i tillegg til de brukervendte begrepene ovenfor, bruker vi domene som en intern, analytisk modelleringsterm (bounded context i DDD-forstand) — hvordan data og regler er strukturert internt. Et domene kan strekke seg over flere tjenesteområder (f.eks. person-domenet ligger under både opptak, resultater og studieadministrasjon), og et tjenesteområde kan trekke på flere domener. Domene brukes ikke i kommunikasjon med lærestedene — det er et internt verktøy for å strukturere ansvar og modeller.
Se begrepet domene og domenedrevet design i FS.
Samlet eksempel
FS er et produkt med brukergrensesnittene FS Admin for ansatte og Min kompetanse for søkere og studenter, med APIet FS GraphQL API. FS dekker tjenesteområdene studieinformasjon, opptak, utdanningsregister og kompetanseregister, som hver inneholder en rekke tjenester relevante for ansatte, søkere og studenter.
| Aktør | Grensesnitt | Tilgangsprofil | Tilgjengelige tjenester (eksempel) |
|---|---|---|---|
| Søker med bare vgs i Norge | Min kompetanse | Ingen tidligere høyere utdanning | Se resultater, søke opptak til høyere utdanning/høyere yrkesfaglig utdanning |
| Utenlandsk søker, ingen utdanning i Norge | Min kompetanse | Ingen registrert utdanningshistorikk i Norge | Søke opptak |
| Student ved UiO, vgs + UiO-resultater | Min kompetanse | Aktiv student ved lærested | Se alle resultater, søke annen utdanning, administrere egne studier |
| Ansatt ved Samordna opptak | FS Admin | Ansatt ved opptaksorgan | Behandle opptakssøknader |
| Ansatt ved fagskolen Viken | FS Admin | Ansatt ved lærested (fagskole) | Opprette/vedlikeholde utdanninger, behandle søknader i opptak |
| Ansatt ved UiO | FS Admin | Ansatt ved lærested med FS-lisens | Samme som fagskolen Viken, samt følge opp og administrere studenter |
Samme tjenesteområde og samme grensesnitt gir altså ulikt sett med tilgjengelige tjenester, avhengig av aktørens rolle og tilhørighet — ikke fordi de bruker forskjellige «tjenester» i den gamle, systemvendte betydningen av ordet.