Herken je dat? Je hebt met de beste ideeën een Data Warehouse gebouwd en onderhoudt dat al een tijdje. Er zijn echter veel aanvragen die volgens de gebruikers heel klein zijn, maar onder water veel impact hebben! Hoe los je dat nu op?

Ilse van HR is één van je klanten. wil graag een paar nieuwe metrics in haar dashboard te zien krijgen. Ze heeft hier al regelmatig om gevraagd en “het staat op de backlog”. Ze heeft het idee dat ze met een kluitje in het riet gestuurd wordt. Daarom denkt ze erover om haar mensen op een Power BI-training te sturen. Naar het schijnt, kunnen ze dan hun analyses zelf oplossen. Want als ze op het BI-team moet wachten, kan ze de tent wel sluiten..

Als BI-team wil je Ilse echter graag helpen. Dat betekent dat je nieuwe kolommen moet gaan inladen. Met als direct gevolg aanpassingen in het doorladen richting andere onderdelen van het Data Warehouse. Hoewel de aanpassing van buitenaf bezien eenvoudig is, betekent het voor jullie als BI-team momenteel dat er in alle “lagen” van het Data Warehouse een aanpassing gedaan moet worden. Dat heeft veel potentiële impact, wat zich vertaalt in een zwaar test- en releaseproces.

Kennelijk sluit de verwachting die je gebruikers hebben niet altijd aan bij de manier waarop het Data Warehouse opgebouwd is. Daarom geef ik in dit artikel 3 stappen om je Data Warehouse releaseproces te versnellen

Stap 1: Automatiseer je builds en releases

Wanneer je dit leest, ga ik ervan uit dat je je releases al niet meer ad-hoc uitvoert. Als profesioneel BI-team heb je een vast stappenplan hebt dat je elke release doorloopt. Maar wanneer je met de hand een stappenplan kunt doorlopen, dan kun je het ook automatiseren!

Het automatiseren van je builds en releases zorgt ervoor dat het systeem voor jou een release doorvoert op bijvoorbeeld een testomgeving. Omdat het systeem dat uitvoert, kun jij ondertussen doorwerken aan nieuwe ontwikkelingen. En omdat je je release getest hebt, ben je er zeker van dat de uitrol op een productie-omgeving ook goed zal gaan.

Het automatiseren van builds en releases wordt vaak CI/CD genoemd. Een tool die je hier goed voor kunt gebruiken is Azure DevOps. Voor zowel on-premises als cloud-oplossingen kun je hiermee automatisch builds en releases laten uitvoeren bij elke wijziging die in versiebeheer terecht komt.

Stel dat je release momenteel 6 uur duurt in elke sprint - je reserveert er dus twee dagdelen voor. Die doorlooptijd is vaak opgebouwd uit een paar componenten:

• Samenstellen van de release (2 uur)
• Doorlopen van de release op een acceptatie-omgeving (1 uur)
• Verifiëren van de resultaten (2 uur)
• Doorlopen van de release op een productie-omgeving (1 uur)
• wellicht nog andere checks en controles

Het invoeren van deze eerste stap zorgt ervoor dat er elke sprint vier uur extra vrijkomt. Alleen het verifiëren van de resultaten is namelijk nog iets dat je handmatig doet! En mochten er tijdens een release-proces bevindingen zijn (bijvoorbeeld in de verificatie-fase), dan loopt die winst verder op. Die tijd kun je vervolgens besteden aan het daadwerkelijk toevoegen van waarde voor je eindgebruikers. Bijvoorbeeld door verder te ontwikkelen, ondersteunen, of instrueren waar dat nodig is.

Stap 2: Start met Continuous Delivery

Wanneer je builds en releases geautomatiseerd kunnen plaatsvinden, is er geen reden meer om het uitvoeren van je release uit te stellen tot het einde van de sprint: van elke wijziging kun je nu namelijk geautomatiseerd testen of de release nog steeds goed gaat.

Initieel kiezen veel teams er nog steeds voor om het doorzetten van wijzigingen naar hun productie-omgevingen uit te stellen tot het einde van de sprint. De doorlooptijd daarvan gaat echter drastisch korter zijn: je hebt de release gedurende je sprint al tientallen keren laten testen!

