Many boards think their systems are connected, while in practice separate links run that don't quite complete each other. This article walks through four quiet signs that "everything is connected" isn't yet a reality in your organisation: the difference between protocols, how security and access are set up, what real connection actually delivers, and how to start with one thin flow instead of everything at once.
Kees Pronk
CEO
Many boards think their systems are connected, while in practice separate links run that don't quite complete each other. A system integration is what lets different software systems exchange data automatically, without manual copy-paste work. At Impacture we see it every day: companies who believe their integrations are complete, until a report somewhere doesn't add up.
Not every integration works the same way, and that difference often explains why "everything's connected" still grates. With sFTP (a secure file transfer protocol) systems exchange files at fixed times, while an API (an interface that lets systems request data in real time) responds directly to a request.
EDI (Electronic Data Interchange, the automatic exchange of structured messages between companies) and UBL (a universal invoice format) are typical for integrations between organisations, for example in procurement or invoicing. AS2 and SMTP handle the transport layer beneath that: how the message travels safely from A to B. Pick the protocol based on the speed the process needs, not based on whatever happens to be running already.
An integration without proper access control isn't really an integration, it's a leak in the making. Make sure every connection runs over secure channels with encryption, not via a loose password that three people happen to know.
Set up row-level security (security that decides which data rows a user is allowed to see) so an employee only sees what is relevant for their role. Tie single sign-on (SSO, one login for multiple systems) to your Azure AD environment, so access stays centrally managed rather than scattered across separate accounts per system. This is exactly where many integrations look complete on paper but aren't set up in practice.
The real benefit of connecting data sources isn't in the technology itself, but in what you can do with it. Reusing data from multiple systems prevents the same customer details being typed in three times, with three chances of error.
Automatic synchronisation between source systems and your platform means a change in one system flows straight through to the other. No more manual export-import, no forgotten update. That's the difference between "we have an integration" and "our data is always right".
Building a system integration doesn't start with the technology, but with a question: which flow has the biggest impact when it's right? Ask yourself as a board things like: where does an error or delay already lead to extra work or an unhappy customer, which report do you most often have to correct by hand, and which data are we already sharing with customers or partners without the source being unambiguous? Pick one thin flow from source to outcome, instead of connecting everything at once.
Build with DTAP environments (Development, Test, Acceptance, Production, separated environments for testing changes safely) so a change is tested first before it hits production. Without that separation, data drifts quietly, and you only notice when a report has been slightly off for months. Then expand per new question, not for the whole platform in one go.
At Runderkamp, active in food retail and catering, connecting around 1,400 products and PLUs to some 170 suppliers created a central overview that previously only lived in scattered spreadsheets. Four DTAP environments kept that integration stable, even as it expanded.
At CentreBlock, active in marketing intelligence, more than a million visitor records and eleven KPIs moved from separate exports to standardised reporting. What used to take days now takes minutes, thanks to an integration that was set up on governance from the start.
A system integration, then, is more than a technical link between two systems. Only once protocols, security and governance line up properly can you say your data is really connected. Not sure whether that's the case in your systems? Book a Discovery Call and we'll take a look together.
Author
CEO
Storage keeps the data. Semantics records what it means. A data project that only looks at tables gets stuck on interpretation differences between departments.
Kees Pronk
CEO
Full database access is not enough. Without semantic context, an AI fills meaning gaps itself and still gives the wrong answer.
Kees Pronk
CEO
A semantic layer ties technical fields to business definitions, so terms like revenue and active customer mean the same thing everywhere. Without it, an AI agent quietly keeps calculating on outdated rules.
Kees Pronk
CEO
