Informatieanalyse is niet uit te besteden

23 juni 2005
De laatste tijd is er in de praktijk weer een hernieuwde belangstelling waar te nemen voor een degelijke informatieanalyse en -modellering, een absolute noodzaak voor het ontwikkelen en onderhouden van informatiesystemen. Hoe is deze trend te verklaren? Uit het kader ‘geschiedenis’ blijkt dat deze ontwikkeling geen vanzelfsprekende zaak is. Je zou zelfs kunnen zeggen dat het ambacht van informatie- en gegevensanalyse donkere middeleeuwen heeft gekend. Ook Han Schouten (Automatisering Gids 17 juni) constateert enigszins pessimistisch dat het ‘pragmatisme’ - het achterwege laten van een formele analyse - wijdverbreid is en dat echte analisten praktisch overal verdwenen zijn. Ik ben het met zijn betoog in grote lijnen eens, maar denk dat het verstandig is om, als voorstanders van de instelling ‘eerst denken en dan doen’, ook de hand in eigen boezem te steken. Want we moeten ons natuurlijk ook afvragen hoe het komt dat mensen pragmatisch zijn gaan handelen, al of niet onder de vlag van ‘prototyping’. Dat is mijns inziens lang niet altijd onwil geweest, het heeft ook te maken met het feit dat het denken van de ‘denkers’ nogal eens kromme gedachten opleverde, waar niemand in de praktijk iets mee kon.

Goeroes
Veel ontwerpers hadden een broertje dood aan formele methoden, dat is wellicht ook te wijten aan de richtingenstrijd onder de goeroes. Voor hun gevoel maakte men alleen maar ruzie over de tekenwijze (zie figuur 1) en daar hadden ze dan nog niet eens zo ongelijk in. In de wetenschappelijke wereld is hiervoor ook betrekkelijk weinig aandacht. Kijken we bijvoorbeeld naar Nederland dan is men bijzonder sterk in het onderzoek naar het inwendige van databasemanagementsystemen. Het maken van een model voor een relationele database wordt, zo lijkt het, in wetenschappelijke kring als een futiliteit gezien. Dit laatste is overigens enigszins aan het veranderen.
Aan de universiteit van Nijmegen en de Hogeschool van Arnhem en Nijmegen (het lectoraat ‘Data Architectures and Metadata Management’) wordt informatiemodellering intensief bestudeerd en gedoceerd en is de methode FCO-IM tot grote bloei gekomen. Guido Bakema onder anderen stimuleert het idee dat de verschillende methoden elkaar ook kunnen aanvullen, zodat de sterke punten van elke methode kunnen worden gebruikt. Helaas is dit alles binnen Nederland (nog) niet erg bekend, in het buitenland (met name de VS en Azië) wordt dit meer gewaardeerd.
Deze hernieuwde interesse voor informatieanalyse en -modellering is te verklaren uit een aantal factoren. We beginnen met de belangrijkste. In de software-engineering zien we een duidelijke trend naar (meer van) wat tegenwoordig MDA wordt genoemd (Model Driven Architecture). Het idee is dat een complete applicatie wordt gegenereerd op basis van een model. Dit kan natuurlijk alleen maar als van het onderhavige vakgebied de generieke problematiek goed is onderkend en in zijn algemeenheid begrepen. Gewone administratiesystemen zijn hiervan een goed voorbeeld. Het model op basis waarvan deze ontwikkeling plaatsvindt is voor 90 procent een informatiemodel en het is dus uitermate cruciaal dat dit goed is ontworpen.

Hoofdpijn
Ook op andere terreinen breekt deze ontwikkeling door, bijvoorbeeld bij BI (Business Intelligence). We zien daar dat er, naast de erkende markten voor ETL- en OLAP-tools, nu ook een nieuwe markt ontstaat voor ‘generieke DWH-tools’. Een voorbeeld hiervan is het product Kalido (ontwikkeld binnen Shell), maar ook in Nederland zijn boeiende ontwikkelingen gaande op dit gebied. Voor dergelijke tools is het businessmodel (het informatiemodel van de business) het uitgangspunt. Het mooie is dat dit informatiemodel relatief eenvoudig kan blijven omdat het in gegevenspakhuizen belangrijke aspect van de historie van de gegevens niet hoeft te worden meegemodelleerd. En juist dit bezorgt de ontwerper van een datawarehouse vaak hoofdpijn. Dit is inderdaad geen makkelijke materie, zeker als er (zoals in de verzekeringswereld) sprake kan zijn van mutaties met terugwerkende kracht. Het goede nieuws is echter dat deze problematiek generiek is en dus maar één keer goed hoeft te worden opgelost en dit dan natuurlijk bij voorkeur door softwareleveranciers. Maar, nogmaals, wat blijft is dat het uitgangspunt van hoge kwaliteit moet zijn: het informatiemodel. En dat is geen taak voor de leveranciers.
Dit laatste is overigens wel geprobeerd. Het idee was dat je niet meer aan informatiemodellering hoefde te doen omdat je dat ook kunt kopen. En inderdaad leveren sommige leveranciers kant-en-klare datamodellen (bijvoorbeeld het IBM-bankingmodel). De geluiden uit de praktijk die ik hierover hoor, zijn niet altijd positief. Behalve dat het niet goedkoop is (er zitten, zo beweren de leveranciers, zeer veel know-how en R&D-investeringen in), blijkt er in de praktijk toch nog veel aan gesleuteld te moeten worden. Bovendien wordt dit nog niet echt gecombineerd met bovenstaande MDA-ontwikkeling, hetgeen het pas echt boeiend zou maken.