In CI/CD wordt vaak het onderscheid gemaakt tussen “Continuous Deployment” en “Continuous Delivery”. Continuous Deployment gaat over het daadwerkelijk continu (en geautomatiseerd) doorzetten van elke wijziging naar productie-systemen. Voor ons als Data Warehouse-specialisten is het tweede interessanter: Continuous Delivery. We verzekeren er ons van dat onze software op elk punt in de tijd in principe te releasen is. En dat verifiëren we dus continu.

Met deze tweede stap wordt het verifiëren van de resultaten opgebroken in kleine stukjes. Voordat je deze stap implementeerde had je één groot probleem aan het einde van de sprint: twee weken aan ontwikkelwerk dat je in één keer gaat verifiëren. Met continuous delivery heb je gedurende de sprint continu de resultaten bekeken, en waar nodig al gecorrigeerd. Dat zorgt ervoor dat je makkelijker kunt verifiëren wat er mis gaat, eerder bewust bent van problemen, en minder vaak bevindingen hebt in je release-proces.

Stap 3: Maak je Data Warehouse-ontwerp meer modulair

Stap drie is de meest ingrijpende stap, maar ook één van de meest winstgevende. Want hoewel de business steeds meer iteratief is gaan werken, hebben voor ons Data Warehouse kleine aanpassingen nog steeds veel impact op het hele systeem. Concreet: wanneer er een kolom wordt toegevoegd in een bronsysteem, heeft dit vaak impact op alle lagen van je Data Warehouse. Staging, historische lagen, integratielagen, business layers, data marts en zelfs vaak de kubussen worden geraakt. En dat zorgt voor vertraging.

Tightly Coupled Systems

In software engineering is hier een term voor: tightly coupled systems. Dat betekent dat je bij een aanpassing in bestaande functionaliteit op een onderdeel A (bijvoorbeeld de staging-laag) direct enkele andere onderdelen (bijvoorbeeld ETL-procedures) moet aanpassen. Dat maakt systemen minder flexibel.

De tegenhanger van tightly coupled is loosely coupled. Dat betekent dat de communicatie tussen twee onderdelen volgens een vastgestelde interface of contract gaat. Omdat de definitie daarvan vaststaat, kun je component A eenvoudig vervangen zonder door een nieuwe versie, zolang er maar aan het contract voldaan wordt.

Interfaces

Direct gevolg is dat je de interface of het contract niet zomaar kunt wijzigen. Dat zie je bijvoorbeeld bij webservices. Op het moment dat er extra data geleverd gaat worden via de webservice, maakt het niet uit welke software aan de achterkant draait of door wie deze wordt aangeroepen: de manier van aanroepen staat vastgelegd, en de manier van antwoorden ook. Daarom zal niemand in-place een wijziging aanbrengen: er wordt een nieuwe versie van de webservice uitgerold die parallel draait aan de huidige implementatie. Er zijn op enig moment vaak meerdere versies van een webservice actief. De reden? Je kunt geen wijzigingen aanbrengen in een interface (= afspraak hoe je communiceert). Dus introduceer je een nieuwe versie van de interface, en blijf je de oude versie nog een tijdlang ondersteunen.

Dit kun je ook op je Data Warehouse toepassen: denk eens na over de “interfaces” die er zijn tussen de onderdelen van jouw systeem. Welke processen hebben verwachtingen van datastructuren? Zijn er manieren om die te ontkoppelen? Het resultaat is dan direct zichtbaar: je kunt kleinere stukjes onafhankelijk van elkaar releasen, wat je ontwikkeling flexibeler maakt (en de impact van je releases kleiner).

Conclusie en bonus

Met de implementatie van de eerste twee stappen hierboven hebben BI-teams die in iteraties twee weken werken vaak al een besparing van een dag per sprint te pakken: 10% van de sprint dus! De derde stap kost wat meer werk - als Data Warehouse-team zien we vaak onze oplossing nog als één groot product. De derde stap kan echter wel enorm veel flexibiliteit en ontwikkelsnelheid brengen: doordat de componenten die je krijgt kleiner worden, is de impact van wijzigingen kleiner. Naast het handmatig testen dat sneller wordt, maakt deze meer "modulaire" aanpak ook de drempel voor geautomatiseerd testen een stuk lager.

Een laatste tip waar je naar zou kunnen kijken: feature toggles. Dat is een manier om nieuwe features die gereed zijn, maar ook geen impact veroorzaken wel op te nemen in je releases. Omdat de systeemprocessen en gebruikers de nieuwe features niet (kunnen) aanspreken, maakt dat dat je minder aan het integreren bent en eenvoudiger kunt "proefdraaien".