Manifest voor het belang van De Kunde van Kennisrepresentatie voor Informatiediensten
Dit document wordt begeleid door een document met een uitwerking van de Beschouwingsniveaus, inclusief de benamingen die voor deze beschouwingsniveaus vaak worden gebruikt.
Wij, professionals actief bij het ontwerpen, ontwikkelen en leveren van informatiediensten, zijn van mening dat de Kunde van Kennisrepresentatie een noodzakelijke voorwaarde is om te komen tot goede informatiediensten.
Zij die deze kunde beheersen, herkennen zich in de volgende stellingen en zijn betrokken bij het maken van de hieronder beschreven modellen voor elk beschouwingsniveau.
Wij zien een informatiedienst daarbij als een dienst die wordt geleverd door (of namens) een organisatie, waarbij de dienst die daarbij wordt geleverd primair uit de verwerking van gegevens bestaat (in tegenstelling tot bijvoorbeeld een dienst voor fysieke producten, zoals een koerier of een detailhandel). Onder dergelijke informatiedienst verstaan wij ook de consequentie die daaruit volgt. Ook kan sprake zijn van een dienst waarbij aangeleverde gegevens worden verrijkt of verwerkt. De Engelse term is “information service” en het ontwerpen daarvan “information service engineering”.
STELLING 1: Ontwerpen van een informatiedienst vereist een expliciet begrip van het domein
Informatiediensten worden tegenwoordig vaak geleverd met behulp van IT systemen. Deze systemen worden gemaakt door mensen en deze systemen verwerken gegevens. De gegevens representeren concepten die een specifieke betekenis hebben in het domein waarin de informatiedienst wordt gebruikt. Een expliciet begrip van de context waarbinnen de informatiedienst wordt gebruikt, is hiervoor nodig. De informatiedienst vervult een behoefte in het domein, het lost een probleem op. Door dit probleem te begrijpen, kun je er ook een oplossing voor ontwerpen. We zien dan ook dit expliciete begrip als randvoorwaarde voor het kunnen starten met het ontwerpen van een informatiedienst.
STELLING 2: De sleutel tot het begrijpen van een domein is het begrijpen van de gebruikte taal
Wij mensen gebruiken taal bewust om elkaar te begrijpen en te beïnvloeden. Succesvolle samenwerking vereist dat we communiceren met elkaar. Dat doen niet alleen mensen, maar feitelijk alle dingen die samenwerken: ook andere levende wezens en ook machines. Communicatie tussen mensen kan rechtstreeks, maar ook via de informatiedienst. Wij kunnen taal ook gebruiken om elkaar te leren begrijpen: we zijn ons bewust van het gebruik van taal. We zijn daarmee in staat om te begrijpen waarover we communiceren, dat wil zeggen: waarover we communiceren, of anders gezegd: wat er zich zoal afspeelt in het domein. Door de taal te begrijpen die in een domein wordt gebruikt, ontstaat begrip van het domein. Je begrijpt een taal, als je weet waarover gesproken wordt, wat er mee bedoeld wordt. Hoe datgene waar over gesproken wordt in elkaar zit. Dit begrip van het domein is de noodzakelijke randvoorwaarde, om de dialoog te kunnen starten.
STELLING 3: Alleen via een gestructureerde dialoog kan gezamenlijk begrip van het domein ontstaan
Om de taal van een domein te kunnen begrijpen zul je vragen moeten stellen over de betekenis van de woorden en van de combinaties waarin deze woorden te gebruiken zijn. Het is een dialoog met de intentie om de verschillende betekenissen en patronen te harmoniseren tot een gezamenlijk begrip over het domein. Bestaande documentatie kan versnelling opleveren: de documentatie is als het ware de vastlegging van eerdere dialogen. Doordat zowel de taal als het domein evolueert, zal een dialoog nodig blijven: het is een steeds terugkerende interactie tussen mensen om te komen tot een gemeenschappelijke taal. Merk op dat IT systemen op dit moment nog vrij slecht zijn in het voeren van een dergelijke dialoog. Begrijpen van een domein is een menselijke kunde. Niet alleen zijn IT systemen slecht in het voeren van een dergelijke dialoog, je mens als mens ook actor in het domein.
STELLING 4: Een formeel model is nodig om de betekenis van de domeintaal voldoende expliciet vast te leggen
De betekenis van een domeintaal blijft altijd in beweging: het gebruik van de taal bepaalt in belangrijke mate de betekenis van die taal. Toch zal bij de verwerking van gegevens aannames gedaan worden over die betekenis. Van belang voor informatiediensten is dan ook dat expliciet wordt gemaakt welke betekenis van een begrip vaststaat, en welk deel van de betekenis in het gebruik nog kan schuiven (waarbij dan stelling 5 om de hoek komt kijken!). Om deze expliciete betekenis vast te leggen is een formeel model bruikbaar. IT systemen kunnen niet met elkaar in dialoog gaan om elkaar te begrijpen. IT systemen hebben een formeel model van de taal in een domein nodig om de woorden en combinaties van woorden uit de domeintaal op de juiste wijze te verwerken.
STELLING 5: De context bepaalt wat (een) gegeven betekent.
Gegevens zijn vastgelegde beweringen over eigenschappen van objecten. Dit vastleggen gebeurt met symbolen: woorden, getallen, codes, afkortingen en nummers. De betekenis die een schrijver of lezer van de symbolen van die beweringen aan toekent, is afhankelijk van de context, zoals andere gegevens, maar ook de situatie waarin de schrijver en lezer zich bevinden (zonder dat hierover gegevens bekend hoeven te zijn). Gesprekspartners begrijpen elkaars gegevens als ze van elkaar weten welke betekenis ze aan de symbolen toekennen. De ontvanger van gegevens kan pas de juiste betekenis toekennen aan gegevens als de context van de verstrekker bekend is. Gegevens worden pas betekenisvol binnen de context en interpretatie van de schrijver en lezer. Om misverstanden te voorkomen, begrip te vergroten en foutloze automatische verwerking mogelijk te maken moet context van gegevens zo veel mogelijk expliciet gemaakt worden.
STELLING 6: Duurzaam behouden van de beoogde betekenis van gegevens vergt zorg
De betekenis van woorden in een taal kan evolueren door de tijd heen. Ook is de betekenis van taal afhankelijk van het domein. Gegevens die ooit zijn ontstaan, verwijzen naar de betekenis op dat moment in de tijd, door degene die er een betekenis mee beoogde op dat moment. Deze stelling impliceert daarmee niet alleen dat onze modellen kunnen veranderen door de tijd heen, maar ook dat een juiste verwerking van de gegevens alleen mogelijk is als de oorspronkelijke modellen nog beschikbaar zijn. Deze gegevens-over-de-gegevens (ook wel metadata genoemd) zijn cruciaal voor de juiste duiding. Dit gaat niet vanzelf: zonder expliciete zorg hiervoor, gaat de beoogde betekenis (de oorspronkelijke context en interpretatie van de observant) van gegevens verloren en worden deze gegevens waardeloos.
STELLING 7: Het beoogd gebruik bepaalt welke gegevens nodig zijn en in welke vorm
De betekenis die met de gegevens wordt beoogd kan volledig beschreven zijn in het formele model. Maar welke gegevens daadwerkelijk uitgewisseld worden in de interactie van het IT systeem en zijn omgeving, of welke gegevens daarbij gebruikt worden of geadministreerd worden: dat hangt af van de behoefte van de gebruiker en het proces waarin deze gebruiker een rol speelt. Een bepaalde combinatie van gegevens leidt tot relevante informatie in een bepaalde context. Ook de benodigde kwaliteit van deze gegevens is afhankelijk van het gebruik.
STELLING 8: Gegevens blijven hetzelfde, ongeacht het technisch formaat
In welk technisch formaat de gegevens nu worden uitgewisseld, getoond of opgeslagen: het blijven dezelfde gegevens. De technische eisen bepalen in hoofdzaak wat de meest voor de hand liggende vorm is. Zolang in deze vorm de relatie met het formele model gehandhaafd blijft, blijft de bedoelde betekenis ook behouden. Deze stelling kan ook omgekeerd worden gelezen: als het technische formaat feitelijk leidt tot andere inhoud, dan is geen sprake meer van dezelfde gegevens, maar van andere.
BESCHOUWINGSNIVEAUS
Vanuit de implicaties die bovenstaande stellingen hebben, zien wij vier beschouwingsniveaus waarbij het van belang is om deze niveaus uit elkaar te houden:
Het eerste onderscheid dat we van belang vinden is het onderscheid tussen de beschouwing van het (probleem)domein en de beschouwing van (het ontwerp van) de oplossing voor dat probleem.
- Modellen voor het probleemdomein zijn primair analysemodellen: het zijn modellen die een representatie zijn van het domein zelf, zonder dat de modelleur hier een ontwerp-afweging (engineering) bij maakt. Deze modellen hebben tot doel om inzicht te krijgen in het domein.
- Modellen voor de oplossingsruimte zijn primair ontwerpmodellen: het zijn modellen die een representatie zijn van het ontwerp (engineering) van de informatiedienst. Deze modellen hebben tot doel om helder te maken hoe we de informatiedienst gaan ontwikkelen.
Bij alle beschouwingsniveaus geldt dat de modelleur modelleringsafwegingen maakt. In ieder geval zal een afweging gemaakt moeten worden over de scope van het model: welk deel van het domein relevant is om te modelleren, of wat de scope is van de informatiedienst zelf. Zo ontstaan op elk beschouwingsniveau meerdere modellen.
Binnen de beschouwing van het probleemdomein is vervolgens onderscheid nodig tussen:
- Modellen die primair bedoeld zijn om de dialoog te voeren tussen mensen over de betekenis van de taal die in het domein wordt gevoerd.
- Modellen die interpreteerbaar zijn voor IT systemen, die volledig formeel en precies het domein beschrijven. Zodat deze systemen het gedrag kunnen vertonen dat past bij het domein, en zodat met behulp van deze systemen een beter gefundeerd inzicht wordt verkregen van het domein.
Binnen de beschouwing van de oplossingsruimte is vervolgens onderscheid nodig tussen:
- Logische ontwerpmodellen die een vorm bezitten waarmee beschreven kan worden welke gegevens verwerkt worden binnen het IT systeem, zonder daarbij ook al keuzes te maken voor de technische oplossing: het zijn technologie onafhankelijke modellen.
- Technische ontwerpmodellen die een vorm bezitten waarmee beschreven kan worden welke gegevens verwerkt worden binnen het IT systeem op een manier die past bij de technische oplossing: het zijn technologiespecifieke modellen.
Door deze vier beschouwingsniveaus met elkaar te verbinden ontstaat verticale samenhang (lineage): vanuit een beschouwing van het probleemdomein wordt een oplossing ontworpen, waarbij de betrokken gegevens herleidbaar zijn tot de betekenis die zij hebben voor mensen.
Deze beschouwingsniveaus gaan niet in op de verbinding die kan bestaan tussen modellen op hetzelfde beschouwingsniveau: horizontale samenhang (lineage). Zoals bijvoorbeeld de samenhang tussen een interfacemodel en een (intern) model van een informatiesysteem dat deze interface levert. Een dergelijke indeling is buiten de scope van dit manifest.
Niveau | Werkwijze | Ontstaat door* | Object van beschouwing |
I | Analyseren | Dialoog | (de taal in) Het probleemdomein |
II | Analyseren | Systematisch | (de formalisatie van) |
III | Ontwerpen | Dialoog | (de invulling, specificatie van) De oplossingruimte, de informatiedienst |
IV | Ontwerpen | Systematisch | (de technisch implementeerbare invulling van De oplossingruimte, de informatiedienst |
* “ontstaat door” richt zich op de wijze waarop we het model primair inzetten. Bij “dialoog” gaat het om de mensgerichte communicatie die nodig is om helder te krijgen waarover we het hebben c.q. wat we nodig hebben in het ontwerp van de oplossing. Bij “systematisch” gaat het om een model dat interpreteerbaar is door een systeem, waarmee een precies model ontstaat van het domein c.q. de oplossing.