Category Archives: Architectuur

GAP Analyse met TripleA als referentiearchitectuur

Het nut van referentiearchitectuur in de praktijk wordt concreter voor mij. Daarom hieronder enkele ervaringen tot nu toe.

Eerst even een situatieschets: voor een deel van onze organisatie hebben we een vrij groot flankerend systeem voor het registreren van studenteninformatie. Om allerlei redenen is de functionaliteit in de loop van de tijd toegenomen. Echter, het kan niet het leidende systeem zijn zoals ons KRD (nu nOISe, straks EduArte), omdat er o.a geen koppeling met DUO plaatsvindt.

Het nadeel van deze situatie: twee systemen met op onderdelen dezelfde functionaliteit. Twee keer onderhoud, twee keer licentiekosten, twee keer ontwikkeling en zelfs hier en daar dubbele administratieve handelingen.

Het is niet mogelijk om zómaar het ene systeem in te ruilen voor het andere. Om überhaupt iets zinnigs te kunnen zeggen, is een gap-analyse nodig die de verschillen én overeenkomsten toont. Dit maakt het mogelijk om op onderdelen een strategie te bedenken.

Aanpak voor de analyse op functionaliteit:

Verzamel overzichten van alle functionaliteit van het te analyseren systeem. Soms zijn deze geordend als use cases, soms als modules met onderdelen. Of overleg met applicatiebeheerders.
Maak een tabel met daarin alle use cases, zoals die uit de TripleA encyclopedie komen, gegroepeerd naar katern.
Zoek van elke use case op of dit proces ondersteund wordt door de functionaliteit van het systeem.
Vink deze aan, eventueel met aanvullende opmerkingen.
Verder maakten we onderscheid of functionaliteit nú aanwezig is, of deze ook daadwerkelijk geïmplementeerd is, of dat het op de roadmap voor volgende versies staat.

Aanpak voor de analyse op architectuur:

Verzamel documentatie over het te analyseren systeem of overleg met applicatiebeheerders.
Maak een tabel met daarin de eisen vanuit de Business, Informatie en Technische Arcitectuur.
Analyseer in hoeverre het systeem voldoet aan deze eisen en vink deze aan, eventueel met kanttekeningen.

Randvoorwaarde is wel dat er van te voren een referentiearchitectuur gekozen is! Uiteindelijk leidde deze lijst tot een advies waarin enkele scenario’s genoemd worden voor de toekomst.

Architectuur: 4x nuttig

Op de overdrachtsconferentie TripleA nam ik deel aan een aantal korte thematafel’s. Één daarvan was “Structuur door Architectuur”. Er kwamen 4 voorbeelden voorbij waarin het gebruiken van architectuur handig is. Helemaal als deze architectuur al omschreven is en je die kunt lenen. Omdat deze voorbeelden zo aansluiten bij mijn eigen ervaringen neem ik ze hier rechtstreeks over:

Basis voor aanbesteding: De TripleA architectuur omvat een verzameling principes, richtlijnen en technische eisen die de basis kunnen zijn voor eisen in een aanbesteding. Op deze manier hebben we het zelf ook gebruikt, als onderlegger voor een Programma van Eisen en Wensen.
Project Start Architectuur: Beoogde projecten kunnen op de TripleA architectuur worden “afgebeeld”. Van nieuwe initiatieven kan bekeken worden of ze in de architectuur passen. Wat ik frappant vind is dat je met een aantal platen onder de arm heel veel zaken een plek kunt geven. Het eenvoudige feit dat je een nieuw idee of initiatief kunt aanwijzen, een visueel plekje kunt geven op een procesplaat of applicatielandschap werkt erg verhelderend. Het bevordert sterk de samenhang van dingen.
Referentiearchitectuur: De modellen, principes en richtlijnen kunnen gebruikt worden om de generieke structuur te vertalen naar de eigen situatie.
Diagnose instrument en roadmap: De eigen processen en applicaties kunnen gestructureerd worden conform de architectuurmodellen. Eventuele knelpunten komen zo boven drijven. Vervolgens legt dit de basis voor stapsgewijze vernieuwing.

Overdrachtsconferentie TripleA

