Ontwerpprincipes van data-centric IT-architecturen

Een data-centric architectuur koppelt data los van een heterogene toepassingsomgeving zodat bedrijfsdata op een consistente manier kan worden gebruikt. Dit artikel behandelt de negen belangrijkste ontwerpprincipes en een case study, dat is geschreven door Clemens Esser, Chief Technologist bij Hewlett Packard Enterprise (HPE).

Overheden over de hele wereld strijden om de macht in de data-economie. Kijk maar naar verklaringen van de Chinese Communistische Partij of de Europese Commissie uit 2020. Zij gaan ervanuit dat het creëren van datawaarde de komende decennia een cruciale rol speelt in economische en sociale vooruitgang.

De basis voor de data-economie is nieuwe industriële en professionele data, waarmee organisaties waarde kunnen creëren, zoals nieuwe inkomstenbronnen en bedrijfsmodellen en betere klantervaringen. Daarbij kunnen ze betere beslissingen nemen op basis van data. Een voorbeeld: McKinsey voorspelt dat connected-car data in 2030 jaarlijks 250 tot 400 miljard dollar kan opleveren voor spelers in het mobiliteitsecosysteem.

De vraag is uiteraard in welke mate organisaties in staat zullen zijn om deze kansen ook daadwerkelijk te benutten. Ze moeten dan immers data-inkomsten genererende capaciteiten ontwikkelen. Dat wil zeggen: ze moeten data kunnen extraheren, aggregeren, verwerken, analyseren en aan het werk zetten binnen hun eigen organisatie en hun ecosysteem.

API-mandaat vs. Data-anarchie
Cloudgiganten weten wel hoe dit werkt. Hun voordeel is dat ze in staat waren om hun IT-architecturen al vroeg ‘datacentric’ in te richten. In 2002 stelde Jeff Bezos zijn welbekende "API-mandaat" in; alle data-uitwisseling tussen apps en diensten bij Amazon moeten plaatsvinden via service-interfaces, zonder uitzondering en ongeacht de gebruikte technologieën. Iedereen die dit niet doet, wordt ontslagen.

De situatie bij de meeste bedrijven is totaal anders. Zij hebben vaak te maken met datasilo's die op een ruwe en kant-en-klare manier bij elkaar worden gehouden door een veelheid van scripts, interfaces en point-to-point verbindingen. Op de lange termijn zijn dergelijke spaghetti-architecturen niet alleen duur, maar vormen ze ook een ernstige belemmering om waarde uit data te halen. De kwaliteit van de data is vaak slecht en grote stukken van de data blijft ongebruikt. Uit wereldwijd onderzoek van IDC en Seagate blijkt dat bedrijven slechts een derde van de data gebruiken waarover ze beschikken. Daarom is het ook zo belangrijk om over te schakelen op een bedrijfs-brede data-centric IT-architectuur - gebaseerd op het model van de organisaties die al groot zijn in cloud.

Ontwerpprincipes van data-centric architecturen
De belangrijkste kenmerken van zo’n architectuur zijn eenvoudig samen te vatten. In de kern wordt de data losgekoppeld van de toepassingen die de data genereren, door ze via een centrale datahub te kanaliseren. Hierbij wordt gebruik gemaakt van datastreamingtechnologieën zoals Kafka of HPE Ezmeral Data Fabric, aangevuld met dataopslag op basis van relationele, NoSQL- en graph databases, en een data lake (meestal met Hadoop, maar ook meer en meer S3 buckets). Elke applicatie fungeert als een "producent" van data voor de datahub en elke query is een "consument" van de uitgebreide, gedistribueerde datapool. Dit alles is ingebed in een overkoepelend raamwerk voor data governance.

Hieronder worden de belangrijkste ontwerpprincipes van een dergelijke architectuur beschreven. In de praktijk moet ook rekening gehouden worden met organisatorische, culturele en bedrijfsbeleidsmatige belemmeringen. Een fictieve casestudy laat zien hoe deze belemmeringen kunnen worden overwonnen.

