Over mij

Ik ben Richard Steijn en datawarehousing/BI specialist. Bij vele organisaties in diverse branches heb ik een kijkje in de keuken mogen nemen. Verscheidene technologieën hebben mijn pad gekruist. Data en alle vraagstukken daaromheen vormen een rode draad in mijn werkzame leven. In deze blog schrijf ik over de dingen die mij zoal bezighouden.

door Richard Steijn

Archief voor 'Data Warehouse'

Everytime we load, we lose a little

Managementinformatie wordt gemaakt op basis van data afkomstig uit een of meer bronsystemen. Tussen het moment van het onttrekken aan het bronsysteem en het moment van afleveren van managementinformatie bij de eindgebruiker kan de ruwe brondata aan verschillende transformaties worden onderworpen. Niet zelden wordt er in dit proces gebruik gemaakt van een of andere vorm van historische data opslag. Een belangrijke reden om datahistorie te bewaren is dat dit ons in staat stelt om op ieder gewenst moment eerder geproduceerde managementinformatie exact te kunnen reproduceren. Zo kan de gebruiker, op een later tijdstip verdere analyse uitvoeren op dezelfde cijfers als destijds. Dit wordt ook wel het non-volatility principe genoemd.

Binnen verschillende BI architecturen wordt op verschillende manieren omgegaan met brondata, het bewaren van historie en de transformaties die nodig zijn om van ruwe brondata managementinformatie te maken. De ene architectuur is er primair op gericht informatievragen die hier en nu spelen te kunnen beantwoorden en bevatten geen voorzieningen voor non-volatility.  Andere architecturen zijn ambitieuzer van opzet en garanderen wel non-volatility en houden tegelijkertijd rekening met het gegeven dat bronsystemen kunnen wijzigen evenals de informatiebehoefte van de gebruikers van managementinformatie. Alles daar tussenin is uiteraard ook mogelijk.

Verlies van historie

Bij de meeste BI architecturen kan informatie verloren gaan over de historie en herkomst van de brondata. Dit is altijd het gevolg van het transformeren van data waarbij de uitkomst van de transformatie wordt bewaard maar de data die als input voor de transformatie diende niet. Voor de meeste BI specialisten is dit gesneden koek (mag ik hopen), echter voor de business, de eindgebruiker van de BI architectuur, is dit lang niet altijd het geval (We hebben een datawarehouse dus we bewaren de historie van al onze data…). Daarom is het goed om eens te benoemen wat er allemaal gebeurt met de data uit de operationele systemen voordat het uiteindelijk is getransformeerd naar bruikbare management informatie.

Manieren om data historie te verliezen

Hieronder beschrijf ik aan welke transformaties data binnen een BI architectuur onderworpen kan worden en hoe dit tot verlies van data historie kan leiden.

Data cleansing

Dit is het opschonen van data door het toepassen van kwaliteitsregels alvorens deze data in het datawarehouse worden geladen. Er zijn verschillende situaties die er toe kunnen leiden dat een data item niet in het datawarehouse terecht komt:

  • Er treden problemen op bij het converteren van velden van het ene gegevenstype naar het andere. Bijvoorbeeld: Een orderregel in het bronsysteem heeft een veld ‘Orderdatum’ van het gegevenstype ‘Tekst’ met de waarde ‘1 januari Z012’. Deze waarde kan niet geconverteerd worden naar het gegevenstype ‘Datum’ hetgeen noodzakelijk is om het op te kunnen slaan in het daarvoor bestemde datumveld de historische data opslag.
  • Door het niet laden van onbestaanbare informatie. Bijvoorbeeld een orderregel met een negatief te factureren bedrag.
  • Door het niet laden van informatie met ontbrekende sleutelwaarden. Bijvoorbeeld een record met persoonsinformatie waarvan het burgerservicenummer ontbreekt kan niet worden geladen omdat binnen het datawarehouse de entiteit persoon uniek identificeerbaar moet zijn met het burgerservicenummer.
  • Door codes die niet bekend zijn in het datawarehouse, te vervangen door een standaardwaarde. Bijvoorbeeld een orderregel met een onbekende productcode die vervangen wordt door de waarde ‘UNKNOWN’ alvorens hij wordt opgeslagen in het datawarehouse.

Data integratie

