Business promise
One source of truth instead of ten customer copies
This page is about turning data from a side effect of systems into a managed product with owners, contracts and lineage.
We connect ERP, CRM, ECM and dozens of internal systems into a managed data architecture. No single points of failure, no point-to-point chaos.
System integration is not "configure an API between two systems". It is an architectural discipline that turns the client's system zoo into a coherent environment with a single source of truth, predictable event delivery and transparent data lineage.
Master Data Management (MDM) and Data Governance are mandatory parts. Without them, AI projects, analytics and digital products start with garbage-in and exit as garbage-out.
This page is about turning data from a side effect of systems into a managed product with owners, contracts and lineage.
Product, analytics, compliance and AI teams suffer from the same cause: no agreed master entities and no clear data flows.
We do not start with an ESB or MDM vendor. We first map the system landscape, data owners, duplicates and integration contracts.
Master Data Management is first an organizational decision, then a technology choice. Before launching a tender for an MDM platform, we help identify the data owner on the business side.
Buying an ESB "to grow into" for an organization with 4 systems is guaranteed overengineering. We are honest about when an ESB is not needed.
This is not a bug — it is a natural consequence of how enterprise environments evolve. If your data looks "clean", you simply have not analyzed it.
It is more honest to say "you do not need this yet" than to sell an engagement that will not deliver ROI.
Inventory of systems and data flows, duplicate and conflict detection, mapping of master entities (customer, product, account), assessment of documentation state.
Choosing the MDM model (registry / consolidate / hub), event-driven architecture via Kafka or ESB, API contracts, governance scheme.
Implementing MDM for one master entity (usually customer) across 2–3 systems. Proves the architecture at production quality without breaking everything at once.
Phased expansion to remaining systems and entities. Each new integration is a separate sprint with visible business outcome.
Regular data quality reviews, lineage monitoring, anomaly escalation. Without this MDM degrades to the same state within 2 years.
Project lead: Data Management IG (MDM, governance, data lineage).
Brought in when needed: InBase (UnityBase for master-data hub), SL Global Service (integration infrastructure).
Buy an MDM platform and tell IT to "implement it". IT delivers the technical part in 3 months. The business spends 9 more months figuring out whose customer record is "the right one" — CRM or billing.
What we do instead: we appoint a Data Steward on the business side before any technical work begins.
An ESB platform is bought "to grow into". 4 systems are integrated — overengineering is visible to the naked eye. Support costs more than it saves.
What we do instead: for <5 systems we recommend point-to-point or a lightweight integration layer like n8n/Make.
The plan: switch all systems to the new MDM during a Friday-Sunday production downtime. Reality: on Monday, 30% of users cannot find their data.
What we do instead: parallel run of old and new systems for at least 30 days. Switchover is phased by user segment.
Systems are integrated "as they came together". A format change in one system breaks three others. Every change is a release incident.
What we do instead: we formalize data contracts via schema registry. Contract changes go through review before release, not after.
Each example shows the client-side story: what was getting in the way, what changed, and what result the team got.
Nine recent expert articles — from thematic overviews to specific architectural decisions.
Informatica MDM · Reltio · Profisee · UnityBase (InBase) · Talend MDM · IBM InfoSphere
Apache Kafka · RabbitMQ · MuleSoft · WSO2 · Apache Camel · Tibco BusinessWorks
Kong · Apigee · AWS API Gateway · Azure API Management · WSO2 API Manager
Talend Data Quality · Informatica Data Quality · Collibra · Alation · Atlan
Airflow · dbt · Fivetran · Talend · Apache NiFi · Pentaho
ISO/IEC 27001 · DAMA-DMBOK · GDPR · DCAM · ArchiMate
A data warehouse is for analytics (read-only, historical data). MDM is for operational use (single source of truth that updates in real-time and propagates back to source systems). Different jobs, not alternatives.
Pilot on one master entity — 3–4 months. Full implementation for tier-1 enterprise — 12–18 months. If you are promised "MDM in 2 months", that is a 1C-style rewrite, not MDM.
Kafka — when you need event history (replay, audit) and throughput >100k events/sec. RabbitMQ — for classic queue scenarios with low latency. For most enterprise scenarios — Kafka, because regulator audit requirements rule out RabbitMQ.
Data Mesh pays off for organizations with 5+ data domains and autonomous product teams. If you have centralized analytics and one team — it is overengineering.
A person from the business side (not IT) responsible for defining the rules for a specific master entity. The Customer Steward decides whose record is "right" when CRM and billing conflict. Usually 20–40% of an existing employee's time, not full-time.
Three options: (1) database-level integration via CDC (Change Data Capture); (2) screen scraping via RPA (temporary); (3) facade service over legacy. The choice depends on risk tolerance and time until planned legacy decommissioning.
Real projects rarely fit in one competency. See which other areas we work in.
30-minute discovery call. We will discuss your architecture and whether we have something to offer — no commitments.
Intecracy Group does not force a single delivery team. We clarify the task, identify the required competencies and help involve the relevant alliance members.