Archive for the ‘Architectuur’ Category.

Standaarden in competentiemodellen

Via de nieuwsbrief van EduStandaard kwam het verslag “Vertaling Competentiemodellen” binnen. Het is geschreven door Jos van der Arend en Bas Jonkers:

“Dit verslag beschrijft de resultaten van de inventarisatie naar vertaling van competentiemodellen. Kennisnet voorzag een sterk toenemende behoefte aan vertalingen tussen competentiemodellen. Doelstelling van de studie was om te komen tot een methodiek om vertalingen van competentiemodellen mogelijk te maken.
Om de problematiek helder te maken is gestart met een verkenning naar mogelijke competentiemodellen. Vervolgens zijn een algemeen competentiemodel‐vertalingsmodel en algemene gebruikscenario’s beschreven.
Met het vertalingsmodel en deze gebruikscenario’s zijn een aantal relevante belanghebbenden in het MBO‐domein benaderd en ondervraagd over de vertaalbehoefte. Conclusies zijn dat er in het MBO‐domein niet veel behoefte is aan vertalingen. Hét competentiemodel binnen het MBO is de Competentiegerichte Kwalificatiestructuur (CKS) van COLO.”

Ten eerste toont deze conclusie indirect de rijpheid van het CGO gedachtegoed aan. Het komen tot standaarden is een moeizaam proces en meestal eindig je met meerdere ’standaarden’. Het verslag zegt verder dat het algemeen geaccepteerd is en er groot draagvlak voor is.

Verder is het verslag nuttig voor wie een overzicht wil hebben van alle modellen, frameworks en standaarden die er zijn: ERK, EQF, ECS, e-CF, HR-XML, ICOPER, IEEE WG20, IMS RDCEO. Ik ben niet alleen gek op modellen, maar ook op afkortingen ervan ;) . Verder dan alleen een opsomming worden deze gerelateerd (zie afbeelding).

Conclusies:

Competenties bevinden zich in het spanningsveld tussen opleiding en beroep (domein leren respectievelijk werken). Wil het deze brugfunctie vervullen, dan zijn vertalingen van en naar deze deelgebieden onvermijdelijk.” Maar:

“Een korte inventarisatie binnen en buiten Kennisnet gaf aan dat er op dit moment nog niet erg veel behoefte is aan vertalingen in het voortgezet onderwijs (VO) en het middelbaar beroepsonderwijs (MBO). Binnen het VO wordt nog niet veel gebruikgemaakt van competentiemodellen, binnen het MBO (en ook een beetje het VMBO), is er één algemeen geaccepteerd, centraal competentiemodel: Competentiegerichte Kwalificatie Structuur (CKS) van COLO.”

Architectuur: noodzakelijk stuurinstrument voor BVE-bestuurders

Architect

Ik was vandaag te gast bij ROC Midden Nederland voor alweer de derde Markt van Leveranciers. Georganiseerd door het BVE-Platform, of nauwkeuriger: onder de vlag van saMBO~ICT. Onze instelling is al een tijd zich aan het oriënteren op een opvolger voor nOISe. Deze markt ging niet alleen over kernregistratie, maar ook onderwijslogistiek en andere terreinen van planning en organisatie.

De openingslezing werd gehouden door Daan Rijsenbrij. Met als titel: “Architectuur, noodzakelijk stuurinstrument voor BVE-bestuurders”.

Daan opent met de kreet: “Je kunt niet zonder architectuur!” en de vraag of dat geen flauwekul is. Daan ziet vaak dat er wel een (referentie)architectuur wordt gebruikt, zonder dat de noodzaak eigenlijk bekend is. Architectuur is geen “IT-feestje”. Hij schetst een linkeroever met een hiërarchische instelling en losse IT systemen en een rechteroever met genetwerkte systemen in een webachtige instelling.

Vervolgens komt Daan met een open vraag: “Waarom blijven ontwikkelingen hangen?” Stilte in de zaal, toch twee reacties: Jaap de Maare oppert als probleem “decentrale inspraak zonder regie” en een ander “te weinig jonge mensen”.

