Agile business intelligence, kan dat wel?

Agile business intelligence, kan dat wel?
Vrijwel elk softwareteam is bezig met agile ontwikkelen of is dat aan het overwegen. Agile biedt een fundamentele oplossing voor uitlopende projecten en budgetoverschrijdingen. Kun je agile ook voor business intelligence gebruiken? Business intelligence is toch iets heel anders dan softwareontwikkeling?
Marco Coopmans en Rini van Solingen
Vrijwel elk softwareteam is bezig met agile ontwikkelen. Met agile kun je via korte cycli direct sturen op een werkend product met maximale waarde. Omdat een business intelligenceoplossing ook uit software bestaat, ontstaat al snel het idee om agile ook voor business intelligence te gebruiken. Kan dat?
Softwareontwikkeling wordt (of werd) hoofdzakelijk gedaan conform een soort van waterval. Deze bestaat uit één enkele cyclus waarin analyse, ontwerp, realisatie, test en implementatie elkaar opvolgen. Deze fases worden sequentieel doorlopen. In de analyse- en ontwerpfase wordt de benodigde functionaliteit bepaald en gedocumenteerd. Vervolgens wordt de software gebouwd, getest en in gebruik genomen. Een dergelijke enkelcyclische aanpak is gebaseerd op drie uitgangspunten:
• De gebruiker weet wat hij wil;
• De bouwer weet hoe hij het moet bouwen;
• Gedurende het project verandert er niets.
De klassieke aanpak van business intelligence is gebaseerd op het idee dat een corporate datawarehouse met ‘one version of the truth’ het meest wenselijk is. De inhoud van het datawarehouse wordt bepaald door de informatiebehoefte en deze wordt vooraf bepaald en in een specificatie vastgelegd. Daarbij komt nog dat vanwege de ‘one version of the truth’-gedachte getracht wordt corporate-breed definities te bepalen. Verder is datakwaliteit en volledigheid altijd een heikel
punt binnen business intelligence. Vandaar dat in de klassieke aanpak al in het beginstadium een intensieve bronanalyse uitgevoerd wordt. Kenmerkend voor de klassieke watervalgebaseerde business intelligence-aanpak is dan ook:
• De informatiebehoefte staat centraal en moet dus bekend zijn. Maar het is lastig om vanuit de business vooraf te benoemen wat de exacte informatiebehoefte is en daarom wordt maar alles gevraagd;
• Er moet voldaan worden aan corporate definities, die slechts moeizaam of helemaal niet bepaald kunnen worden;
• Er wordt een intensieve bronanalyse gedaan om de datakwaliteit en volledigheid te kunnen bepalen;
• Eerst wordt alles ontworpen alvorens het te bouwen;
• Er wordt een zware architectuur opgezet, gericht op een allesomvattende, toekomstbestendige, vaak corporate toepassing, die eigenlijk niet gericht is op de specifieke informatiebehoefte;
• Eerst wordt de volledige back-end gemaakt door het opzetten van een groot datawarehouse, met een complex ETL-proces. Pas als dit afgerond is, worden daar de informatieproducten uit afgeleid in de front-end. Het gevolg is dat de gebruiker pas na een zeer lange tijd (maanden tot soms jaren) iets te zien krijgt, waardoor feedback pas in een zeer laat stadium beschikbaar komt.
Deze klassieke business intelligence-aanpak is het best te vergelijken met de waterval bij de ontwikkeling van software. Ook voor business intelligence-projecten geldt daarom dat ze vaak uitlopen, erg veel kosten en niet leveren wat gewenst is. Agile gaat juist uit van het tegenovergestelde:
• De gebruiker ontdekt tijdens het project wat hij nodig heeft;
• De bouwer ontdekt tijdens het project hoe hij het moet bouwen;
• Er is veel dynamiek en verandering tijdens het project.
In een omgeving waarin de behoefte niet volledig duidelijk is en nog verandert in de tijd is het raadzaam een aanpak te hanteren die daarmee kan omgaan. Een enkelcyclische traditionele aanpak kan dat niet. Het is dus ook in het business intelligence-domein zeer raadzaam om op een agile manier te werken. Feedback komt dan veel eerder beschikbaar en het is ook veel sneller mogelijk om toegevoegde waarde te bieden.
Agile over de hele linie
Bij agile business intelligence-projecten wordt in de praktijk vaak onderscheid gemaakt in de manieren waarop de back-end en de front-end ontwikkeld worden. De back-end bestaat uit de dataopslag en de ETL1. De front-end is de wijze waarop de informatie ter beschikking wordt gesteld aan de eindgebruikers, dit zijn de rapportages, dashboards, et cetera. De agile aanpak wordt dan wel gebruikt voor het ontwikkelen van de front-end, want dat is de functionaliteit die direct door de eindgebruiker gevraagd wordt.
Voor de back-end wordt echter nog de meer traditionele watervalaanpak gehanteerd.
Dit onderscheid is echter onlogisch en zorgt ervoor dat het hele business intelligence-traject nog niet agile wordt ingericht. Tenslotte moet eerst de back-end er zijn voordat een eerste informatieproduct op een agile manier kan worden gemaakt. Als je daarbij nog bedenkt dat zestig tot tachtig procent van de werkzaamheden juist in de back-end plaatsvindt, dan houd je nog maar twintig tot veertig procent van de werkzaamheden over die je agile doet. Een fundamenteel uitgangspunt bij agile ontwikkelen is dat alles wat je doet een directe toegevoegde waarde heeft voor de gebruiker. Dat betekent dat je over de hele linie agile moet ontwikkelen. De back-end en front-end ontwikkel je dus samen, waarbij de front-end bepalend is. De front-end bepaalt wat er in de back-end moet zitten, en niet andersom. Daarom begin je te redeneren vanuit de informatiebehoefte die je nu kent en die nu direct de meeste waarde heeft. Daarvoor ontwikkel je de front-end, met de daarvoor benodigde backend. Je zoekt als het ware de kortste weg naar de meeste toegevoegde waarde. Dat klinkt toch behoorlijk agile?
Architectuur
Een van de twaalf principes van agile (zie het Agile Manifesto) is: eenvoud – de kunst van het maximaliseren van het werk dat niet gedaan wordt – is essentieel. Dat impliceert dat je in iedere iteratie alleen dat bouwt wat minimaal nodig is voor het leveren van de benodigde functionaliteit voor die iteratie. Het hoeft dus helemaal niet zo te zijn dat je vanaf het eerste moment al een volledige back-end moet optuigen. In bepaalde gevallen kun je wellicht volstaan met bijvoorbeeld een semantische schil (‘universe’ of ‘framework’) met daarop de rapportages, of een datamart of kubus met rapportages. In een agile aanpak groeit de oplossing (architectuur) mee met de functionaliteit. Een datawarehouse en ETL ga je pas ontwikkelen op het moment dat er voldoende noodzaak is, zelfs als je op voorhand denkt te weten dat dit noodzakelijk is voor de eindoplossing.
Kleine stappen
Allereerst geldt ook voor het ontwikkelen van een business intelligence-omgeving dat je het niet in één keer kunt doen, maar dat je dit in kleine stappen doet. Het is een programma waarbij je projectgewijs delen van de functionaliteit ontwikkelt. Dat ontwikkelen kun je langs twee assen doen: data en functionaliteit (figuur 1) . De data is onder te verdelen in logische brokken (informatiedomeinen). De functionaliteit kun je ook onderverdelen, in standaardrapportages, ad-hocmogelijkheden, analysemogelijkheden, dashboarding, et cetera.
Figuur 1. Ontwikkelen langs twee assen

