Leer in 13 minuten

  • Wat een goede data-architectuur eigenlijk inhoudt
  • Waarom zo’n architectuur zo belangrijk is
  • Welke stappen nodig zijn om zo’n architectuur te ontwerpen

Bij de architectuur van een gebouw weet iedereen waar we het over hebben. Bij een dataplatform is dat een ander verhaal. Voor de ene persoon is een data-architectuur een plaatje, voor de ander een heel boekwerk. Toch kan een goede data-architectuur het verschil maken tussen het succes en falen van een project. Hoe ziet zo’n architectuur eruit? En hoe zet je die neer?

Laten we even teruggaan naar de analogie met de architectuur van een gebouw. Stel, je wilt een groot gebouw neerzetten. Waarschijnlijk ga je hier met heel veel werklieden aan bouwen. Misschien zelfs met werklieden van verschillende onderaannemers of groepjes die verschillende onderdelen los van elkaar bouwen. Hoe zorg je er dan voor dat al deze mensen hetzelfde gebouw voor ogen hebben? Dat de verschillende onderdelen op elkaar aansluiten? En dat het gebouw toekomstbestendig is? Precies, daar heb je een architectuur voor nodig. Die zet een kader neer voor iedereen die aan de oplossing bouwt en bepaalt de bouwblokken, uit welke materialen ze bestaan en hoe ze samenhangen.

Onmisbare basis

Een data-architectuur heeft dezelfde functie en is net zo onmisbaar. Je beschrijft erin hoe je dataplatform – het ‘gebouw’ dus – eruitziet. Toch ontbreekt het in de praktijk vaak aan een goede, duidelijke data-architectuur als basis voor een dataplatform. Organisaties ontwikkelen dataoplossingen los van elkaar. Ze starten projecten om bijvoorbeeld selfservice analytics of data science van de grond te krijgen en maken daarbij eigen keuzes bij de ontwikkeling van logica. Dat leidt tot dubbel werk en daarmee tot dubbele kosten. Waardevolle inzichten opgedaan in het ene project worden ook niet toegepast in het andere. Daarbij komt nog dat dezelfde gegevens en informatie leiden tot verschillende uitkomsten en dus tot verkeerde beslissingen.

Mensen hebben bovendien verschillende ideeën over wat het ontwerpen van een data-architectuur inhoudt. Er wordt van alles gedaan: plaatjes maken, modelleren of coderen. Ze gebruiken ook vaak verschillende begrippen door elkaar of als synoniemen van elkaar. Denk aan termen als concepten, functionaliteiten, oplossingen of technologieën. Dit leidt bij de uitvoering en opbouw van een data-architectuur onherroepelijk tot verwarring, vertraging of – erger nog – het mislukken van projecten.

Elementen van een data-architectuur

Wat organisaties nodig hebben, is een complete en breed toepasbare data-architectuur. Maar wat houdt dit nu precies in? De volgende elementen mogen in ieder geval niet ontbreken:

  • Principes
    Belangrijke beslissingen waaraan je keuzes binnen je architectuur ophangt. Denk aan bedrijfsbrede principes zoals cloud first, Microsoft tenzij, altijd open source en GDPR-compliancy. Die vul je aan met specifieke principes voor je data-architectuur, bijvoorbeeld: zo min mogelijk datareplicatie toepassen.
  • Business capabilities
    De dingen die je dataplatform vanuit een gebruikersperspectief moet kunnen, dus de diensten die op basis van je use cases nodig zijn.
  • Technische capabilities
    Een beschrijving van de blokken functionaliteit die je dataplatform moet hebben om je use cases in te vullen. Zoals functies om data te integreren, op te slaan, te modelleren en te presenteren.
  • Conceptuele architectuur
    Een plaatje met de blokken functionaliteit van je platform en hoe deze componenten met elkaar samenwerken. Dit brengt het gemeenschappelijke doel in beeld, waar je naartoe beweegt in diverse tempo’s.
  • Technische architectuur
    De invulling van je componenten met technologie.
  • Roadmap
    De stappen die je moet nemen om je doel te bereiken (de ‘epics’) en de samenhang met relevante zaken buiten de architectuur. Zoals wetgeving van externe toezichthouders, langlopende systeemmigraties (bijvoorbeeld van het primaire registratiesysteem naar een cloud-dienst), nieuwe softwarefunctionaliteit of de langetermijnstrategie en -visie voor data.
  • Ontwerp- en ontwikkelrichtlijnen
    De manier waarop het dataplatform en de systemen, diensten en processen binnen de architectuur worden beschreven en hoe ze moeten worden ontwikkeld. Denk aan release-management, versiebeheer, het wel of niet modelleren met een methodiek en datamodelleer-tool of juist meer ad-hoc, of de mate van datamanagement en -governance. Zorg hierbij voor een gezonde balans tussen wat nodig en wat praktisch toepasbaar is. Mensen moeten de energie die ze in een data-architectuur steken direct terugzien in de waarde die dit oplevert. Anders is er geen draagvlak.

Stapsgewijs een data-architectuur opbouwen

