Wie eerst: data-architectuur of technologie?

Veel organisaties zijn bezig nieuwe data-architecturen te ontwerpen en te implementeren waarmee aan de nieuwe informatiebehoeften kan worden voldaan. Waren we ooit tevreden met systemen die vooraf gedefinieerde dashboards en rapporten tevoorschijn konden toveren en die een-dag oude data toonden, tegenwoordig gelden andere regels. Nieuwe vormen van datagebruik, zoals self-service BI, data science, embedded BI en streaming analytics, vereisen dat nieuwe data-architecturen worden ontworpen.

Ooit gingen we er van uit dat data-architecturen onafhankelijk van technologieën en producten opgezet moesten worden; ofwel, eerst de data-architectuur en dan de bijpassende producten erbij zoeken. Dat kon toen ook omdat veel producten redelijk uitwisselbaar waren. Zo waren ETL-producten vergelijkbaar in mogelijkheden en hetzelfde gold voor veel SQL databaseservers en rapportagetools. Uiteraard bestonden er prijsverschillen en andere, functionele verschillen tussen die producten, maar er kon toch uit een homogene groep producten gekozen worden.

Dus bij het uitdenken van je data-architectuur nam je een blokje ETL op en een blokje databaseserver en later selecteerde je het product waarmee een blokje geïmplementeerd kon worden. Maar is de situatie nog steeds hetzelfde? Zijn de producten nog steeds zo uitwisselbaar?

Specialisatie
De laatste jaren worden we geconfronteerd met een niet aflatende stroom technologieën voor het verwerken, analyseren en opslaan van gegevens. Denk hierbij aan Hadoop, NoSQL, NewSQL, GPU-databases, Spark en Kafka. Deze technologieën hebben een grote invloed op data-architecturen. Dit komt omdat ze op twee manieren verschillen van de wat klassiekere producten.
Het eerste verschil is dat veel producten gespecialiseerd zijn. Ze zijn niet meer geschikt voor allerlei soorten toepassingen maar voor slechts één of twee. Bijvoorbeeld, veel NoSQL-producten, zoals MongoDB en Riak, zijn ontwikkeld en geoptimaliseerd voor het verwerken van veel transacties. Daarentegen zijn hun analysemogelijkheden zeer minimaal. Neo4j, ook een NoSQL-product, is juist gebouwd om data te analyseren en is niet sterk in transacties. In feite ondersteunt het één vorm van analyse en wel graph analytics. GPU-based SQL databaseservers zijn speciaal ontworpen om razendsnel query’s op veel data te verwerken. Het zijn ideale producten om als data mart in te zetten. Hun specialisatie maakt ze echter een stuk minder uitwisselbaar.

En dit was ooit compleet anders. Bijvoorbeeld, de bekende klassieke databaseservers waren geschikt voor een breed scala aan toepassingen. Ze konden ingezet worden ter ondersteuning van transacties, rapportage, portals, websites, datawarehouses, en nog veel meer.

Unieke interne architecturen
Het tweede verschil betreft hun meestal unieke interne architecturen. Een SQL databaseserver als SnowflakeDB bijvoorbeeld is eigenlijk een product dat de rol op zich neemt van de drie databases waaruit een datawarehouse-architectuur bestaat; dus de staging area, het datawarehouse en de data marts. Een ander voorbeeld is de databaseserver Edge Intelligence die query’s verwerkt op de plekken waar de data geproduceerd wordt. Op een bepaalde manier is het een gedistribueerde databaseserver.

Dit soort producten dwingt een bepaalde data-architectuur af. Wil men optimaal van ze gebruik maken, dan moeten ze ten eerste ingezet worden voor de toepassing waarvoor ze gebouwd zijn. Ten tweede moet hun interne architectuur leidend zijn bij de bepaling van de data architectuur. Dus kunnen we nog wel een technologie onafhankelijke data-architectuur ontwikkelen? Het lijkt me niet.

Rick van der Lans zal over dit onderwerp tijdens de Data Warehousing & Business Intelligence Summit op 27 maart 2019 een keynote presenteren; De invloed van nieuwe database-technologie op data-architecturen.