Integration vendors now present iPaaS, event streaming and AI as a single wave that replaces the way systems used to be connected. The three address different parts of the problem, and each leaves a different part of it with your team. Treated as one thing, they produce a modern platform running the same fragile design as the old nightly scripts, with a larger invoice attached.
Three shifts sold as one
It is worth separating the three before evaluating any of them. An iPaaS changes where integrations run and who maintains the plumbing. Event-driven design changes when data moves and which system decides that it should. AI assistance changes how mappings and anomalies are found, but leaves the decision about them with a person.
None of the three changes the underlying question, which is who owns each piece of data and who is responsible when a flow fails. A company that has answered that question can adopt any of these shifts with modest risk. A company that has not will find that each of them makes the unanswered question more expensive, because there are now more flows, running faster, with less human attention on each.
What an iPaaS takes off your hands
An integration platform as a service (iPaaS) is a hosted platform for building and running integrations. It comes with prebuilt connectors for common SaaS products such as Salesforce, Workday, SAP, HubSpot and Zoho, a low-code flow builder, and one screen for watching runs.
What it removes is plumbing. Authentication, API paging, retries, token refresh and hosting are handled for you. What it does not remove is the decisions. Someone still has to define how a Workday employee maps to an SAP record, what happens when a field is missing, and who looks at a failed run in the middle of the night.
Consider a D2C brand that connects its own store, a marketplace feed and Zoho Books through an iPaaS. The connectors are live in an afternoon. What to do when a marketplace order arrives with a pin code the warehouse does not serve is not a connector question, and the platform will pass that order straight through unless someone has written the rule. The iPaaS hosts the rule; it does not supply it.
Events in place of nightly batches
Older integrations moved data in batches: an overnight sync, a periodic export, a CSV emailed at month end. Event-driven design publishes a fact when it happens, such as an order placed, a payment declined or a UPI settlement received, and lets other systems react to it. A payment service publishes a payment event, and a fraud check consumes it before the order ships, in place of finding it in a report the next morning.
- Order service
- Fraud check
- Inventory
- Notifications
- Reporting
The order service does not know who consumes its events, so consumers can be added without changing it.
The trade-off is that you are now operating asynchronous systems, which is a different discipline. Messages arrive twice. They arrive out of order. A consumer that was down for an hour has to catch up without double-counting anything. Consumers must therefore be written so that handling the same event twice does no harm.
Event formats also need an owner, because renaming one field breaks every subscriber at once. In my view the first question in an event-driven design is who owns the order event schema; which broker to use comes some way after it. A schema with an owner and a version rule can survive a change of broker. A broker with unowned schemas will be a source of incidents whichever product it is.
AI assistance is a suggestion engine
The claims made for AI in integration fall into four groups: suggested field mappings between systems, recommended automations based on how flows are used, anomaly detection on data in transit, and pairing with robotic process automation (RPA) for steps that involve people. Each of these is a suggestion engine, and each has a weak point worth naming.
A mapping suggestion that looks plausible but is wrong does not fail loudly; it writes bad data quietly until an accountant notices during GST filing. Anomaly detection needs a baseline of normal behaviour, and a new flow has none, while a flow whose baseline was learnt during Diwali week will misjudge February. Classifying inbound documents, such as supplier invoices or customer correspondence, raises the question of where the content is sent to be classified and who may see it there. Every suggestion needs a person to accept or reject it, and that review time is a real part of the cost.
Data quality sits underneath all four. An engine reading messy records suggests messy mappings. If you plan to use any of this, keep a small set of records that people have verified by hand, and run every suggested change against it before it touches live data. Where a step needs judgement rather than a fixed rule, our piece on when a task needs an agent and when a workflow is enough sets out the distinction. Cost is the other recurring surprise; model calls, platform run counts and event storage all grow with volume, so estimate them from a busy festive-season week and not from the demonstration.
How teams misuse all three
The pattern I see most is rebuilding the old point-to-point web inside the new platform, flow by flow, so that the integration diagram looks like the one from five years ago with a different logo on it. The platform changed and the design did not. The middleware layer has the same failure modes it always had, which our piece on what integration middleware does and where it breaks describes in detail.
The second is making everything real time. A sales report that a regional head reads once a day does not need an event stream, and streaming it costs money every hour. The third is publishing events with no schema owner and no version rule, which works until the second consumer joins. The fourth is accepting AI-suggested mappings in bulk without checking a sample against real records. The fifth is counting only the licence and forgetting that someone has to watch the runs and handle the failures, which is a person's time every week for as long as the flows exist.
Deciding per flow
- 01Can it wait?A day is fine: batch
- 02Must others react?Publish an event
- 03Standard SaaS apps?Use an iPaaS connector
- 04Repetitive mapping?Suggest, then review
Answer in order for each flow, and never once for the whole company.
These questions apply to each flow, not to the company as a whole. An NBFC can reasonably run batch exports for its month-end finance pack, events for disbursement and repayment, and an iPaaS for its HR and marketing tools, all at once. That is a coherent design, because each flow was given the mechanism that fits it.
Take one flow you plan to rebuild this quarter and answer the questions above for it, along with two more. Who owns the data it carries? Who is alerted when it fails? If those answers are not yet available, the platform choice is premature, and our enterprise application integration work would start there. The platform you choose this year will probably be replaced within a decade; the ownership rules and event schemas you define will outlast it, and they are what the next migration will depend on.
