Indien een organisatie 'Agile' werkt, kan dit betekenen dat er een Agile-werkwijze is geadopteerd zoals Scrum. Scrum voorziet in een aantal protocollen, zoals dagelijkse standups en sprints waarin iedere twee of drie weken toegevoegde waarde voor de gebruiker wordt opgeleverd (potentially shippable product). Vaak houdt het hier op, maar om echt Agile te werken, is er meer nodig, om te beginnen een Agile-architectuur en en een Agile-architect.
Een Agile-architectuur is een architectuur die flexibel is (eenvoudig aan te passen) en die goedkoop is in ontwikkeling, gebruik en beheer. Doordat er binnen een sprint functionaliteit wordt opgeleverd, zijn we er zeker van dat deze relatief goedkoop is in ontwikkeling, er is namelijk maar drie weken ontwikkeltijd aan besteed. Echter, doordat de focus van het team niet langer is dan deze drie weken, is het nog onduidelijk of de toekomstige kosten laag blijven en de flexibiliteit voldoende is.
Standaarden
Als we het Scrum-team nader gaan bestuderen en alle teamrollen bekijken, zien we dat er een rol ontbreekt: de architect. Veelal is de architect wel elders aanwezig in de organisatie (enterprise architecten, EA), maar hebben ze geen actieve rol binnen een Scrum-team. Als alternatief hebben ze vanuit hun EA-rol standaarden gedefinieerd, waar het Agile-team zich aan dient te houden. Dit kunnen standaarden zijn als 'passen in het landschap', of 'hergebruik componenten'.
Er zit echter nogal een gat tussen deze standaarden en de druk op het Scrum-team om functionaliteit per sprint op te leveren. Om dit gat te vullen moet er in het Scrum-team een Agile-architect meespelen. Deze Agile-architect beheert enerzijds de relatie met alle stakeholders in de organisatie (EA, security, beheer, etc.) maar bewaakt de oplossingen van het Agile-team ten opzichte van de Agile-uitgangspunten: flexibiliteit en kosten.
Agile BI-architecturen
Binnen de BI-wereld zijn er veel vooroordelen over de toepasbaarheid van Agile/Scrum specifiek voor BI. Een van de redenen is dat er veel ETL gebouwd moet worden, dit is niet zichtbaar voor de gebruiker, en daarmee voldoet dit niet aan de definitie van een potentially shippable product. De komende tijd meer blogs hier over Agile BI-architecturen en de rol van de BI-architect hierin.
Hoeveel kretologie wil je bij elkaar hebben in één artikel?
Dit is hyping en geen content.
In de Scrum-gedachte is de architectuurfunctie (ontwerpstandaarden richtlijnen etc) juist de verantwoordelijkheid van het team zelf, of zoals het agile manifesto het zegt: The best architectures, requirements, and designs emerge from self-organizing teams.
Niet een aparte BI-architect dus, maar architectuur als onderdeel van de verantwoordelijkheden van het team (net als ontwerp, testen, programmeren etc.). Architectuur is dan niet een van te voren volledig uitgewerkt masterplan, maar meer een routekaartje wat meegroeit met het project.
Het is de verantwoordelijkheid vd Scrum-master om er voor te zorgen dat er voldoende communicatie is tussen het team en de stakeholders.
Architecten moeten uit hun ivoren toren komen en gewoon meedraaien in het team, niet als politie-agent om collega’s te controleren, maar door als teamlid gezamenlijk verantwoordelijkheid voor het projectresultaat te dragen. Bij succesvolle Scrumprojecten zie je dat dit ook gebeurt.
Oke, het commentaar in de vorige twee reacties zijn niet geheel onterecht, maar het punt wat getracht wordt te maken is dat BI en Agile Scrum inderdaad wat moeilijk te combineren zijn. Je moet weten hoe je ETL/kubus/DWH eruit gaan zien qua scope, anders wordt het erg inefficiënt. De risico’s die je loopt op het aanpassen van dergelijke onderdelen ten gevolge van de Agile Scrum werkwijze zijn enorm en daarmee kostbaar. Ik hoop dan ook dat de volgende blogs snel zullen volgen.
Bottom-up architectuur werkt wellicht voor kleine projecten. Voor grotere projecten, multiteam, multiproduct, safetykritisch of andere zware nonfunctionals zul je toch echt topdown aan de slag moeten. Daarbinnen kun je evt kortcyclisch doorontwikkelen, maar wel vanuit een overkoepelend ontwerpkader. Anders kun je het zogenaamde shippable product na een tijdje echt weggooien omdat het niet voldoet ondanks alle gelopen sprints met features. (helaas in meerdere projecten moeten constateren) Een goed fundament/de hoofdstructuur is voor zowel BI als software engineering trajecten onmisbaar.
Een citaat uit het artikel wat bij mij toch een vraag oproept:
“Een Agile-architectuur is een architectuur die flexibel is (eenvoudig aan te passen) en die goedkoop is in ontwikkeling, gebruik en beheer.”
Dit lees ik als dat grote complexe producten/architecturen niet met Agile ontwikkeling ondersteund zouden kunnen worden.
Een interessante BLOG zou dan zijn wat de grenzen zijn van de Agile ontwikkeling: hoe groot is groot, hoe complex is complex?
Every Angle heeft al 10 jaar een Agile BI-architectuur. Om meer te weten, zie http://www.everyangle.com. Ik nodig BI-experts uit om eens een praatje te komen maken om de ‘agile’ filosofie in de praktijk te zien werken.
Agile is in grote opkomst. Of het nu binnen de BI, de architectuur of een samensmelting daarvan is. Ik vraag me wel eens af waar dit nu opeens vandaan komt. 10 jaar geleden (of waarschijnlijk wel meer) hadden we al DSDM, vooral in de softwareontwikkeling. Dat werd maar met mondjesmaat geaccepteerd en geimplementeerd. Wat is er gebeurd, dat het nu zo ‘hot’ is? Is het toegankelijker geworden? Is bewezen dat het nut heeft?
Voor jullie informatie: op 13 december is het Agile Business intelligence congres. Met internationale en nationale sprekers. Tevens is er de simulation game: quality versus speed.
Interessant om meer te weten te komen over verschillende visies op Agile en Bi, maar vooral ook door de praktijkcasus die langskomen. http://www.agilebicongres.nl