Gepokt en gemazeld in het BI-speelveld zijn velen van ons tot de conclusie gekomen dat het oh zo bekende eenrichtingspad, genaamd waterval, vaker niet dan wel de juiste benadering voor een BI-traject is. Na een levendige discussie over project- en ontwikkelmethoden kwam de vraag boven drijven of agile het ei van Columbus is voor BI.
Naarstig zijn wij met z’n allen opzoek naar 'betere' methodes. Methodes om de broodnodige flexibiliteit te combineren met resultaatgerichtheid. Tegelijkertijd maken vrijwel alle aan agile gerelateerde werkwijzes een hernieuwde populariteit mee. In verschillende markten zien we het veelvuldig toegepast worden. Een link met de snel wijzigende projecten uit de BI-wereld is vervolgens snel gelegd. Gezien de dynamiek van deze projecten is de impact van agile wellicht zelfs groter dan elders in softwareland.
Is dat daadwerkelijk zo? Zien we de kern van agile, zoals samengevat in het agile-manifesto en hieronder benoemd, ongeacht de specifieke methodes zoals extreme programming, scrum etc. terug in onze projecten?
– Individuen en interactie boven processen en tools.
– Werkende software boven uitgebreide documentatie.
– Samenwerking met de klant boven contract onderhandelingen.
– Aanpassing aan wijzigingen boven het volgen van een plan.
De eerst genoemden sluiten de schuin gedrukte termen niet, maar ze zijn wel belangrijker in de agile-wereld.
Stel, we passen deze principes toe, leidt dat tot succesvollere BI-projecten? Zijn wij überhaupt in staat een project volledig agile uit te voeren? Zijn onze tools voldoende flexibel om op dergelijke wijze te ontwikkelen? Zijn wij vervolgens instaat een dergelijke opdracht te verkopen aan onze opdrachtgevers of kunnen zij voldoende personeel vrij spelen voor deelname aan de verschillende iteraties?
Tig vragen, met duizenden mogelijke antwoorden en nuanceringen. De kernvraag blijft ‘worden agile-methodieken geadopteerd en toegepast in de BI-wereld?’ Ontwikkelen we rapportages volgens pair programming, elke dag starten met een scrum-meeting of stiekem toch nog DSDM? Ongeacht de methode kijk ik uit naar de ervaringen van de andere BI-experts en BI=-specialisten. Wat zien jullie? Een hersenspinsel, een hype of de volgende grote stap in BI-ontwikkeling?
Kristiaan Soomers & Ivo van der Heijden
Alleerst moet ik kwijt dat ik het ontzettend lastig vind antwoord op een vraag te geven waarin twee begrippen worden gebruikt die multi-interpretable zijn: Business Intelligence en Agile projectmethodieken. Mijn antwoord kan ik dan ook alleen maar geven binnen de context waarbinnen ik beide begrippen plaats. Mijn ervaring van de afgelopen 13 jaar heeft mij geleerd dat het niet ??n van beide is, maar beide. Zowel waterval als agile moet worden toegepast om goede BI oplossingen te kunnen bieden. Dat heeft te maken de mapping
van projectmethodieken op informatiebehoeftes en informatievastlegging.
Projectmanagement is in basis heel simpel. Binnen een project heb je 3 parameters waarop je kunt sturen: Bestede tijd (= geld), doorlooptijd en functionaliteit. Een project kan slechts goed worden gemanaged als 1 van de 3 parameters variabel is. Anders valt er ook niks te managen. Met een waterval methode zet je normaliter de doorlooptijd en functionaliteit vast en wordt de bestede tijd variabel. Bij agile methodes zet je de bestede tijd en doorlooptijd vast en maak je de
functionaliteit variabel.
Als we naar BI kijken dan staan we altijd voor 2 uitdagingen: 1) hoe krijg ik de data zo goed mogelijk in het Datawarehouse 2) hoe sluit ik de informatie zo goed mogelijk aan bij de behoefte van de consument.
Het datawarehouse is d? omgeving waarbinnen de data juist goed moet zijn. Een beetje meer of minder correcte data is funest. Daarmee zet je de fuctionaliteit vast. Je kunt dus niet anders dan via een
watervalmethode het datawarehouse vullen. Wat trouwens niet wil zeggen dat je eerst alle data die er ook maar bestaat in je datawarehouse moet stoppen alvorens je met uitdaging 2 kunt beginnen. Het principe
“Think big start small” blijft hier van kracht.
Voor het invulling geven aan de informatiebehoefte van de consument, is het onmogelijk vooraf te defini?ren wat de gebruiker achteraf wil weten. Daarmee wordt de functionaliteit dus flexibel en
is de enige juiste projectmethodiek die daar bijpast een agile aanpak.
Conclusie, beide aanpakken moet je beheersen en toepassen om succesvol te kunnen zijn met Business Intelligence.
Voor meer achtergrond informatie:
http://www.bifacts.com/mydoc/het_succes_achter_bi.pdf
http://www.bifacts.com/mydoc/enterprise_warehouse_architectuur.pdf
Dat agile voordelen biedt boven de watervalmethode is duidelijk. De centrale vraag is eerder of we in staat zijn om een agile aanpak ook daadwerkelijk te realiseren. Ik zie de uitdaging met name bij het frequente contact en de voortdurende afstemming met de klant. Op zich juist een van de aspecten die agile zo aansprekend maakt. Echter, is het bij een watervalaanpak vaak al moeilijk om voldoende tijd van de business te claimen, bij een agile aanpak wordt dat alleen maar moeilijker. Dat is niet zozeer een uitdaging die specifiek kleeft aan agile BI, maar een algemene uitdaging voor de agilemethode.
Het is te boud om te stellen dat de huidige BI-tools gereed zijn voor agile. Ze zijn daar immers nooit voor ontworpen. Als de vraag luidt of de huidige BI-tools beschikken over een ontwikkelomgeving die ook in het geval van agile als volwaardig kan worden beschouwd (denk bijvoorbeeld aan tracking en tracing) dan zal het antwoord in de meeste gevallen ontkennend moeten luiden. Kun je een BI-tool inzetten bij een agile aanpak? Natuurlijk. Maar je kan ook de K2 beklimmen in je sloffen.
Deze kanttekeningen nemen niet weg dat ik van harte hoop dat agile een vaste plek weet te veroveren in BI. Het zou goed zijn voor zowel de snelheid als kwaliteit van de geleverde oplossingen.
Mijn stelling is dat BI er vooral behoefte aan heeft snel mee te kunnen veranderen met omstandigheden, bedrijfsdoelstellingen en dergelijke. Immers, het doel van BI is het verschaffen van inzicht en niets is zo veranderlijk als de behoefte aan voortschrijdend inzicht. Nieuwe ?agile? ontwikkelmethoden kunnen daar een belangrijke bijdrage aan leveren en verdienen dan ook adoptie door het BI vakgebied. Wat kan ons nog tegenhouden?
Een van de laatste obstakels van ?waterval? naar ?agile? is de vaak lange doorlooptijd van wijzigingen in het datawarehouse. Hoe vaak worden ?agile? BI projecten niet geremd als in het datawarehouse een nieuwe bron moet worden toegevoegd? Zolang randvoorwaarden als de juiste architectuur, aanpak en modelleringtechnieken niet vooraf zijn ingevuld blijft het een hypothetische discussie.
Gelukkig staan de ontwikkelingen ook op dat vlak niet stil. Zo hebben wij het afgelopen jaar uitstekende resultaten geboekt met het genereren van datawarehouses op basis van templates zonder dat hiervoor tijdrovend en handmatig ETL code moet worden aangepast. Dit onder een heldere BI architectuur waarin Data Vault duidelijk gepositioneerd is.
Dit brengt ontwikkeltijden terug tot minimale proporties en neemt diverse technische en organisatorische belemmeringen weg. Met het inzetten van deze methodiek hebben onze klanten meer tijd gekregen voor de business vragen. En was het daar niet juist om te doen bij business intelligence?