Een metamodel is een essentiële bouwsteen voor data management. Een goed ontworpen metamodel creëert eenheid van taal om over data en datamanagement te communiceren en relevante metadata te kunnen administreren. 

Ondanks dat veel termen gemeengoed lijken (‘data steward’, ‘data classificatie’, ‘data kwaliteitseis’ etc.) komt het vaak voor dat dergelijke termen worden gebruikt zonder dat betrokkenen écht goed begrijpen wat er mee wordt bedoeld, zeker in de specifieke context van hun eigen organisatie. Bij iets als ‘datakwaliteitseis’ zal menigeen waarschijnlijk snel een bepaalde associatie hebben. Maar wat is het nu precies? Waarop heeft zo’n eis betrekking (op een heel systeem, op de onderliggende database, op een specifiek scherm / tabel / attribuut)? Moeten we eisen typeren? Hoe leggen we een relatie tussen een abstracte formulering als ‘de data moet voor 95% compleet zijn’ en de fysieke werkelijkheid van die data in concrete gegevensdragers etc.

Dat gebrek aan eenduidigheid en specificiteit belemmert ook metadata management. Dat wordt bijvoorbeeld zichtbaar wanneer handmatige administraties worden ingericht in Excel of Sharepoint. Door onduidelijke definities gaan dit soort lijsten een eigen leven leiden, zijn verschillende lijsten niet consistent met elkaar of worden ze op een andere manier gevuld dan bedoeld.

Uiteindelijk is metadata gewoon data. Voor metadata is dus ook data management nodig. Dat betekent het opstellen van definities, bepalen van kwaliteitseisen voor metadata, inrichten van beheerprocessen, zorgen voor ondersteunende technologie etc. Het vertrekpunt hiervoor is het opstellen van een data model voor metadata: het metamodel.

Kwaliteit van een metamodel

Bij het professionaliseren van data management gaan organisaties vaak voortvarend aan de slag met metadata en het opstellen van een metamodel. Maar helaas is de toegevoegde waarde soms beperkt: het model wordt niet gebruikt, concepten zijn te abstract en worden daardoor niet begrepen of concepten zijn te algemeen en daarmee niet bruikbaar in de specifieke context van de organisatie.

De kwaliteit van een metamodel is dus sterk bepalend voor de bruikbaarheid ervan. Maar hoe beoordeel je nu de kwaliteit van zo’n metamodel? Wat maakt een metamodel goed of slecht? Wat moet er allemaal in zo’n metamodel staan? Moeten we alle data management concerns modelleren? 

In dit artikel bespreken we vijf kwaliteitscriteria waarmee de bruikbaarheid van een metamodel beoordeeld en verbeterd kan worden. Hiervoor maken we gebruik van het onderstaande, fictieve metamodel om verschillende situaties te illustreren. 

Vijf kwaliteitscriteria

• Specificatie en definitie van concepten
  Zijn alle concepten uit het metamodel ondubbelzinnig en specifiek gedefinieerd? Ieder concept – iedere term die in het metamodel voorkomt – moet een definitie hebben. Is duidelijk op basis van die definities wat het specifieke onderscheid is tussen de verschillende concepten? Van ons voorbeeld model moet bijvoorbeeld duidelijk zijn wat het verschil is tussen een Data Domein en een Data Object. Daarnaast is het van belang om de relaties tussen de concepten goed te definiëren. 
  
  
