ONZE INTERPRETATIE VAN HET KNOOPPUNT PLATFORM

Maat: px

Weergave met pagina beginnen:

Download "ONZE INTERPRETATIE VAN HET KNOOPPUNT PLATFORM"

Ferdinand Claessens
8 jaren geleden
Aantal bezoeken:

1 MEMO: ONZE INTERPRETATIE VAN HET KNOOPPUNT PLATFORM Boek.be

2 1 INHOUDSTAFEL 1 INHOUDSTAFEL ALGEMENE INFORMATIE DOCUMENT INFO NASCOM INFO KLANT INFO INTERPRETATIE EN MENING INLEIDING PLATFORMONDERDELEN BEHEREN GEBRUIKEN CONCLUSIES EN VOLGENDE STAPPEN... 8 Boek.be Onze interpretatie van het Knooppunt platfom 2

3 2 ALGEMENE INFORMATIE Dit document is uitsluitend bestemd voor de persoon of entiteit aan wie zij is gericht en kan vertrouwelijke en / of bevoorrechte materiaal bevatten. Het openbaar maken, kopiëren, distribueren of een andere actie op basis van de informatie door personen of andere entiteiten dan de beoogde ontvanger is niet toegestaan. 2.1 DOCUMENT INFO Project Datum Versie Auteur Memo: ons gedacht over het knooppunt platform 14 oktober Wouter Walgraeve (wouter.walgraeve@nascom.be) Erik Willemse (erik.willemse@nascom.be) 2.2 NASCOM INFO Bedrijf Adres Telefoon Fax E- mail Website Nascom nv C- mine 1 bus 13, Evence Coppéelaan 91, 3600 Genk, BE info@nascom.be KLANT INFO Bedrijf Adres Telefoon Contact E- mail Boek.be VZW Te Boelaerlei Borgerhout Goedroen Vanlerberghe goedroen.vanlerberghe@boek.be Boek.be Onze interpretatie van het Knooppunt platfom 3

4 3 INTERPRETATIE EN MENING 3.1 INLEIDING Dit document beschrijft onze interpretatie en meningen over het Knooppunt platform. Het gaat uit van een korte toer doorheen het huidige platform en combineert een aantal ideeën, gevoelens en inzichten met strategische aanbevelingen op basis van onze digitale expertise. Aan de hand van een login op de testomgeving hebben we de huidige infrastructuur en functionaliteiten kort bekeken. We proberen met dit document een antwoord te geven op de volgende vragen: wat is onze interpretatie van het Knooppunt platform? wat zijn de kernblokken? wat zijn de mogelijke moeilijke punten in het vernieuwingsproject? Dit document beschijft kort een visie: hoe ga je een nieuw en toekomstgericht Knooppunt platform bouwen. Naar onze mening kan je dit enkel aan de hand van een gelaagde API- gebaseerde architectuur in combinatie met een programma aanpak en het uitwerken van een roadmap. 3.2 PLATFORMONDERDELEN Het Knooppunt platform bestaat eigenlijk uit twee lagen of blokken met bijhorende (technische) vereisten: beheren van lesmateriaal gebruiken van lesmateriaal Opmerking: het doel van het Three Ships platform ontgaat ons een beetje. We moeten hierover meer uitleg hebben. Ons gevoel zegt dat het een omgeving is waarin het lesmateriaal zelf beheerd wordt maar dat konden we niet helemaal achterhalen wegens foutmeldingen en problemen op het platform. 3.3 BEHEREN Het beheren van lesmateriaal is een interactie tussen School/leerkracht/... en Uitgeverij. Het platform biedt een omgeving waarin een uitgeverij zijn aanbod kan beheren en aanbieden aan afnemers. Scholen en leerkrachten kunnen lesmateriaal activeren/aankopen voor gebruik in de lessen. Dit is op zich een vrij rechttoe rechtaan verhaal van een aankoop tussen twee partijen waarbij validatie van de overdracht gebeurt via controle van activatielicenties. Er zit echter een iets ingewikkelder beheer achter om de structuur van de school te kunnen beheren (school, klas, leerling,...). Ons gevoel zegt dat dit luik een API nodig heeft die open Boek.be Onze interpretatie van het Knooppunt platfom 4

