OTAP reloaded

Het OTAP vraagstuk bij datawarehouses is een lastig probleem en heeft in 4 specifieke gevallen waarschijnlijk 5 oplossingen. Ik ga hieronder ten tweede male in op het OTAP vraagstuk en geef hieronder een aantal aspecten die een rol spelen bij het bepalen van de OTAP strategie. Het eerste OTAP blogje is alweer van 7 november 2009.

Architectuur

Vanuit architectuur oogpunt wil je zoveel mogelijk standaardiseren en processen en objecten herhaalbaar hebben. Architectuur, gebruikte hard- en software en de topologie van de informatieketen, bepalen voor een groot deel de ‘kopieerbaarheid’ van een ‘datawarehouse’. Dat is dus één factor die bepaalt of je wel of niet de P kopieert naar de Acceptatieomgeving. Bij één van mijn klanten hebben ze zonder met de ogen te knipperen de hardware en software 2 maal besteld om te voorzien in een Productie en een acceptatie omgeving. Men wilde ook e.e.a. nog eens dubbel uitvoeren om aan de eisen voor ‘High Availability’ te voldoen. Dat kwam dus neer op 4 giga servers en dito opslag en software. Argument was dat men ook de acceptatieomgeving wilde kunnen testen op performance. Daarvoor moet de load ongeveer overeenkomen met productie.

Een ander architectuuraspect is het gebruik van metadata gedreven generatie van laadprocessen. Indien er gebruik gemaakt wordt van een generatie-engine waarbij de laadprocessen on the fly kunnen worden gegenereerd, geven ook een extra dimensie aan dit vraagstuk. Eventueel herstel van fouten is hiermee veel makkelijker en dus geeft dat andere eisen aan geslotenheid van productie en de opzet van de testomgevingen. Het stelt daarentegen ook speciale eisen aan de productiebeheerders.

Beheer
Uit beheer oogpunt is het vaak niet wenselijk dat mensen bij de Productie omgeving kunnen komen om daar veranderingen in door te kunnen voeren, die buiten de releasekalender vallen. Dat is, als je het beheer wilt inrichten net als bij traditionele systemen. Zoals ik in het volgende hoofdstukje ‘Eisen aan de omgeving en informatie’ aangeef worden er andere eisen gesteld aan een datawarehouse- of informatie omgeving.

De reden dat men de productie (en acceptatie) vaak wil afschermen zit hem volgens mij in de bepaling van de verantwoordelijkheid voor het resultaat en de kosten voor reparatie van fouten die in de productie kunnen komen als gevolg van ongecontroleerd wijzigingen doorvoeren op de productieomgeving. Een katalysator kan zijn dat het ‘technisch’ beheer van het datawarehouse is ge-outsourced en dat de outsourcingpartij het gewoon niet toestaat dat er ook maar ‘iets’ wordt aangepast in de productie, omdat ze dan mogelijk niet meer aan hun SLA kunnen voldoen.

Eisen aan de omgeving, en aan de informatie

De eerste vraag die je moet stellen is: “Wordt het DWH gebruikt als primair systeem”. Met andere woorden, wordt informatie uit het DWH teruggevoerd in het primaire proces waardoor afwijkingen of problemen grote gevolgen voor het primaire proces hebben. Als dat zo is dan moet de productie omgeving van het DWH ook als zodanig beheerd worden, dichtgemetseld dus. Meestal is dat echter niet zo. Wordt het alleen als informatiesysteem gebruikt voor geaggregeerde informatie en is het geen drama als er een kleine afwijking zit in een analyse. Meestal zijn deze afwijkingen in een open systeem ook makkelijk en snel op te lossen.

De eisen die aan de omgeving (datawarehouse) en de informatie gesteld worden zijn uiteindelijk bepalend voor de architectuur, waaronder ik ook de procesarchitectuur schaar. Daarin staat hoe de ontwikkelprocessen lopen en dus de OTAP strategie. Voorbeeld: Een datawarehouse waar een maandelijkse load in gebeurd en die ook maandelijkse rapportverversing kent stelt hele andere eisen aan de beschikbaarheid van de P omgeving dan een real-time geladen real-time refresh dwh. In het eerste geval zou je kunnen besluiten om op een korte ‘gesloten periode’ na de Productie open kan zetten voor wijzigingen, mits goed van metadata en documentatie voorzien uiteraard.

De ‘geslotenheid’ van de productieomgeving is een belangrijke factor bij het bepalen van de inrichting van de Acceptatie. Omdat:

a. de mate van beveiliging een onderdeel is van-, en invloed heeft op het testproces;

b. een ‘toegankelijke’ Productie omgeving het makkelijker maakt om bepaalde informatiegroepen uit het DWH te kopiëren voor het opzetten van de A;