Dit is het samensmeden van gefragmenteerde data tot een geheel. Ik onderscheid twee vormen van data integratie:

  • Intra bronsysteem integratie. Dit is integratie van data die op verschillende momenten wordt onttrokken aan hetzelfde bronsysteem.  Als bij dit type data integratie historische informatie verloren gaat, is dit doorgaans een bewuste keuze. Soms wordt er bewust gekozen voor het niet of slechts deels opbouwen van een tijdslijn van een entiteit, bijvoorbeeld omdat dit geen business belang dient. Echter soms gaat het hier ook onvoorzien mis doordat sleutelvelden niet stabiel in de tijd zijn. Bijvoorbeeld: Stel we hebben een productregistratiesysteem waarin de producten uit het assortiment, zijn gedefinieerd. Het systeem dwingt af dat ieder product een unieke productcode toegewezen krijgt. Bij eerste invoer krijgt het product de unieke code ‘PRODUCTA’ toegewezen. Vervolgens wordt deze informatie geladen in het datawarehouse waarbij de productcode als unieke sleutel wordt gebruikt. Weer wat later komt men erachter dat de code foutief was en daarom wordt deze vervangen door een andere, eveneens unieke code ‘PRODUCTB’. Als vervolgens ook deze informatie wordt geladen in het datawarehouse, dan wordt de tijdslijn van het product met code ‘PRODUCTA’ niet voortgezet. In plaats daarvan wordt een nieuwe tijdslijn gestart voor het product met code ‘PRODUCTB’. Het feit dat product met code ‘PRODUCTA’ hetzelfde product betreft als het product met code ‘PRODUCTB’ gaat hier verloren.
  • Bronsysteem overstijgende integratie. Dit is integratie van data die wordt onttrokken aan verschillende bronsystemen om zo een compleet beeld te creëren van een entiteit waarvan data gedistribueerd is opgeslagen. Bij dit type data-integratie kan historie verloren gaan als het integratie algoritme niet gegarandeerd 100% zonder fouten verloopt. Bijvoorbeeld persoonsgegevens die geïntegreerd moet worden op naam, geslacht en geboortedatum. Dit kan fout gaan als het integratiealgoritme geen rekening houdt met verschil in gebruik van diacrieten, hoofdletters, koppeltekens etc. in de naam. Als de architectuur van het datawarehouse  vereist dat direct tijdens het laadproces ook de data geïntegreerd wordt dan is er vaak geen weg meer terug. Als achteraf blijkt dat er iets is fout gegaan tijdens de data-integratie dan kunnen binnen het datawarehouse al zoveel afhankelijkheden zijn ontstaan met het foutief geïntegreerde data-item dat de kluwen niet meer zonder informatieverlies te ontwarren is. Daarnaast kan bij bronsysteem overstijgende integratie natuurlijk hetzelfde type probleem optreden als beschreven is bij intra bronsysteem integratie.

Calculatie

Dit is het berekenen van numerieke waarden op basis van verschillende getallen in een of meer records uit het bronsysteem.  Denk hierbij bijvoorbeeld aan het berekenen van een omzet voor een orderregel door het verkochte aantal te nemen en dit te vermenigvuldigen met de stuksprijs van het bestelde product en hiervan een eventueel verleende korting af te trekken. De berekende omzet wordt opgeslagen in het datawarehouse, maar de onderliggende getallen (aantal verkocht, stuksprijs en kortingsbedrag) niet.

Aggregatie

Dit is het berekenen van numerieke waarden door het samenvatten van data uit meerdere records uit het bronsysteem voor een of meer dimensies en dit opslaan in het datawarehouse. Tegelijkertijd worden de onderliggende detailgegevens niet bewaard in het datawarehouse. Een voorbeeld van aggregatie is het berekenen van het verkochte aantal van een product per week door de som van het verkochte aantal van alle orderregels voor het betreffende product die binnen dezelfde week vallen, op te tellen.

Wat is nou eigenlijk het probleem?

In de bovengenoemde voorbeelden onder het kopje data integratie is het probleem evident. Door voortschrijdend inzicht in de wijze waarop de data geïntegreerd moet worden of door er te laat achter te komen dat er iets mis is gegaan met de data integratie is het onmogelijk de oorspronkelijke brondata te reconstrueren en opnieuw te integreren volgens de nieuwe inzichten.

