--- title: "Systems Integration: Connecting The Systems AI Depends On" description: "How systems integration works, the patterns to choose from, why ERP integration is hard, and how a governed foundation gives AI controlled access." canonical: https://shipshapedata.com/resources/data-architecture/systems-integration/ language: en-GB author: "Emile Van Zyl" author_role: "MarTech Automation Consultant" author_url: https://www.linkedin.com/in/emile-vanzyl-enhancing-your-human-advantage/ date_published: 2026-11-03 date_modified: 2026-11-03 --- # Systems integration: connecting the systems AI depends on > How systems integration works, the patterns to choose from, why ERP integration is hard, and how a governed foundation gives AI controlled access. Section: Home > Resources > Data & architecture Canonical page: https://shipshapedata.com/resources/data-architecture/systems-integration/ By Emile Van Zyl, MarTech Automation Consultant (https://www.linkedin.com/in/emile-vanzyl-enhancing-your-human-advantage/) | published 2026-11-03 Your finance team exports from the ERP every Monday. Sales works from the CRM, the warehouse runs its own system, and someone reconciles the three in a spreadsheet before the board meeting. Each system works on its own terms. The trouble starts when a report, an automation or an AI model needs them to agree. Systems integration is the work of connecting separate applications, such as an ERP, a CRM and operational systems, so they exchange data and act as one coordinated whole. Done well, the systems agree on the records they share. For AI, that agreement matters more than the connections themselves, because a model repeats whatever disagreement it finds. Shipshape Data builds data foundations and the AI that runs on them. This guide is for the person who has been asked to make the systems talk to each other, often because an AI programme depends on it. It covers the main integration patterns, why ERP integration is usually the hard part, how systems integration differs from data integration, and what changes when the consumer is a model rather than another application. ## What systems integration means Systems integration means connecting the applications an organisation runs so that information entered in one is available, correct and usable in the others. The applications are usually familiar: an enterprise resource planning (ERP) system for finance, stock and orders; a customer relationship management (CRM) system for sales and service; a warehouse management system; a helpdesk; payroll; and a few specialist tools that one department chose for itself. A simple example shows the scope. A salesperson closes a deal in the CRM. The order needs to appear in the ERP so it can be invoiced, the warehouse system needs to know what to pick, and finance needs the revenue in the right period. Without integration, someone retypes the order three times. With integration, the order is entered once and each system receives what it needs. The term covers three kinds of work that often get mixed together: - Application integration: an event in one system triggers an action in another, usually through APIs or an integration platform. - Data integration: data from several systems is combined into one consistent view for reporting, analysis or AI. - Legacy integration: older, often on-premise systems are bridged to newer cloud applications, usually by working around limited interfaces. A systems integrator is the person or team that designs these connections, builds them and keeps them running. The role is part architecture and part negotiation, because each system has an owner with their own priorities. When integration is missing or partial, the result is the familiar pattern of data silos: each team holds its own version of the facts and trusts nobody else's. ## The main integration patterns There are four broad ways to connect systems. Most organisations run a mix of all four, built up over years, and the mix itself is often the problem. ### Point-to-point connections Each pair of systems is wired directly together with a custom script or a built-in connector. It is quick for the first two or three systems and needs no extra platform. The cost grows with every system added, because each new application may need a connection to every existing one. When one system changes its fields, several connections break at once, and few of them are documented. ### Middleware and integration platforms A central layer sits between the systems and routes messages between them. Older designs call this an enterprise service bus; newer cloud products are sold as integration platform as a service. Each system connects once, to the middle, which reduces the number of connections and gives one place to monitor them. The risk is that business logic gathers in a tool few people understand, and every change waits for the same small team. ### API-led integration Each system exposes a defined interface that other systems call to read or write data. Well-designed APIs make the contract between systems explicit: what can be requested, in what format and with what permissions. Modern cloud applications are built this way. Older ERP and on-premise systems often are not, or their APIs cover only part of what the business needs. ### Warehouse-centred integration Data from every source system is copied into a central cloud data warehouse, cleaned and modelled there, and served from one place to reports, applications and models. This pattern suits analysis and AI rather than real-time transactions. It does not replace the operational connections that move an order from CRM to ERP, but it gives the organisation one agreed version of the data those systems hold. Our guide to data ingestion covers how the data gets there. > Connections tell you that data moved. They do not tell you that the systems agree. ## Why ERP integration is usually the hard part The ERP is normally the system of record for money, stock and orders. Every other application wants to read from it or write to it, and it is usually the hardest one to connect. The same four problems come up in most organisations. ### Years of customisation Most ERPs have been configured and extended over many years. Custom fields, local codes and modified workflows mean the vendor's standard connector covers only part of the real system. The integration has to reflect how the business uses the ERP, not how the manual describes it. ### Master data that does not match The ERP and the CRM both hold customer records, and they rarely agree. One system has a parent company and three trading names; the other has five accounts for the same organisation with different spellings. Product codes, units of measure and cost centres drift in the same way. Until someone decides which record is the master, an integration only moves the disagreement faster. Master data management is the discipline that settles this. ### Timing and period close Finance runs on periods. An order booked in the CRM on the last day of the month may land in the ERP the next morning, in the wrong period. Overnight batch jobs, adjustments after close and late credit notes all create gaps between what the systems show at any moment. ### Ownership and change control The ERP usually belongs to finance or a central IT team, and changes go through a careful process for good reasons. An integration that depends on a field nobody agreed to keep stable will break at the next upgrade. Writing the agreement down as data contracts between the producing and consuming teams is what keeps an ERP integration working after the people who built it move on. ## Systems integration and data integration The two terms overlap and are often used as if they were the same. They answer different questions. - Systems integration asks whether the applications can work together: does an event in one system cause the right action in another, at the right time. - Data integration asks whether the data from those applications can be combined into one consistent whole: do the customer, product and revenue figures agree once they sit side by side. Systems integration is mostly operational. It keeps orders flowing, invoices raised and stock updated. Data integration is mostly analytical. It produces the single view that reports, forecasts and models rely on. Our guide to what data integration involves covers its techniques in detail. You need both, and each depends on the other. Operational integration that writes inconsistent records into the ERP produces inconsistent analysis downstream. Data integration that exposes the inconsistency gives you the evidence to fix the operational connections. Treat the shared definitions, what counts as a customer, an order or a booked sale, as one piece of work owned across both. ## Integration for AI: governed access over copies Traditional systems integration wires applications to each other. For AI, the question changes. A model that answers questions about orders, drafts a reply to a customer or forecasts demand reads data from several systems at once, and it needs those systems to agree. If the CRM says an account is active and the ERP says it is on hold, the model will give a confident answer based on whichever record it saw first. The tempting route is to connect the model directly to each system, or to copy extracts into a separate store for the AI to read. Both repeat the point-to-point problem with higher stakes. Copies drift from the source within days. Direct connections give the model whatever access the connecting account has, often far more than it needs, with no clear record of what it read. ### A governed foundation first The alternative is to build the agreement once, in a central foundation, and let models reach it through controlled routes. Data from the ERP, CRM and operational systems lands in a cloud data warehouse and is cleaned in stages, from bronze to silver to gold, using a medallion architecture. A semantic layer then gives one governed definition of every business term, so revenue means the same thing to the finance dashboard and to the model. Our guide to AI-ready data sets out how to test whether you are there. ### Controlled routes such as MCP Model Context Protocol (MCP) is an open standard for connecting AI models to tools and data. Placed over a governed foundation, an MCP server lets a model query only the data it is permitted to see, apply the business logic the organisation has agreed and leave an auditable record of each request. The model reaches governed data without a copy being made somewhere ungoverned. Grounded applications depend on this. At Slimstock, a custom AI chat interface answers from the company's own content and provides 24/7 support in 11 languages. That result rests on the content being current and reachable through a governed route, not on the chat interface alone. > Build the agreement once, then let every system and model read from it. ## Choosing a system integration service A system integration service can mean anything from a contractor who writes connectors to a consultancy that redesigns how data moves across the business. Decide which problem you have first. If orders fail to reach the ERP, you need operational integration. If reports disagree and an AI programme is waiting, you need the systems to agree on shared data before anything else. A useful service should include the following: - An assessment first. The supplier maps your systems, the data each one owns and where they disagree before proposing a tool or pattern. - Agreed definitions and ownership. Shared terms such as customer, order and product get one definition and a named owner. - A pattern chosen for the job. The supplier explains the trade-off between point-to-point, middleware, APIs and a warehouse rather than selling one answer. - Reconciliation. Figures in source and target are checked against each other, not assumed to match because a job ran. - Data protection by design. For UK organisations, personal data moving between systems falls under UK GDPR, so the design records what moves where and why. - Governed access for AI. If models will use the data, the work covers access controls, business logic and lineage, not only connections. - Support after go-live. Integrations fail quietly when a field changes or an API is upgraded, so someone watches them and responds. Be wary of a supplier who will connect a model straight to the ERP without asking whether the data is ready. Sometimes the right answer is to fix the master data before building anything, and a supplier willing to say so is protecting your budget. If you are unsure where you stand, the free AI readiness assessment scores strategy, people, data and change on the spot, with no email gate. ## Where this leaves you Systems integration has moved on from wiring each application to the next. The connections still matter, because orders still need to reach the ERP. For reporting and AI, the more important question is whether your ERP, CRM and operational systems agree on the data they share, and whether a model can reach that data without bypassing your controls. Start with the disagreements. Map where the systems hold different versions of the same record, decide which is the master and write down the definitions. Then build the foundation that holds the agreed version and give models controlled routes into it. A first integration that settles one shared definition and supports one measurable use case will pay for the next. We build the governed foundation that your ERP, CRM and operational systems feed, and the controlled routes that let AI reach it. The data foundation covers the warehouse, medallion architecture and semantic layer; MCP connections covers the access controls, business logic and lineage between your data and your models. We scope first, build on governed data and stay past go-live, and we will tell you if a different route suits you better. Talk to us about where your systems disagree and what it would take to fix it. ## Frequently asked questions Systems integration is the work of connecting separate applications, such as an ERP, a CRM and operational tools, so they exchange data and work as one coordinated whole. It covers application integration, data integration and bridging legacy systems with cloud applications. Done well, the systems agree on the records they share, which matters for reporting and for any AI that reads from them. System integration connects applications so that information entered once reaches every system that needs it. For example, when a salesperson closes a deal in the CRM, an integration sends the order to the ERP for invoicing, to the warehouse system for picking and to finance for revenue reporting. Without it, staff retype the same order into each system, with a chance of error at every step. The ERP is usually the system of record for money, stock and orders, so most other applications need to read from it or write to it. That central role makes it the hardest system to connect. Years of customisation, master data that does not match the CRM, period-close timing and strict change control all have to be handled before an ERP integration can be trusted. A systems integrator designs, builds and maintains the connections between an organisation's applications. The work includes mapping which system owns which data, choosing an integration pattern, building connectors or APIs, checking that figures reconcile between systems and monitoring the connections after go-live. Good integrators also settle shared definitions and ownership, because connecting systems that disagree only moves the disagreement faster. Integration in IT systems means making separate applications work together. Systems integration focuses on whether applications trigger the right actions in each other, such as an order moving from CRM to ERP. Data integration focuses on combining their data into one consistent view for reporting, analysis and AI. Most organisations need both, and both depend on agreed definitions of shared terms such as customer and order. Systems integration and architecture together describe how an organisation's applications are connected and why. The architecture sets the pattern: point-to-point links, middleware, APIs or a warehouse-centred foundation. The integration is the work of building and running those connections. For AI, the architecture increasingly places a governed data foundation at the centre, with models reaching it through controlled routes such as Model Context Protocol (MCP). ## Frequently asked questions ### What is systems integration? Systems integration is the work of connecting separate applications, such as an ERP, a CRM and operational tools, so they exchange data and work as one coordinated whole. It covers application integration, data integration and bridging legacy systems with cloud applications. Done well, the systems agree on the records they share, which matters for reporting and for any AI that reads from them. ### What is system integration with an example? System integration connects applications so that information entered once reaches every system that needs it. For example, when a salesperson closes a deal in the CRM, an integration sends the order to the ERP for invoicing, to the warehouse system for picking and to finance for revenue reporting. Without it, staff retype the same order into each system, with a chance of error at every step. ### What is the role of ERP systems in systems integration? The ERP is usually the system of record for money, stock and orders, so most other applications need to read from it or write to it. That central role makes it the hardest system to connect. Years of customisation, master data that does not match the CRM, period-close timing and strict change control all have to be handled before an ERP integration can be trusted. ### What does a systems integrator do? A systems integrator designs, builds and maintains the connections between an organisation's applications. The work includes mapping which system owns which data, choosing an integration pattern, building connectors or APIs, checking that figures reconcile between systems and monitoring the connections after go-live. Good integrators also settle shared definitions and ownership, because connecting systems that disagree only moves the disagreement faster. ### What is integration in IT systems? Integration in IT systems means making separate applications work together. Systems integration focuses on whether applications trigger the right actions in each other, such as an order moving from CRM to ERP. Data integration focuses on combining their data into one consistent view for reporting, analysis and AI. Most organisations need both, and both depend on agreed definitions of shared terms such as customer and order. ### What is systems integration and architecture? Systems integration and architecture together describe how an organisation's applications are connected and why. The architecture sets the pattern: point-to-point links, middleware, APIs or a warehouse-centred foundation. The integration is the work of building and running those connections. For AI, the architecture increasingly places a governed data foundation at the centre, with models reaching it through controlled routes such as Model Context Protocol (MCP). --- Shipshape Data is a London AI consultancy: we build the data foundation your AI depends on, then the AI on top. Site guide for agents: https://shipshapedata.com/llms.txt | Contact: hello@shipshapedata.com