Om kosten te besparen, een veelgenoemde aanleiding voor Business Intelligence (BI) projecten, wilde een bekende overheidsinstantie weten hoe effectief de bestrijding van uitkeringsfraude was. Hierbij speelt een interessant fenomeen. Het onderzoeken van mogelijke fraude kost de instantie geld, maar het vinden van fraudeurs levert daarentegen direct geld op. En dus wilde men op zoek naar de optimale verhouding tussen het aantallen onderzoeken en het aantal opgespoorde fraudes. Snel vertaald, wilde met zo min mogelijk onderzoeken zoveel mogelijk frauders vinden.
Het hiergenoemde project is archetyisch voor BI. Alhoewel de doelstellingen voor het project redelijk zijn te definieren, is de invulling hiervan nog schimmig. Welke rapportages moeten worden ontwikkeld en wat staat daar op? Tijdens het project doen zich voortdurend nieuwe inzichten voor, enerzijds over het ontbreken van benodigde informatie in de bronsystemen, anderzijds doordat opgeleverde rapportages en analyses de opdrachtgever inspiratie geven voor nieuwe wensen voor het project.
Op het gebied van systeemontwikkelmethodieken hebben zich de laatste jaren enorme veranderingen voorgedaan. Meer en meer organisatie en projecten stappen over naar kort iteratieve methoden, ook wel agile genoemd, die voortschrijdend inzicht niet langer schuwen. Ze worden effectief inzetten om het eindresultaat van het project te verbeteren en daarnaast te streven naar het zo snel mogelijk en frequent opleveren van voor de opdrachtgever relevant software. Dit artikel toont onze ervaring met het toepassen van agile software development, en de methode Smart in het bijzonder, in BI projecten.
Wat kenmerkt een business intelligence project?
De doelstellingen van business intelligence projecten zijn altijd direct business gerelateerd, zoals het minimaliseren van verzekeringsfraude of het behouden van klanten. Tijdens een project worden analyses en rapportages gedefinieerd die het mogelijk maken de bedrijfsprocessen van de klant beter te beheersen en bij te sturen. Dit gebeurt op basis van de informatie uit rapportages die - meestal dagelijks - gevoed worden uit het te ontwikkelen data warehouse.
Kenmerkend voor dit type projecten is dat het lastig is vast te stellen welke bijdrage deze analyses en rapportages uiteindelijk leveren aan het optimaliseren van deze bedrijfsprocessen. Neem voorbeeld de overheidsinstantie, waarbij het niet van te voren was uit te drukken hoeveel geld men bij het vinden van de optimale verhouding in de fraudeurs situatie zou besparen. Na afloop van dit project waren de resultaten beter dan van te voren kon worden ingeschat.
Daarnaast is vroegtijdig in het project nog wel te bepalen
welke analyses en rapportages benodigd, maar is de exacte invulling hiervan vaak nog erg diffuus. Wat wil ik nu echt zien in mijn rapporten? In eerste instantie stelt men op hoofdniveau vast waarover het rapport gaat, bijvoorbeeld de afweging tussen inkomende en uitgaande berichten. Wanneer de klant het rapport onder ogen krijgt, blijkt dat er diverse typen inkomende berichten zijn, die ook weer gekoppeld zijn aan diverse andere typen uitgaande berichten. Pas op dat moment bereikt men de volle reikwijdte van de analyse.
Een derde interessant fenomeen is het Extractie-, Transformatie- & Laad-proces (ETL). In een aantal stappen worden de gegevens uit de bronsystemen verzameld, geintegreerd en geaggregeerd tot een formaat dat voor de rapportages en analyse benodigd is.
DWH Reference Architecture
Alhoewel het ETL proces in de meeste business intelligence projecten zo'n 80% van de ontwikkeltijd beslaat, blijft dit werk onzichtbaar voor de klant, die zich vooral - en terecht - richt op de op te leveren rapportages en analyses. De ontwikkel fasen in een BI project worden nog te vaak ingericht volgens de stappen uit het ETL proces. Dat wil zeggen, eerst worden alle extracties ontwikkeld, dan de transformatie, om vervolgens alle data te laden en dan pas de rapportages en analyses te definieren. Pas in de laatste fase van het project wordt er iets opgeleverd waar de klant practisch mee aan de slag kan gaan.
DWH verticale aanpak
Tot slot zijn de gegevens uit de bronsystemen vrij zelden afdoende voor het invullen van de ifornatie behoefte. Aanvullende gegevens worden dan vaak handmatig toegevoegd tijdens het ETL proces. Hiervoor worden nu gaandeweg het project mini administratie applicaties ontwikkeld. Even los van het feit dat deze applicaties door de verkeerde ontwikkelaars - business intelligence specialisten en geen reguliere ontwikkelaars - worden ontwikkeld, ontstaat deze kennis over deze ontbrekende gegevens meestal pas gedurende het project. In de reguliere software development spreekt we dan over voortschrijdend inzicht.
Wat kenmerkt agile software development?
In de afgelopen jaren is een hele nieuwe generatie aan systeemontwikkelmethodieken en -processen ontstaan, die de best practices van vorige generaties koppelen aan een sterk iteratieve en cooperatief karakter. Deze methodieken, zoals DSDM, extreme programming, Scrum, Smart en feature driven development (FDD) kenmerken zich alle in de volgende karakteristieken:
- Korte iteraties. Werkende software wordt opgeleverd in korte iteraties, per methodiek varierend van twee weken tot een mand. Hiermee versnellen projecten de mogelijkheden tot het geven van feedback door de klant en zo verbetert de kwaliteit van de software in hoog tempo. Dit in tegenstelling tot traditionele projecten, waarin de software vaak in een big bang wordt opgeleverd aan het eind van het project.
- Compacte eenheid van werk. Bovenstaande kan alleen worden bereikt als er een eenduidige en kleine eenheid van werk wordt gehanteerd in projecten. Hierbij geldt dat de individuele werkitems waarde moeten vertegenwoordige voor de opdrachtgever en bovendien moeten ze zo klein zijn dat er meerdere zijn te realiseren tijdens een enkele iteratie.
- Snel en frequent opleveren van software. Tijdens agile projecten wordt al tijdens de eerste iteraties software opgeleverd aan de opdrachtgever, al dan niet direct in productie. Dit zorgt ervoor dat problemen, bijvoorbeeld rond de software architectuur, al vrij snel na de start boven water komen.
- Incorporeren voortschrijdend inzicht. Anders dan in traditionele projecten, waar voortschrijdend inzicht zoveel mogelijk wordt uitgebannen, is het in agile projecten mogelijk nieuwe requirements gedurende het lopende project nog mee te nemen. Hiertoe wordt bij de start van iedere iteratie opnieuw vastgesteld welke werkitems in deze iteratie worden opgepakt. Nieuw werkitems kunnen hierin worden meegenomen, ten faveure over oudere werkitems.
- Nauwe samenwerking klant en opdrachtnemer. Het snel en frequent opleveren van software in korte iteraties vraagt een intensieve samenwerking tussen klant en opdrachtnemer, waarbij bij voorkeur (!) op dagelijkse basis overleg plaatsvind, bijvoorbeeld om de nieuwe gerealiseerde werkitems te bekijken.
- Geintergreerd testen. Omdat software frequent en al vroegtijdig wordt opgeleverd in projecten, is testen van de software wezenlijk belang vanaf dag een in een project.
Smart
Smart is een agile systeemontwikkelmethode die veel is toegepast in reguliere systeemontwikkelprojecten. De methode is ooit ontwikkeld als implementatie van DSDM, maar is inmiddels uitgegroeid tot een kernachtige agile methodiek, waarin best practices zijn ondergebracht uit bijvoorbeeld Rational Unified Process, Scrum en extreme programming. Naast de karakteristieken die iedere agile methodiek kenmerken kent Smart een aantal extra technieken, aangevuld met best practices uit de praktijk. Deze technieken geven projecten een eenduidige eenheid van werk, maar helpen ook de voortgang van het project te bewaken.
- Smart use cases. De eenheid van schatten, plannen, requirementsanalyse, ontwerp en ontwikkeling is een ver gestandaardiseerde vorm van use cases, die wel smart use cases worden genoemd. Smart use cases worden gebruikt om de functionele requirements van een project uit te drukken. Interessant aan deze smart use cases is dat ze gelijkmatig van grootte zijn, waardoor ze gemakkelijk zijn in te schatten, en dat ze zo klein zijn dat er verschillende binnen het tijdbestek van een enkele iteratie worden gerealiseerd.
- Smart use case schattingen. Aanvullend hierop is een schattingstechniek die Smart Estimation heet. Hierbij wordt de totale complexiteit en omvang van een project uitgedrukt in smart use case punten op basis van de complexiteit van de individuele smart use cases. We hanteren hiervoor een eenvoudige schaal, die van 1 tot 5 gaat, maar voor uitzonderingssituaties 8 en 10 heeft gereserveerd. Interssant is dat er voor diverse typen projecten standaardtypen use cases zijn geidentificeerd, die al zijn uitgezet op deze schaal. Dit geldt uiteraard voor het ontwikkelen van bedrijfsapplicatis, service georienteerde applicaties, content management en reporting, bijvoorbeeld met behulp van Sharepoint. Inmiddels zijn ook standaardtypen voor etraxtie en transformatie geidentificeerd.
- Monitoring. De voortgang in Smart projecten wordt voortdurend gemonitord via een tweetal pragmatisch tools. Enerzijds wordt een dashboard gebruikt waar de smart use cases per status zijn uitgewerkt, anderzijds gebruiken projecten een burn down chart, waarin steeds de verwachte einddatum is te extrapoleren.
Fasen van Smart
Smart kent een beperkt aantal eenvoudige fasen, verdeeld in de twee voorbereidende fasen Propose en Scope, een kortcyclische hoofdfase Realize, een afrondende fase Finalize en eventueel een beheerfase Manage, die start zodra het project de software heeft opgeleverd.
 Fasen van Smart |
