Data- en integratieplatform voor de voedingsindustrie

Samenvatting

Een middelgroot productiebedrijf in de voedingsindustrie migreerde van on-premise ERP naar Dynamics 365 Business Central in de cloud. De BC365-data was daarna niet ontsloten voor BI en rapportage. House of Data ontwierp en beheert het complete data- en integratieplatform: een Microsoft Fabric Lakehouse met near-realtime dataspiegeling, een Azure API Management-laag als centrale integratiehub, en de architectuurcoordinatie over zes betrokken leveranciers.

Aspect	Voor	Na
BC365-data in BI	Niet beschikbaar	Near-realtime (elke 10-15 minuten)
Integratiepatroon	FTP/CSV batch, point-to-point	API-first, event-driven via APIM
Monitoring & audit trail	Geen	Volledige logging via Application Insights
Architectureel eigenaarschap	Verdeeld over 6 leveranciers	Centraal bij House of Data

Situatie

Het bedrijf - circa 200 medewerkers, meerdere productielijnen - stond op een kantelpunt. De migratie van het on-premise ERP-systeem naar Dynamics 365 Business Central (BC365) in de cloud was afgerond. Maar de data uit BC365 was niet ontsloten. BI-tooling had geen toegang tot de ERP-data. Er waren geen datapipelines, geen rapportages op actuele bedrijfsdata.

Daarnaast wisselde het MES-systeem op de productievloer gegevens uit met BC365 via handmatige CSV-exports en FTP-transfers. Het planningsysteem haalde productieorders op via een eigen koppeling. Externe partners leverden data aan via vergelijkbare batch-mechanismen.

Het landschap bestond uit zes leveranciers: de ERP-leverancier die BC365 beheerde, een BI-partner voor rapportages, een systeembeheerpartner voor de infrastructuur, een leverancier voor productieautomatisering, een programmanagementpartij, en House of Data als platformarchitect.

Geen van deze partijen had overzicht over het geheel. Elke leverancier optimaliseerde zijn eigen component. Niemand bewaakte de samenhang.

Uitdaging

De problemen waren structureel, niet incidenteel.

BC365-data niet ontsloten. Na de migratie naar de cloud was de ERP-data niet toegankelijk voor BI-tooling en rapportage. Er bestond geen datapipeline om BC365-data beschikbaar te maken voor analyse. De organisatie vloog blind op operationele data.

Fragiele integraties. De koppelingen tussen systemen waren historisch gegroeid. FTP-servers fungeerden als integratiepunt. CSV-bestanden werden op vaste tijdstippen gedropt en opgepikt. Er was geen foutafhandeling, geen monitoring, geen audit trail. Als een bestand niet aankwam, merkte niemand het tot de eindgebruiker klaagde over ontbrekende data.

Authenticatie-wildgroei. Elk systeem had een eigen authenticatiemechanisme. BC365 vereiste OAuth2 met token-refresh. Het MES-systeem ondersteunde uitsluitend API-keys. Het planningsysteem werkte met basic authentication. Credentials lagen verspreid over configuratiebestanden bij verschillende leveranciers.

Geen architectureel eigenaarschap. Zes leveranciers, elk met eigen scope, eigen planning, eigen prioriteiten. De klant had geen interne IT-architectuurcapaciteit om deze partijen aan te sturen. Beslissingen over de datalaag werden genomen door partijen die de datalaag niet als hun verantwoordelijkheid zagen.

Aanpak

House of Data nam de rol van platformarchitect op zich: het ontwerp, de realisatie en het doorlopend beheer van het data- en integratieplatform, plus de coordinatie van alle betrokken leveranciers.

BC365-data ontsluiten: van Synapse naar Fabric Open Mirroring

De eerste prioriteit was het ontsluiten van BC365-data voor BI en rapportage. Op dat moment ondersteunde Fabric nog geen Open Mirroring voor BC365. We ontwierpen daarom een pipeline op basis van de beschikbare technologie: bc2adls exporteerde CDC-deltas naar Azure Data Lake Storage, Synapse Spark consolideerde die deltas, Azure Data Factory orkestreerde het laden, en een SQL Warehouse diende als querylaag. Data werd elk uur ververst.

Die oplossing werkte, maar was bewust pragmatisch: vijf componenten, elk met eigen faalgedrag. Toen Fabric Open Mirroring beschikbaar kwam (bc2adls versie 26.32+), migreerden we naar de eenvoudigere architectuur. BC365-data wordt nu rechtstreeks opgepikt door een Fabric Lakehouse, zonder Spark-consolidatie en zonder ADF-orchestratie.

Dit vereiste coordinatie met de ERP-leverancier voor de upgrade van de bc2adls-extensie in BC365. Technisch niet complex, maar organisatorisch een afstemming die zonder centraal architectuuroverzicht niet zou zijn geinitieerd.

Het resultaat: een architectuur van twee componenten in plaats van vijf. BC365-data is beschikbaar in het Fabric Lakehouse binnen 10 tot 15 minuten na mutatie. Het SQL Analytics Endpoint wordt automatisch gegenereerd - BI-tools kunnen direct verbinden zonder handmatige view-definities.

Azure API Management: de integratiehub

De tweede pijler was het vervangen van de FTP/CSV-integraties door een API-first architectuur met Azure API Management (APIM) als centrale gateway.

APIM fungeert als vertaallaag en beveiligingsgrens:

• Het MES-systeem stuurt REST-requests naar APIM met een API-key. APIM valideert de key, wisselt deze in voor een OAuth2 Bearer token bij BC365, en forwardt het request. Het MES-systeem hoeft niets te weten over OAuth2-flows.
• Het planningsysteem haalt productieorders op via dezelfde gateway, met eigen rate limits en toegangsrechten. Alleen GET-requests zijn toegestaan; schrijfoperaties zijn geblokkeerd op policy-niveau.
• Webhooks vanuit BC365 worden ontvangen door APIM en doorgerouteerd naar de relevante consumenten. Waar voorheen een scheduled batch draaide, wordt nu event-driven gewerkt: data wordt gepusht op het moment van wijziging.
• Externe partners krijgen toegang via API-keys met strikte rate limits en scope-beperkingen. Elke call wordt gelogd in Application Insights.

De FTP-servers zijn uitgefaseerd. Geen CSV-bestanden meer die ergens in een map staan te wachten. Geen cron-jobs die op vaste tijden draaien en stilzwijgend falen.

Multi-vendor coordinatie

De architectuurrol omvatte meer dan technisch ontwerp. Bij zes leveranciers is afstemming het verschil tussen een werkend platform en een verzameling losse componenten.

Concreet betekende dit:

• Architectuuroverzicht bewaken. Elke wijziging die een leverancier voorstelde - een nieuwe koppeling, een schema-aanpassing, een infrastructuurwijziging - werd getoetst aan de overkoepelende architectuur. Niet als poortwachter, maar als de partij die ziet hoe de stukken samenhangen.
• Technische specificaties opstellen. API-contracten, datamodellen, authenticatie-eisen - House of Data definieerde deze en zorgde dat alle partijen dezelfde specificaties hanteerden.
• Escalaties voorkomen. Wanneer de ERP-leverancier een schema-wijziging doorvoerde die downstream gevolgen had, was House of Data de partij die dat signaleerde voordat het een productiestoring werd.

Resultaat

Het platform draait in productie en wordt doorlopend beheerd door House of Data.

BC365-data ontsloten. Voor het eerst heeft de organisatie toegang tot actuele ERP-data in BI-tooling. Operationele dashboards zijn bruikbaar geworden doordat data binnen 10 tot 15 minuten beschikbaar is in het Fabric Lakehouse.

Betrouwbare integraties. Elke API-call wordt gelogd, gemonitord en beveiligd. Rate limiting voorkomt dat een enkel systeem de backend overbelast. De OAuth2-vertaallaag elimineert credential-spreiding. En als iets faalt, is dat zichtbaar - niet stilzwijgend.

Architecturele eenvoud. Een datapipeline van twee componenten. Een centrale integratiehub in plaats van point-to-point spaghetti. Minder bewegende delen betekent minder faalplekken, minder onderhoud, en snellere doorlooptijd bij wijzigingen.

Een aanspreekpunt voor de datalaag. De klant heeft niet langer zes leveranciers nodig om een datavraag te beantwoorden. House of Data fungeert als het architectureel geweten van het platform - de partij die weet hoe de stukken samenhangen en die de samenhang bewaakt.

Geleerde lessen

Bouw met wat beschikbaar is, vereenvoudig zodra het kan. De Synapse-route was de juiste keuze op het moment dat we begonnen - Open Mirroring bestond nog niet. Maar we hielden de architectuur onder review. Toen de eenvoudigere optie beschikbaar kwam, migreerden we. Pragmatisme bij de start, discipline om te vereenvoudigen wanneer het kan.

FTP is geen integratiestrategie. CSV-bestanden via FTP uitwisselen werkt - tot het niet werkt. En wanneer het niet werkt, weet niemand het. De overgang naar API-first integraties was niet alleen een technische verbetering, maar een fundamentele verschuiving naar zichtbaarheid en beheersbaarheid.

Multi-vendor landschappen vereisen een architect. Zes leveranciers zonder overkoepelend architectuuroverzicht leidt tot lokale optimalisaties die globaal suboptimaal zijn. Iemand moet de samenhang bewaken. Niet als projectmanager, maar als technisch architect die de consequenties van keuzes overziet.

Begin bij de organisatie, niet bij de technologie. De bc2adls-upgrade was technisch triviaal maar organisatorisch de bottleneck. De APIM-implementatie was technisch straightforward maar vereiste buy-in van vijf leveranciers. De technologie was het makkelijke deel. De coordinatie was het echte werk.