Nu is het grote voordeel wel dat met de komst van cloudomgevingen als Microsoft Azure en Amazon Web Services (AWS) de drempel veel lager is geworden om een eigen omgeving op te zetten. Ook de kosten, wel met een degelijk ontwerp en mits je de juiste maatregelen neemt, kunnen flink lager zijn dan traditionele oplossingen. Daarnaast kan je klein beginnen en investeringen ook stapsgewijs nemen waardoor het voor kantoren met een minder grote omvang ineens ook heel interessant wordt om een eigen dataplatform op te zetten. Wat ons betreft is een modern dataplatform in de cloud dan ook de juiste weg vooruit en onze aanpak is ook volledig op een cloud oplossing gericht.
Waar begin je dan?
Het begint met het verkennen van datakansen vanuit een business perspectief. De kansen worden uitgewerkt in use-cases en geprioriteerd. Pak de meest relevante use-case en neem dit als uitgangspunt. Voordat je daadwerkelijk kan experimenteren met data is een cloud infrastructuur nodig, het fundament voor jouw platform. Natuurlijk kan je data ook direct in Excel inladen en een ‘Proof of concept’ uitwerken. Dit is een goede manier om zelf proefballonnen op te laten en zeker een goed startpunt voor analyses, maar zodra een initiatief rijp is om te delen met collega’s wil je de oplossing ook structureel goed borgen. Dan wil je een dataplatform tot je beschikking hebben. We sommen hier de voordelen van een dataplatform op:
- Geautomatiseerd data verwerken en hiermee repeterend werk wegnemen
- Borgen ‘1 versie van de waarheid’
- Data uit meerdere bronsystemen samenvoegen en combineren
- Historie opbouwen over jouw data, wat weer vele nieuwe mogelijkheden van data-analyse
met zich meebrengt - Grote rekenkracht om veel data te verwerken. Excel begint al snel te piepen en te kraken bij
toename van data. - Betere beveiliging van data.
Terug naar dat het neerzetten van de basisinfrastructuur, ook wel het fundament van jouw platform.
Zonder technische achtergrond is dit behoorlijk lastig. Dus schroom niet om hier specialisten in te
huren wanneer je deze kennis (nog) niet zelf in huis hebt. Net zoals bij het bouwen van een huis
moet er een gedegen fundament zijn. Dit bepaalt in grote mate het succes van jouw dataplatform. Het zou dus ook een slecht advies zijn om hierop te beknibbelen.
De cloudomgeving is als een grote blokkendoos. De bouwblokken zijn de verschillende functionaliteiten in een cloudomgeving die je kan aanmaken en configureren. Bijvoorbeeld een opslag account of een database, maar ook infrastructuur onderdelen als een virtueel netwerk, sleutelkluizen om wachtwoorden in op te slaan en bijvoorbeeld een firewall. Het geheel van deze bouwblokken vormt jouw dataplatform. Het ontwerpen en inrichten van zo’n dataplatform wordt normaliter door een data-architect gedaan. Natuurlijk zijn er ook andere rollen die dit eventueel zouden kunnen, maar dan moeten deze specialisten wel een gedegen kennis hebben van cloud omgevingen en data architecturen. Hoe bepaal je nu welke bouwblokken in jouw situatie het beste passen?
Selecteren van de bouwblokken
Hiervoor hebben we een aantal eenvoudige richtlijnen:
Start klein: Zoals we al een paar keer benoemd hebben: start klein, maar denk vooral groot. Ook bij het ontwerp van jouw dataplatform. Kies bouwblokken waar je met lage kosten kan instappen, maar die wel enorm schaalbaar zijn. Kies in de beginfase zo veel mogelijk voor ‘pay per use’ cloud consumptie. Je betaalt dan naar gebruik en als je bouwblokken niet gebruikt betaal je er ook niet voor. Houdt wel rekening mee dat je wel altijd betaald voor opslag van data, maar opslag is goedkoop. De rekenkracht om data te analyseren zal de meeste kosten met zich meebrengen. Door efficiënt gebruik van deze rekenkracht kan je kosten wel laag houden. Kijk vooral naar bouwblokken met rekenkracht welke automatisch aan gaan bij gebruik en ook weer uitgaan bij inactiviteit. Ook bouwblokken die automatisch op- en afschalen binnen een bepaalde bandbreedte zijn aan te raden. De ‘pay per use’
manier van consumeren biedt je flexibiliteit en kan je kosten besparen. Let wel op dat je de kosten goed blijft monitoren. Bouwblokken die niet automatisch uitgaan en vergeten worden om uit te zetten kunnen de kosten enorm laten oplopen.
Schaalbaarheid: Dit betekent dat jouw dataplatform zich kan aanpassen aan veranderende omstandigheden zoals een toename (of afname) van de data of het gebruik ervan. Daarom is schaalbaarheid enorm belangrijk. Je wilt dat data binnen een acceptabele tijd beschikbaar is, maar je wilt ook grip houden op de kosten. Hier zit een tegenstrijdigheid in en zul je een juiste balans moeten zoeken. De meeste bouwblokken in de cloud zijn goed schaalbaar, daar zit immers ook een grote kracht van cloud omgevingen. Moderne analytische databases als Snowflake of aan dataplatform als Databricks of Microsoft Fabric zijn enorm schaalbaar, maar bieden dus ook de mogelijkheid om automatisch terug te schalen. Ook opslagaccounts als datalakes kunnen ontzettend hard groeien zonder dat het direct ten koste gaat van de performance van data-oplossingen.
Ontkoppelbaar:Een belangrijk advies wanneer je een dataplatform in de cloud inricht is
goed na te denken over ontkoppelpunten. Houdt data en rekenkracht zo veel mogelijk gescheiden en zorg ook dat je verrijkte datamodellen weer zou kunnen opbouwen op basis van de ruwe data. Door hier bewust in jouw ontwerp rekening mee te houden is het ook makkelijker om bepaalde bouwblokken in te ruilen als ze niet de toegevoegde waarde brengen die je had verwacht of wanneer er simpelweg nieuwe bouwblokken komen die beter zijn. Waar het kan zorg dat technologie relatief eenvoudig in te wisselen is. Hierbij moeten we natuurlijk wel de kanttekening maken dat het altijd een bepaalde inspanning kost om bouwblokken te vervangen hoe goed alles ook ontworpen is.
Datakwaliteit: Houdt rekening met de kwaliteit van data. Zorg altijd dat er plek is om de onbewerkte data op te slaan en dat je deze ook goed bewaard. Maak een tweede laag binnen de architectuur voor geïntegreerde en opgeschoonde data en een derde laag voor verrijkte data. Die integratie en verrijkings-laag kan je virtueel maken zodat je niet continue data aan het rond kopiëren bent. Zorg wel dat je altijd vastlegt hoe de data aangeleverd is, dus zonder aanpassingen. Dit noemen we ook wel de ruwe data. Hierdoor ben je in staat om te bepalen of data issues al in een bronsysteem ontstaan of door onjuiste logica op jouw dataplatform.
Security by design: De beveiliging van jouw platform moet je ook niet lichtzinnig opvatten. Een hack of een data lek kan voor veel problemen zorgen. Denk aan reputatie schade of zelfs boetes vanuit toezichthouders. Het is niet meer acceptabel om hier vooraf niet over na te denken bij het maken van jouw ontwerp voor een dataplatform. Het grote voordeel is wel dat moderne cloud providers veel aandacht besteden aan beveiliging en er ook veel opties zijn om jouw data en jouw platform te beveiligen. Denk hierbij aan rol gebaseerde toegang, firewalls en detectie van onverwachte en schadelijke activiteiten.
Privacy by design: Het zal je waarschijnlijk niet ontgaan zijn dat er ook veel gebeurd op het gebied van privacy. De wetgeving is de laatste jaren steeds strenger geworden met betrekking. Daarom is het, net zo als bij security, een vereiste om hier in jouw ontwerp over na te denken. Het is verstandig om risico’s en eventuele schade uit te zetten tegenover de kosten van de te nemen maatregelen. Mocht je interessante data initiatieven bedacht hebben waarbij privacy gevoelige data nodig is dan moet je toetsen of er voor deze use- case(s) een grondslag is om privacy gevoelige informatie in een data platform op te slaan. Dit kan via een Data Privacy Impact Assesment (DPIA). Dit kan als gevolg hebben dat je andere bouwblokken moet kiezen om de maatregelen toe te passen die vereist zijn.
Kennisniveau: Het kennisniveau van collega’s die het platform moeten onderhouden, maar ook de data bedrevenheid van de consumenten die platform gaan gebruiken moet je ook absoluut meenemen in keuze voor de bouwblokken. Wanneer je bijvoorbeeld kiest voor zelf-service oplossingen dan heeft een SQL gebaseerde technologie vaak een lagere instap. Oplossingen gebaseerd op programmeertalen als Python of Scala is meer specialistische kennis voor nodig. Ook de keuze voor SaaS, PaaS of IaaS kan afhangen van beschikbare kennis. Wil je volledig ontzorgd worden of wel je zelf meer kunnen configureren. Houdt er wel rekening mee dat wanneer je meer beheer naar jezelf toe trekt je hier ook de kennis voor in huis moet hebben.
Visualiseer de architectuur: Om een dataplatform te ontwerpen is het goed om jouw ontwerp te visualiseren. Wij gebruiken daar normaliter onze dataplatform referentie architectuur voor. Dit is een uitwerking van alle functionaliteiten welke een dataplatform zou kunnen bevatten. We hebben een vereenvoudigde versie gemaakt van hoe zo’n visualisatie er uit kan zien. Deze visualisatie is nog zonder keuze voor specifieke bouwblokken, maar die kan je samen met jouw datateam en eventuele datapartner samen invullen. Bijvoorbeeld als opslag kan je voor een Azure datalake storage:
(ADLS gen 2) kiezen en voor rekenkracht zou je Databricks of Microsoft Fabric kunnen inzetten. Met de richtlijnen die we hier hierboven beschreven hebben als leidraad kan je de bouwblokken naast elkaar zetten om keuzes te maken.
Deze richtlijnen geven je houvast bij het maken van keuzes. We hebben hierboven de meest
relevante richtlijnen benoemd. Natuurlijk zijn er nog meer van deze richtlijnen te bedenken. In IT- jargon zul je ook vaak de term ‘guiding principles’ horen vallen voor dit soort fundamentele richtlijnen. Deze guiding principles zijn geen wetten, maar je moet als ontwerper wel zwaarwegende redenen aandragen om hiervan af te wijken. Het is verstandig om deze guiding principles uit te werken en de implicaties te beschrijven. Maak er eventueel een one-pager van die je op de muur (of ergens op een digitale werkplek, als er veel remote gewerkt wordt) hangt bij de domein teams en het centrale data team, zodat iedereen weet wat deze richtlijnen zijn en iedereen dezelfde taal gaat spreken. TOGAF is een architectuur framework wat hierbij kan helpen. Op de website van TOGAF kan je bijvoorbeeld veel documentatie terugvinden hoe je een data architectuur en bijbehorende guiding principles uitwerkt. Zie TOGAF als een grote gereedschapskist waar jij de juiste tools uit kan gebruiken.
Wanneer je een blauwdruk voor jouw dataplatform hebt gemaakt kan je de bouwblokken daadwerkelijk uitrollen in de cloud omgeving naar keuze en kan je aan de slag met de data use-case(s). Ga vooral beginnen, experimenteer en leer. Laat je goed adviseren als je zelf niet de kennis in huis hebt en leer stapje voor stapje als organisatie en als individu om data bedreven te worden. En onthoud: een kasteel wordt niet in één dag gebouwd, maar met de kennis van dit whitepaper en een goede mindset zijn wij ervan overtuigd dat het voor elk accountskantoor mogelijk is om je eigen kasteel te bouwen. De datagedreven accountant is nu aan zet!
Wil je aan de slag met data maar heb je hulp nodig bij het verkennen van kansen, het uitwerken van een use-case of het ontwikkelen van een dataproduct dan helpen wij daar graag bij. Neem gerust contact met ons op!
Geef een reactie