Een vraag die ik als Integration Consultant geregeld krijg, is wat het verschil is tussen systeemintegratie en data-integratie. Laat ik Formule 1, een sport die tegenwoordig wel tot de verbeelding spreekt, eens gebruiken om dat verschil uiteen te zetten. In deze blog leg ik uit waarom het één veelal niet zonder het ander kan.

Rollende computer

Het is alweer ruim een week geleden dat “onze” Max wereldkampioen werd in de Formule 1. Ooit was dat een autosport. Maar het is tegenwoordig zo veel meer. De auto waarmee Max wereldkampioen werd, is een rollende computer met een motor erin.

Een Formule 1 auto heeft tegenwoordig meer dan 300 sensoren aan boord. Vervolgens zijn er langs de baan én in de pit duizenden sensoren aanwezig. We krijgen daarmee steeds meer “Insights” te zien als we een Formule 1 race bekijken. Hoe efficiënt was de pitstop? Hoe snel reageerde een coureur bij de start? Wie nam het meeste risico tijdens een race? Deze Insights zijn mogelijk door alle data zo snel mogelijk vanuit de auto en de baan bij de kijker te krijgen. Voor veel mensen is dat de normaalste zaak van de wereld. Maar het hart van een Integration of Data Analytics Developer gaat daar stiekem toch harder van kloppen.

De Insights van F1 zijn Powered by AWS. Dat betekent dat Amazon Web Services wordt gebruikt voor het verwerken en interpreteren van alle data. AWS geeft toegang tot ontzettend veel rekenkracht, Machine Learning (ML) en Artificial Intelligence (AI). Toch moet het harde werk nog steeds gedaan worden door ons, de architecten en ontwikkelaars. Je kunt nog zo veel data opsturen, als je het niet slim verwerkt, komt de data nog steeds niet op een snelle en juiste manier bij de kijkers. Het gebruik van de juiste technieken, die je ter beschikking hebt binnen de cloud waarin je opereert, is hierbij de belangrijkste factor.

Het integratieprobleem: Data zo snel mogelijk op de juiste plek

Als je het over het transport van de data hebt, dan gaat het vooral over de problematiek die te maken heeft met systeemintegratie. De sensoren sturen events (hele kleine berichten) met data. Je wilt deze berichten zo snel mogelijk op de juiste plek laten landen. Dit hoeft niet op een gestructureerde, maar wel op een integere en veilige manier.

Als System Integrator kun je bijvoorbeeld de volgende vraag stellen: Moeten berichten in de juiste volgorde worden verwerkt? Of is een parallelle verwerking, en daarmee veel snellere verwerking, de beste keuze? Daarnaast moeten deze berichten zo snel mogelijk gebruikt kunnen worden om weer te geven. Hoe nauwkeurig moet deze data zijn voor de kijker thuis op de bank? Is alle data nodig, of voldoet een klein deel van de enorme set aan berichten ook? Laten we er even vanuit gaan dat de plas- en bierpauzes de enige strategische keuzes van kijkers zijn. Dan mag er gerust wat afwijking in de berichtgeving zitten. Voor de kijker maakt het echt niet uit of Hamilton Verstappen over 5 rondes of 7 rondes in zal halen (tenzij dat vlak voor de finish lukt). Je kunt hiervoor dus met een kleinere dataset werken dan een F1 team dat de strategische keuzes hierop baseert.

Het data analytics probleem: De juiste weergave van die data

Maar met ruwe data alleen kan een kijker vrij weinig. Het is niet zo interessant om een berichtje te zien met wat ’timestamps’ en waardes erin. Data moet op een juiste manier weergegeven worden.

De Data Integrator zorgt ervoor dat data op een juiste manier getransformeerd wordt en in een gestructureerde vorm wordt klaargezet voor weergave.

Een Data Integrator zal zich dus afvragen wat de beste manier is om de ruwe gegevens op te slaan. Daarbij is het van belang dat ze op een snelle en juiste manier geïnterpreteerd en weergegeven kunnen worden op een tv scherm. Het maakt dus uit waarvoor deze data gebruikt wordt.

Een Integration Developer maakt zich echter totaal niet druk om hoe berekend wordt dat de banden van Max ‘bijna op’ zijn. Of wanneer Hamilton er voorbij steekt. Een Data Integrator daarentegen kan zich hier wel degelijk druk om maken. Het slim klaarzetten van de data kan betekenen dat het systeem het in enkele seconden tevoorschijn tovert, of er een half uur voor nodig heeft.

En het gaat veel, veel verder

Op bijna iedere Formule 1 auto prijkt tegenwoordig een IT-partner. Denk hierbij aan Oracle (Red Bull), Microsoft (Renault), Splunk (McLaren) en Tibco (Mercedes). Het geeft aan hoe belangrijk deze partners voor ze zijn. En dat is zeker niet alleen om data heen en weer te schuiven of weer te geven. Zonder de IT van deze organisaties is het niet meer mogelijk om de auto te ontwikkelen. En al helemaal niet om wedstrijden te winnen.

