"Wanneer wordt aangetoond dat een goed gegevenspakhuis reeds op korte termijn geld bespaart, zal het geen groot probleem meer zijn om grotere budgetten te verkrijgen," aldus Frans Tolen.Dit moet de weg effenen voor de realisatie van de ‘virtual machine’.
Martin Healey vraagt zich in zijn column van 24 mei 1996 af hoe de samensmelting van de produktiesystemen, de operationele systemen en het gegevenspakhuis tot een ‘virtual machine’ te realiseren is met aanvankelijk kleine budgetten. Hij stelt ondermeer dat het rendement van een compleet centraal gegevenspakhuis niet eenvoudig te meten zal zijn. Als hij daarmee het effect op managementinformatie bedoelt, is dat zeker waar. Een gegevenspakhuis dient dan ook te voorzien in andere functies, waarvan het effect wel meetbaar is. Bij het opzetten van de kleinste ‘datamarkt’ (deelpakhuis, red.) dient men hier al rekening mee te houden. Alleen dan kan men voldoende steun en financiële middelen beschikbaar krijgen voor het opzetten van het ideale gegevenspakhuis.
De huidige gegevenspakhuizen worden allemaal gebouwd als een apart te realiseren project met een vast eindresultaat, namelijk een omgeving die gevoed wordt door bronsystemen en eenvoudig door de organisatie te benaderen is. Als gegevenspakhuizen daarentegen worden beschouwd als tussenfase op weg naar een gedistribueerde client/server-omgeving waar alle gebruikers van een organisatie toegang toe hebben, moeten de eisen aan de componenten van het gegevenspakhuis anders gedefinieerd worden.
Wat zijn dan die andere functies die eveneens in het gegevenspakhuis moeten worden ondergebracht? Hierbij moet men vooral denken aan functies die onnodig de produktie- en operationele systemen belasten. Voorbeelden zijn lijstjes die geprint worden, etikettenprogramma’s, uittreksels voor managementinformatie en distributiefuncties. Binnen diverse organisaties houden hele afdelingen zich hiermee bezig. Het vervangen van deze functies is heel goed meetbaar. Door ze te onderzoeken wordt het gegevenspakhuis-project niet verzwaard, omdat dit toch moet gebeuren. Juist dit soort functies vertelt veel over het "huidige gegevenspakhuis" van de organisatie. Veel organisaties realiseren zich niet dat ze nu reeds in het bezit zijn van een operationeel gegevenspakhuis. In elke organisatie worden genoemde functies immers ondersteund door programma’s en systemen. Deze zijn echter niet voor een ieder toegankelijk binnen de organisatie, en meestal zijn er geen metadata van beschikbaar. Het realiseren van een gegevenspakhuis is niet anders dan het formaliseren en structureren van dit reeds bestaande ‘zwarte markt’-gegevenspakhuis. Ook deze effecten zijn goed te meten.
Daarnaast moet het toekomstige gegevenspakhuis dezelfde resultaten geven als het ‘zwarte markt’-gegevenspakhuis. Het is dodelijk als er onverklaarbare verschillen optreden tussen de twee pakhuizen.
Steun in de organisatie
Alle steun in de organisatie die op deze wijze verworven wordt, kan verloren gaan als de kosten van het gegevenspakhuis te hoog worden. De initiële kosten voor aanschaf van hard- en software, reclame en voorlichting zijn al fors; daarnaast zijn er ook nog de exploitatiekosten. Zeker in organisaties die voor het vullen van het gegevenspakhuis gebruik maken van ‘copy-management-processen’, zullen de exploitatiekosten snel als te hoog worden ervaren. Ook hiermee dient men rekening te houden bij het kiezen van tools.
Aan de andere kant zijn er ook tools beschikbaar die – in vergelijking met ‘copy-management-processen’ – de cpu nauwelijks belasten. Denk daarbij aan ‘data-propagator’-achtige tools. Deze zijn immers in staat vanuit de database-logfiles data te repliceren naar bewaarplaatsen die niet per se op de mainframes hoeven te staan. Dit maakt het mogelijk om real-time data te distribueren en deze vervolgens op goedkopere platforms dan het mainframe verder te verwerken.
In organisaties die al te kampen hebben met overbelaste mainframes kan juist deze manier van werken eveneens voor een breed draagvlak zorgen. Bij vervanging van het ‘zwarte markt’-gegevenspakhuis, wordt het voor iedereen zichtbaar dat een goed gegevenspakhuis reeds op korte termijn geld zal besparen. Als dit eenmaal aangetoond is, zal het geen groot probleem meer zijn om grotere budgetten te verkrijgen.
Drijfveer
Het gegevenspakhuis mag dus niet alleen beschouwd worden als een verzameling gestructureerde ‘bron’data, maar vooral als een verzameling gestructureerde ‘meta’data. Met andere woorden: men bezit een kennis-bibliotheek met de informatiebehoefte van het betreffende deel van de organisatie. Deze kennis is zeer goed te gebruiken voor hergeneratie van onderdelen van produktie- en operationele systemen. Wanneer dit besef doordringt, wordt de keus voor de gegevenspakhuis-tools beperkt.
Het spreekt vanzelf dat men bij het kiezen van tools voor het gegevenspakhuis rekening moet houden met genoemde eisen. Dit geldt voor de programmeertools maar vooral ook voor het database-managementsysteem.
Om functies te kunnen vervangen in de produktie- en operationele systemen dienen de gekozen tools gebruik te maken van een repository met metadata, aangevuld met kennis over de beste implementatievorm.
Een voorbeeld. Voor het benaderen van een database op een ander platform dan dat waarop de query draait, kan natuurlijk een copy-management-slag worden uitgevoerd. Met de huidige technieken als drda kan ook een gedistribueerde implementatie van DB2 voldoen. De ontwikkeltools moeten hiertoe een advies kunnen geven en alle alternatieve implementaties kunnen ondersteunen.
Daarnaast moeten er vooral ook beslissingen vallen over de vulmethoden van het gegevenspakhuis, met de daarbij behorende tools.
De ‘utopie’ van een virtual machine kan in de toekomst gerealiseerd worden. Met behulp van de huidige in gebruik zijnde tools is een deel van de benodigde architectuur in te vullen. Zo heeft IBM met haar Open Blueprint reeds op alle hardware-platformen DB2 geschikt gemaakt voor gedistribueerde verwerking. Daarnaast voldoen huidige versies van besturingssystemen als OS/390(MVS), AIX en OS/2 reeds aan de standaarden van de Open Software Foundation/Distributed Computing Environment. Steeds meer produkten van diverse fabrikanten voldoen aan deze OSF/DCE-standaarden. Zij voorzien in transparante toegang voor applicaties tot data, waar dan ook binnen de organisatie.
Wat nog ontbreekt is een sterke drijfveer waardoor de benodigde gelden beschikbaar komen en voldoende inzicht in de legacy-systemen verworven wordt om ze te herbouwen in een gedistribueerde omgeving. Juist deze mogelijkheid wordt geboden door de bouw van een gegevenspakhuis. Indien gewenst, dient men de keuze voor gegevenspakhuis-tools hierop af te stemmen. Dit impliceert dat deze tools moeten werken vanuit een centrale repository. De software dient te voldoen aan OSF/DCE standaarden, terwijl de hardware moet bestaan uit een mainframe, midrange-computers en PC’s.
Alleen hierdoor kunnen produktiesystemen, operationele systemen en gegevenspakhuis samensmelten tot een ‘virtual machine’, wat in de toekomst een belangrijk concurrentievoordeel kan opleveren.
Frans Tolen, consultant datawarehousing bij CMG-Finance