Ook rondom data cleansing strategieën kunnen we voorschrijdende inzichten krijgen. Bijvoorbeeld we komen tot het inzicht dat, geheel tegen de afspraken in, de order desk orderregels ‘misbruikt’ door een negatief te factureren bedrag in te voeren om zo geld terug te storten op rekening van klanten die te veel betaald hebben. Nu we dit weten, blijkt dat we, achteraf gezien, de orderregels met een negatief factuurbedrag wel degelijk hadden moeten meenemen in de berekening van de weekomzet. Echter deze orderregels zijn buiten het datawarehouse gehouden en zijn in de tussentijd mogelijk gewijzigd in het bronsysteem. Met terugwerkende kracht zijn we nu niet meer in staat de weekomzet te herberekenen volgens de nieuwe methode.

Organisaties zijn continue onderhevig aan veranderingen. Hetzelfde geldt voor de markt waarin zij opereren. Het kan dan ook niet anders dan dat de informatiebehoefte van de gebruikers van de BI oplossing verandert in de tijd. Om tegemoet te kunnen komen aan deze veranderende informatiebehoefte, moeten soms wijzigingen worden aangebracht in het datawarehouse. Stel dat de eindgebruiker aanvankelijk geïnteresseerd was in de omzet per product, per verkoper, per week. Om aan deze informatiebehoefte te voldoen, zijn de orderregels afkomstig uit het ordersteem geaggregeerd per product, verkoper en week. Het resultaat van deze aggregatie is opgeslagen. De onderliggende orderregels niet. Op een later moment geeft de eindgebruiker aan dat hij de omzet ook nog per verkoopregio wil kunnen bekijken. We hebben nu geen andere keus dan de omzet opnieuw te berekenen door de orderregels zoals ze nu in het ordersysteeem staan, opnieuw te aggregeren, ditmaal met de extra dimensie verkoopregio. Er is een gerede kans er inmiddels iets is veranderd in het orderregels in het ordersysteem. Als we het non-volatility principe belangrijk vinden, moeten we in dat geval de oorspronkelijke omzetcijfers (per product, per verkoper, per week) bewaren in het datawarehouse en daarnaast de omzetcijfers volgens de nieuwe berekening (per product, per verkoper, per week, per verkoopregio) gaan opslaan. De oorspronkelijke omzetcijfers uitsplitsen volgens een extra dimensie kan in dit geval dus niet.

Business beslist mee 

Nu we weten waar we historie kunnen verliezen, kunnen we, indien gewenst, hierop anticiperen. Dit kan door de juiste BI architectuur te kiezen, in combinatie met de juiste wijze van het modelleren van data. Voordat een organisatie een keuze maakt, is het belangrijk om helder te hebben welke consequenties deze keuze heeft in termen van mogelijk verlies van data-historie en hoe dit de flexibiliteit en onderhoudbaarheid van de oplossing beïnvloedt.  Architectuurkeuze is dus niet enkel een technische aangelegenheid. De business moet hier ook bij betrokken worden.

 

Data Vault in een datamigratie traject

Bij de kreet Data Vault wordt al vrij snel gedacht aan data warehousing. Dit is echter niet het enige domein waarvoor deze modelleringtechniek/architectuur nuttig is. In deze post wil ik eens aandacht besteden aan de toepasbaarheid van Data Vault in een datamigratiestraat. Een typisch data migratie traject houdt in ieder geval in dat:

  1. data van een of meer brondatabases naar een nieuwe doeldatabase wordt overgezet. In het geval van meerdere bronnen is vaak data-integratie nodig.
  2. data uit het bronsysteem moet waar nodig worden opgeschoond. Als het bewaken van datakwaliteit in het bronsysteem gebrekkig is, levert dit eigenlijk gegarandeerd vervuiling op. Een ander bekend fenomeen is het gegeven dat bepaalde velden in bronsystemen zijn gebruikt voor andere doeleinden dan waarvoor ze oorspronkelijk bedoeld zijn.
  3. entiteiten in de bronsystemen moeten worden getransformeerd naar entiteiten in de doeldatabase. Dit is soms kinderlijk eenvoudig maar in andere gevallen is dit een pittige opgave.
  4. er doorgaans meerdere iteraties nodig zijn om tot uiteindelijk resultaat te komen. Vaak moet er zoveel worden verspijkerd aan de oude data alvorens deze naar het doelsysteem kan worden overgezet dat dit onmogelijk in een enkele conversieslag kan worden gedaan. Voortschrijdend inzicht is eerder regel dan uitzondering. Er vindt dan een proefmigratie plaats, die vervolgens wordt geëvalueerd door mensen die inhoudelijk op de hoogte zijn van de over te zetten data. De uitkomsten van de evaluatie worden vervolgens verwerkt in een nieuwe proefmigratie, etc. Ook kan deze evaluatie leiden tot het verbeteren van de datakwaliteit in de bronsystemen.