Onderstaand filmpje geeft een goed beeld van hoe belangrijk IT, en met name de cloud, tegenwoordig is voor een sport als Formule 1. Rob Smedley van Formula 1 laat zien hoe AWS cruciaal is geweest voor de ontwikkeling van de nieuwe regelgeving voor 2022.

Photo header by Grahampurse (CC0 license) https://commons.wikimedia.org/wiki/File:Max_Verstappen_(Austin_2021).jpg

Een goede klant van ons was aan de slag gegaan met Microsoft Power BI. Na verloop van tijd kwam het besef dat de weg die ze waren ingeslagen niet houdbaar was. In een korte periode waren veel rapporten gerealiseerd. Door de snelheid van de realisatie was er te weinig aandacht besteed aan de het onderhoud van de rapporten. Tijd om ze op te schonen en te verbeteren was er niet. Voor het genereren van de rapporten waren bovendien handmatige handelingen nodig op de laptop van een medewerker. Daarmee was er te veel afhankelijkheid van één persoon. Daarom besloten ze om toch een volledige datawarehouse oplossing te implementeren. Aangezien wij als Etesian ook al de website ontwikkelen en beheren, vroegen zij ons om ook dit datawarehouse project met meerdere van onze consultants vorm te geven. In deze blog lees je hoe wij dat hebben opgepakt.

Te veel informatie

Alleen al voor de afdelingen Marketing en E-commerce zijn ruim 100 Power BI rapporten gemaakt waarin zij door de bomen het bos niet meer zagen. Bovendien bevatten al deze rapporten niet alle stuurinformatie waarover de Marketing afdeling graag zou willen beschikken. Ook andere afdelingen wisten niet meer om te gaan met de overvloed aan informatie. Door de creatieve inborst van medewerkers en toepassing van huisstijl en logo waren het fraaie rapporten geworden, maar de indeling verschilde nogal per rapport. Het werd langzaamaan zaak om te optimaliseren, rapporten gebruikersvriendelijk te maken en herijken van de informatiebehoefte. 

De handmatige werkzaamheden die nodig waren voor het genereren van de rapporten vormden een risico. Mocht deze medewerker uitvallen dan was geen overdracht mogelijk en valt de rapportageproductie stil. Data uit het bronsysteem verzamelen en opslag vonden plaats in een AWS (Amazon Web Services) omgeving. Hierdoor zijn extra veelal handmatige handelingen nodig om de data klaar te zetten in de Azure (Microsoft) omgeving voor gebruik door Power BI. De klant zag dit als een aanzienlijk risico voor de lange termijn en heeft ons om advies gevraagd.

Azure Data Factory

We hebben de klant geadviseerd, een projectplan opgesteld en dit opgepakt met meerdere consultants. Allereerst is een back-up van de brondata uit AWS overgezet op een SQL Server database in een eigen Azure omgeving. Vervolgens wordt alle benodigde data voor Power BI geladen in een Azure datawarehouse. Dit laden gebeurt met behulp van data pijplijnen in Azure Data Factory. Dat is een component van Azure waarmee data van de ene naar andere database gekopieerd kan worden en eenvoudig in te stellen is. Voor dit project hebben we in de Azure Data Factory een aantal best practices meegenomen:

• Per object (binnen de bron) een enkele pijplijn;
• Snel laden, om bronsystemen minimaal te belasten;
• Incrementeel laden, om grote gegevensobjecten niet elke keer volledig in te laden.

Voordeel van de ondersteuning met Azure Data Factory is dat geen handmatige acties meer nodig zijn om Power BI rapporten te verversen. Dit gebeurt rechtstreeks in Power BI Service aangezien nu ook de brondata online, dus in Azure, staat. Bijkomend voordeel is dat diverse andere handmatige werkzaamheden overbodig zijn geworden. Ook is de rapportenproductie minder afhankelijk van een specifieke persoon aangezien alle voorbereidingen van data voor gebruik in Power BI online plaatsvinden.

Vermindering van het aantal rapporten

Door automatisering van datastromen aan de ‘achterkant’ kunnen we de hoeveelheid Power BI rapporten voor de Marketing afdeling drastisch verminderen. Dat levert ruimte en inhoud op voor verdere afstemming over de informatiebehoefte aan de ‘voorkant’. Doordat definities nu eenduidig zijn, stelt het de klant in staat om de kracht van Power BI in te zetten. Dit resulteert in dashboards die op visueel aantrekkelijke wijze inzicht geeft in de bedrijfsvoering. De klant kan stuurinformatie gebruiken waar het voor bedoeld is: handelen naar inzicht uit data.

Dit project met Power BI en Data Factory loopt gestaag. We vertellen je er graag meer over.