Ik ben vandaag bij de “Overdrachtsconferentie” TripleA, in het ADO stadion. Onze instelling heeft van het gedachtegoed van TripleA en de encyclopedie dankbaar gebruik gemaakt, ook tijdens onze aanbesteding. Alle ontwerpen zijn voor ons onmisbaar gebleken tijdens het proces dat we intern hebben doorgemaakt. Vandaar dat ik een beetje bezorgd was toen ik hoorde dat TripleA ging stoppen, als organisatie. Dat bleek voor niets te zijn: het gedachtegoed wordt overgedragen aan saMBO~ICT. Gelukkig maar, want wij hebben nog veel te doen op de rest van ‘de plaat‘.
John van der Meulen opende de conferentie met een stukje geschiedenis en Ben Geerdink van saMBO nam de bal over. Deze zal gekoesterd worden, volgens Ben. De overdracht zelf is niet alleen die van het ‘product’, maar nog belangrijker, ook die van de werkstijl en ‘community’. Ik ben daar blij mee omdat de verdere ontwikkeling dan geborgd is. De architectuur die is ontworpen is, hoe waardevol ook, altijd een momentopname. Aangezien het product een CC licentie kent, staat niets verdere ontwikkeling in de weg.
De community kenmerkt zich door snelle samenwerking, korte doorlooptijden, ontwikkeling in relatief kleine groepen, brede beschikbaarheid van de producten. Ben vermeld wel dat de ambities verder reiken dan het beschikbare geld op dit moment. Vooralsnog gaat saMBO “toch hard aan de slag ermee”.

Bas Kruiswijk gaat verder met de stand van zaken TripleA. Er zijn 2 addendum’s verschenen:

Functioneel Ontwerp bij het deel Kernregistratie Deelnemers. Het addendum bevat de uitwerking voor domeindeskundigen en een aanvulling van het technische gedeelte.
Prototype Roosteren: een aanvullend onderzoek naar complexiteit en haalbaarheid van de roostermachine. Het vermeld o.a. 2 oplosstrategieën (wiskundig). Daarna is een werkend prototype gemaakt: CourseTT. Het kan veel, wiskundig, maar het is nog geen direct implementeerbare oplossing. Het is wel mogelijk dat er laboratoriumexperimenten meer gedaan worden of dat het wordt aangeboden aan een leverancier. CourseTT is open source.

Tot slot werd de gouden encyclopedie uitgereikt aan Paul Meltzer als grootste supporter!

Jan Bartling volgde met een schets van hoe saMBO~ICT verder gaat met de encyclopedie. De echte werkelijkheid is namelijk dat binnen de implementatie van het hele ontwerp de nadruk nog steeds ligt op KRD. Alle overige terreinen (Onderwijslogistiek, Ondersteuning Primair Proces, etc.) dienen komende tijd meer in beeld te komen. Jan gaf ook een kort overzicht van de stand van Onderwijslogistiek. En verder naar de toekomst kijkend: zijn onze applicaties ook in de toekomst afbreekbaar? Want in de levenscyclus van alle software komt na ‘volwassenheid’ toch echt de afbreek-fase. En die vergt een eigen aanpak. Veel hangt samen met het beleidsplan van saMBO~ICT.

Ik wens saMBO~ICT veel succes!

http://sites.google.com/a/sambo-Addendum Prototype tosterenict.nl/sambo-ict/nieuws/conferentieoverdrachttripleanaarsamboict

Scenario’s als hulpmiddel bij functioneel ontwerpen

Ik was vandaag bij de bijeenkomst “Onderwijslogistiek – Van Plan naar Realiteit”. De 6 instellingen die zich verenigd hebben voor het uitwerken van het functioneel ontwerp Onderwijslogistiek toonden de eerste resultaten. Het eindproduct wordt op 15 juni gepubliceerd. De basis blijft het TripleA ontwerp hiervoor.

Waarom niet ‘gewoon’ het Functioneel Ontwerp overgenomen zoals dat er lag? Gedeeltelijk vanuit pragmatisme. Het deel Onderwijslogistiek van de TripleA encyclopedie is ontworpen met een punt op de verre horizon in gedachte. Mijn samenvatting ervan:

Een systeem dat massamaatwerk levert door op grote schaal voortdurend dynamisch de veranderende individuele leervraag te matchen met het onderwijsaanbod èn de benodigde resources. Tussentijds business rules checkt en daarna een rooster produceert.