Belangrijk is dat iedere iteratie in het migratietraject herhaalbaar en traceerbaar is. De data in de bronsystemen is echter doorgaans in beweging tijdens dit traject. Al is het maar vanwege het verbeteren van datakwaliteit in de bronsystemen naar aanleiding van een proefmigratie. Om herhaalbaarheid van iedere iteratie te garanderen is het noodzakelijk dat er “foto’s” genomen worden van de bronsystemen. Voor dit doel kan per bronsysteem een Source Data Vault (sDV) worden aangelegd (of liever nog: genereren). De sDV bevat enkel de volledige (inhoudelijk) ongewijzigde data op verschillende peilmomenten in het betreffende bronsysteem.

Voor data-integratie en datatransformaties zijn soms vertaaltabellen nodig. Deze kunnen worden ondergebracht in een Helper Database. Als we streng in de leer zijn en we willen gaan voor 100% reproduceerbaarheid van iedere iteratie in het migratietraject dan zouden we ook van deze vertaalinformatie de historie moeten gaan bijhouden.

Niet iedere opschoonactie of transformatie is volledig te automatiseren. Menselijke tussenkomst is dan noodzakelijk. Onze migratie architectuur moet ruimte bieden voor handmatige ingrepen die niet plaats vinden in de bronsystemen maar ergens verderop in de migratiestraat. Om hier herhaalbaarheid te kunnen garanderen is het noodzakelijk dat het handmatig ingrijpen op gestructureerde wijze gebeurt. Dit kan door handmatige wijzigingen te zien als zijnde afkomstig uit een correctiesysteem dat we behandelen als bronsysteem. En net als voor alle andere bronsystemen wordt ook voor dit systeem een sDV aangelegd. Deze speciale sDV noem ik Correctie Data Vault (cDV). Hier wordt de historie van de correcties bewaard. Voor de duidelijkheid, het correctiesysteem is geen echt systeem, het is in feite een set correctiebestanden volgens een vast stramien. Dit kunnen bijvoorbeeld Excel bestanden zijn met in iedere rij een te vervangen data-item, gecombineerd met vervangende data. Of Excel bestanden met de sleutels van de entiteiten (of relaties) die niet meegaan in de migratie.  Om maar eens wat te noemen. Deze correctiebestanden worden ingelezen in de cDV.

De bouwstenen voor de migratie zijn dus sDV’s, de cDV en de Helper DB. Als we een proefconversie voorbereiden, zullen deze allereerst gevuld moeten worden. Alle gegevens in deze bouwstenen worden vervolgens op een bepaalde wijze opgeschoond, bewerkt en gecombineerd zodat nieuwe data ontstaat, die geschikt is om te importeren in het doelsysteem. De wijze waarop dit gebeurd, is sterk onderhevig aan voortschrijdende inzichten. Om 100% reproduceerbaarheid van deze stap te garanderen is het natuurlijk noodzakelijk om alle versiebeheer toe te passen op de gebruikte bewerkingen (programmacode dus). Daarnaast is het handig (maar niet strikt noodzakelijk) om de uitkomst van deze bewerkingen historisch op te slaan in een speciaal hiervoor bestemde Migratie Data Vault (mDV). Dit maakt het vergelijken van de uitkomsten van verschillende iteraties eenvoudiger. Ook kan hierin voor ieder data-item worden vastgelegd uit welke bewerking het precies afkomstig is. Dit is met name handig naarmate de betreffende bewerking complexer is. Daar waar het simpele bewerkingen betreft, zou eventueel kunnen worden volstaan met een view op de betreffende sDV.

De mDV vormt uiteindelijk de bron van waaruit het doelsysteem wordt geladen.

In onderstaande afbeelding is het hierboven beschrevene nog eens schematisch weergegeven. De letters A, B en C geven aan waar na iedere iteratie verbeteringen kunnen worden aangebracht.

schematische weergave van de datamigratiestraat

 

Data-integratie met een slag om de arm

