Scrum voor Business Intelligence – deel 4: Iedereen is architect

Business Intelligence is complex. Je hebt enerzijds te maken met snel veranderende informatiebehoeften. Anderzijds heb je te maken met verschillende bronsystemen en een vaak onvolledig zicht op de kwaliteit en beschikbaarheid van de data. Daarnaast zorgt nieuwe technologie voor nieuwe mogelijkheden, maar brengt de invoering daarvan weer nieuwe complexiteit met zich mee.

Scrum is een raamwerk dat gebruikt wordt om werk aan complexe producten te managen. Het is daardoor goed toepasbaar in een Business Intelligence omgeving. De grote kracht van Scrum zit hem in de eenvoud van het raamwerk, maar het succes is afhankelijk van een goede toepassing hiervan. Hoe pas je Scrum toe in een Business Intelligence omgeving? Wat zijn de valkuilen en de tips?

In deze serie blog posts deel ik mijn inzichten op dit gebied. Iedere blog post gaat in op een bepaald onderwerp: van het opstellen van user story’s tot de rol van de product owner en van de manier waarop je plant tot de rol van architectuur. Waar mogelijk zal ik daarbij ingaan op de specifieke zaken waar je in een Business Intelligence omgeving tegenaan loopt. Deze vierde blog post gaat over de rol van architectuur in Scrum.

De juiste architectuurkeuzes
Een Scrum team bestaat uit een product owner, een Scrum master en een ontwikkelteam. Dit ontwikkelteam is een zelf-organiserend, multidisciplinair team. Individuele leden kunnen wel specifieke vaardigheden en aandachtsgebieden zoals business analyse, architectuur of testen hebben. Maar de verantwoordelijkheid ligt bij het team als geheel. Scrum kent geen aparte rollen voor een business analist, een tester en ook niet voor een architect. Maar dat betekent nog niet dat architectuur binnen Scrum geen belangrijke rol speelt. Integendeel, om snel te kunnen leveren en flexibel te zijn in het maken van aanpassingen is het van belang dat je de juiste architectuurkeuzes op het juiste moment neemt.

Vooral aan de datakant zijn er architectuurkeuzes die een agile manier van werken goed kunnen ondersteunen. Enkele voorbeelden hiervan:
• De keuze voor een agile datamodeleringsmethode zoals Data Vault waarbij wijzigingen van de structuur van de brondata, of het toevoegen van nieuwe bronnen, een minimale impact hebben op je datawarehousemodel.
• Het toepassen van datawarehouse automation tooling zoals TimeXtender of Wherescape, of scripting zoals BIML, waarmee je bepaalde stappen in je ontwikkelproces kunt automatiseren, en changes sneller door te voeren zijn.
• Het virtualiseren van alle of bepaalde datalagen tussen bron en rapport waardoor er minder (her)laadacties nodig zijn om een wijziging door te voeren.

Sommige architectuurkeuzes zullen al voor de eerste sprint door anderen zijn gemaakt. Vaak zullen er vanuit de organisatie al bepaalde eisen gesteld worden aan de architectuur. Deze eisen neem je dan, zoals ook besproken in Minimale criteria, maximale waarde, in de ‘definition of done’ mee. Daarnaast vindt de productontwikkeling vaak plaats binnen een al bestaande BI-omgeving.

Maar ook tijdens de productontwikkeling zal een Scrum team nog de nodige architectuurkeuzes moeten maken. En wat daarbij voor nieuwe Scrum teams wennen zal zijn is dat je al met de ontwikkeling start, terwijl je bepaalde architectuurkeuzes nog moet maken. Zo zal je in het begin niet altijd weten hoe het volledige datamodel eruit gaat zien, welke bronnen je allemaal gaat ontsluiten of hoe het overall ontwerp van je dashboards en rapporten eruit gaat zien.

Niet in steen gebeiteld
De architectuur is daarmee niet iets wat je vooraf volledig definieert, maar iets wat je iedere sprint verder vormgeeft en bijstuurt op basis van wat je in de sprints ontdekt en leert. Door verticaal te slicen heb je bovendien vanaf de eerste sprint al aandacht voor het hele traject van bron tot rapport en alle architectuurkeuzes die daarmee te maken hebben. In opvolgende sprints zal je de architectuur, wanneer je nieuwe verticale slices oplevert, steeds verdere invulling geven.

Het voordeel van deze manier van werken is dat de architectuur niet in steen gebeiteld staat, maar aangepast kan worden om nieuwe en gewijzigde requirements te kunnen faciliteren. Daarentegen wordt door sommigen beweerd dat deze manier van werken totaal niet efficiënt is. Zij stellen dat met een vooraf volledig uitgewerkte architectuur ‘constructiefouten’, en daarmee rework, kan worden voorkomen. Maar zij gaan er dan ook ten onrechte vanuit dat je, net als bij het bouwen van een huis, alle requirements van tevoren in kaart kunt brengen. En dat je op basis daarvan de ideale architectuur kunt ontwerpen. De praktijk leert echter dat in beton gegoten Business Intelligence oplossingen zelden voldoen aan de continu voortschrijdende inzichten en wensen. De kunst als team is dan ook om aan het begin wel een overall visie en richting te hebben, maar de volledige invulling van de architectuur stapsgewijs, gedurende de verschillende sprints, verder in te vullen en bij te sturen.

Think big, act small, fail fast en learn rapidly zijn daarmee de principes die ook ten aanzien van architectuur in Scrum worden gehanteerd. Daarmee is architectuur niet iets wat door een architect vanuit een ivoren torentje wordt bedacht, maar iets waarvoor je als team een gezamenlijke verantwoordelijkheid hebt.