Ontwerpprincipe 1: Laat alle data als een event stream via de datahub lopen
Alle databronnen pushen hun data naar de datahub via een event stream. In het geval van applicaties zijn dit alle data uit het logische datamodel; in het geval van IoT-apparaten zijn het alle lokaal verzamelde statusdata. De data worden verzonden in het bronformaat; er mag geen transformatie plaatsvinden op applicatieniveau. Dit voorkomt fouten en verlies van informatie. De verbinding is gebaseerd op het connect once-principe - één verbinding per databron. Er zijn verschillende mogelijkheden om data over te dragen, waaronder het MQTT-protocol voor IoT, Kafka Connect, CDC (Change Data Capture), Apache NiFi, enz. Hoe dichter de overdracht bij het basisdatamodel van de producent ligt, hoe sneller en goedkoper de integratie kan worden gerealiseerd. Net als de databronnen (producenten), communiceren de bevragende apps en diensten (consumenten) alleen via de datahub. Dit voorkomt dat de interfaces bij elk nieuw verzoek om aanvullende informatie opnieuw moeten worden aangepast.

Ontwerpprincipe 2: Laat alle producenten metadata publiceren
Om de data op lange termijn te kunnen gebruiken, worden alle data die via de hub lopen gedocumenteerd. Dit omvat tenminste de relevante metadata van semantiek en classificatie. Naarmate de architectuur rijper wordt, omvat de metadata ook andere informatiemarkeringen zoals: GDPR-relevant, GDPR-informatieverzoek, GDPR-verwijdering, automatisch verzameld, handmatig verzameld, real-time informatie, periodiek verzameld, vertrouwensniveau, enz. Een governance applicatie verzamelt deze metadata en beheert de datacodering en toegang.

Streams uit één bron bevatten vaak data van verschillende beveiligingsniveaus (C1 t/m C4, dat wil zeggen: openbare, interne, vertrouwelijke en geheime data). Daarom moet voor elk van de classificatieniveaus een thematische context (topic) worden gecreëerd en moeten, afhankelijk van de opdracht, sleutels tussen de deelnemers worden uitgewisseld. Alleen de ‘subscribers’ die voor dit beveiligingsniveau zijn goedgekeurd, kunnen de respectieve data zien. Als eerste stap of als minimum viable product kan deze metadata-informatie worden gecombineerd met rol-afhankelijke toegang voor toepassingen. Deze controles zijn van toepassing op het topic-niveau. Bij een hogere volwassenheidsgraad kan dit worden uitgebreid met informatie van Identity & Access Management voor toegang via microservices.

Ontwerpprincipe 3: Bewaak iedere interface die deel uitmaakt van de CMDB
De datahub vereist een maximale beschikbaarheid. Platformen als Kafka en Ezmeral Data Fabric zijn gebouwd voor zulke strenge eisen, maar dat geldt niet voor alle connectoren. NiFi zou bijvoorbeeld maar op één node kunnen draaien, wat in tegenspraak is met de hoge beschikbaarheidseisen - en zelfs met Kafka komt het voor dat een interface niet werkt zoals gewenst. Des te belangrijker is het dat elke afzonderlijke interface een CI in de CMDB vertegenwoordigt. Het is ook belangrijk om elke interface te monitoren en er specifieke KPI's aan toe te wijzen. De IT-afdeling creëert deze in eerste instantie handmatig; op een hoger volwassenheidsniveau kunnen de drempelwaarden worden gegenereerd met behulp van machine learning (ML).

Ontwerpprincipe 4: Beheer alle interfaces
De omgeving verandert waarschijnlijk snel en continu. Daarom is het essentieel dat de architectuur gelijke tred houdt met deze veranderingen. Wijzigingen aan producerende of consumerende interfaces moeten soepel en gecontroleerd verlopen. Daarom moet de IT-afdeling alle interfaces kunnen beheren, en moet het operationele team dagelijks eenvoudige interacties met één klik kunnen uitvoeren. Basisfuncties zoals "stop" of "herstart" moeten vanaf het begin worden geïntegreerd en beschikbaar zijn voor de servicedesk en tweedelijnsondersteuning.