Kies voor de eerste stap één of enkele informatiedomeinen met daarbovenop een functionaliteit. Vervolgens kun je zowel in de breedte groeien (meer data, nieuwe gebruikersgroepen) als in de hoogte (meer, rijkere functionaliteit bieden aan de bestaande gebruikers waardoor bestaande informatiedomeinen nog beter worden benut).
Het Mona Lisamodel
Ook in een business intelligence-omgeving wordt gewerkt met ‘user stories’. Met de user story specificeert de gebruiker welke functionaliteit hij wenst te krijgen. Er wordt hierbij geen onderscheid gemaakt in functionele en technische stories; termen als ‘ETL’, ‘datamart’, et cetera komen er niet in voor. Een user story is bijvoorbeeld: “Ik wil alle opbrengsten kunnen zien per maand, omdat ik dan inzicht heb in de financiële situatie en kan sturen op verlies- en winstgevende activiteiten.” Of: “Ik wil alle verhuurde objecten kunnen zien per locatie, omdat ik dan weet wat de bezettingsgraad is.” Een user story wordt dan over de volle linie (back-end en front-end) opgepakt. Er is dus géén sprake van een intensieve analyse en ontwerpfase en er wordt ook geen uitgebreide bronanalyse gedaan.
Om de agile business intelligence-aanpak te verduidelijken is een model opgesteld dat we het ‘Mona Lisamodel’ noemen2. Bij het Mona Lisamodel begin je met een grove schets en vervolgens ga je deze steeds verder verfraaien tot je het mooi genoeg vindt. Hetzelfde doe je bij de ontwikkeling van business intelligencefunctionaliteit. Je begint met het zo simpel mogelijk beschikbaar stellen van de data. Vervolgens ga je dit veredelen, en ten slotte ga je het zo toegankelijk maken dat iedereen er gebruik van kan maken (figuur 3) . (De technische elementen aan de linkerkant zijn afhankelijk van de gekozen oplossing c.q. architectuur. Zo is een datawarehouse of datamart niet in alle gevallen van toepassing.) De aanpak bestaat uit een aantal stappen
(figuur 4) .
 
