Architectuurscan Onderwijsserviceregister

Uit ROSA Wiki
Ga naar: navigatie, zoeken

Deze pagina toont een samenvatting van de ROSA Architectuurscan van het onderwerp Onderwijs serviceregister. Met de ROSA Architectuurscan worden op systematische wijze alle architectuuraspecten van een bij Edustandaard ingebracht onderwerp in kaart gebracht en worden knelpunten en kansen gesignaleerd. Niet alleen kan de indiener er zijn voordeel mee doen, ook kan ROSA ermee worden verrijkt. En tot slot stelt het andere ketenpartijen in staat om kennis te nemen van architectuurwijzigingen en het belang hiervan voor de eigen organisatie of achterban te bepalen (transparantie in de keten, informatiepositie).

De architectuurscan is uitgevoerd op 15 februari 2018. Zie voor meer informatie, waaronder de adviezen die naar aanleiding van de scan door de Architectuurraad zijn uitgebracht, het adviesdeel en het bevindingendeel.

ROSA onderdeelBevindingen uit project: Onderwijs serviceregisterRelatie met ROSA (blauw: ROSA, geel: Onderwijs serviceregister)
Werkingsgebied

Hele onderwijsdomein. In de eerste fase ligt de nadruk op onderwijsinstellingen en SAAS-leveranciers.

Fullyconformant.pngFully conformant - het werkingsgebied valt samen met het ROSA werkingsgebied ‘onderwijsdomein’

Toepassingsgebied

Ondersteuning van berichtuitwisseling tussen ketenpartijen

Compliant.pngCompliant - het serviceregister past binnen de ketenfuncties Informatieverwerking en Identificatie en toegang

Bovensectorale samenwerking

Het ontwerp van het serviceregister gaat onder andere uit van het doel Terugdringen administratieve lasten en geeft daar invulling aan door de ontwerpkeuzes OK1 Geen extra administratieve complexiteit en OK2 Geen nieuwe koppelvlakken.

Het serviceregister maakt Eenmalige registratie, meervoudig gebruik van serviceinformatie mogelijk. Nu wordt die informatie nog bijgehouden in toepassingsspecifieke “silo’s”.

Onbepaald.pngOnbepaald - In het ontwerp wordt een aantal voorbehouden gemaakt met betrekking tot de mate waarin het serviceregister gerealiseerd kan worden zonder extra administratieve complexiteit. Onvoldoende duidelijk is welke eventuele aanvullende complexiteit intrinsiek door het serviceregister wordt geïntroduceerd, en welke complexiteit het gevolg kan zijn van latere implementatiekeuzes ten aanzien van het gebruik van het serviceregister.

IBP

Het serviceregister stelt kwaliteitseisen aan de geregistreerde informatie in verband met de vertrouwelijkheid van sommige services en de vereiste integriteit van gegevens in het register. RIO is een mogelijke bron voor informatie over onderwijsaanbieders die in het serviceregister aan diensten en aanleverpunten worden gekoppeld. De kwaliteitseisen die het serviceregister stelt zijn daarom relevant voor (de kwaliteit van) de informatie die in RIO is ondergebracht.

Onbepaald.pngOnbepaald - De kwaliteitseisen die voor het serviceregister gelden dienen verder te worden geëxpliciteerd.

IAA

Het ontwerp van het serviceregister doet nog geen uitspraken over het te gebruiken IAA-middel voor toegang door een ‘bevoegde medewerker van een onderwijsinstellig’ en daaraan gerelateerde onderwerpen (e.g., Wie bepaalt bevoegdheid? Hoe wordt dat vastgelegd?)

Het serviceregister is ‘neutraal’ ten opzichte van de te gebruiken PKI-infrastructuur voor publieke sleutels die in het serviceregister worden opgenomen.

Onbepaald.pngOnbepaald - Het ontwerp van het serviceregister doet nog geen uitspraken over het te gebruiken IAA-middel

Gegevensuitwisseling in de keten

Het serviceregister geeft invulling aan het ontwerpkader Serviceinformatie samenhangend openbaar.

Het ontwerp gaat in op de beschrijving van services in termen van ‘waar’ (aanleverpunt/afleveradres) en ‘wie’ (mandateringsrelatie onderwijsaanbieder/dienstaanbieder). Het bestaan en bekend zijn van een service is het uitgangspunt voor gebruik van het serviceregister. Er vindt dus geen registratie plaats van ‘wat’ een service doet.