In iets meer detail:
- Propose. Tijdens de fase Propose wordt de scope, de omvang en de complexiteit van het project vastgesteld. Propose mondt uit in een projectvoorstel.
- Scope. Tijdens de fase Scope wordt het projectvoorstel verder uitgewerkt, onder meer in een use-case model en een domain model. Deze fase leidt tot het plan van aanpak.
- Realise. De fase Realise is gericht op het interactief realiseren van de software. Deze fase is opgedeeld in korte iteraties, liefst van twee weken. Tijdens iedere van deze iteraties worden een aantal smart use-cases gerealiseerd. Welke use-cases dit zijn, wordt vastgesteld bij de start van een iteratie tijdens de deelfase Plan wordt genoemd en meestal een workshop beslaat. Iedere iteratie telt vervolgens een deelfase Build, waarin de use-cases worden uitgewerkt en gereali-seerd. De deelfase Run zorgt voor de deployment.
- Finalise. Tijdens de fase Finalise wordt het systeemontwikkelproject afgerond en geëvalueerd.
- Manage. De fase Manage beschrijft het onderhoud van de opgele-verde software. Ook hierbij gelden de smart use-cases als uitgangs-punt, en wordt gewerkt in maandelijkse of tweemaandelijkse itera-ties.
Aardig is dat deze cyclus en technieken uitstekend zijn toe te passen in business intelligence projecten. Laten we eens kijken hoe.
Wat biedt agile aan business intelligence?
Alhoewel de meeste agile methodieken zijn voortgekomen uit de reguliere systeemontwikkeling, zijn de principes en karakteristieken ervan goed toepasbaar op business intelligence projecten - in principe natuurlijk ook software development. Maar voor welke van de hier geschetste uitdagingen biedt agile, en in het bijzonder Smart, nu profijt?
Snel en frequent opleveren
Het snel en frequent opleveren van voor de klant relevante software is een aspect van agile methodieken dat in business intelligence bijzonder van pas komt. In plaats van de verticale fasering in traditionelere projecten, kiezen we ervoor om het realiseren van analyses en rapporten juist horizontaal in te steken. Niet langer worden alle extracties, alle transformaties, het laden en dan pas de rapportages gerealiseerd, maar wordt er per rapport ontwikkeld. Hierbij kiest de klant welke rapportages de hoogste prioriteit hebben, en start het team met het alleen realiseren van de daartoe benodigde extracties en transformaties, en het opstellen van het rapport. Deze kanteling maximaliseert de snelle feedback van de klant, en vergroot zo de toepasbaarheid van het opgeleverde. Tijdens de propose en scope fase moet wel voldoende aandacht worden besteed aan het globale informatie model, om suboptomalisatie te voorkomen.
DWH horizontale aanpak
Belangrijk bijkomend voordeel is dat de rapportages zodra ze beschikbaar zijn, soms al enkele weken na aanvang van het project, direct kunnen worden aangewend om de bedrijfsprocessen te verbeteren. Dit toont al op hele korte termijn directe benefits voor de klant.
Korte iteraties
Agile software development stimuleert het werken in hele korte iteraties, bijvoorbeeld van 2 weken of 30 dagen, waar bij de start van iedere iteratie wordt beschouwd welke work items voor de komende iteratie de hoogste prioriteit hebben. Hiermee wordt voortschrijdend inzicht nu niet eens uitgebannen, zoals in traditionele werkwijzen, maar kunnen nieuwe inzichten direct worden geincorporeerd. In principe kunnen nieuwe requirements die tijdens een iteratie worden gezien, al bij de eerstvolgende op de rol worden gezet.
Zodra de klant een eerste versie van een analyse of rapport onder ogen krijgt, kan hij of zij feedback formuleren, die vrijwel direct kan worden geimplementeerd, zonder daarbij afbreuk te doen aan de structuur en voortgang van het project. hebben in projecten gemerkt dat hiermee het benutten van analyses en rapportages veel sneller tot stand komt.
Ook is het mogeljk om nieuwe inzichten rond eventueel benodigde data entry vrijwel onmiddelijk op te pakken, zodra deze gaande het project worden onderkend.
DWH korte iteraties
Compacte eenheid van werk
Een business intelligence project is uit te drukken in drie typen ontwikkelwerk: ETL en datamodellering, het definieren van analyses en rapporten en het ontwikkelen van data entry applicaties.
In de agile methodiek Smart geldt de smart use case als eenheid van werk, zowel voor het beschrijven van de requirements, het maken van schattingen als het realiseren van voor de gebruiker relevante functionaliteit en zelfs als eenheid voor het testen van deze functionalitiet. Voor het opstellen van smart use cases gelden stringente modelleerrichtlijnen, die ertoe bijdragen dat smart use cases een vergelijkbare lage granulariteit hebben, en al vroeg in een project zijn toe te passen. Daarnaast zijn ze een zeer bruikbare eenheid van plannen en werken in software development projecten. Inmiddels is een groot aantal standaardtypen smart use cases beschreven, de use case stereotypes.
Ook in agile business intelligence projecten voldoet deze eenheid van werk. Wat betreft het definieren van rapporten en het ontwikkelen van data entry ligt dit voor de hand, omdat dit werk niet wezenlijk verschilt van reguliere software development. Maar ook voor het vaststellen van analyses en zelfs voor de ETL hebben we inmiddels standaardtypen smart use cases vastgesteld, zoals collect, integrate en aggregate .
De smart use cases worden vroeg in het agile business intelligence project geidentificeerd, en aan de hand hiervan schatten en plannen we vervolgens de iteraties die de fase Realize telt. Dit heeft tot resultaat dat we in staat zijn gemakkelijk individuele rapportages te realiseren, op basis van de hiertoe benodigde smart use cases voor ETL, eventuele data entry en het definieren van het rapport.
Bijkomende voordelen zijn bovendien dat de onderliggende dataflows, uitgedrukt in smart use cases, beter individueel zijn te testen, en is zelfs door het modelleren van de use cases hergebruik van dataflows al snel geidentificeerd.
Benefits
In business intelligence projecten is het snel en frequent opleveren van rapportages en analyses van groot belang. Immers, ieder nieuwe opgeleverde rapportage kan direct worden benut en levert zo direct toegevoegde waarde aan het optimaliseren van de bedrijfsprocessen van de opdrachtgever. Daarnaast hebben business intelligence projecten te maken met voortdurend voortschrijdend inzicht. Beter dan dit uit te bannen, zoals in traditionele projecten wel wordt gepoogd, is om juist effectief gebruik te maken van deze inzichten en feedback. Daarbij is de keuze om ons in projecten eerder te richten op de realisatie van rapporten en analyses cruciaal, in plaats te focussen op de traditionele fasering rond de realisatie van het ETL proces. Daarbij biedt SMART een tweetal tools om de voortgang van het project te bewaken:
Agile dashboard. Het dashboard biedt een pragmatisch overzicht over de smart use cases in het project, die in kolommen zijn verdeeld, afhankelijk van de status waarin de smart use cases zich bevinden. Die kan New zijn, maar ook In Iteration, Working (realiseren), Testing, Reworken Accepted. In een oogopslag is zo, ook voor de klant, te zien hoever het project is.
 Smart dashboard |
