Leer in 10 minuten
- Hoe een seriële en holistische aanpak van elkaar verschillen
- Wat een holistische aanpak precies inhoudt
- Aan welke vier invalshoeken je moet denken bij een holistische aanpak
Mij is ooit geleerd dat het ontwerpen van een data-architectuur begint met het ontwerpen van een conceptuele data-architectuur waarin technologieën en producten niet voorkomen. Pas als deze gereed is, bepaal je welke producten er het beste bij passen. Deze seriële aanpak is tegenwoordig niet meer aan te raden. Gezien de mogelijkheden van moderne technologie is een aanpak nodig die tegelijkertijd kijkt naar de conceptuele architectuur én de technologie. In feite moet een puzzel vanuit meerdere kanten opgelost worden. We moeten van een seriële naar een holistische aanpak.
De seriële aanpak
De seriële aanpak was ooit goed toe te passen. We werkten allemaal met producten die een vergelijkbare interne architectuur en functionaliteit hadden. Daardoor waren ze ook redelijk uitwisselbaar. Bijvoorbeeld, als je als architect een datawarehouse in de data-architectuur opnam, kon je daarna bepalen of deze met Oracle of Microsoft SQL server geïmplementeerd moest worden. Of als je besloten had het datawarehouse met een ETL-product te laden, kon je later bepalen welk product daar het meest geschikt voor zou zijn.
Deze redelijke uitwisselbaarheid van producten is aan het verdwijnen. De afgelopen jaren neemt het aantal specialistische producten namelijk sterk toe. Dit zijn producten die uitsluitend voor een beperkt aantal use cases zijn ontwikkeld. Neo4j is bijvoorbeeld een zeer krachtig product voor het toepassen van graph analytics. Redis is speciaal ontwikkeld als lookup technologie, waarbij enorme hoeveelheden data in memory worden vastgehouden en razendsnel kunnen worden opgezocht. En Edge Intelligence is een SQL-databaseserver die ontwikkeld is voor omgevingen waar data decentraal en remote wordt ingevoerd, maar centraal geanalyseerd moet worden en waar de hoeveelheid data te groot is om naar het centrale punt te kopiëren.
Vanwege hun specialistische karakter zijn deze producten lastig uitwisselbaar. Dit vereist dat je precies moet weten wat de use cases van die producten zijn, of ze passen bij je eigen use cases en wat het effect is op het ontwerpen van je data-architectuur.
Specialistische producten
Ter illustratie drie voorbeelden van producten met zeer unieke interne architecturen en aparte functionaliteit en dus een hele specifieke use case.
Snowflake DB is een moderne, analytische, cloud based SQL-databaseserver. Het product is niet alleen zeer snel, maar biedt ook een aantal unieke mogelijkheden. De interne architectuur is ontworpen om een cloudplatform, zoals dat van Amazon, Google of Microsoft, optimaal te benutten. Het product kan automatisch op- en afschalen afhankelijk van de veranderende workload. Data wordt end-to-end geëncrypt. Het inzetten van deze databaseserver heeft invloed op de uiteindelijke data-architectuur. Veel ontwerpbeslissingen die bij andere databaseservers nog genomen moeten worden, zijn door de engineers van de SnowflakeDB al bepaald.
Het Denodo Platform is een datavirtualisatieplatform met veel extra functionaliteit voor het opvoeren, organiseren en gebruiken van metadata. Denodo maakt technische metadata zelf aan. Ontwikkelaars en gebruikers kunnen veel bedrijfsgerichte metadata toevoegen en daar doorheen navigeren. Deze metadata functionaliteit van Denodo kan een aanzienlijke invloed op de data-architectuur hebben, aangezien het wellicht niet nodig is een apart product voor het beheer van metadata aan te schaffen.
Fivetran is een data warehouse automation product dat uitblinkt in het extraheren van data uit packaged applicaties. Bij dit product hoeft alleen te worden aangegeven uit welke applicaties de data opgehaald moet worden en Fivetran regelt de rest. Letterlijk alle data wordt uit de database van die applicatie opgehaald, de data wordt in een staging area opgeslagen en vervolgens genormaliseerd in een data warehouse opgeslagen. Fivetran werkt de data automatisch periodiek bij. Ontwikkelaars hoeven hiervoor niets te ontwerpen of beslissen. Een groot deel van de data-architectuur wordt door Fivetran bepaald. Het werk van de architect begint pas vanaf het data warehouse.
De holistische aanpak
Aangezien veel producten bepalend zijn voor het ontwerp van (een deel van) de data-architectuur, is het noodzakelijk om over te stappen van een seriële naar een holistische aanpak. Bij een holistische aanpak gaan het kiezen van producten en het opstellen van de conceptuele data-architectuur hand in hand. Zonder holistische aanpak halen bedrijven waarschijnlijk niet het maximale uit de producten. Dit kan leiden tot een inefficiënte data-architectuur of een onnodig complexe en dure data-architectuur.
Voor alle duidelijkheid, bij de holistische aanpak worden niet eerst de producten gekozen en daarna de architectuur. Dit gebeurt tegelijkertijd.
De holistische aanpak vereist veel verschillende vaardigheden. Data-architecten en technologiespecialisten moeten samenwerken om tot een perfecte data-architectuur te komen. Deze laatste groep moet niet alleen alle ins en outs kennen van de producten die al in gebruik zijn, maar moet ook goed op de hoogte zijn van alle nieuwe technologieën. De specialisten moeten weten wat de interne architectuur van die nieuwe producten is en wat de use cases zijn.
Vier invalshoeken van de holistische aanpak
In een ideale situatie wordt de holistische aanpak uitgebreid met nog twee invalshoeken; zie figuur 1.
De derde invalshoek is databeveiliging en data-privacy. Specialisten op dit gebied moeten zo vroeg mogelijk worden betrokken bij het opzetten van de data-architectuur en het selecteren van de technologie. Deze aspecten kunnen nooit te vroeg uitgedacht worden. Te vaak wordt deze groep er te laat bij betrokken wat een goede beveiliging en naleving van de regelgeving voor data-privacy bemoeilijkt.
Vergelijk dit met het bouwen van een nieuw kantoorpand dat beveiligd moet worden. De bekabeling van de beveiligingsapparatuur kan beter direct bij de bouw ingebouwd worden dan achteraf. Tijdens de bouw kunnen de kabels direct in de muren worden weggewerkt en hoeft het pand niet eerst weer half gesloopt te worden. Wat wel het geval is als het achteraf moet gebeuren.
De vierde invalshoek is het definiëren van algemene architectuurprincipes. Denk hierbij aan principes voor hoe en waar data opgeschoond wordt, hoe en waar datahistorie opgeslagen wordt, waar regels voor data-privacy geïmplementeerd worden en hoe data-eigenaarschap wordt toegekend.
Algemene architectuurprincipes zijn noodzakelijk om te voorkomen dat ontwerpers en ontwikkelaars voor vergelijkbare problemen geheel verschillende oplossingen bedenken. Bijvoorbeeld, het verwerken en opslaan van datahistorie kan op veel verschillende manieren gebeuren, van eenvoudig tot zeer geavanceerd. Welke oplossing gekozen wordt bepaalt of elke mogelijke situatie gedekt wordt, hoeveel functionaliteit geïmplementeerd wordt en hoe toegankelijk de datahistorie is. Als elke ontwerper voor een bepaald probleem een andere oplossing hanteert, moet deze telkens opnieuw bestudeerd worden, moet een specifieke oplossing voor de implementatie bedacht worden en moeten de gebruikers van de data leren omgaan met al die verschillende oplossingen. Dit gaat ten koste van de productiviteit, de uniformiteit waarmee data opgeslagen wordt en de toegankelijkheid van de datahistorie.
Een toekomstbestendig dataplatform
Veel organisaties hebben initiatieven gelanceerd om meer datagedreven te worden en hebben hun digitale transformatie ingezet. De meerderheid beseft ook dat als ze willen slagen, de bestaande IT-systemen niet toereikend zijn. Nieuwe IT-systemen moeten ontwikkeld worden of de bestaande moeten fors uitgebreid en opgewaardeerd worden. Kortom, er moet een nieuwe data-architectuur ontwikkeld worden.
Sta jij ook voor deze uitdaging? Pas dan een holistische aanpak toe en creëer een data-architectuur die geschikt is voor het ontwikkelen van een toekomstbestendig dataplatform.