Gegevens in het OSR zullen worden ontsloten middels een SOAP service, c.q. Edukoppeling. Bij voldoende belangstelling is een uitbreiding naar REST en JSON denkbaar.

Consistent.pngConsistent - Het serviceregister geeft invulling aan het ontwerpkader Serviceinformatie wordt samenhangend openbaar gemaakt.

Gegevens in het serviceregister zijn (deels) vertrouwelijk van aard. Voor deze gegevens is het ontwerpkader Gebruik Edukoppeling voor vertrouwelijke gegevensuitwisseling van toepassing. Het eventuele gebruik van REST/JSON voor niet-vertrouwelijke delen van het serviceregister valt buiten de bestaande ontwerpkaders van ROSA (maar is daarmee niet in tegenspraak).

Ketenprocessen

Het onderwijsserviceregister is een administratieve, technische component die in principe voor alle soortern processen gebruikt kan worden.

Er wordt in het ontwerp een hard onderscheid gesuggereerd tussen ‘binnen’ en ‘buiten’ een onderwijsinstelling. Dat onderscheid is niet (altijd) te maken. F.3 is beschreven als ‘routering naar de onderwijsinstelling’, maar zou juist ook kunnen worden gebruikt voor routering binnen de onderwijsinstelling.

Compliant.pngCompliant - Het onderwijsserviceregister is een administratieve, technische component die in principe voor alle soortern processen gebruikt kan worden

Zeggenschappen en gegevenssoorten

Figuren 1 en 2 in het PvE vertegenwoordigen een andere view (gebruik in H2M2M-keten resp. beheer van de inhoud van het register), maar tonen beide de rol ‘onderwijsprofessional’. De betekenis van die rol is hierdoor onduidelijk.

Zeggenschap in kaart Het serviceregister kent verschillende soorten gegevens: (a) het bestaan van een dienst, (b) het gebruik van een dienst (mandateringsrelatie) en (c) de locatie van een dienst (afleveradres). De zeggenschappen over deze gegevens komen nu vooral in de functionele wensen tot uitdrukking.

Het ontwerp gaat sterk uit van de beoogde situatie in fase 1. Daardoor is bijvoorbeeld nog niet duidelijk wat de impact is op de uit het serviceregister herleidbare mandateringsrelatie tussen onderwijsinstelling en dienstaanbieder wanneer bijvoorbeeld DUO of een andere partij ook aanleverpunten zou gaan registreren.

Nonconformant.pngNon-conformant - de zeggenschappen zijn indirect (via functionele wensen) uitgewerkt en bovendien niet in relatie gebracht tot de beoogde faseringen.

Bouwstenen en voorzieningen

Kenmerken voor routering worden bekend verondersteld (bijvoorbeeld ‘uit eerdere communicatie’). Dat betekent dat het OSR geen koppeltabel levert of bijhoudt tussen bijv. onderwijsvolger en endpoint. In plaats daarvan wordt bij een aanleverpunt een kenmerk opgenomen waarop kan worden gezocht. Dat is een goed uitgangspunt (geen persoonsgegevens in OSR), maar vereist mogelijk wel aanpassingen in bestaande pakketten die nu adresseren op basis van individuele onderwijsvolgers.

Compliant.pngCompliant - Het minimaliseren van persoonsgegevens is in lijn met IBP-principes uit ROSA. Bestaande systemen kunnen blijven werken op de huidige manier totdat aansluiting op het serviceregister opportuun is of vanuit ketensamenwerking wordt gevraagd.

Beheer en (door)ontwikkeling

Uitbreiding Internationaal roept de vraag op of hier een rol is weggelegd voor het serviceregister, of dat een knooppunt bij bijv. DUO, dat door internationale partijen is te bevragen, volstaat. Gaan / kunnen / willen internationale partijen op NL serviceregister aansluiten? Wat betekent dat voor PKI e.d.?

N.v.t. -

Implementatie

Werken bevragingen op het OSR altijd real-time, of wordt de mogelijkheid van een vorm van client-side caching voorzien? Vereist wellicht aanvullende functionaliteiten voor cache-invalidatie (subscription op OSR-events ten gevolge van beheer van serviceinformatie)

N.v.t. -

Deze pagina is vastgesteld door Architectuurraad, op 15 februari 2018.