Data Warehousing

Top Down of Bottum Up of The best of Two Worlds

2008-09-15T12:28:00.000-07:00

Top down is een complex probleem in stukken hakken; methodisch uitwerken; ontwerpen onder architectuur en daarna maken. Alles van grof naar fijn min of meer volgens de waterval methode. Zo maken we gebouwen, infrastructuur en (management) informatie systemen. Dit is de blauwe wereld van de denkers. Zij hebben het overzicht.

Bottum up is een probleem of uitdaging creatief aanpakken. Er is een idee van een oplossingsrichting. Die wordt getest, het werkt maar half. Een nieuwe richting ontstaat. Kortom de oplossing wordt gevonden door het te proberen en ontstaat tijdens het werk. Dit is de wereld van de doeners. Ook Agile software ontwikkeling en RUP werken zo. Net als veel kunstenaars. Zij kunnen producten maken.

Als je slechts een van de twee werelden toepast mis je veel. Niet alles is te top down plannen. Doe dit alleen op hoofdlijnen. Laat de makers de ruimte op hun manier de problemen aan te pakken. Beperkt hun tijd zodat de resultaten binnen de grenzen worden opgeleverd.
Geef beide werelden de ruimte en gebruik hun kracht: ratio en creativiteit.

Droom of Nachtmerrie

2008-04-21T12:12:00.000-07:00

Ik kom ze nog steeds tegen. Projecten met requirements die op zichzelf allemaal heel valide zijn en een mooi doel nastreven. Het is bijna als een droom als het allemaal voor elkaar komt.

De praktijk is een stuk weerbarstiger. Na een lange tijd, soms meer dan een of twee jaar, blijkt dat de droom te hoog gegrepen is. De droom lijkt een nachtmerrie te worden.

Hoe kunnen we nu voorkomen dat dit gebeurd?

Inmon zie het al: groot denken en vooral klein starten. Dat is waar, maar hoe doe je dat dan.

De volgende 3 stappen kunnen helpen om een droom waar te maken.

1 Bedenkt je droom. Ga na wat je wilt bereiken en gebruik je fantasie.

2 Bedenk een plan. Ga na wat nodig is om je droom te bereiken, maakt een realistisch plan van aanpak. Hierbij zijn kleine stappen in de richting essentieel.

3 Ben kritisch. Doe een risico analyse, bedenk wat er allemaal fout kan gaan

Pas je plan van aanpak en/of je droom aan. Blijf de stappen doorlopen totdat je tevreden bent. Vaak helpt het om andere hieraan mee te laten doen. Op deze manier kan je een droom realiseren en wordt je droom geen nachtmerrie.

Doen wat je wilt

2008-04-04T04:20:00.001-07:00

Doe wat u wilt,
Niet alleen wat u kunt.

Met dit soort advertenties worden mensen geworven. Deze is van CAP.
Het lijkt leuk, maar wat kunnen ze er van waarmaken? In mijn ogen zijn het valse beloften.

Als ik een medewerker krijg die niet doet wat ie voor staat opgesteld (een boom omzagen) en als dat dan ook nog 10x zoveel tijd kost gaat ie er uit. Ongeacht hoe mooi het resultaat is.

Als je veel kan en wil doen wat je wilt, ga je niet in dienst bij een van de grote mensleveranciers!
Als je een kunstenaar bent, ga je toch geen hout hakken!

Kennis en ervaring

2008-03-09T12:20:00.000-07:00

Vorige week las ik een interessant artikel in het Brabants Dagblad. Het ging over de herbouw van een oude molen. Bij de werkplaats die dat uitvoerde was een korte schets voldoende om een ingewikkeld houten rader gestel te bouwen. Volgens de directeur kwam dit omdat de medewerkers veel kennis en ervaring hadden. Nieuwe medewerkers recht van school kunnen alleen van heel gedetailleerde tekeningen werken en het kost veel tijd die te maken.

Dat is herkenbaar. Gisteren had ik kennissen te eten. Ik ging op een gegeven ogenblik uitleggen hoe ik een onderdeel van een houten hekje wilde monteren. De tijd die het kost om het uit leggen is bijna net zo veel als om het uit te voeren.

Daar ligt de link met ICT. Het uitleggen van ingewikkelde zaken zoals DW en BI aan verschillende partijen kost veel tijd, zeker als het publiek niet echt geschoold is in het vak. Ook de ICT’ers hebben vaak hun eigen jargon en ideeën en het kost veel tijd nieuwe ideeën en best practices uit te leggen. Op zich is het een goede investering. Alleen vaak jammer dat de mensen na een tijd weer wat anders gaan doen.