Figuur 3. Het Mona Lisamodel
 

Stap 1. De eerste stap genaamd ‘Initiatie en Model Storming’ is een voorbereidende. Je maakt een eerste opzet van het informatiemodel (een functioneel dimensioneel model). Het model levert niets op in termen van een eindproduct, maar is wel de basis voor het hele project. Met het model krijg je een aardig idee van de informatiebehoefte en van wat de definities zijn. Op basis van het model kun je user stories maken en gaan prioriteren (backlog vullen).
Stap 2. In stap 2 zorg je ervoor dat de gebruiker zoveel mogelijk data te zien krijgt. Dat betekent dat zoveel mogelijk ruwe data uit het bronsysteem in hun meest elementaire vorm ontsloten worden conform het model uit stap 1 (zonder verdere verfijning, controles, en dergelijke). Wanneer dit te groot is voor een iteratie, selecteer je een deel van het in stap 1 gemaakte model. Bij voorkeur kunnen de betrokken gebruikers (power users) dan op basis hiervan zelf met de data gaan spelen.
 

Stap 3. De basis staat nu, vervolgens ga je in een aantal iteraties verder verfijnen en functionaliteit toevoegen om tot de gewenste informatie te komen. Denk aan zaken als het toevoegen van transformaties, ‘business rules’ (controles), inbouwen van historie, maken van standaardrapportages. Dit alles gebeurt natuurlijk op basis van user stories die aan de back-log worden toegevoegd en geprioriteerd.
Stap 4. Als de inhoud eenmaal voldoet, werk je in een aantal iteraties toe naar het toegankelijk maken van de informatie voor de eindgebruikers. Hierbij worden de definitieve rapportages ontwikkeld, metadata ingevuld, autorisaties toegevoegd. Hier ligt het accent dus heel sterk op de front-end. Parallel hieraan ga je ook documenteren, gebruikersopleiding voorbereiden, et cetera.
 
Het grote voordeel van deze aanpak is dat de gebruiker zo snel mogelijk geconfronteerd wordt met de data. Op die manier kan hij al snel een beter inzicht krijgen in zijn informatiebehoefte en de wijze waarop die toegankelijk moet worden gemaakt. De praktijk leert namelijk dat gebruikers pas echt knelpunten en vragen ontdekken als ze iets tastbaars zien. Bovendien ontdek je op deze wijze al dingen in een veel eerder stadium dan bij een traditionele analyse of ontwerpaanpak.
De Mona Lisa-aanpak stelt wel twee voorwaarden:
1. In de beginfase moeten de betrokken gebruikers de ‘power users’ zijn, ofwel gebruikers die in staat zijn om met ruwe data om te gaan en veel kennis hebben van het bronsysteem.
2. Om de output voldoende representatief te laten zijn, moet je beschikken over de echte (‘productie-like’) data.
 
Conclusie
Een belangrijke succesfactor van een business intelligence-traject is de betrokkenheid van de business. Agile ontwikkelen dwingt participatie van de business af. De business mag en moet bepalen wat wanneer gedaan wordt. De betrouwbaarheid van de informatie wordt geborgd door deelname van domain experts en power users uit de business die continu het resultaat beoordelen (testen).
Bij business intelligence-opleveringen is vaak sprake van issues die te wijten zijn aan verkeerde definities en datakwaliteit. Bij agile ontwikkelen worden definities en de kwaliteit van de data getackeld op het moment dat dit issue zich voordoet. Het issue is dan heel inzichtelijk en tastbaar vanuit een concrete informatiebehoefte en is dan ook veel beter te bespreken.
De meest gehoorde uitspraak als het gaat om managementinformatie is dat de gebruiker maar moeilijk kan specificeren wat hij of zij nodig heeft. Onder het mom van ‘beter te veel dan te weinig’ wordt daarom maar ‘alles’ gevraagd. Agile werkwijzen zijn uitermate geschikt voor business intelligence omdat agile ervan uitgaat dat niet alles op voorhand duidelijk is en er omgegaan moet kunnen worden met tal van verrassingen en wijzigingen.
Een business intelligence-traject hoort dus gewoon volledig agile te worden uitgevoerd. Alleen dan heb je eerder toegevoegde waarde, leer je sneller en voorkom je veel nutteloos en vertragend werk, is de benodigde businessparticipatie en daarmee ook de betrouwbaarheid en acceptatie geborgd. Kortom, agile en business intelligence: een uitstekende match!
 
Marco Coopmans is freelance enterprise/informatie-architect met de nadruk op agile ontwikkelen. Business intelligence is een van zijn specialisaties. E-mail: marco.coopmans@gnie.nl
 