5 staat om te communiceren met AD/LDAP/... zodat structuren kunnen binnen genomen worden vanuit andere omgevingen (zoals bijvoorbeeld Bingel). Concreet betekent dit dat Knooppunt een communicatiemanier moet aanbieden waarmee platformen van derden (i.c. uitgevers) content kan aanbieden. Knooppunt bepaalt de manier van communiceren in de vorm van een API. 3.4 GEBRUIKEN Het gebruik van Lesmateriaal is een wat ingewikkeldere materie. Het gaat hier om applicaties en toepassingen die toelaten om het lesmateriaal te consumeren/gebruiken op verschillende touchpoints. Die touchpoints kunnen verschillende toestellen en/of kanalen zijn. Nu, om een website, een online applicatie, een mobiele app, een slimme TV en dingen (in het kader van The internet of things - concepten) te laten communiceren met één en dezelfde bron aan data hebben we een gelaagde API- gebaseerde architectuur nodig De kracht van API- denken Een application programming interface (API) is een verzameling definities op basis waarvan een digitaal platform kan communiceren met een ander platform of onderdeel. Een API zorgt voor de scheiding tussen verschillende lagen van abstractie, zodat applicaties op een hoog niveau van abstractie kunnen werken en het minder abstracte werk uitbesteden aan andere programma's. Concreter: een API definieert de toegang tot de functionaliteit die er achter schuil gaat. De buitenwereld kent geen details van de functionaliteit of implementatie, maar kan dankzij de API die functionaliteit wel gebruiken. Een voordeel hiervan is dat met een API meerdere implementaties benaderbaar kunnen zijn, zolang deze maar voldoen aan de API. De web platformen zoals Knooppunt worden meer en meer taakgericht en gebouwd met het oog op functionaliteit. De oplossing om hiermee om te gaan is een API als manier om data uit te wisselen. Het openstellen van data biedt kansen om efficiënter en vrijer te werken. Het stelt je in staat specifieke data uit te wisselen met anderen. Je creëert eigenlijk een nieuwe vorm van het platform Een gelaagde API- gebaseerde architectuur Een gelaagde architectuur of opbouw is sowieso cruciaal bij de vernieuwing van een platform zoals Knooppunt. Allereerst hebben we een API nodig die als engine optreedt voor het aanbieden van de oefeningen. We denken dan vooral aan een template engine waarin types oefeningen worden aangemaakt. Neem het volgende eenvoudige voorbeeld: + = is een optel- engine en aan de hand van die engine kan je oefeningen beginnen opbouwen zoals =?, 6 +? = 10,... Hierbovenop moet je een asset engine laag gaan bouwen die je kan gebruiken voor visualisatie van de oefening: Boek.be Onze interpretatie van het Knooppunt platfom 5

6 zes stippen +? = tien stippen, waarbij? kan ingevuld worden met een dropdown, inputfield, drag- drop,... De API- aanpak laat ons toe om los van de context te werken, zodat op een eenvoudigere manier aparte toepassingen kunnen gebouwd worden voor leerkrachten op smartboard, leerlingen op tablet, huistaken op desktop,... Onderstaande illustratie toont hoe zo een gelaagde API- architectuur er kan uitzien. Boek.be Onze interpretatie van het Knooppunt platfom 6

7 3.4.3 API- denken en datastrategie Het succes van een digitale strategie hangt af van hoe je data gaat inzetten. Welke data heb je? En wat ga je er uiteindelijk mee doen? Het definiëren van een datastrategie is geen korte termijn oefening en een antwoord op deze vragen past niet in het kader van dit document. Bovenstaande sketch is dan ook maar een eerste stap naar de architectuur. Tijdens een uitgebreide BUT (Business User Technology) analyse gaan we de (communicatie tussen de) lagen aanpassen aan de noden en verwachtingen van Knooppunt, de gebruikers en de technologische mogelijkheden/beperkingen. Een API als uitgangspunt voor een digitale strategie dwingt je om vanuit een lange termijn strategie te werken. Uit de strategie ontstaat een programma en een roadmap waarin projecten en (deel)projecten kunnen bepaald worden. Een BUT- analyse is onderdeel van onze standaard manier van werken en pas na deze analyse kunnen budgettaire en technische inschattingen gemaakt worden. Boek.be Onze interpretatie van het Knooppunt platfom 7

8 4 CONCLUSIES EN VOLGENDE STAPPEN Inschattingen maken op basis van de huidige informatie is quasi niet mogelijk omdat de gelaagde API- architectuur, de bijhorende datastrategie, de roadmap en de features/requirements nog niet concreet en uitgelijnd zijn. Er moeten sowieso discussies gevoerd worden of de API enkel moet aanbieden of ook oefeningen moet kunnen ontvangen. Er moet een duidelijke onderscheid gemaakt worden tussen de beheerslaag en de gebruikslaag zodat Knooppunt in staat moet zijn om te verwijzen naar lesmateriaal dat in de gebruikslaag wordt aangeboden als lesmateriaal dat door een uitgeverij in zijn eigen platform wordt aangeboden. We denken dat het bijvoorbeeld niet onlogisch zou zijn dat een uitgeverij zoals VanIn het beheerluik van het platform gebruikt om daarna door te verwijzen voor het feitelijke lesmateriaal naar zijn eigen Bingel platform. Nu, dit zijn discussies waarbij een business model canvas (en andere typische Digital Service Design deliverables die Nascom consultants gebruiken) kunnen helpen om keuzes te maken. In al onze voorstellen voorzien wij daarom steeds eerst een discovery traject. De invulling van dit traject valt echter buiten de scope van dit document. Concreet denken we dat we moeten starten met een korte oefening om de verschillende requirements uit te tekenen. Mogelijke deliverables van deze oefening zijn o.a. een Stakeholdermap. Deze analyse leidt tot een conceptueel model en dat resulteert dan op zich in user stories. Een dergelijke oefening lijkt ons doenbaar op 3 à 4 dagen en vereist ongeveer een gelijkwaardige inzet vanuit de verschillende Boek.be stakeholders. Boek.be Onze interpretatie van het Knooppunt platfom 8

Vergelijkbare documenten

MOBILE STRATEGY Mobile strategy, hoe pak je dat aan?

MOBILE STRATEGY Mobile strategy, hoe pak je dat aan? Hoe u bereikt dat mobile een strategisch onderdeel van uw bedrijfsvoering wordt INHOUD Wat is een mobile strategy? 3 Aanpak van een mobile strategy