In praktijk merk je dat het uitleggen van complexe zaken aan mensen met kennis en ervaring een stuk eenvoudiger is. Dat scheelt veel tijd en geld. Wel is het dan zaak goed te documenteren zodat anderen (beheer) het later op kunnen pakken.

Cobb’s Paradox (2)

2008-02-22T02:04:00.000-08:00

Mijn vorige beschouwing was nogal filosofisch.

In praktijk is het eenvoudig. Slechte projectleiders zijn er nog steeds. Laatst was ik adviseur bij een project en daar bleek de projectleider geen PID (of PvA) te kunnen schrijven, daar "had" hij mensen voor, ik dus. Zelfs naar het voorkauwen, ik heb een concept geschreven, maakte hij er niets van.
Nadat ik had aangegeven dat ik niet tevreden was over zijn kwaliteiten en houding (hij stond ook niet open voor constructieve feedback) heb ik de zaak overgedragen aan een andere collega.
Een paar maanden later zag ik zijn eindresultaat, niet om aan te zien! Het project zit nu, na een half jaar, nog steeds in onduidelijk vaarwater.

Aan dit soort praktijken kan ik behoorlijk ergeren! Maar het is wel duidelijk waarom projecten fout blijven gaan.

Cobb’s Paradox

2007-07-20T12:19:00.000-07:00

"We know why projects fail, we know how to prevent failure—so why do they still fail?" Martin Cobb, Treasury board of Canada Secretariat, Ottawa, Canada

Een goede vraag is je eerste indruk. Bij nadere beschouwing is het niet de vraag “so why do they still fail?” die maakt dat het een schijnbare tegenspraak is. Het gaat om de tweede stelling “know how to prevent failure”. Deze stelling is volgens mij onjuist!

We weten welke factoren belangrijk zijn bij het falen van projecten. Deze zijn uitgebreid in kaart gebracht. Tevens zijn processen, methoden, technieken, tools en volwassenheidsmodellen ontworpen om dat falen te voorkomen. Toolkits te over, alsof een project met procedures naar succes te managen is. Ook de menselijke aspecten hebben de aandacht gekregen. Communicatieplannen, management technieken, teambuilding, kernkwadranten en zelfs enneagrammen zitten in de tas van projectmanagers.

Als we het met zijn alle allemaal zo goed weten, waarom werkt het dan niet? Het antwoord is erg simpel.

Punt een, weten is niet voldoende. Het gaat erom dat je de kennis toepast en wel op het moment dat het nodig is. Voor velen is kennis een en doe het andere. Alleen als je kennis doorleeft is en je kunt het toepassen in stressvolle situaties wordt het effectief.

Punt twee, projecten zijn complex. In een bewegende omgeving iets nieuws neerzetten met een nieuw team en inspelen op steeds veranderende behoeftes heeft meer weg van een organisch systeem dan van een mechanisch systeem. De boven genoemde processen, methoden en technieken zijn mechanisch van aard. Ze zijn procedureel beschreven en “iedereen” kan het volgen.

De werkelijkheid is veel complexer. Zoals gezegd die is organisch, er is wederzijdse beïnvloeding tussen project en omgeving en de succesfactoren zijn steeds anders en veranderen tijdens het traject. Hier past geen methode. Wel kan je onderdelen van methoden gebruiken.

Wat telt is persoonlijk leiderschap. Vanuit je eigen kwaliteiten een bijdrage leveren aan de tot stand komen van een resultaat. Met een open geest de anderen tegemoet treden en samen naar oplossingen zoeken. Vanuit leiderschap kies je elementen uit de methoden die op dat moment nodig zijn. Je geeft zelf het goede voorbeeld en bent een inspiratiebron voor de anderen.

Teun van Aken heeft aspecten hiervan al een keer duidelijk beschreven in zijn boek “De weg naar projectsucces”. Dit werk is wetenschappelijk onderbouwd, maar zijn boodschap lijkt niet aan te slaan.

Zoals ik het zie is het voor velen niet duidelijk waarom projecten falen en hoe ze dat de volgende keer beter kunnen doen.Het volgen van de huidige weg met zijn woud aan methodes en technieken is heilloos omdat het meer problemen met zich meebrengt dan oplost. Tevens houden ze je van de echte oplossing af. De oplossing dient op een hoger niveau gezocht te worden. Het gaat om de mensen, hun communicatie en hoe ze elkaar beïnvloeden. Niet vanuit de theorie, maar in de praktijk.

Doe het zelf of uitbesteding in BIDW

2007-04-17T12:27:00.001-07:00

