Het ‘corporate datawarehouse’ geldt als dé infrastructuur voor het bedrijfsbreed ontsluiten van gegevens. Door een aantal structurele knelpunten voldoet zo’n gegevenspakhuis slechts zelden. Om deze op te heffen zijn er enkele technieken in ontwikkeling, stelt een koppel consultants van Ordina. Uit onderzoek naar federatieve databases, kennistechnologie en gegevensintegratie in web-omgevingen tekent zich een architectuur af voor de opvolger van het gegevenspakhuis, de Common Information Retrieval Broker Architecture.
Gegevenspakhuis-projecten worden vaak voor verschillende klanten (afdelingen of business units) uitgevoerd en beogen hen daarbij tot een aantal gemeenschappelijke gegevensdefinities te laten komen. Dit laatste is in de praktijk lastig of onmogelijk: elke klant heeft zijn eigen kijk op de gegevens. Verder kunnen de integratie en kwaliteitsverbetering van gegevens forse, niet te rechtvaardigen inspanningen vergen. De projecten krijgen een typische doorlooptijd van twee tot drie jaar, wat in combinatie met de brede klantengroep tot een onduidelijk en aan veranderingen onderhevig resultaat leidt.
Inmiddels begint de kleinschaligere en incrementele projectaanpak terrein te winnen. De meeste kans biedt een stapsgewijze opbouw van de gegevensontsluiting, waarbij elke stap in de behoefte aan gegevens (bijvoorbeeld van stuurinformatie of financiële verslaglegging) voorziet. Activiteiten ten behoeve van gemeenschappelijke definities, kwaliteitsverbetering en integratie blijven beperkt tot delen waarbij de meerwaarde aantoonbaar is. Een stapsgewijze aanpak kan in eerste instantie ten koste gaan van de samenhang van het model van het gegevenspakhuis. Hergebruik van gegevens of definities en het onderhoud van het model zullen dus beter moeten worden ondersteund.
In een operationeel gegevenspakhuis zouden de metagegevens, die de data en processen beschrijven, een centrale rol moeten spelen – een breed onderschreven stelling, waarvan in de praktijk maar weinig terechtkomt. Wanneer de meta- en de feitelijke gegevens en processen slechts beperkt gekoppeld zijn, kan het actueel houden van de metagegevens zeer arbeidsintensief worden. Het doorvoeren van wijzigingen is dan kostbaar en risicovol.
De metagegevens zouden de gebruikers van het gegevenspakhuis, de business, inzicht moeten geven in de beschikbare data. Deze metagegevens sluiten echter vaak maar matig aan op het wereldbeeld van de business, wat de bruikbaarheid beperkt. Hiermee kan een van de belangrijkste drijfveren voor het onderhoud van de metagegevens wegvallen.
Tot slot worden gegevenspakhuizen nagenoeg altijd in ‘batches’ bijgewerkt; vaak is het zelfs een architectonische keuze om het pakhuis overdag niet te wijzigen. De vraag naar (vrijwel) real-time gegevens, 24 uur per dag, neemt toe: het call-center wil een actueel klantbeeld, bezoekers van de Internet-balie willen ook ’s nachts terecht kunnen. Een gegevenspakhuis zal niet goed in deze behoeften kunnen voorzien.
Nieuwe technieken
Veel technieken waarmee de genoemde problemen aangepakt kunnen worden, zijn gerelateerd aan het onderzoek naar federatieve databases (fdbms-en). Een federatief dbms kan worden gezien als een virtuele database waarin de gegevens uit een aantal bronsystemen tot op zekere hoogte geïntegreerd (aansluitend gemaakt) zijn ondergebracht. Een federatieve database is geen gegevenspakhuis, maar meer een interface op de onderliggende systemen: gegevens worden vaak real-time uit de bronsystemen gehaald, er wordt geen historie bijgehouden en wijzigingen zijn door te voeren.
Aan de hand van het fdbms worden enkele relevante technieken geïntroduceerd. Hierna komt de toepassing van deze technieken in web-omgevingen aan de orde; de grote motor achter de ontwikkelingen. De IT-industrie participeert sterk in al het genoemde onderzoek.
‘Wrappen’ en gegevensmodellering
Om de heterogene bronsystemen te laten aansluiten op het fdbms, worden ze ingepakt met een wrapper. De wrapper biedt een uniforme interface die de brongegevens in het voor het fdbms vereiste formaat levert. Vaak worden wrappers op basis van metagegevens gegenereerd.
Onderzoekers nemen voor de modelleringswijze en de querytaal van het gemeenschappelijke gegevensmodel meestal de standaard van de Object Database Management Group (ODMG) (http://www.odmg.org) als uitgangspunt. Dit is een uitbreiding op het objectmodel van OMG’s Corba (http://www.omg.org) ten behoeve van object-georiënteerde databases. Wrappers leveren in dit geval de gegevens als objecten. Voorbeelden van op ODMG gebaseerde federatieve databases zijn Iro-db (http://www.darmstadt.gmd.de/oasys/projects/irodb) en Vhdbs (http://www.isst.fhg.de/pages/projekte/vhdbs_euromednet98.pdf). Ook het wrappen van legacysystemen naar business-objecten als basis voor nieuwe applicaties, als bij IBM’s Component Broker Connector (http://www.software.ibm.com/ad/cb), is een toepassing van deze technieken.
Semantische integratie en ontologieën
Bij het integreren van gegevens in een federatief database-managementsysteem bestaan zelfde behoeften als bij een gegevenspakhuis: de metagegevens zouden leidend moeten zijn en door een hoog conceptueel niveau ook voor niet-technici bruikbaar moeten zijn.
De oplossing wordt hier gezocht in de semantische integratie van informatie en ontologieën. Hierbij kijkt men niet alleen naar de vorm, de syntax, maar ook naar de betekenis, de semantiek, van de gegevens en gegevensbewerkingen. Globaal komt dit er op neer dat de concepten waar de gegevens van een systeem voor staan en de relaties tussen die concepten in een kennisbank beschreven worden. Het conceptuele model van het ‘wereldbeeld’ van het systeem wordt een ontologie van het systeem genoemd.
De integratieproblematiek komt nu neer op het leggen van relaties tussen de concepten uit de ontologieën van de bronsystemen en de concepten in een gemeenschappelijke ontologie. Een ontologie kan door het conceptuele niveau goed aansluiten op het wereldbeeld van de business. Omdat ook binnen de business op uiteenlopende wijzen naar de gegevens wordt gekeken, zal er niet één gemeenschappelijke ontologie ontstaan, maar een verzameling van domein-ontologieën (marketing, financiële verslaglegging, enzovoort). Eén gegeven kan dan onder meerdere concepten vallen. Het vastleggen van de betekenis van gegevens in een kennisbank maakt intelligente programmatuur mogelijk, waarover later meer.
Beschrijvingen van de vorm van gegevens blijven noodzakelijk: het is nuttig om te weten dat twee bronsystemen een identiek concept ‘klant’ met een ‘adres’ kennen, maar ergens moet ook zijn vastgelegd welke formaten de adressen hebben en welke bewerkingen nodig zijn om ze te kunnen vergelijken. Deze syntactische beschrijvingen zullen deels uit de ontologieën af te leiden zijn.
Mediators
Na het specificeren van de vorm en, mogelijk, de betekenis van de gegevens en gegevensbewerkingen, volgt de implementatie hiervan in een aantal processen. Een algemeen geadopteerd concept om dergelijke processen te structureren is de mediator van Wiederhold (http://www-db.stanford.edu/people/gio.html).
Mediators zijn middleware-modules die gegevens van een aantal bronnen verwerken tot meer waardevolle gegevens, ten behoeve van een of meer toepassingen. Complexere functionaliteit wordt bereikt door mediators te combineren. In een federatieve database kan een mediator een proces zijn dat een ‘databaseview’ of een object realiseert.
De combinatie van mediators, semantische integratie en wrappers wordt onder meer gevonden bij de fdbms-en Tsimmis (www-db.stanford.edu/tsimmis) en Merlin (id.inel.gov/merlin).
Toepassing in webomgevingen
Het potentieel van bovenstaande technieken op Internet heeft de ontwikkelingen in een stroomversnelling gebracht. Er worden systemen nagestreefd die uit een groot, divers en dynamisch gegevensaanbod zinvolle informatie halen. De systemen zullen zelfstandig met gegevensbronnen moeten onderhandelen over de betekenis en de vorm van de geboden gegevens. (Dergelijke autonome, intelligente systemen worden meestal agents genoemd). Intelligente integratie op basis van ontologische principes speelt hierin een sleutelrol.
Operationele toepassingen zijn er onder meer in webwinkels die het aanbod van een aantal webwinkels integreren. De klant wordt zo in staat gesteld om bijvoorbeeld de goedkoopste leverancier te vinden, als bij Shop The Web van Amazon (http://shoptheweb.amazon.com/stw/template/home.html). Een ander soort toepassing is de personeelsbank van Restrac (http://www.restrac.com), waarin CV’s uit diverse bronnen bijeen worden gebracht.
Deze systemen beperken zich nog tot een klein domein, zodat de interpretatie van brongegevens (webpagina’s) haalbaar blijft. Veel ambitieuzer is het onderzoekssysteem Infosleuth (http://www.mcc.com/projects/infosleuth2), waarmee al pilots zijn uitgevoerd. Hierin melden bronnen (websites, maar ook ingepakte databases) zich aan en vertellen zij via hun ontologie wat voor gegevens ze bieden. Informatieverzoeken aan Infosleuth worden uitgezet bij de bronnen die er mogelijk antwoord op kunnen geven, de antwoorden komen geïntegreerd bij de vraagsteller.
Voordat dergelijke systemen iets met de gegevens op websites kunnen, zal de betekenis van deze gegevens beschikbaar moeten zijn. Hiervoor is een belangrijke stap gezet met de brede acceptatie van XML (http://www.w3c.org/xml). Html is de standaardtaal waarin de opmaak van de gegevens op een webpagina wordt beschreven; met XML kan ook de betekenis van de gegevens worden benoemd (bijvoorbeeld ‘auteur’). Er wordt nu hard gewerkt aan standaardbegrippen voor bepaalde domeinen (dus ‘auteur’ en niet ‘schrijver’): eenvoudige domein-ontologieën dus. XML beperkt zich niet tot webomgevingen en is ook door databaseleveranciers opgepakt.
Een nieuwe architectuur
Met de beschreven technieken zijn de knelpunten van het gegevenspakhuis weg te nemen. Eenmaal volwassen zullen systemen als Infosleuth zich nog uitgebreid moeten bewijzen, voordat inzet in een grootschalige productieomgeving een optie wordt. De bedrijfsbrede informatiemarkt waarop zowel de primaire als de ondersteunende processen autonoom en workflow-bewust informatie uitwisselen is nog ver weg.
De komende generatie infrastructuur voor bedrijfsbrede gegevensontsluiting zien we als een tussenvorm: functioneel beheer op een hoger niveau; implementatie in betrouwbare, gedistribueerde processen. Voor deze infrastructuur zal een prototypische architectuur geschetst worden. De voornaamste winstpunten hiervan ten opzichte van het gegevenspakhuis zijn:
- ontologieën doen hun intrede op het niveau van functioneel beheer;
- afnemers (de business) kunnen zelf de gewenste gegevens specificeren, in hun eigen terminologie;
- elke groep afnemers wordt volgens zijn eigen wereldbeeld benaderd;
- real-time en ad hoc ontsluiting zijn mogelijk;
- hergebruik en change-management worden intelligent ondersteund;
- een gedistribueerde architectuur is de basis voor een incrementele opbouw en schaalbaarheid.
Bronsystemen
Bronsystemen kunnen uiteenlopen van legacysystemen tot systemen met een moderne architectuur. Bij het aansluiten van een bronsysteem worden de concepten, gegevensmodellen en administratieve eigenschappen (onder andere gegarandeerde levertijden en actualiteit) van het bronsysteem in de repository opgenomen. Aan de hand hiervan genereert de mediatormanager een wrapper voor het bronsysteem.
Aan de afnemende kant bevinden zich ondermeer applicaties en ‘datamarts’. De gewenste gegevens worden met de informatiemakelaar gespecificeerd. Daarbij worden ook eisen aan administratieve eigenschappen en bijvoorbeeld historie gesteld, waarbij de informatiemakelaar kan bepalen in hoeverre deze haalbaar zijn.
Repository
Het fundament van de architectuur is de repository. Dit is een kennisbank die enerzijds de specificaties bevat die de functionaliteit van het systeem bepalen en anderzijds de statusinformatie bevat die volgt uit het functioneren van het systeem.
In de repository bevinden zich verschillende ontologieën. Ieder bronsysteem kent zijn eigen ontologie. Ontologiebeheerders koppelen deze aan domein-ontologieën, die elk overeenkomen met een wereldbeeld van een bepaalde groep afnemers. Domein-ontologieën worden incrementeel en toepassingsgericht opgebouwd. De gegevens voor een afnemend systeem worden op basis van de domein-ontologieën gespecificeerd. Afnemers kunnen hierbij eigen concepten aanmaken, die echter niet ongecontroleerd algemeen beschikbaar komen.
Onder het semantische niveau met de ontologieën, ligt een syntactisch niveau waarop de vorm van de gegevens en de bewerkingen tussen de gegevens gespecificeerd zijn. Hiervoor kan een objectmodel als dat van ODMG gebruikt worden. Het syntactisch niveau zal tot op zekere hoogte door de informatiemakelaar uit het semantische niveau zijn afgeleid.
De specificatie van de verdeling van functionaliteit over mediators en de statusinformatie bevinden zich op het technisch niveau.
Informatiemakelaar
De informatiemakelaar maakt het gegevensaanbod voor de business toegankelijk en dient als gereedschap voor het functioneel beheer. Omdat de betekenis van de gegevens in een kennisbank is vastgelegd, kan de makelaar erover redeneren. Dit legt de basis voor intelligente ondersteuning van de gebruikers.
De afnemers van gegevens kunnen de informatiemakelaar in hun eigen terminologie (domein-ontologie) benaderen. Via interactie met de makelaar komen afnemers tot een specificatie van hun gegevensbehoefte. De implementatie hiervan gebeurt door de mediatormanager. Door naar gegevens met een vergelijkbare betekenis te kijken, kan de makelaar hergebruik van definities of gegevens actief bevorderen. Informatie over de status van het systeem kan de makelaar op conceptueel niveau geven (‘De maandcijfers wachten nog op de omzetgegevens van de reisverzekeringen’).
Verder worden met de informatiemakelaar de ontologieën en gegevensmodellen onderhouden. Algemene definities zijn op te bouwen of aan te kopen en zijn als bouwstenen te gebruiken. Bij wijzigingen is automatische bepaling van migratiestappen en de bewaking van functionaliteit mogelijk. Samen met het actief bevorderen van hergebruik steunt dit een incrementele opbouw van de gegevensvoorziening.
Mediatormanager en mediators
Met de mediatormanager verdelen technisch beheerders de functionaliteit van het systeem over mediators. Voor de verdeling gelden randvoorwaarden: eisen aan administratieve eigenschappen zoals levertijden, eisen ten aanzien van historie en het streven om wijzigingen in de productieomgeving te beperken. De mediatormanager bewaakt deze randvoorwaarden en genereert de mediators, bijvoorbeeld als Corba-objecten of als parameters voor generieke mediators. Ten behoeve van historie of beschikbaarheid kunnen mediators van lokale gegevensopslag worden voorzien.
In het geval van een eenmalige, ad hoc gegevensbehoefte kunnen de benodigde mediators buiten de productieomgeving worden gegenereerd en uitgevoerd. Het afnemend systeem is dan bijvoorbeeld een spreadsheet. Inpassing door technisch beheer is niet noodzakelijk. Er zijn mediators denkbaar die niet gegenereerd worden, bijvoorbeeld een complex ontdubbelingssysteem of een ‘legacy’ gegevenspakhuis. Deze zijn als vaste componenten in de repository op te nemen.
Andere faciliteiten van de mediatormanager zijn het bekijken en beïnvloeden van operationele mediators en de generatie van wrappers voor bronsystemen.
Invulling van de architectuur
De voor invulling van deze architectuur vereiste technieken verkeren in verschillende stadia van volwassenheid. Generatie van wrappers en gegevensverwerkende programmatuur vanuit metagegevens gebeurt al jaren in maatwerkoplossingen en wordt bijvoorbeeld ook al geboden door de Power-serie van Informatica (http://www.informatica.com).
Met semantische integratie en ontologieën zal nog veel praktijkervaring moeten worden opgedaan. Dit is echter goed geleidelijk uit te bouwen, waarbij de functionaliteit van de informatiemakelaar meegroeit. Ordina Utopics (http://www.utopics.nl) heeft op dit punt positieve ervaringen met een gegevenspakhuis waarbij de business zelf de behoefte aan gegevens specificeert: een beperkte mate van semantiek heeft hier al een grote meerwaarde.
Tot slot is er de implementatie in gedistribueerde processen die real-time ontsluiting ondersteunen. De ontwikkelingen op dit gebied gaan snel. Er zijn standaarden voor de uitwisseling van (meta)gegevens, maar een volwaardige standaardarchitectuur ontbreekt nog.
Architectuur met oplossingen
De knelpunten die bedrijfsbrede gegevensontsluiting via gegevenspakhuizen met zich meebrengt worden niet opgelost door dezelfde gegevenspakhuizen incrementeel op te bouwen. De opvolger van het gegevenspakhuis moet gezocht worden in een architectuur waarin oplossingen voor de business voorop staan. Nieuwe technieken op het gebied van gegevensintegratie bieden hiervoor de middelen.
Beheersbaarheid wordt bij deze meer gedistribueerde aanpak gevonden in een leidende rol voor metagegevens, van een hoger niveau. Hiermee kan de business bij het functioneel beheer worden betrokken, bijvoorbeeld gefaciliteerd door geautomatiseerde informatiemakelaars. Onderzoek op het gebied van semantische integratie en ontologieën moet hiervoor naar de praktijk vertaald worden.
Deze bedrijfsbrede gegevensvoorziening is niet meer gelimiteerd tot het leveren van maandelijkse rapportages of het leveren van gegevens voor trendanalyses, maar kan ook voorzien in real-time gegevensbehoeftes, zoals een geïntegreerd klantbeeld.
In dit artikel is een voorbeeld gegeven van een dergelijke architectuur en de bijbehorende componenten. Standaardisatie van zo’n architectuur zou een versnelling in deze markt kunnen brengen. Pakketten en componenten kunnen dan beter ingezet worden om de architectuur in te vullen. In navolging van Corba, een referentiearchitectuur voor gedistribueerde functionaliteit, zou Cirba (Common Information Retrieval Broker Architecture) een referentiearchitectuur voor gedistribueerde informatie kunnen zijn.
Menno Jonkers en Martijn Sanders, consultants bij Ordina Utopics Corporate Information BV, een Competence Center van de Ordina Groep.