Burn down chart. Een burn down chart toont de totale voortgang van het project, uitgedrukt in de hoeveelheid uren nog te besteden, uitgezet in de tijd. Een eenvoudige extrapolatie toont meestal nog de verwachte einddatum van het project. In agile business intelligence projecten is het zinvol niet alleen een burn down chart voor het gehele project te gebruiken, maar om ook een chart per rapport te tonen. Juist omdat deze zo snel mogelijk worden opgeleverd, levert dit de klant directe informatie wanneer zijn rapport gereed is, en direct is in te zetten.
 Een burndown chart |
De agile methodieken en technieken zoals hier gepresenteerd spelen bijzonder goed in op deze wensen en eisen aan business intelligence projecten. Het toepassen van smart use cases biedt projecten daarnaast een gestructureerde, maar vooral pragmatische manier om in het hele project met eenzelfde eenheid van schatten en werken te opereren. De gereedschappen die in Smart projecten worden gebruikt om de voortgang te meten, zoals het agile dashboard en de burn down charts per rapport, bieden bovendien nog direct inzicht in de realisatie van de rapportages en analyses, met snel resultaat tot gevolg, en met snel groeiende tevredenheid van de klant. En daar was het allemaal om te doen toch?
Authors
Sander Hoogendoorn, Principal Technology Officer Capgemini.
Sandra Wennemers, Managing Consultant Capgemini.
Read more