Van oudsher is BIDW het terrein van de business. Het credo is “give us the tools and we will finish the job”. Prima als mensen met verstand van de inhoud met behulp van intelligente (rapportage)tools zelf toepassingen kunnen maken.

Het onderliggende probleem is vaak dat de grondstof (gegevens) voor de rapportages niet zo eenvoudig te verkrijgen is en dat de kwaliteit ervan vaak niet voldoende is. Het standaard leveren van geïntegreerde gegevens van hoge kwaliteit is werk voor ICT professionals.

Ieder zijn vak denk ik dan. Doe het zelven van de business op het gebied van gegevens is vaak peny wise, pound foolish. Bezuinigen op gegevens levert op korte termijn besparing op, maar kost op duur veel geld. Rapporten maken kan de business vaak veel beter dan de ICT’ers, doe dat dus vooral zelf.

Professionalisering ontstaat door specialisatie en vooral door ervaring. Die ervaring is binnen BIDW een probleem. Binnen een (half) jaar ben je senior in je rol en binnen een jaar krijg je een andere rol, een ander aandachtsgebied of een andere toolset. Hoe kan je dan ervaring op doen en leren? Zo blijft het “doe het zelf” niveau in stand en worden keer de zelfde fouten gemaakt.

Ontwikkelkosten van een Data Warehouse

2007-03-30T08:32:00.000-07:00

Ik verbaas me vaak over de genoemde productiviteitswinst van tools. In percentages per fase wordt aangegeven wat de winst is ten opzichte van de traditionele ontwikkelmethoden. Als ik doorvraag op de bron van deze cijfers dan laat de leverancier het vaak afweten. Ik zou graag echt gemeten ervaringscijfers zien van deze tools.
In mijn dagelijkse praktijk gebruik ik mijn eigen ervaringscijfers. Door de vele projecten kloppen die aardig voor de traditionele ontwikkelmethoden.
Bottum line worden de kosten bepaald door het aantal gegevens dat wil ontsluiten en het aantal rapporten.
Daarnaast zijn het vooral de architectuurkeuze die de kosten bepalen. Wel of geen auditlog, wel of geen historie van de historie, wel of geen drielagen model, wel of geen roll back mechanisme.
Voor een betrouwbare schatting is dus nodig de algemene en functionele requirements duidelijk te hebben.
Ik geloof dat tools als PowerPack en BIReady sneller kunnen ontwikkelen omdat ze een aantal architectuur elementen standaard hebben ingebouwd. Ik zou graag van een aantal projecten met deze tools de ervaringscijfers zien. Aantal uren per brontabel of aantal uren per feit en dimensie zouden mij een beter inzicht geven in de daadwerkelijke tijdswinst en daarmee de ontwikkelkosten.

Power Pack

2007-03-16T05:35:00.000-07:00

Naast BIReady is er het tool Power Pack. Power Pack genereert op basis van metadata de mappings voor Oracle Warehouse Builder. Dit bespaart veel ontwikkel- en testwerk. Bij de Universiteit van Tilburg, een van mijn klanten, zijn ze zeer tevreden over het tool. Een van de elegante kenmerken is dat je niet afhankelijk wordt van PowerPack, de mappings zitten gewoon in OWB. Daarnaast is de prijs betaalbaar; je verdiend het zeer snel terug! Ik beveel het elk project dat gebruik maakt van OWB aan.

BIReady

2007-03-12T01:09:00.000-07:00

De eisen flexibiliteit en korte doorlooptijd voor het ontwikkelen van een Data Warehouse worden steeds belangrijker. De ETL leveranciers kunnen niet echt voldoen aan deze eisen. De (her)bouwtrajecten blijven lang duren.

Een van de tools die kan helpen bij het snel bouwen van je Data Wasehouse is BIReady. Met dit tool kan je op basis van een business model en een staging area je pakhuis en winkels genereren.
Harm van der Lek gaf woensdag 7 maart voor een groep ervaren DWBI consultants een presentatie. We waren onder de indruk van de mogelijkheden. Harm heeft veel van zijn ervaring in het tool gestopt.

Datawarehouse Business Intelligence 2.0

2007-03-09T15:43:00.000-08:00

Een nieuwe spruit is geboren. We noemen hem DWBI 2.0. Ik ben benieuwd wat er van hem gaat worden, hoe hij zich ontwikkeld en wat hij gaat bereiken.

De eerst geborene was een beetje te star en stram geworden voor de snel veranderende wereld. Maar hij kan nog mee.

Deze blog gaat over het vakgebied van Datawarehousing en Business Intelligence. Ik zal regelmatig verslag doen van mijn bevindingen.