De kunst is om voor iedere functionele component in je architectuur de beste technologische fit te zoeken en nieuwe toepassingen als zelfstandig samenwerkende delen aan je data-architectuur toe te voegen. Zo kun je de data-architectuur of het dataplatform geleidelijk aan opbouwen en onderdelen inzetten wanneer je dat wilt, in de gewenste schaalgrootte. Dit zijn de stappen die je hierbij neemt:

  1. Zet de principes die richting geven aan alle keuzes voor je data-architectuur op een rij. Dit zijn zowel de bedrijfsbrede principes, als de principes die specifiek voor je architectuur gelden. Hierboven noemden we al wat voorbeelden.
  2. Stel vast waarom je de data-architectuur, en het dataplatform dat erin wordt beschreven, maakt. Want dit is nooit een doel op zich, maar altijd een middel om waarde voor je bedrijf te creëren. Welke door de business gedreven use cases wil je ondersteunen? Achterhaal dit in een workshop met business-collega’s: mensen met een visie en een goed beeld van de waarde van data voor je bedrijf. Voorkom lange, uitputtende sessies door meteen compleet te willen zijn. Focus je op de use cases met veel impact en relatief weinig moeite en baseer daar de eerste versie van je architectuur op.
  3. Bepaal welke diensten de use cases van je data-architectuur vragen, vanuit een gebruikersperspectief. Zo zal de maandelijkse rapportage aan een ministerie, diensten vergen die de auditeerbaarheid garanderen. Leg ook vast voor welk type gebruikers je dataplatform is bedoeld. Zo zal een data scientist andere diensten nodig hebben dan een CEO.
  4. Bepaal welke technische capabilities je platform moet hebben om de nodige diensten te leveren. Een capability-model helpt daarbij. Daar lees je meer over in dit blog.
    Zo heb je voor de historische opslag van data waarschijnlijk functionaliteit voor gestructureerde opslag nodig.
  5. Bepaal uit welke componenten (groeperingen van je capabilities) je dataplatform bestaat, wat ze moeten kunnen en hoe ze moeten samenwerken. Hieronder zie je een voorbeeld uit onze referentiearchitectuur.
  6. Bekijk welke technologie geschikt is voor je dataplatform. Maak eventueel een short-list en probeer verschillende technologieën uit in de volgende stap.
  7. Breng je architectuur tot leven en test deze uit met een pilot use case die je naar productie brengt.
  8. Leer uit de pilot en ga de volgende cyclus in met nieuwe use cases, want net als je dataplatform is je data-architectuur nooit af.

Essentiële uitgangspunten

Welke keuzes je ook maakt bij het ontwerpen van een data-architectuur, het is belangrijk altijd voor ogen te houden dat techniek niet leidend mag zijn. Dat is een valkuil waar veel organisaties in stappen. Wat telt zijn je doelen en met welke blokken functionaliteit, in welke onderlinge samenhang, je deze doelen probeert te bereiken. Daarna kijk je pas met welke techniek je dit invult. De volgende uitgangspunten helpen je de juiste beslissingen te nemen bij het neerzetten van een echt goede data-architectuur:

  • Ontkoppel broncomplexiteit
    De complexiteit van je bronnen mag de informatievoorziening niet in de weg staan. Ontkoppel je bronnen dus van je diensten.
  • Ontkoppel veelgebruikte logica van datagebruik/applicaties
    Pas veelgebruikte logica op één plek toe op je data. Iedere applicatie kan er zo gebruik van maken.
  • Bied meerdere data-integratiesporen
    Zorg voor flexibiliteit in je dataverwerking: virtueel, fysiek, met of zonder historie, real-time of batch en pas toe wat bijdraagt aan een use case of de informatiebehoefte. Een data-platform is geen fabriek waar alles op dezelfde manier doorheen moet.
  • Staar je niet blind op één technologie
    Clouddatabase, api-framework of datavirtualisatie, … een moderne architectuur is nu eenmaal hybride. Succesvolle integratie en verdeling van functies staan hierin voorop.

Onze data-architectuuraanpak

Bij Axians werken we bij het ontwerpen van nieuwe data-architecturen altijd vanuit een referentiearchitectuur. Die is gemaakt om mee te kunnen bewegen met de snelle technologische ontwikkelingen van vandaag. Met deze referentiearchitectuur maken we duidelijk onderscheid tussen verschillende lagen: functie, concept, technologie en oplossing.

Maar zoals eerder gezegd gaat het bij het maken van een goede data-architectuur niet alleen om het hoe-wat-waarmee. Vooral ook de wie (organisatie en proces, mensen) en waarom (cultuur en gebruikers, missie, strategie) mogen niet worden vergeten. Deze twee aspecten zijn integraal onderdeel van het maken van een uitvoerbare en gedragen data-architectuur. Ook daar houden we in onze aanpak rekening mee, zoals het plaatje hieronder laat zien.

Houvast voor de toekomst

Kortom, met een echte data-architectuur schep je een duidelijk kader voor het samenwerken en integreren van verschillende concepten en oplossingen. Je beschrijft waarom je dataplatform bestaat, wat het moet leveren en aan wie, hoe het dat gaat doen en met welke technologie dit gebeurt. Zo biedt een data-architectuur houvast. Het is mogelijk om met allerlei mensen tegelijk aan een toepassing te werken en toch een toekomstvaste oplossing neer te zetten. Bij Axians zien we hoe goed dat werkt!

Hoe concreet en uitgewerkt is de data-architectuur van jouw organisatie?