• Concrete voorbeelden
  Bestaan er van ieder concept en iedere relatie tussen concepten concrete voorbeelden? Valt de bedoeling, betekenis, werking van ieder concept en relaties daartussen te illustreren aan de hand van concrete voorbeelden? Zo niet of roept dit meer vragen op dan het beantwoordt, dan is dat een indicatie dat het concept niet scherp genoeg gedefinieerd is. Het gebruik van concrete voorbeelden helpt ook bij het verder aanscherpen van definities. Bespreek het model aan de hand van voorbeelden.
  
  Terug naar het voorbeeld model en de concepten Gegevenseigenaar, Data Object en de relatie ertussen. Wie of wat zijn voorbeelden van een gegevenseigenaar? Is dat een persoon (Jan de Boer), een specifieke functie (Hoofd Planning & Control) of een organisatorische eenheid (afdeling Klantcontact)?  Dezelfde vragen moeten gesteld worden voor het concept Data Object. Wat is dat? Iets abstracts als ‘Klantgegevens’ of iets fysieks als Microsoft Dynamics CRM database; of een folder, Amazon S3 storage bucket, een verzamelingbestanden etc.? En wat zijn van voorbeelden van de relatie ertussen? Wanneer er geen concrete voorbeelden voorhanden zijn, bijvoorbeeld omdat je een nieuw concept wilt introduceren, is het nodig om zelf representatieve voorbeelden te bedenken. Een praktische manier om met concrete voorbeelden te werken is door deze letterlijk op te schrijven en tabulair weer te geven, zoals geïllustreerd hieronder:
  

Gegevenseigenaar	Data Object
Hoofd Finance & Control	Peoplesoft Financials
Teamleider klantcontact	Sharepointlijst Klachtenmeldingen
Data Lab	Centraal Datawarehouse (DWH)

• De voorbeelden zijn fictief en roepen bij het lezen beslist allerlei vragen op: is Peoplesoft niet eigenlijk een Applicatie? Kan een afdeling (‘Data Lab’) of een functie (‘Hoofd F&C’) allebei een Gegevenseigenaar zijn? Het CDW bevat heel veel verschillende soorten data; is het Data Lab daar dan allemaal eigenaar van, etc.?
  
  Scherp het model aan door discussie en vragen
  Het stellen van dergelijke vragen naar aanleiding van de concrete voorbeelden en de discussie hierover is juist de bedoeling! Het zorgt voor verheldering wat met een bepaald concept wordt bedoeld, hoe het wordt geïnterpreteerd en als het wordt gebruikt en ingevuld, of het bruikbaar is. Stel je voor dat deze aanscherping niet plaats zou vinden en dat direct, op basis van een abstract metamodel meteen een oplossing wordt ontwikkeld of metadata management-oplossing wordt aangekocht. Dan komen dit soort vragen pas tijdens de implementatie of het gebruik naar boven met alle gevolgen van dien.
  
  Geen voorbeelden, geen concept
  Wanneer het niet mogelijk is om concrete voorbeelden aan te leveren of op te stellen, is de kans groot dat bedachte concepten niet bruikbaar zijn in de praktijk. Verwijder ze daarom uit het metamodel!

• Concrete data management concerns
  Niet alleen staat een metamodel aan de basis van het eenduidig administreren van de data zelf, ook het administreren van vraagstukken over die data – de data management concerns – wordt door een metamodel c.q. metadata management oplossing ondersteund.
  
  Metamodel toont de vraagstukken van de organisatie
  Hierbij is het logisch maar helaas niet altijd vanzelfsprekend dat dat wat in het metamodel wordt opgenomen, ook concrete en actuele vraagstukken uit de praktijk representeert. Bijvoorbeeld: een metamodel waarin eigenschappen van data kwaliteit zijn opgenomen terwijl er in de praktijk een knelpunt is met het stroomlijnen van de inkoop van externe databronnen, zal niet veel toegevoegde waarde (kunnen) bieden.
  
  Kortom, actuele en concrete data management-vraagstukken uit de praktijk moeten gerelateerd kunnen worden aan concepten uit het metamodel. Andersom kan ook getoetst worden of bij ieder concept uit het metamodel er concrete praktische vraagstukken zijn die het concept representeert dan wel die met dat concept kunnen worden geassocieerd. Zo niet, dan heeft het concept waarschijnlijk geen toegevoegde waarde en is het niet effectief om dit concept te administreren.