Ontwerpprincipe 5: Onderhoud een Enterprise Data Model met datacatalogus en metadatabeheer
Terwijl brondata van producenten zo dicht mogelijk bij het bronformaat moeten blijven bij de overdracht naar de hub, moeten andere data worden geconsumeerd in het gestandaardiseerde formaat; het Enterprise Data Model (EDM). De IT-afdeling definieert, publiceert en onderhoudt hiervoor een centraal EDM. Elke EDM-eenheid wordt geïmplementeerd in een specifiek onderwerp in de datahub. Voor elk onderwerp moeten regels worden vastgesteld met betrekking tot wie er toegang toe heeft en hoe. Het beheer van de toegangscontrole en de richtlijnen vindt plaats via het metadatabeheer. Dit werkt nauw samen met het beheer van de enterprise-architectuur, de rollen van databeheer en de ontwikkeling van de datahub, en wordt ondersteund door governance-functies. Op basis hiervan creëert de IT-organisatie een datacatalogus voor data-abonnementen. Er moeten duidelijke verantwoordelijkheden zijn voor datamanagement, inclusief de bijbehorende rollen:
- Data-eigenaren; bepalen hoe data worden bewaard en gebruikt
- Data stewards; beheren de data volgens de specificaties van de data-eigenaar en zijn verantwoordelijk voor de datakwaliteit en het bepalen welke data verwijderd moeten worden.

Ontwerpprincipe 6: Stel de gebruiker centraal – maak datacatalogus-elementen beschikbaar via op microdiensten gebaseerde API's en micro-UI's
Het IT-team stelt de datacatalogus beschikbaar voor applicaties, gebruikers en, indien nodig, partners. Voor apps is data beschikbaar as-a-service via API's, en voor gebruikers en partners via rol-specifieke gebruikersinterfaces (micro-UI's). API's op basis van microservices en containertechnologie maken de snelle ontwikkeling mogelijk van gebruikersgerichte apps die gebruikers precies de informatie bieden die ze nodig hebben. Dit maakt het leven van de werknemers gemakkelijker. Met een hogere mate van volwassenheid zijn de apps niet alleen afgestemd op de specifieke rol, maar ook op regio's en culturen.

Ontwerpprincipe 7: Maak documentatie relevant, concreet, begrijpelijk en gemakkelijk toegankelijk
Agility en governance vereisen transparantie. Het is daarom aan te raden om relevante informatie te documenteren in een wiki die voor alle betrokken medewerkers toegankelijk is. De inhoud van een wiki omvat architectuurprincipes, best practices, uitzonderingen op de regels en verantwoording, protocollen van de architectuurraad, datamodellen en in het bijzonder het EDM waarop de datacatalogus is gebaseerd. Als broncodecomponenten deel uitmaken van de architectuur, moet er een link zijn naar de code opslagplaats. Naar architectuurcomponenten wordt verwezen als best practices in de architectuurwiki. Operationele concepten, testconcepten, coderingsregels en testdatabeheer moeten ook gedocumenteerd en toegankelijk zijn. Dit vergemakkelijkt de samenwerking, ondersteunt de continue verbetering van de omgeving, bevordert de wendbaarheid en optimaliseert de dienstverlening en operaties.

Ontwerpprincipe 8: Pas test-gestuurde ontwikkeling en continue levering toe
Een betrouwbare CI / CD pipeline met geautomatiseerd testen versnelt de verdere ontwikkeling van de data-architectuur, verhoogt de kwaliteit van de service en creëert de basis voor agile ontwikkeling en DevOps. Naarmate het aantal test cases toeneemt, neemt ook het verzamelen van testdata toe. Net als de code zelf moeten deze in versies worden bijgehouden en zo performance- en regressietests op een hoger niveau mogelijk maken.

Ontwerpprincipe 9: Laat een "digitale tweeling" van de datapool de basis vormen voor alle data usecases
De introductie van een data-centric architectuur dient uiteindelijk het doel om een "digitale tweeling" te creëren van de gehele datapool van een bedrijf of ecosysteem. Datacatalogisering en metadatabeheer van alle data zorgen voor transparantie en creëren de basis voor een voortdurend toenemende datakwaliteit. Naast de databronnen onthult het centrale databeheer ook de waarde van elke bron en overlappende datafeeds. Dit betekent dat voor alle toepassingen geschikte data kunnen worden gevonden en geanalyseerd. Hierop voortbouwend ondersteunt een service catalogus de creatie van datawaarde door data en analyses via geschikte apps toegankelijk te maken voor verschillende doelgroepen.

Case study: De weg naar data-inkomsten

Het volgende voorbeeld van een fictief luchtvaart logistiek bedrijf illustreert de procedure voor de invoering van een data-centric architectuur. Het bedrijf heeft in de loop der tijd verschillende bedrijven overgenomen met als resultaat een heterogene mix van IT, toegesneden op de behoeften van afzonderlijke functies en/of afzonderlijke overgenomen bedrijven. Applicaties communiceren via point-to-point verbindingen; er is geen uniforme data-architectuur. Bovendien is er geen alomvattende data-analyse en zijn respectieve projecten na de eerste pogingen beëindigd, omdat de kosten voor het aansluiten op talrijke databronnen te hoog waren. Er was geen duidelijk zicht op de juiste bronnen. Een fictief voorbeeld dat IT-specialisten van grotere bedrijven enigszins bekend in de oren zou moeten klinken.

Maar nu de ommekeer: met steun van het topmanagement definieert het bedrijf een data-centric architectuur als visie. De initiële business case betreft het implementeren van een datahub inclusief event streaming en meta-datamanagement. Het proces: elke wijziging van een csv-uitwisseling leidt tot de implementatie van een Kafka-verbinding. Al na een paar maanden is merkbaar dat de eerdere hoge kosten voor interfaces worden teruggedrongen. Tegelijkertijd krijgt de organisatie met iedere nieuwe connector een beter inzicht in haar data. Gaandeweg wordt duidelijk dat veel externe interfaces overbodig zijn. Als gevolg daarvan begint het bedrijf overbodige contracten te beëindigen. Tegelijkertijd merken de eindgebruikers dat de toegang tot de data eenvoudiger is geworden en dat de data betrouwbaarder zijn.

Als test maakt het IT-team een datakubus met data uit een aantal bronnen om te illustreren hoe analyses via de datahub kunnen worden gebruikt om de sales afdeling van actuele informatie te voorzien. De verkoopafdeling besluit de verdere ontwikkeling van de architectuur te ondersteunen. Nadat de belangrijkste bedrijfsapplicaties op de datahub zijn aangesloten, volgt een Proof of Concept die laat zien hoe een gebruikersgerichte app medewerkers op de landingsbaan kan helpen. Via de app ontvangt het grondpersoneel actuele informatie over de vlucht - bijvoorbeeld of deze vertraagd is, net geland is, of de gate gewijzigd is. Het personeel ontvangt instructies van de supervisor via de chat en kan informatie uitwisselen met teamgenoten. De voordelen van het gebruik van de nieuwe app gaan rond in het bedrijf. Als gevolg daarvan krijgt de IT-afdeling talloze extra verzoeken voor dergelijke apps.

Hierdoor ontstaat er een gemeenschappelijke taal van datagebruik voor steeds meer usecases. De kwaliteit van de data blijft toenemen, steeds meer medewerkers krijgen real-time de data die ze nodig hebben, en het wordt voor het management eenvoudiger om operationele en financiële data op elkaar af te stemmen. Als volgende stap is het bedrijf van plan data te delen met klanten en partners. Eindklanten zullen gratis statusinformatie ontvangen en expediteurs krijgen toegang tot individuele real-time data via een interface - wel tegen betaling. Een directe inkomstengeneratie aan de hand van informatie ligt nu binnen handbereik.

Conclusie
Zodra de datapools verenigd zijn met gestandaardiseerd databeheer en governance via een datahub, is het relatief eenvoudig om snel een groot aantal usecases te implementeren. De weg ernaartoe is echter niet eenvoudig. En het zal in de toekomst alleen maar moeilijker worden, gezien de steeds complexere applicatielandschappen en de snelgroeiende hoeveelheden data. En zoals bij alle strategische IT-initiatieven zijn steun van het topmanagement en solide governance nodig om deze hindernissen te overwinnen. Het is echter van het grootste belang om agile methoden toe te passen voor architectuurbeheer, ontwikkeling en exploitatie. Want alleen dan zijn de weg en het doel in harmonie: in beide gevallen gaat het erom piramides en silo's te overwinnen met als doel minder met jezelf en meer met je klanten bezig te zijn.