Rini van Solingen is CTO bij Prowareness en deeltijdhoogleraar Global Software Engineering aan de TU-Delft. Hij is mede-auteur van De kracht van scrum . E-mail: rini@scrum.nl
 
 

KADER 1: Wat is Agile?

Bij Agile ontwikkelen staat het leveren van business value centraal. Business value komt tot uiting in het continu leveren van werkende en geteste software, met directe toegevoegde waarde voor de eindgebruiker (klant). Het leveren van waarde mag je nooit uitstellen. Daarom wordt het werk opgeknipt in iteraties: korte periodes van enkele weken die telkens een werkende en geteste versie van het product opleveren. Werkend en getest, zodat eindgebruikers het daadwerkelijk kunnen gebruiken om waarde te creëren. Iteratief ontwikkel je zodoende het product en wordt het al zo snel mogelijk gebruikt. Het is dus ook belangrijk om het meest waardevolle als eerste te ontwikkelen. Immers, dat levert de meeste toegevoegde waarde dus moet ook als eerste naar de eindgebruikers toe.
Agile gaat op een fundamenteel andere manier om met de dimensies scope, tijd, geld en kwaliteit. In een traditionele enkelcyclische aanpak wordt scope vastgezet waardoor tijd, geld en kwaliteit flexibel worden gemaakt. Dat dat zo is blijkt uit de grote problemen in dit type trajecten: te laat, te duur, niet goed. Agile draait dit om. Door in vaste korte cycli te werken met een stabiel team en vaste acceptatiecriteria, worden tijd, geld en kwaliteit vastgezet. Dat lukt alleen door scope flexibel te maken. Dat is niet erg. Het helpt namelijk enorm bij het ontdekken wat de gebruiker nodig heeft. Voorwaarde is wel dat iedere cyclus werkende en geteste software oplevert. Zodoende kun je gaande het project nog goed bijsturen. Als er namelijk geen werkende en geteste software wordt opgeleverd is bijsturen ondoenlijk, er is immers niets af dus een ander pad inslaan kan nog niet. Bij Agile gaat het om het zo optimaal mogelijk besteden van tijd, geld, kennis en kunde, ofwel het zoveel mogelijk leveren van toegevoegde waarde binnen deze grenzen. Daarbij is één ding zeker: de klant krijgt alleen wat hij echt nodig heeft en wat voor hem/haar de meeste toegevoegde waarde heeft.

Verschil in omgang met dimensies scope, tijd, geld en kwaliteit bij waterval en agile

 
Daarnaast gaat Agile er vanuit dat je van tevoren niet alles kunt bedenken en vastleggen en dus zo snel mogelijk software aan gebruikers moet geven om hun feedback te krijgen. Met die feedback stuur je bij, lever je nog meer toegevoegde waarde, of kom je er achter dat je ideeën helemaal niet kloppen en dat je dus beter iets anders kunt gaan doen.
De term Agile vertalen naar het Nederlands is lastig. Het best in de buurt komt ons woord ‘lenig’, echter daarin ontbreekt het opportunistische karakter van Agile. Agile zorgt er namelijk voor dat je snel op verandering kunt inspelen, in het bijzonder wanneer dat extra toegevoegde waarde levert. In het Nederlands zou je dan de term ‘wendbaar’ kunnen gebruiken. Om hier geen hele verhandeling te houden over de beste Nederlandse vertaling gebruiken wij in dit artikel gewoon de engelse term Agile, maar bedoelen daarmee dus een flexibele, wendbare, opportunistische, zelflerende manier van werken.
 
 

KADER 2: Het Agile Manifesto en de 12 principes

Het Agile Manifesto beschrijft 4 kernwaarden en 12 principes die tot betere resultaten moeten leiden bij het ontwikkelen van software. De 4 kernwaarden (values) zijn:

  1. Mensen en hun onderlinge interactie zijn belangrijker dan processen en tools
  2. Werkende software is belangrijker dan allesomvattende documentatie
  3. Samenwerking met de klant is belangrijker dan contractonderhandelingen
  4. Inspelen op verandering is belangrijker dan het volgen van een plan

Dit betekent niet dat de zaken aan de ‘rechterkant’ zoals processen, documentatie, plannen en dergelijke niet belangrijk zijn. Het betekent wel dat werkende software, interactie en meegaan met veranderingen gewoonweg belangrijker zijn en altijd de voorkeur horen te krijgen.

Naast de kernwaarden kent het Agile Manifesto ook nog 12 principes:

  1. Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.
  2. Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant.
  3. Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden.
  4. Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.
  5. Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.
  6. De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.
  7. Werkende software is de belangrijkste maat voor voortgang.
  8. Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.
  9. Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.
  10. Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.
  11. De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.
  12. Op vaste tijden, onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.
 
 
 
 
 
 
 
 
 
 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag