Wat

is

data

ontsluiten?

Wat betekent data ontsluiten precies?

Data ontsluiten betekent dat gegevens uit een bronsysteem bereikbaar worden voor andere toepassingen. Denk aan orderregels uit een ERP die in een klantportaal moeten verschijnen, of meetwaarden uit een machine die in een rapportage terechtkomen. Het resultaat heet ook wel data-ontsluiting.

Ontsluiten is de eerste stap, niet de hele weg. Wat je daarna met de gegevens doet, zoals combineren, synchroniseren of verrijken, valt onder integratie. Het onderscheid is nuttig omdat de problemen verschillen. Bij ontsluiten gaat het om toegang en belasting van het bronsysteem, bij integratie om betekenis en samenhang.

Waarom zit data vast in een bronsysteem?

Data zit vast omdat het bronsysteem is gebouwd voor zijn eigen taak, niet om gegevens te delen. Een boekhoudpakket moet goed boekhouden. Of het die gegevens ook netjes kan doorgeven, was bij de aanschaf zelden een criterium.

Daar komen praktische drempels bij. Het systeem heeft geen API, of een API die maar een deel van de gegevens teruggeeft. De leverancier rekent extra voor toegang. Het datamodel is zo complex dat niemand meer weet welke tabel wat bevat. En bij oudere systemen is de kennis over de opbouw soms met de oorspronkelijke bouwer vertrokken.

Welke methodes zijn er om data te ontsluiten?

Er zijn vier methodes, elk met een eigen afweging tussen snelheid, betrouwbaarheid en belasting van het bronsysteem.

Via een API van het bronsysteem.

Een API is de afgesproken ingang waarlangs software gegevens opvraagt en terugschrijft. De meeste moderne pakketten bieden een REST-API. Dit is de netste route: de leverancier bepaalt wat er beschikbaar is en houdt de API stabiel bij updates. Let wel op autorisatie en rate limiting, het maximale aantal verzoeken per tijdseenheid. Hoe zo'n verbinding in elkaar zit, lees je in wat een API-koppeling is.

Rechtstreeks op de database.

Heeft het systeem geen bruikbare API, dan kun je de onderliggende database direct uitlezen. Dat geeft toegang tot alles, maar je bent afhankelijk van een datamodel dat de leverancier bij een update kan wijzigen. Lees bij voorkeur uit een kopie van de database in plaats van uit de productieomgeving. Meer over de opbouw staat in wat een database is.

Via export- en importbestanden.

Het systeem zet periodiek een bestand klaar, bijvoorbeeld een CSV-bestand op een beveiligde server, dat een ander systeem inleest. Deze route is eenvoudig en werkt vrijwel overal. Het nadeel is dat de data zo oud is als de laatste export, en dat een export die stopt vaak niet direct opvalt.

Via een middlewarelaag of dataplatform.

Bij meerdere bronnen loont een tussenlaag die de ontsluiting centraal regelt. De laag haalt gegevens op, zet ze klaar in een staginggebied en vertaalt ze naar een gezamenlijk datamodel. Dat heet ETL (extract, transform, load), of ELT als de vertaling pas na het laden gebeurt. Zo'n middleware als tussenlaag voorkomt dat elk systeem met elk ander systeem een eigen verbinding heeft. In een Data Management Platform komt die aanpak samen met opslag en beheer van de gegevens.

Hoe kies je tussen realtime en batch?

Kies op basis van de vraag hoe oud de gegevens mogen zijn op het moment dat iemand er een beslissing op neemt. Een voorraadstand in de webshop moet actueel zijn, een maandrapportage niet.

Realtime ontsluiting werkt met webhooks, waarbij het bronsysteem een melding stuurt zodra er iets verandert, of met polling, waarbij je in korte intervallen vraagt of er iets nieuws is. Batchverwerking haalt gegevens in één keer op, bijvoorbeeld 's nachts. Batch is eenvoudiger en belast het bronsysteem op een rustig moment. Realtime is sneller maar vraagt meer van de opzet en de monitoring.

Wat gaat er in de praktijk mis bij het ontsluiten van data?

Het meest voorkomende probleem is dat het bronsysteem de extra leeslast niet aankan. Een ERP dat overdag orders verwerkt, wordt traag als er tegelijk elke minuut een volledige uitlezing draait. Haal daarom alleen de wijzigingen op, of lees uit een kopie.

Het tweede probleem is stilte. Een export die stopt of een API-sleutel die verloopt, levert geen foutmelding op in het ontvangende systeem, alleen gegevens die niet meer worden bijgewerkt. Zonder monitoring merk je dat pas als iemand vraagt waarom de cijfers van vorige week zijn.

Het derde probleem zijn rechten. In het bronsysteem ziet een medewerker alleen zijn eigen afdeling. Na ontsluiting staat alles in één rapportage die iedereen kan openen. Neem de autorisatie mee in het ontwerp, niet achteraf.

Data ontsluiten uit legacy-systemen.

Legacy-systemen zijn oudere systemen die nog kritisch zijn voor de bedrijfsvoering, maar die niet meer actief worden doorontwikkeld. Ze hebben vaak geen API en draaien op een verouderde database. Toch zijn er drie routes.

Je kunt de database direct uitlezen, met de risico's die daarbij horen. Je kunt een eigen API-laag bovenop het systeem bouwen, zodat andere toepassingen via een stabiele ingang werken en het oude systeem later vervangen kan worden zonder dat de rest merkt. En als het systeem zelf het probleem is, kom je uit bij replatforming van verouderde software.

Van ontsloten data naar bruikbare data.

Ontsloten data is nog geen bruikbare data. Gegevens uit verschillende bronnen gebruiken vaak andere codes, andere schrijfwijzen en andere definities van hetzelfde begrip. Een actieve relatie betekent in het CRM iets anders dan in het ERP. Voor stamgegevens zoals relaties, leveranciers en artikelen leg je die definities vast met master data management.

Daarom volgt op ontsluiten bijna altijd een stap van vertalen en controleren. Welke gegevens dubbel voorkomen en waar de verschillen zitten, laat zien hoe diep de datasilo's in je landschap zitten, en hoe het staat met de datakwaliteit. Hoe je bronnen daarna blijvend samenbrengt, valt onder data-integratie.

Kort samengevat.

Data ontsluiten is het beschikbaar maken van gegevens uit een bronsysteem voor andere toepassingen. De vier routes zijn een API, directe toegang tot de database, exportbestanden en een middlewarelaag. De keuze tussen realtime en batch hangt af van hoe actueel de gegevens moeten zijn. Let op de belasting van het bronsysteem, op monitoring en op rechten, want daar gaat het in de praktijk het vaakst mis.