Data Integration Services
Connect business systems without losing control of the data.
Integrate ERP, operational, cloud and reporting platforms through governed, monitored and supportable data flows.
Discuss this requirement →Start with the environment, risk and required outcome.
Integrate ERP, operational, cloud and reporting platforms through governed, monitored and supportable data flows. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
The integration methods and where each belongs
| Method | How it works | Latency | Suits |
|---|---|---|---|
| Batch file exchange | Scheduled export and import, usually flat files | Hours | Legacy systems, third parties, anything without an interface |
| Database to database | Direct extraction from the source database | Minutes to hours | Systems you control, where vendor support permits it |
| API integration | Calls against the vendor’s published interface | Minutes | Modern SaaS platforms and anything with a supported API |
| Change data capture | Reading the database transaction log | Near real time | High-volume sources where extraction load matters |
| Message queue | Events published and consumed | Seconds | Genuine event-driven requirements, which are rarer than proposed |
Latency requirements are usually overstated. Near-real-time integration costs considerably more to build and to operate than an hourly batch, and the number of business decisions that genuinely change because data is four minutes old rather than forty is small. Establish what the decision actually needs before designing for it.
Vendor support position matters. Reading directly from a vendor’s application database is frequently faster to build and frequently unsupported, which becomes a problem at the next upgrade. Where a supported API exists, use it even where it is slower.
What makes system integration hold up
Reconciliation
Both sides agree on counts and totals, checked automatically, with a reported variance. Integration without reconciliation is an assumption that runs on a schedule.
Idempotency
Re-running after a failure must not duplicate. This is the single most common defect in integrations we inherit and it surfaces as duplicate transactions nobody can explain.
Error handling that separates records
One malformed record should not stop the batch. Route the failures to an error queue with enough detail to correct them, process the rest and report what was held back.
Watermarking
The integration knows where it stopped and resumes from there, rather than reprocessing everything or guessing.
Interface documentation
What connects to what, in which direction, on what schedule, owned by whom. Undocumented integrations are the reason system replacements take longer than planned, because nobody knows what will break.
Master data
The problem underneath most integration work.
Two systems each hold a customer record. The identifiers differ, the names differ slightly, one has an address the other does not. Joining them requires a decision about which is authoritative and how they match.
Decide the system of record per entity
Customer, product, supplier, employee, cost centre. One system is authoritative for each and the others receive.
Matching rules, written down
Exact match on an identifier where one exists. Fuzzy matching only where it must be, with a manual review queue for anything below the confidence threshold, because automated fuzzy matching quietly merges records that should be separate.
A survivorship rule
When two records disagree, which wins, per field.
This is unglamorous and it is the difference between an integration that produces trustworthy joined data and one that produces plausible joined data. Plausible is worse, because it gets used.
What Namandla delivers
Integration design across batch, database, API, change data capture and messaging. Source system analysis and supported-access assessment. Reconciliation and variance reporting. Error handling and correction workflow. Master data and matching rule design. Interface documentation and register. Ongoing operation under managed data services.
Remote delivery nationally. Onsite in Gauteng where source system access needs it.
Common questions about Data Integration
What are data integration services?
Data integration services connect separate systems so data can move between them or be combined for reporting, using batch exchange, direct database access, APIs, change data capture or messaging depending on the systems involved.
The work is less about the transport than about the agreement: which system is authoritative, how records match, what happens when they disagree and how both sides prove they are in step. Transport is the straightforward part.
Do we need real-time integration?
Usually not. Near-real-time costs considerably more to build and operate, and few business decisions genuinely change because data is four minutes old rather than forty.
Establish what the decision on the receiving end actually requires. Where it is a dashboard reviewed each morning, hourly or daily batch is correct and cheaper. Where it is an operational process that acts within minutes, near-real-time is warranted and worth paying for.
Can you integrate with our ERP?
Generally yes. The approach depends on what the vendor supports: a published API, a supported extraction method, a reporting replica or, as a last resort, direct database access.
Direct database reads against a vendor application are often technically easy and unsupported, which becomes a problem at the next upgrade when the schema changes. We establish the supported path first and use it where it exists, even where it is slower to build.
What is master data and why does it keep coming up?
Master data is the core entities several systems share: customers, products, suppliers, employees, cost centres. It comes up because joining data across systems requires deciding which system is authoritative and how records in each are matched.
Without those decisions, joined data is plausible rather than correct, which is worse than obviously wrong because it gets used. Deciding the system of record per entity, writing down the matching rules and setting a survivorship rule for conflicts is the foundation of any integration that spans systems.
How do we know an integration is working correctly?
Reconciliation. Both sides agree on counts and totals, checked automatically on every run, with variance reported.
Integration without reconciliation is an assumption running on a schedule. The failure mode is not a crash, it is a slow divergence where a few records fail each day and nobody notices until the difference is large enough to be visible in a financial report.
We have integrations nobody documented. Can you help?
Yes, and building the interface register is usually the first piece of work. What connects to what, in which direction, on what schedule, owned by whom.
This becomes urgent when a system is being replaced, because undocumented integrations are what makes replacements overrun. Discovering them during a cutover is considerably more expensive than mapping them beforehand.
When is integration the wrong answer?
When the requirement is actually reporting rather than data movement. If you need to see data from two systems together, a warehouse reading from both may serve better than integrating them with each other.
Point-to-point integrations accumulate. Six systems fully integrated is fifteen connections to maintain. Where the need is analytical rather than operational, routing everything into a warehouse is fewer moving parts and easier to reason about. Covered on data warehousing.