Er wordt tegenwoordig vaak gezegd dat data het nieuwe goud is. In de praktijk ligt de focus nog steeds op applicaties en de functionaliteit rondom die applicaties. Data zelf is natuurlijk ook allang een product, maar data heeft nog niet altijd de focus. Data hubs kunnen dit veranderen.
Data integratie is traditioneel vooral gericht om de toegang en de uitwisseling tussen verschillende applicaties mogelijk te maken. Daarmee is data nog geen zelfstandig product. De eerst stap daartoe is vaak API gedreven te werken en een data mesh te creëren.
API’s worden in een data mesh als product ontworpen en via een self-service developer portal beschikbaar gesteld. Deze API gedreven manier van werken, kent echter ook een aantal beperkingen. Bijvoorbeeld:
- Afhankelijkheid van de kwaliteit van de achterliggende API/Applicatie.
- Afhankelijkheid van de kwaliteit van de netwerkverbindingen naar een API is per applicatie verschillend.
- API’s moet bij elkaar worden gebracht (door middel van een API Platform).
- Data is verspreid over de applicaties (functies/domeinen)
Wat als we API’s (en API Management) en Data (en Data Management) bij elkaar kunnen brengen in één oplossing? Dit is het idee achter een data hub. Data hub is een term die oorspronkelijk van Gartner komt. Ze geven op hun website hierover aan:
It turns out that so many organizations had assumed all data and/or policy should be centralized (think ERP), or widely distributed at the edge (think standalone business application or IoT edge device).
It turns out that a ‘new’ approach, once that permits the notion of intermediate nodes to store/execute the policy or trusted data itself somewhere within all the spaghetti of systems, yields real efficiencies and drives agility.
Those “nodes” we introduced as ‘data hubs’, knowing that the word “hub” was already well used.
Hieronder zijn de verschillende manieren van data distributie waarover Gartner spreekt grafisch weergegeven:
Hub-Spoke
Het basis idee van een data hub is net als een internationaal vliegveld die als overstapplek dient voor een aantal kleinere vliegvelden in de buurt. Dit is bekend als het Hub-Spoke model:
Meestal is er niet sprake van één hub, maar van meerdere hubs. De subnodes kunnen direct, maar ook via de hubs met elkaar communiceren. Bij vliegvelden is dit als volgt:
Het concept
Nu is het niet zo dat je met een standaard relationele database een datahub kunt maken, je hebt technologieën nodig die schaalbaar en redundant zijn. Dit kan het aantal stappen van een integratie aanzienlijk verkleinen en de betrouwbaarheid van de verbindingen verhogen.
Lange tijd werden Data hubs als data collecties sceptisch benaderd, omdat het veel opslagruimte, data replicatie, schaalbaarheid, connectiviteit en security vereist. Daarnaast was er niet een duidelijk protocol, zodat andere systemen hierop in konden prikken.
Wat je wel veel zag dat data centraal werd verzameld in een data warehouse, maar deze alleen voor analyse en rapportage doeleinden bedoeld was. Data hubs zijn specifiek ook voor operationele doeleinden geschikt. Wikipedia geeft aan:
A data hub differs from a data warehouse in that it is generally unintegrated and often at different grains. It differs from an operational data store because a data hub does not need to be limited to operational data.
A data hub differs from a data lake by homogenizing data and possibly serving data in multiple desired formats, rather than simply storing it in one place, and by adding other value to the data such as de-duplication, quality, security, and a standardized set of query services.
Een data hub bevind zich conceptueel dus ergens tussen centraal en decentraal en operationeel en strategisch.
Voordelen
Maar wat is nu het voordeel van een data hub? Het basisvoordeel is hetzelfde als bij grote vliegvelden die als hub dienen. Je hoeft niet tussen elk punt een verbinding te maken, maar kiest een aantal punten waar je data slechts deels centraliseert.
Verschillende kleinere systemen kunnen zo makkelijk via de hub data uitwisselen. Het hoeft daarbij niet met één groot centraal systeem verbonden te worden, maar alleen met de data hub.
Vaak worden data hubs als concept tegenover een centrale ERP of een mainframe gezet. We kunnen deze benadering echter ook goed tegenover meer traditionele decentrale benaderingen zetten. Deze gaan meestal er van uit dat opslag en integratie van elkaar gescheiden zijn.
Een integratie in een decentraal applicatielandschap heeft meestal de volgende opbouw:
- Bron (opgeslagen data)
- Connector/API met de bron
- Bron via connectors/apis ontsloten via middleware
- Middleware: Integratie logica die de data routeren, transformeren enzovoorts.
- Connector/API met het doel: Ophalen/sturen van data van/naar het doelsysteem.
- Doel: Consumeren van gegevens (verwerken en/of opslaan)
Hier boven staan 6 stappen, maar in de praktijk kunnen dit lange ketens van tientallen stappen zijn. Soms ook met afhankelijkheden op derde systemen en API’s.
Data hubs kunnen het aantal stappen aanzienlijk verminderen. Een voorbeeld van zo’n data hub is een hub voor artikelinformatie. Nu zijn er enorm veel leveranciers die artikelen maken en enorm veel bedrijven die artikelen verkopen. Er wordt daarom vaak besloten deze op een centraal punt te verzamelen.
De artikelgegevens van duizenden leveranciers worden verzameld. Elke afnemer kan via een API (wellicht in een eigen data format of protocol) een deel van de data stromen consumeren.
In het voorbeeld van artikelgegevens gaat het om meerdere bronnen, maar telkens om dezelfde data. Het is natuurlijk ook mogelijk verschillende type data te combineren. Bijvoorbeeld verschillende financiële data in één data hub:
Producten
Bij een data hub gaat dus om data als product. Er zijn echter nog weinig aanbieders die een Data hub als product of als onderdeel van hun product aanbieden.
Er zijn drie soorten data hub producten:
- Data hub als onderdeel van een centrale applicatie. De applicatie is een knooppunt naar de rest van de organisatie. Bijvoorbeeld een centraal financieel systeem, waar verschillende kleine financieel gerelateerde systemen aan gekoppeld zijn, het centrale systeem is de hub naar de kleine applicaties en andere domeinen in de organisatie.
- Data hub als een business oplossing waarbij de data hub al gevuld is met data. Deze data kan bijvoorbeeld publieke data uit verschillende bronnen zijn en aan één of meerdere partijen toegankelijk worden gemaakt.
- Data hub als een specifieke technische oplossing waarbij data bijvoorbeeld in een organisatie vanuit meerdere kleinere bronnen zijn gecentraliseerd en vanuit daaruit operationeel worden ontsloten. Bijvoorbeeld meerdere financiële systemen die samen komen in een data hub (dat zelf geen andere functie kent dan als hub).
OData
Een term die bij veel data hubs gebruikt wordt is OData (Open Data Protocol). Dit is een standaard op basis van een aantal best practices voor het maken van REST API’s.
OData helps you focus on your business logic while building RESTful APIs without having to worry about the various approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats, query options, etc. OData also provides guidance for tracking changes, defining functions/actions for reusable procedures, and sending asynchronous/batch requests.
Verschillende data hubs, zoals die SAP, MarkLogic en Mendix ondersteunen ODATA.
Voorbeeldproducten
De meeste leveranciers breiden een belangrijke domein applicatie uit met data hub functionaliteit. Er zijn echter ook initiatieven die een zelfstandige data hub kunnen opzetten.
Bijvoorbeeld:
1. Cloudera Enterprise Datahub
2. InfinyOn
3. Mendix Data Hub
4. MarkLogic Datahub
5. IRIS Data Platform
6. SAP Data Cloud
Conclusie
Er zijn verschillende benaderingen om een data hub op te zetten. Overkoepelend kunnen we wel stellen dat data hubs
- Waarde creëert door het bundelen van data vanuit gedistribueerde bronnen.
- Het totaal aantal integraties verminderd.
- Data deelt via API’s op een veilige en gestandaardiseerde manier.