• Noodzaak en prioriteit
  Data management is een breed vakgebied. Op basis van ons eigen Data Management Framework vallen al zo’n 45 aspecten aan te wijzen die kandidaat zijn om opgenomen te worden in een metadata administratie. Die 45 aspecten zouden leiden tot een veelvoud aan concepten die in het metamodel zouden moeten terugkomen. Voor het aspect Gegevensleveringsovereenkomst (GLO) bijvoorbeeld kunnen verschillende eigenschappen worden geadministreerd:
  
  – Ontvangende partij
  – Leverende partij
  – Inhoud van de levering, zowel qua data als qua technisch formaat
  – Contactpersonen
  – Frequentie van aanlevering
  – Termijn van de overeenkomst
  – etc.
  
  Het is onvermijdelijk om keuzes te maken om het ontwerp, implementatie en gebruik van een metamodel en metadata administratie beheersbaar te houden. Daarom is in stap 3 ook de nadruk gelegd op het adresseren van concrete en actuele datamanagement-vraagstukken.Vervolgens is het belangrijk om tot een verdere aanscherping te komen van wat precies moet worden geadministreerd. Neem het voorbeeld uit stap 3: gebrek aan inzicht in de inkoop van externe databronnen. Dit kan aanleiding zijn om de focus te leggen op het administreren van GLO’s. Maar zoals hierboven werd geïllustreerd kunnen over GLO’s ook weer een veelheid aan eigenschappen worden vastgelegd. Gegeven de specifieke context – inzicht in inkoop van externe databronnen – is een beheersbare eerste stap – een minimum viable product (MVP) zo je wilt – om te beginnen met het puur administreren bij welke partijen wordt ingekocht en wat. Om daarna het metamodel c.q. de administratie verder uit te breiden.
  
  De vraag is dus of alle mogelijke concepten nodig zijn om concrete data management vraagstukken op te lossen. Of is het mogelijk nu concepten weg te laten omdat ze nog niet actueel of relevant zijn? Less is in dit geval zeker more!

• Beheerproces
  De eerste vier criteria zorgen voor een scherpe afbakening en definities van de belangrijkste concepten die in het metamodel c.q. metadata administratie moeten worden opgenomen. 
  
  Hoe vullen we het model?
  Een belangrijke vervolgvraag is dan of duidelijk is hoe de instanties van die concepten tot stand komen. Met andere woorden: hoe ontstaat de data zelf – die het metamodel definieert? Kunnen deze geautomatiseerd worden afgeleid of moeten ze handmatig worden ingevoerd?
  Neem weer het voorbeeld metamodel en laten we aannemen dat een Data Object een fysiek ‘ding’ is (e.g. een database, schema, tabel, file, folder etc.). Het is duidelijk dat het aantal instanties – het aantal records in een metadata administratie – zo in de duizenden tot miljoenen kan lopen. Dat valt al snel niet meer met de hand bij te houden. Tools waarmee de infrastructuur kan worden uitgelezen om vervolgens de gescande objecten volgens de definities uit het metamodel te administreren, zijn dan al snel onvermijdelijk.
  
  Andere concepten zullen waarschijnlijk handmatig moeten worden vastgesteld en ingevoerd in de administratie. Op basis van welke spelregels wordt bijvoorbeeld vastgesteld dat er een nieuw Data Domein moet worden opgevoerd? Wie of welk gremium bepaalt dat? Welke medewerker(s) zorgt voor het vervolgens bijwerken van de administratie? 
  
  

Beoordeling

Dit zijn een aantal kwaliteitscontroles die op een metamodel kunnen worden uitgevoerd. Kost het moeite de vragen te beantwoorden, dan valt sterk te betwijfelen of het vastleggen van metadata volgens zo’n metamodel voldoende toegevoegde waarde gaat leveren.

Data Catalog Accelerator programma

Het opstellen van een effectief en efficiënt metamodel is onderdeel van het Data Catalog Accelerator programma. Door middel van een methodische aanpak realiseren we samen met de opdrachtgevende organisatie binnen twee tot drie maanden een klantspecifiek metamodel. We implementeren vervolgens een concrete oplossing voor een actuele use-case en ontwikkelen samen een plan voor het verder structureel inzetten van een data catalog of metadata-management oplossing.

Ben je nieuwsgierig geworden naar wat een metamodel zou kunnen betekenen voor jouw organisatie? Of wil je gewoon meer informatie hebben over het Deltiq Data Catalog Accelerator programma? Neem dan gerust contact met ons op!