Groepenmanagement bij de EUR: Update PoC Group Management 2 november 2016 What s Next @ SURFconext Ton Verschuren
Agenda Inleiding Achtergrond Soorten groepen Plaats van GMS in integratielandschap Te testen scenario s Tijdlijnen 2
Inleiding: Groepen bij de EUR Groepen veel gebruikt in primaire proces: werk-, practicum-, communicatiegroepen, e.d. Dus in veel applicaties: Blackboard, SIN Online, EOBS, Osiris, AD, Weinig hergebruik, soms uitwisseling via excelbestanden, geen integratie met I&AM voor beheer toegangsrechten Reden om een verbeterslag te doen binnen de scope van het I&AM+GM-project. 3
Achtergrond: stappen tot dusverre Begin 2015: marktverkenning: groepenmanagement niet binnen I&AM-suites 2-3Q15: opstellen scenario s voor GM 4Q15: requirements voor GMS vastgesteld 2Q16 EA gestart voor I&AM met GMS optioneel 2Q16 opstellen ontwerp PoC GM 3Q16 gunning EA, keuze voor software PoC (Grouper), start PoC 4
Soorten groepen: Bronsystemen en status van groepen Applicaties die groepen bewaren in of distribueren via GMS noemen we hier bronsystemen (los van een eventuele EUR-brede formele betekenis). Voorbeelden: OSIRIS, EOBS, SIN Online. GMS is zelf geen bronsysteem Elke groep in GMS heeft een aanwijsbare bron Uitzondering: ad hoc groepen (en mogelijk: berekende groepen) GMS kent een classificatie van (ten minste) formeel > proces > ad hoc GMS moet voor elke groep de link tussen groep en bronsysteem bewaken en iets kunnen zeggen over level of assurance van een groep ook/juist ter bescherming van doelsystemen groep uit OSIRIS -> bewerken in EOBS -> resultaat heeft de status procesgroep, niet formele groep GMS zelf is niet normatief; doelsysteem bepaalt acceptabele bronnen (en daarmee: acceptabel level of assurance ) 5
Soorten groepen: Generieke groepen en metadata Het GMS werkt met generieke groepen: dezelfde logica voor alle groepen Metadata / attributen: 1. met één basis-set attributen (bedoeld voor GMS-logica en -besturing) in elk geval: verwijzing naar bronsysteem 2. en een blob : een verzameling attribute/value-pairs die ondoorzichtig wordt doorgegeven van bron- naar doelsystemen 3. met daarnaast attributen (obv ervaring SIN Online) die in de meeste groepen van nut zijn: [nog samen te stellen!] Cursuscode, collegejaar en faculteit? Tags per student per faculteit Rol op groepslidmaatschap? Voorbehoud: wat kan de tooling wel en niet? 6
Soorten groepen: Berekende groepen Dynamisch, m.a.w. samenstelling wordt steeds opnieuw bepaald Is extra service aan doelsystemen (want die zouden ook zelf kunnen uitvragen en berekenen) Statische groepen, d.w.z. gefixeerd op bepaalde datum/tijd Aanname is dat GMS daar geen speciale voorziening voor biedt en dus is bronsysteem verantwoordelijk Zeer afhankelijk van wat GMS aan functionaliteit biedt: als bronsysteem alles zelf moet doen is discussie overbodig 7
Plaats GMS in landschap Belangrijk: I&AM+GM-project speelt zich voor de gebruiker grotendeels onderwater af! GMS: backend systeem en onderdeel integratielaag, net als ESB en IDM Bestaande front-ends (SIN Online, EOBS) wijzigen niet! Wel wijzigt: opslag van groepen: van EOBS, SIN, naar GMS 8
Architectuur PoC 9
Te testen scenario s: Onderwijs- en practicumgroepen algemeen Op cursusniveau zijn alle studenten bekend. Een subset wordt opgedeeld in onderwijsgroepen, een andere subset wordt opgedeeld in practicumgroepen, de onderwijsgroepsindeling komt niet overeen met de practicumgroepsindeling. Via een GUI (= in EOBS of SIN Online) worden de onderwijs- en practicumgroepen samengesteld en opgeslagen. Dit resultaat wordt platgeslagen gepubliceerd naar GMS: Attributen worden weggelaten of vereenvoudigd Natuurlijke groepen worden indien nodig (*) afgebeeld op rolhomogene groepen 10 (*) als het GMS geen ondersteuning biedt aan natuurlijke groepen = vastlegging van rol bij groepslidmaatschap
Te testen scenario s: Provisioning naar cloud (Project Campus) Project campus is een clouddienst die beschikbaar is via SURFconext. Groepsinformatie van onderwijs- en practicumgroepen (samengesteld op basis van studenten en docenten) dient geautomatiseerd te worden provisioned zodat er binnen een cursus een samenwerkingsomgeving beschikbaar is voor elke onderwijs- en practicumgroep. Via een API vraagt Projectcampus 1x per dag de groepsgegevens op van het GMS. In deze groepsgegevens zit per user een kenmerk welke rol deze heeft. Zodra een user voor de eerste keer aankomt bij ProjectCampus wordt deze middels de SSO herkend en meteen geactiveerd en aan zijn/haar groepen toegekend. 11
Te testen scenario s: Gepersonaliseerd cursusrooster -> Eveoh Nog vast te leggen: wat is de informatiestroom van Syllabus+ via Eveoh, zodat het functionele doel wordt bereikt:...uiteindelijke samenstelling van onderwijs- en practicumgroepen komt uit EOBS......en individuele student ziet het rooster met alle activiteiten die voor hem geroosterd zijn. 12
Te testen scenario s: Integratie met SIN Online Onderwijs- en practicumgroepen kunnen worden verrijkt met groepen ondersteuners (onderwijsburo, examencommissie, studie-adviseurs). Groepen kunnen cursusspecifiek danwel cursusoverstijgend worden samengesteld. De groepen worden vervolgens met de juiste attributen naar GMS gepubliceerd. Vanuit het GMS zullen deze direct gepushed worden naar SIN zodat individuen in de groep berichten kunnen schrijven danwel ontvangen. 13
Tijdlijnen PoC: oktober december Evaluatie & voorstel vervolg: december/januari Indien succesvol: Vinden eigenaar, FB, TAB In Fase 2 van I&AM+GM-project realisatie (2H17) Op zijn vroegst operationeel 3Q17 14