Data-integratie speelt een belangrijke rol bij datawarehousing en dataconversietrajecten. Eigenlijk heeft data-integratie veel weg van het maken van een grote legpuzzel. Verspreid in de tijd en over verschillende systemen, wordt allerhande informatie opgeslagen over entiteiten die voor een organisatie van belang zijn. Deze verspreide datafragmenten vormen de stukjes van de legpuzzel. De uitdaging voor de datawarehouse architect bestaat hier uit het bij elkaar zoeken van deze puzzelstukjes zodat een zo compleet mogelijk beeld ontstaat van deze entiteiten. Ook moet er vaak een zo goed mogelijke reconstructie gemaakt worden van hoe deze entiteiten zijn veranderd in de tijd. Dat dit lang niet altijd even eenvoudig is zal ik in dit artikel illustreren aan de hand van de data-integratieproblemen die ik bij de ontwikkeling van het product Boven-wijs ben tegengekomen.

Lees dit artikel verder op: XR Magazine http://j.mp/L4Ktc2

 

When does the coding stop?

Pas sprak ik met een collega over de vraag waarom we nog steeds met zijn allen zitten te programmeren voor het realiseren van een informatiesysteem. Dit terwijl, als je er door je oogharen naar kijkt, er bij de meeste systemen steeds weer sprake van is dezelfde functionaliteit: het vast leggen van attributen van een entiteiten, het aan elkaar koppelen van entiteiten, of het opvragen van attributen van entiteiten in een of ander vorm. Toch zitten we steeds weer opnieuw en opnieuw te programmeren. Waarom genereren we het gros van de informatiesystemen niet gewoon in hun geheel? Een van de oorzaken is ongetwijfeld het feit dat informatiesystemen naast de grote gemene deler die ze hebben, ook hele specifieke eigenschappen hebben die precies op maat zijn voor een bepaald type gebruiker, situatie of platform. Deze specifieke functionaliteit is vaak lastig op generieke wijze te modeleren (bijvoorbeeld met een Model Driven Design tool) en vervolgens te genereren.  Eenmalig genereren en daarna handmatig uitbreiden lukt nog wel maar onderhoud plegen vanuit een functioneel model is al snel lastig. Kort gezegd: hoe meer je genereert, hoe meer flexibiliteit je inlevert.

De laatste jaren houd ik me voornamelijk bezig met data warehousing. Reuze interessante materie maar in het bouwproces zie ik wel veel herhaling van hetzelfde. Onwillekeurig dringt zich dan de weer vraag bij mij op: Waarom zit ik nog steeds te coderen? Gelukkig ben ik niet de enige met dit soort gedachten. Zo zijn de jongens (en meisjes?) van Qosqo al druk doende met de ontwikkeling van het product Quipu waarmee op basis van de structuur van bronbestanden Data Vaults gegenereerd kunnen worden met bijbehorende ETL. Ik denk echter dat codegeneratie binnen de data warehousing context nog veel breder kan worden toegepast. Ik zou een data warehouse architectuur willen kunnen ontwikkelen zonder perse toe te moeten werken naar een specifieke architectuur, en zonder me vast te pinnen op een bepaalde wijze van datamodellering. Ik zou graag op enkel op basis van een specifatie van de brondata en de requirements die gelden voor het data warehouse een volledig functionerende data warehouse architectuur willen kunnen genereren. Het maakt mij dan niet uit of het resultaat een Data Vault, Anchor Model, Historical Staging Area, Dimensional Model of een of andere mengvorm is. De te gebruiken modelleringstechniek is typisch iets dat ik buiten de requirements zou willen houden op basis waarvan de data warehouse architectuur gegenereerd gaat worden.

Ik zie het als volgt voor me: In een data warehouse architectuur zijn, functioneel gezien, een aantal lagen te onderscheiden:

  • De inputlaag, oftewel de databronnen. Deze zijn een gegeven en moeten dus enkel goed beschreven worden bijvoorbeeld in de vorm van een logisch datamodel per bron en bepaalde eigenschappen van de bron (verderop geef enkele voorbeelden).
  • De opslaglaag. Het hart van het data warehouse. Deze moet na analyse van de wensen van de gebruikers en de beschikbare databronnen worden vormgegeven. Modelleren kan in de vorm van logisch datamodel, uitgebreid met wat specifieke eigenschappen (zie verderop).
  • De outputlaag. Hiermee interacteert de gebruiker. De outputlaag is typisch het product van een transformatieproces met als input de opslaglaag en een verzameling business rules. Doorgaans wordt data in deze laag ontsloten door bijvoorbeeld BI tools zoals een cube, een dashboard met KPI’s, standaardrapporten of een voor gebruikers begrijpelijke informatielaag (zoals de Universe van BO en de Catalog van Cognos).  Maar alles is hier in principe mogelijk. Er kan gebruik worden gemaakt van logische datamodellen om de basisdata te beschrijven die beschikbaar moeten zijn om de gewenste output mogelijk te maken.