Dit blijft ook nu nog raketwetenschap. Niet zozeer het technische gedeelte. Er schijnen wiskundige algoritmen en oplossingen voor te bestaan. Maar wat het vergt van de organisatie, dat gaat veel verder. Te ver voor de staat van ontwikkeling nu, dus. Maakt dat het deel in de encyclopedie onbruikbaar? Nee, omdat veel van de omschreven use-cases (21) opzich wel voorkomen in een bepaalde vorm. Ook in de huidige organisaties. De mate waarin en de vorm verschilt echter. Enter scenario’s! Hoe werkt dat:

Verzin 4 dimensies, dimensies waarin organisaties kunnen verschillen. Bijvoorbeeld “Schaal van organiseren”
Maak voor elke dimensie een schaalverdeling met kenmerken.
Groepeer een aantal voor de hand liggende combinaties van kenmerken. Noem dit een scenario.
Werk zo meerdere scenario’s uit.
Vertel van elke use case uit het functioneel ontwerp hoe deze verder ingevuld wordt, voor elk scenario.
Vraag aan de markt of er dit is of kunnen bouwen.

Het resultaat mag dan liever niet een voor elk scenario apart gebouwd systeem zijn. De hoop is dat (groepen) functionaliteiten aan of uit gezet kunnen worden, al naar gelang de kenmerken van een organisatie. Het voordeel, volgens mij:

Het komt tegemoet aan verschillen tussen onderwijsinstellingen. Verschillen op het gebied van flexibiliteitswensen, cultuur en strategie.
Het geeft ruimte om naar de toekomst toe wel te groeien naar meer flexibiliteit en massamaatwerk.

De presentatie en het boekje dat werd verspreid is hier terug te vinden. Overigens is er 24 juni een vervolg tijdens de conferentie “Overdracht TripleA naar saMBO~ICT”. TripleA als organisatie stopt, het gedachtegoed leeft verder, onder vlag van saMBO.

Kijk voor het verslag van Willem Karssenberg hier.

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

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.

Spagaat: Losse tools of monoliet

Willem reageert op de vorige post terecht:

“Dus als tool vast handig, maar we zijn niet meer op zoek naar losse tools.”
Dus daar zijn jullie het al over eens? Voor mij is dat nog steeds de vraag:
Een aantal losse tools die heel goed zijn in waar ze voor gebouwd zijn en ook niet meer dan dat heeft ook zo z’n voordelen! Als al die losse tools dan vervolgens maar goed met elkaar kunnen “babbelen”.

De kern zit hem zeker in het “babbelen”!

Maar eerst even de spagaat toelichten: Aan de ene kant is gebleken dat grote monsterapplicaties die alles willen kunnen, niet werken. Na verloop van tijd worden ze te complex om snel te kunnen aanpassen aan veranderende processen. Aan de andere kant: als je voor elk stukje functionaliteit een tool in huis haalt, dan is door de wildgroei het totaal niet meer te beheersen. Daarnaast hebben leveranciers van tools de neiging om de functionaliteit uit te breiden, per stuk te portaliseren en voor je het weet zit je met een heel portal-landschap van applicaties die min of meer hetzelfde kunnen.

Nu het babbelen: oudere tools kunnen vaak wel babbelen met elkaar door bijvoorbeeld database connecties of interfaces tussen 2 tools te bouwen. Nadeel: per combinatie van tool is dit vaak custom werk.

Wat nu als de manier van het babbelen bij voorbaat is gedefinieerd? Dan is er per tool maar 1 interface te bouwen. Tussen de tool en de babbelstandaard en niet tussen elke mogelijke combinatie van tools.

Dit is er natuurlijk al lang, zie SOA en webservices.

Dan zouden tools zich kunnen beperken tot één ding waar ze goed in zijn, en dat als een service aanbieden. Van leveranciers vraag je dan geen los te distribueren applicatie, maar een webservice die gepubliceerd wordt voor je andere webservices.

Zoals Google gaat doen door zijn API nog meer open te stellen waardoor straks websites webservices kunnen koppelen aan Google tools. De specifieke functionaliteit van een tool wordt hiermee gehangen in een groter geheel (van Google).