System integration through an iPaaS platform holds up when ownership is split by role: an integration architect designs the contracts, a platform owner sets the rules, domain teams answer for the data in their systems and operations handles monitoring and failures. Prebuilt connectors make integrations quick to build; they do not say who fixes them.
Quick Overview
What you will learn:
- What iPaaS is and why it moves integration work closer to the business
- Which roles an integration team needs and how to record them in a RACI matrix
- Why an OpenAPI contract is where teams meet
- Who owns monitoring, retries and error handling
Who this article is for:
- Architects and IT team leads rolling out an integration platform
- Owners of business systems that need to exchange data
- Administrators of low-code platforms and the people who set their rules
Reading time: 7 minutes
The Ownership Gap iPaaS Creates
The explainer on aws.amazon.com defines integration platform as a service as a cloud-based software model for integrating data from multiple applications. Typical capabilities include prebuilt connectors for popular applications and databases, field mapping between systems, flows triggered on a schedule, by an event or on demand, and a central dashboard for managing and monitoring integrations. The same page notes that SaaS administrators and business analysts can build most of the workflows they need without waiting for IT. It also states that AWS itself does not offer iPaaS services and points to Amazon AppFlow for moving data between SaaS applications and AWS.
That accessibility is the source of the governance problem. When people outside IT can wire systems together, flows multiply faster than anyone records who owns them. The first outage of a source system then reveals the gap: the platform vendor answers for the platform, not for the correctness of data moving between your own systems.
The Roles, Clearly Named
Whichever platform you choose, the split below tends to hold:
- Integration architect chooses patterns such as data synchronisation, event flows or API calls, designs contracts and prevents duplicate paths for the same data.
- Platform owner runs environments, permissions and connector rules, and keeps the integration catalogue.
- Domain team owns a source or target system and the meaning of its data, and gives advance notice of changes.
- Operations team responds to alerts, handles retries and routes data errors to the right domain team.
Microsoft’s Power Platform shows what the platform owner actually controls. Its data policies overview on learn.microsoft.com calls connectors strongly typed representations of RESTful APIs and describes data policies as guardrails against users unintentionally exposing organisational data. The connector classification page on the same site sorts connectors into Business, Non-Business and Blocked groups; a new policy starts with all connectors in Non-Business, and makers cannot build an app or flow that combines connectors from different groups. Deciding where a connector sits is deciding which data may be combined, which is why that decision needs a single owner.
Writing It Down: A RACI Matrix
A RACI matrix (Responsible, Accountable, Consulted, Informed) turns the split into something people can check:
| Activity | Integration architect | Platform owner | Domain team | Operations |
|---|---|---|---|---|
| API contract and data mapping | A/R | C | C | I |
| Connector and flow configuration | C | A | R | I |
| Change in a source system | C | I | A/R | I |
| Monitoring and alerting | I | A | I | R |
| Diagnosing and fixing a data error | C | I | A/R | R |
The rule that matters: each row has a single A. If the team cannot name that person, the integration has no owner, and the argument about responsibility will resurface at the first incident.
Contracts at the Seam, Failures with an Owner
Teams meet at the API contract. Captured in an OpenAPI specification, it becomes a file that can be reviewed, versioned and loaded into tooling: the Azure API Management documentation on learn.microsoft.com walks through importing an OpenAPI specification as an API definition from the Azure portal, the Azure CLI or Azure PowerShell. The architect approves that file, and the domain team changes it only through an agreed process.
Error handling needs an owner too. The Azure Logic Apps documentation on learn.microsoft.com describes the retryPolicy setting: when a request fails with a 408, 429 or 5xx response, the default policy for most operations sends up to 4 retries at exponentially increasing intervals, and later actions can react to a failure through runAfter. Those mechanisms ride out a temporary outage. They do nothing for bad data, which has to reach the domain team named in the RACI matrix.
Read Also
- Low-code/no-code: when it’s the right choice — when to build without code
- IT systems integration: key elements and strategies — patterns and approaches
- Security considerations for low-code applications — rules for makers
Build Your Skills
See the API Management with MuleSoft Anypoint Platform and API Design with Swagger and OpenAPI Specification courses. The first covers managing APIs on an integration platform, the second designing the contracts. Contact us to tailor the scope to your team.
Frequently Asked Questions (FAQ)
What does IT system integration actually involve?
It is a controlled, ongoing exchange of data or calls between systems, so that nobody has to key the same information in by hand in different places. It covers the contract (what flows and in which format), the transport mechanism, monitoring and the people accountable for each of those parts.
What are typical examples of system integration?
Keeping customer records aligned across a marketing platform, a CRM and an ERP; passing web shop orders to a warehouse system; creating accounts in internal systems when someone joins the company. The iPaaS explainer on aws.amazon.com lists similar scenarios.
Are low-code platforms suitable for integrating systems?
Yes, for straightforward flows between applications that already have connectors. The condition is a set of rules from the platform owner: which connectors are allowed, which data may be combined and who owns a flow built by someone outside IT.
Who is responsible for system integration in a company?
Responsibility is shared: the integration architect owns contracts and patterns, the platform owner owns rules and access, domain teams own the data in their systems and operations owns monitoring. Record it in a RACI matrix so that each activity has someone accountable.