c. een toegankelijke P geeft ook een soort cultuur statement af waarbij het dus gebruik is om flexibeler met omgevingen om te gaan. Dat zal ook gevolgen hebben voor de Acceptatie. Voor de Acceptatie is dan te verwachten dat hij alleen op piek performance geschaald wordt als dat nodig is. En verder opgebouwd wordt als dat nodig is;

d. een gesloten Productie vraagt om een formeel en zeer goed gedocumenteerd promotieproces wat door technisch beheerders, soms ge-outsourced, uitgevoerd wordt. Wanneer de (outsourcing partner) beheerder informatie nodig heeft omtrent het presteren van de nieuwe release, dan zal dat met een productieload van het datawarehouse moeten worden uitgevoerd.

Business eisen als flexibiliteit en aanpasbaarheid staan in de praktijk helaas toch op gespannen voet met een strak beheerde Productie omgeving. Vaak heeft men een antwoord nodig op een ad-hoc vraag die vraagt om aanpassingen in de laadprocessen van de Productie omgeving. Als die maar 6 maal per jaar mag worden aangepast tijdens een release kan hier niet aan worden voldaan. Ik heb het in mijn termijn van minder dan twee jaar bij een landelijke uitkeringsinstantie een aantal maal meegemaakt dat de minister een antwoord wilde op een ad-hoc vraag. Minstens twee keer moesten we de P aanpassen en daarna konden we daarop de queries draaien. Dat was in een strak beheerde situatie niet mogelijk geweest. In een situatie waar dit soort vragen niet te verwachten zijn is het veel minder een probleem om de Productie dicht te timmeren.

Operatie

Je kunt volgens mij stellen dat de noodzaak voor een ‘zware’ Acceptatie, kopie van Productie, met name afhankelijk is van de eisen die aan het testen van de non-functionals als performance (ook van laden), worden gesteld. Dit is een operationeel requirement. Vaak niet alleen van de eindgebruiker maar ook van de productiebeheergroep. Er worden in de Acceptatieomgeving niet alleen functionele requirements getest maar vaak zijn DBA’s bezig met het verhogen van de prestaties door te experimenteren met indexen, partitionering, parameterinstellingen van de database en dergelijke. Dat zijn ook aanpassingen die naar de productieomgeving gepromoveerd moeten worden.

Wat je vaker ziet is een door analisten met queries overladen productie omgeving, dat vraagt om speciale maatregelen. Te denken valt aan een aparte query/analyse omgeving (sandbox) waarin de analisten naar hartelust hun modellen op kunnen bouwen en testen. Mochten er modellen goed genoeg gevonden worden en geoptimaliseerd zijn om goed te presteren in de productie, rekening houdend met belasting van andere gebruikers, dan kan deze het tot volwaardig algemeen gebruikt informatieproduct schoppen en in de P opgenomen worden.

Wat is dan het antwoord

Als eerste: als ik zeg ‘open’ of ‘toegankelijk’ bedoel ik niet ‘ongecontroleerd’, ‘ongebreideld’ en ‘naar hartenlust toegankelijk’. Al is het vaak niet een primair systeem, ik beschouw de data en informatie als zeer waardevol en deze moeten te allen tijde beschermd en veilig zijn. Goed versiebeheer, metadatabeheer en een uitstekend contingency plan (planning voor alle eventualiteiten en restoren van goed-werkende situaties) helpen ons een end op weg. Daarnaast het besef dat de data in het warehouse een waarde vertegenwoordigd en de benodigde verificatiemethodes moeten voldoende waarborgen bieden voor veilig gebruik van de productie omgeving.

Ten tweede: laten we niet blind de O-T-A-P weg volgen alleen maar omdat dat ooit als beheerbaar principe is uitgevonden. Laten we per situatie bekijken wat onze strategie wordt. Dat kan heel goed een O-A-P-Q-Q’ strategie zijn. Q staat dan voor Query en Q’ staat voor Query kopie/ad-hoc omgeving, in dit scenario kunnen de P en Q de “waarheid” van de organisatie bevatten en als zodanig afgesloten zijn. De Q’ is in dit voorbeeld de speeltuin voor de analisten.

Dat gezegd hebbende, de architectuur en OTAP strategie moeten op maat gemaakt worden. Hoe moeilijk het soms ook is, beheer zal daarop aangepast/opgeleid moeten worden. Dat is niet iets wat in één keer gaat gebeuren, daar moet dus een soort roadmap voor getekend worden. Er zijn wel degelijk voorbeelden van datawarehouse beheer omgevingen, ook ge-outsourced, die op een flexibele manier kunnen werken. Ik heb dat zelf (min of meer) gezien bij een telecom bedrijf.