Ik was afgelopen dinsdag ingegaan op de uitnodiging van het BVE-Platform om aan te schuiven bij de EduArte Gebruikersgroep. Alhoewel mijn ROC dit ‘pakket’ niet heeft aangeschaft is zo’n dag een bron van ‘authentieke’ informatie die ons helpt bij de oriëntatie op de opvolger nOISe.
Nu zou ik een hele waslijst van functionaliteiten kunnen noemen die er onlangs bij zijn gekomen in het pakket. Maar dan zit ik op ‘knopjes’-niveau van een pakket dat nog in ontwikkeling is. Dat bespaar ik jullie. Er zijn me wel een aantal punten heel erg opgevallen.
‘Vroeger’ toen alles nog onverzichtelijk was, zat de wereld eenvoudiger in elkaar: 1 applicatie, 1 leverancier en 1 gebruikersorganisatie. De laatste is zo’n typische ITIL/BiSl term die eigenlijk staat voor een vertegenwoordiging van alle klanten of eindgebruikers. Deze groep dient als klankbord voor de leverancier en tevens kunnen klanten onderling ervaringen uitwisselen over implementatie-trajecten.
Maar nu is er sprake van een ‘applicatielandschap’ waarop verschillende leveranciers functionaliteit kunnen bieden op, gedeeltelijk, overlappende onderdelen. Voor het gemak pak ik even de bollenplaat erbij van TripleA.
TripleA heeft de aanbesteding gedaan voor de Kernregistratie. De gunning is gegaan naar Educus, een samenwerking van Topicus en Stoas. Zij bouwen, respectievelijk vermarkten Eduarte. Volgt u het nog? Maar EduArte levert ook een onderdeel Participatie, Competentiemeter en Deelnemersbegeleidingssysteem, volgens deze releasekalender.
TripleA zit ondertussen niet stil, want de rest van het applicatielandschap moet ook ingevuld worden. Dan moet je “eerst weten wat je wilt”. Die omschrijving noemen we “Functioneel Ontwerp” en zijn na enig zoekwerk hier terug te vinden. Ook deze andere onderdelen gaan aanbesteed worden. Daar kunnen ook andere ROC’s weer aan mee doen. Daar kunnen ook andere leveranciers weer op gaan reageren.
Om tot mijn punt te komen: hoe organiseer je in de toekomst gebruikersgroepen van onderdelen van het applicatielandschap dusdanig, dat de functionaliteitsbehoefte en informatievoorziening geborgd blijft? Op elk blok van het model kunnen meerdere leveranciers zitten. Andersom: gaan ROC’s elkaar in wisselende samenstelling ontmoeten op onderdelen van dit model? Zodat de samenwerking vruchten afwerpt?
Wat ik erg positief vindt: de functionele ontwerpen zijn met subsidiegeld gemaakt en worden daarom vrij ter beschikking gesteld. Of je nu samen aanbesteed of niet. Daar maken ook wij dankbaar gebruikt van.
Daarnaast heeft TripleA het voor elkaar gekregen dat zowel de onderwijscatalogus als de kernregistratie open-source worden. Dit vind ik een grote stap, omdat het in de toekomst de mogelijkheid biedt van leverancier te wisselen zonder last te hebben van de klassieke vendor lock-in. Tevens biedt het andere leveranciers de mogelijkheid om in de SOA architectuur aan te sluiten en hun functionaliteit geïntegreerd aan te bieden.