Daan zelf:
- We durven niet te investeren, kost gaat voor de baat uit.
- Onvoldoende architectuur aanwezig om het op een verantwoorde manier te doen.
- Er is een vloedgolf van nieuwe technologieën.
- Er is een vloedgolf aan eisen en wensen: betere service, nieuwe regelgeving, CGO, lagere kosten, plaatsonafhankelijk leren etc.

Vervolgens pleit hij ervoor om het doel van architectuur scherp te hebben: het biedt een atlas, het helpt complexiteit te verminderen, het is kaderzettend voor de realisatie en het is een communicatiemiddel. Hij geeft ook een definitie van architectuur: “Het schrijft voor hoe een onderneming de informatievoorziening, de applicatie-architectuur en de infrastructuur wordt vormgegeven, dient te worden gebouwd en zich voordoet in gebruik”.

Waarbij de metafoor de volgende lagen kent:

  • stadsplan = schoolorganisatie
  • wijkplan = domein
  • gebouwontwerp = informatiesysteem
  • de ‘binnenhuisarchitectuur’ in deze metafoor is meestal nog in een beginnend stadium.

Verder merkte ik enkele tips op:

  • visualisaties zijn belangrijk (hij onderscheid er 6).
  • let op bij aanschaf van pakketoplossingen: elk pakket heeft een inherente architectuur, als deze je niet duidelijk is, besef dan wel dat je deze cadeau krijgt! En consequenties heeft.
  • start met eigen architectuur.
  • laat de leverancier zijn architectuur tonen.
  • referentiearchitectuur is belangrijk: je hoeft niet het wiel opnieuw uit te vinden.
  • onderzoek de aanpasbaarheid/veranderbaarheid van een pakket.
  • laat architectuur eigendom zijn van businessmanager niet van IT.
  • architectuur dient volledig begrijpbaar te zijn, ontdaan van technische termen.

Valkuilen om te vermijden:

  • Architectuurprincipes vermelden zonder aansluiting bij het ontwerp zinloos. Als het niet aanwijsbaar is, laat het dan weg.
  • Soorten architecten door elkaar halen: de term architect is aan erosie onderhevig. Als je jezelf serieus neemt, dan noem je jezelf architect. Er zijn echter kaderstellende (enterprise en domein) en oplossings- architecten.
  • Niet weten waar je architecten zitten.

De hele presentatie is hier te vinden.

Al met al heb ik er enkele nuttige dingen uit kunnen halen. De presentatie zelf maakte echter een rommelige indruk, de lijn van het verhaal werd niet duidelijk. Ook de manier van presenteren leek van de hak op de tak te gaan, met een verzameling gedateerde sheets, ogenschijnlijk, willekeurig bij elkaar gezet. Samenvattend had ik het idee dat de presentatie “te hoog over vloog”. Helemaal toen er geen enkele vraag bleek te komen uit het publiek. Ook niet toen men daartoe uitgenodigd werd. En dat is een veeg teken: een publiek dat geen enkele reactie vertoont is meestal een signaal dat de boodschap niet overgekomen is.

Dat vind ik jammer omdat de timing en keuze van dit onderwerp binnen de BVE instellingen zeker niet te vroeg komt.

Onderwijslogistieke deel van de bollenplaat

OK, welke bollenplaat bestaat er nu uit rechthoeken? Soms ontstaat een bijnaam uit de vorm van model-onderdelen die later shape-shiften.