Niet uitbesteden
Ten slotte beseffen bedrijven meer en meer dat de concurrentie vaak wordt gewonnen op een aantal essentiële verschillen en dat daar dus toch sprake is van eigen businessmodellen. Het is te hopen dat managers niet doorslaan in hun gedachte dat ze alles aan goedkope landen kunnen uitbesteden. Dat dit uiteindelijk voor onze economie niet goed kan zijn, volgt volgens mij uit een simpele redenering vanuit het ongerijmde: Als al onze kleren in China worden gemaakt, al onze software in India wordt gebouwd (en ontworpen), al onze telefooncentrales vanuit Pakistan worden bediend, kortom, als alles wat we nodig hebben door Aziaten wordt verzorgd, waarom zouden zij dat dan blijven doen? Wij doen immers niks meer waarmee we het (wellicht weinige) geld kunnen verdienen om hen te betalen? Kortom, als we als westerse wereld willen overleven, zullen we moet blijven werken en ondernemen, en dus informatiemodellen moeten blijven maken van onze eigen business.


Harm van der Lek (www.vdlek.nl) is onafhankelijk adviseur en docent. Hij verzorgt cursussen en lezingen over het ontwerp van datawarehouses en informatiemodellering. Dit laatste in samenwerking met de Hogeschool van Arnhem en Nijmegen.

Methoden

RM (Relationele model)
Veruit het bekendste model, omdat de meeste databasemanagementsystemen erop zijn gebaseerd. Het wordt daarom door velen ook niet gezien als een model waarin je de gegevens in eerste instantie modelleert, maar meer als een technische uitwerking daarvan. Toch is het wel degelijk een abstract model waarin de structuur van informatie kan worden beschreven. Bovendien worden in de praktijk de ontwerpen vaak direct in dit model uitgedrukt.
Onmiddellijk implementeerbaar
Zeer bekend
Betekenis voor de gebruikers (zachte semantiek) van de gegevens niet inherent in het model
Nog metaredundantie aanwezig


ER (Entity-Relationship, ook wel EAR en/of ERM)
Door velen gezien als de manier om informatiemodellen op conceptuele/logische manier weer te geven. Ligt dicht tegen het relationele model aan.
Overzichtelijke diagrammen
Veel casetools beschikbaar
Zeer bekend
Gevaarlijk in de handen van zwakke ontwerpers (vaagheid)
Zelfde informatiestructuur op verschillende manieren te modelleren

NIAM (Natuurlijke taal Informatie Analyse Methode)
Door Shir Nijssen geïntroduceerde methode. Gebaseerd op het idee dat men de communicatie moet modelleren en niet de werkelijkheid.
Dwingt ontwerpers concreet te zijn
Grote rijkdom aan constraints
Bewerkelijk
Veel details
Metamodel nog niet optimaal

FCO-IM (Fully Communication Oriented Information Modeling)
Moderne vorm van NIAM. Intern metamodel is generiek: te zien als een generalisatie van RM, ER en ORM (zie figuren 2, 3 en 4).
Als bij ‘NIAM’
Consequenter in het communicatiegeoriënteerde uitgangspunt dan de voorganger NIAM
Goede casetools beschikbaar
Nog niet algemeen geaccepteerd

Infomod
Ook communicatiegeoriënteerd, binnen Philips (van Griethuizen) ontwikkeld, niet meer levend.


ORM (Object Role Modeling)
De door Halpin gepropageerde opvolger van NIAM.
Populair bij business-rulesspecialisten
Nog niet consequent communicatiegeoriënteerd
Blijft nog wat hangen in de ‘bollen en rollen’

UML (Unified Modeling Language)
Qua informatiemodellering eigenlijk hetzelfde als ER. Het zinvolle overblijfsel uit de objectoriëntatie.
Grote acceptatie in de praktijk
Zelfde als ‘ER’