Tussen de input- en de opslaglaag en de opslag- en de outputlaag  kunnen mappings gedefinieerd worden. Deze vormen dan de basis voor het genereren van de benodigde ETL code.

De input- en opslaglagen zijn mijns inziens volledig functioneel te modelleren op een min of meer declaratieve wijze. De outputlaag is de lastigste en kan mogelijk niet volledig gemodelleerd worden zonder te vervallen in een verkapt soort programmeren (waar we juist vanaf willen). Dit is vooral het geval als er zeer exotische (en die komen vaker voor dan ons lief is) business rules het spel zijn.

Delen van de data warehouse architectuur die declaratief te modeleren zijn

Toch is er ook iets te zeggen voor een eenvoudige basistaal waarin procedurele beschrijvingen van business rules kunnen worden vastgelegd. Een dergelijke taal biedt namelijk een platformonafhankelijke wijze waarop allerhande transformaties kunnen worden vastgelegd. Als we het vervolgens voor elkaar krijgen alle business rules met deze beperkte taal volledig te modelleren, kunnen we ook het onderhoud op de resulterende data warehouse architectuur via dit model blijven doen.  Anders blijft altijd de noodzaak bestaan om na het genereren van een nieuwe versie van de data warehouse architectuur handmatige correcties op de niet gegenereerde code uit te voeren.

Wat winnen we met een dergelijke benadering:

  1. We kunnen alle benodige datastructuren genereren op basis van het model.
  2. We kunnen alle benodigde ETL genereren op basis van het model.
  3. Na wijzigingen in het model kunnen we ook de migratie van de oplossing gebaseerd op het oude model naar de oplossing gebaseerd op het  nieuwe model automatiseren.
  4. We zijn niet afhankelijk van de onderliggende techniek omdat we het systeem volledig functioneel hebben beschreven. Komt er nieuwe technologie in beeld, dan kan m.b.v. de bijbehorende code generator het nieuwe systeem gegenereerd worden.

Voor ieder platform een codegenerator

Hieronder noem ik enkele zaken die zoal moeten worden vastgelegd in het functionele model van de BI oplossing. Het is uiteraard slechts een schot voor de boeg.

Informatie rondom de inputlaag

  • Welk type databron betreft het?(csv, Excel sheets, xml, tabellen in een Oracle database, Webservice, …)
  • Moet de brondata continue of per interval worden bijgeladen?
  • Hebben we per laadbatch de beschikking over een volledige of onvolledige foto van het bronsysteem of  alleen de delta’s
  • Mag de databron live worden benaderd voor BI doeleinden of niet?
  • Per bronbestand: Welke entiteiten,relaties en attributen zijn er?
  • Per entiteit: Hoe kan deze uniek te geïdentificeerd worden  (of is er misschien een foutkans, zie ook een vorige blogpost)?

Informatie rondom de data in de opslaglaag

  • Welke entiteiten,relaties en attributen hebben we?
  • Wat willen we wel en wat willen we niet historisch bewaren?
  • Welk attribuut in de inputlaag, correspondeert met welk attribuut in de opslaglaag?

Informatie rondom de data in de outputlaag

  • Per outputvorm (cube, dashboard etc): Welke KPI’s, meetwaarden en dimensies onderscheiden we?
  • Welke entiteiten in de opslagstructuur hebben we nodig om een KPI, meetwaarde of dimensie te creeeren?
  • Per outputvorm: Hoe vaak moet data ververst worden?

Ik realiseer me dat dit een wel zeer globale schets is, en dat er nog het nodige denkwerk verzet moet worden om tot een werkende oplossing te komen. Het is echter de moeite waard om dit verder uit te werken. Alleen zo kunnen we uiteindelijk zeggen: “The coding finally stops!” Ik wil iedere lezer dan ook aanmoedigen om hierop te schieten en zijn/haar ideeën met mij te delen. Wellicht zijn er al vergaande ontwikkelingen in deze richting waarvan ik geen weet heb. Ik verneem ze graag!

 

De kwaliteit van het hoger onderwijs staat de laatste tijd flink ter discussie. Kwaliteitszorg en het daarmee samenhangende accreditatieproces zijn dan ook hot items binnen hogescholen en universiteiten. In dit artikel, gepubliceerd in het blad Onderwijsinnovatie beschrijf ik hoe het slim toepassen van BI de kwaliteitszorg in het hoger onderwijs ten goede komt.