Het was voor mij de eerste kennismaking met het gedeelte onderwijslogistiek binnen de bollenplaat. De kernregistratie kennen we wel zo’n beetje. De processen binnen onderwijslogistiek zijn als volgt samen te vatten:

  • Na het maken van een overeenkomst of na signalen uit het begeleidingsgedeelte wordt een leervraag geformuleerd. Deelnemer en zijn vraag centraal dus.
  • Vervolgens wordt gekeken vanuit de onderwijscatalogus of er inhoudelijk een aanbod gedaan kan worden aan de student.
  • Daarna gaat er een zogenaamde “roostermachine” aan de gang. Niet zozeer een roosterprogramma in de traditionele betekenis, maar eentje die kijkt naar het passende aanbod aan de ene kant en de beschikbare resources (personeel, financieel, facilitair etc) aan de andere kant. Oftewel vraag, aanbod en randvoorwaarden ontmoeten elkaar.
  • De manier waarop deze machine zaken doorrekent of plant hangt samen met de “business rules” van een instelling. Deze uitgangspunten bieden een kader waarbinnen de matching plaatsvindt en eventueel knelpunten naar boven komen.
  • Het niet kunnen faciliteren van een vraag en bijbehorend onderwijsaanbod doorloopt vervolgens een apart proces. Er is immers al een overeenkomst met de deelnemer.
  • Als gedurende de ontwikkeling van een student een veranderende vraag ontstaat gaat de machine weer aan de slag.

Eigen indruk: het “machientje” dat voordurend intelligent omgaat met veranderende vragen van een individu en hierop resources matcht is in mijn ogen raketwetenschap. Tegelijkertijd is het het hart van de logistiek. Dit soort geavanceerde functionaliteit wordt wellicht ook geboden in de wereld van transportlogistiek.
Tegelijkertijd vraag ik me af of dit alleen nodig is omdat het oplossingen biedt voor complexheid die we zelf organiseren. Als er ruimte is voor zelforganiserend vermogen van kleinere teams dan speelt dit wellicht minder. Dus de schaal waarop iets gepland of gematcht wordt speelt een rol.

Vanuit TripleA is men nu bezig om het programma van eisen verder uit te werken. Dat gebeurt door deelnemende instellingen gezamenlijk. Onduidelijk is nog in hoeverre ook de implementatie gezamenlijk wordt uitgevoerd.

Sectorarchitectuur

Tijdens de ELD bijeenkomst vorige week kwam ik de volgende slide tegen met de titel “Sectorarchitectuur”:

Even googlen laat zien dat dit in november 2007 al gepresenteerd (blz 13) is door Bram Gaakeer, medeauteur van NORA (Nederlandse Overheid Referentie Architectuur). Deze voorstelling van infrastructuur is overigens niet operationeel, maar als richting van ontwikkeling vindt ik het wel een interessante.

  • Het komt tegemoet aan het overheidsbeleid: de eigen informatiesystemen zijn er voor de informatiebehoefte van de overheden zelf, daarnaast zal elke sector zijn eigen informatiesysteem of infrastructuur moeten ontwikkelen. Hier voor de sector onderwijs voorgestelt door het bovenste blokje (PO, VO, BVE en HO) met als eigen ‘tonnetje’ de schooladministraties.
  • Deze architectuur schetst een verregaande portalisering met toegang voor zowel instelling als deelnemer (via DigID natuurlijk). 
  • In deze architectuur zou verticaal ruimte zijn voor andere sectoren: bijvoorbeeld de zorg met de zorginstellingen, schakelpunt en portaal.
  • Als ik het goed heb stellen de gele paden dan de platforms waarop informatie wordt uitgewisseld, voor.
  • Dit model zou het aantal “dubbele kruisverbanden” verminderen: nu lever je als onderwijsinstelling informatie aan, aan CFI, IB Groep, Inspectie, gemeentes etc. Elk op een verschillende manier in een andere vorm. Enige consolidatie op dit gebied zou fijn zijn, op zijn zachtst gezegd.

Is dit eng in termen van privacy? Weet ‘men’ dan niet alles over ‘je’? ‘Men’ is hier een heel conglomeraat van belanghebbenden die op bepaalde gedeeltes van de infrastructuur informatie leveren en opvragen. Het wil niet zeggen dat ‘alles’ voor ‘iedereen’ beschikbaar komt. Er zal altijd informatie zijn die binnen een instelling blijft en zich laat tonen aan de deelnemer via de portal. Of informatie die binnen een sector blijft etc. Het wil niet zeggen dat alles zijn weg vindt naar andere schakelpunten.

Pluspunt: je hoort wel eens getallen over het aantal databases waarin je geregistreerd staat. Cijfers lopen uiteen maar spreken meestal over honderden. Dat zou zo i.i.g. minder kunnen worden.