Geschiedenis
Vanaf het allereerste begin van het computertijdperk bestaat de zogenaamde ‘procesgerichte’ manier van ontwerpen van computersystemen. Denk hierbij aan het gebruik van ‘flowcharts’ en dergelijke. Dit is goed verklaarbaar omdat het in dit prille stadium erom ging de computer middels een reeks instructies te vertellen welke processen uitgevoerd moesten worden en hoe dat kon gebeuren. Later kwamen de opslagmedia erbij en werden de gegevensverwerkende systemen geboren. Deze laatste zijn voor het bedrijfsleven van uitermate groot belang, omdat praktisch alle administraties daar nu mee worden gerealiseerd. Toch heeft het even geduurd voordat men begreep dat ook een andere denkwijze, een meer ‘gegevensgerichte’, nodig was voor het ontwerp en de bouw van deze informatiesystemen. En ik durf te stellen dat er tot op de dag van vandaag een tegenstelling valt te constateren tussen de gegevensdenkers (de ‘databoeren’, waartoe ik mijzelf ook reken) en de procesgeoriënteerden. Het heeft mij in de tijd dat ik mijn eerste schreden in dit vakgebied zette altijd verbaasd dat sommige mensen bij het woord ‘informatieanalyse’ onmiddellijk op de proppen kwamen met procesflowdiagrammen. In mijn onschuld dacht ik dat het erom ging (de structuur van) informatie te analyseren en vandaaruit datastructuren te ontwerpen.
De definitieve doorbraak van het relationele model van Codd eind jaren 80 kan gezien worden als de eerste grote overwinning van het datakamp. In deze tijd speelden zich in conferentiezalen en daarbuiten levendige discussies af over methoden om informatie te analyseren en (vandaaruit) databases en applicaties te ontwerpen. Hierbij vlogen de datagerichte denkers elkaar in de haren. Ik kan mij nog een artikel herinneren waarin Codd zijn pijlen richtte op Chen en zijn ‘Entity Relationship’-methode. Shir Nijssen voerde de polemiek op tot grote hoogten. Ik vind het nog altijd jammer dat zijn houding "Wie niet voor NIAM is is tegen (en dom)" ertoe heeft geleid dat veel ontwerpers zich tegen de ‘feittype’-traditie hebben gekeerd. Terwijl de goeroes (allen datagericht) elkaar aldus vliegen afvingen, kwam in de jaren 90 sluipenderwijs het procesgerichte denken terug. De opkomst van objectoriëntatie luidde duistere middeleeuwen in voor de databoeren. Vol afgrijzen moesten zij constateren dat allerlei terecht afgezworen concepten (zoals pointerstructuren en ‘repeating groups’) vrolijk opnieuw werden geïntroduceerd (object identifiers en meerwaardige attributen).
In tegenstelling tot het datakamp wist men hier de gelederen wel gesloten te houden. De bende van drie (de drie amigo’s: Booch, Jacobson en Rumbaugh) dicteerde de wet en UML (Unified Modeling Language) begon aan zijn opmars. Begonnen als een programmeringsparadigma (en daar inderdaad zeer geschikt en succesvol) strekte de OO-wereld begerig zijn vingers uit naar het domein van de datascene bij uitstek: databasemanagementsystemen. OO-databases zouden het helemaal worden en ook de traditionele Rdbms-leveranciers (Oracle, IBM-DB2 en andere) begonnen onder de commerciële druk van de hype OO-features aan hun producten toe te voegen. In het begin van het nieuwe millennium bleken de OO-databasesystemen toch niet massaal door te breken en werd van de genoemde OO-features in de praktijk nauwelijks gebruik gemaakt. Dit luidde de comeback van dataoriëntatie in.

Figuur 1 Tekenwijzen van informatiemodellen
Een werknemer werkt voor hoogstens één afdeling en een afdeling kan aan meer dan één werknemer werk bieden. Volgens veel ontwerpers maakten de modellenbouwers slechts ruzie over de manier van tekenen.

Figuur 2 Relationeel model

Figuur 3 Generiek model

Figuur 4 Van relationeel naar generiek model
In FCO-IM wordt intern een metamodel gebruikt dat ‘generiek’ is. Dat wil zeggen dat het te zien is als een generalisatie van de metamodellen van RM, ER en ORM. Dit maakt de modeltransformaties vele malen eenvoudiger en krachtiger. De figuren 2, 3 en 4 illustreren dit idee.
Figuur 2 is een relationeel model: 2 tabellen, 8 kolommen (rollen), 5 domeinen, 2 primaire sleutels en één verwijzende sleutel. Generiek gezien: 8 rollen en 7 objecten.
Figuur 3 is een ander generiek model voor dezelfde informatie: 7 objecten (waarvan 2 feit-/objecttypen en 5 labeltypen) en 7 (!) rollen. Eigenlijk een ER-model.
Figuur 4 is een overgang van het relationele metamodel naar het generieke metamodel: Links (A) zit een rol (kolom) in een tabel en wordt gespeeld door een domein. Rechts zijn tabellen en domeinen op één hoop gegooid (objecten).
 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!