An integration strategy is the plan for how an organization's systems, data and applications connect, and who owns those connections. It decides which integration patterns to use, which platforms run them, how identity and security work across them, and in what order the work gets done. Integration architecture is the technical design that carries out those decisions.
This vendor-neutral playbook takes each decision in the order most teams make it, with notes for regulated firms.
What an integration strategy decides
An enterprise integration strategy answers six questions:
- Which systems connect, and which connections matter most to the business.
- Which patterns to use for which jobs: APIs, events, integration flows or data replication.
- Which platforms run those patterns, and how many platforms you are willing to operate.
- How identity, security and logging work across every connection.
- Who builds, runs and supports integrations.
- What gets done first, and how you will know it worked.
Most enterprises already have an integration strategy, whether or not anyone wrote it down: the sum of decisions made project by project, many of them accidental. Writing it down replaces accidents with choices, and gives architects a basis for saying no.
A useful strategy is short enough that engineers read it, backed by an interface inventory and a target architecture diagram. Our system integration services often start with this work.
Start with an inventory: systems, interfaces, owners and what breaks today
You cannot choose patterns or platforms without knowing what exists. Most inventories turn up more interfaces than anyone expected: nightly file transfers, direct database links, scripts nobody owns.
Record each interface, not just each system. Copy the header row into a spreadsheet and add one row per interface.
| System | Interface | Pattern today | Protocol or format | Business owner | Technical owner | Data classification | What breaks today |
|---|---|---|---|---|---|---|---|
| Order management | Order status to CRM | Nightly file | CSV over SFTP | Sales operations | Order platform team | Customer data | Status is a day late; failed runs go unnoticed |
| Billing | Payment updates to the data warehouse | Direct database link | SQL | Finance | Billing team | Payment data | Schema changes break downstream reports |
Then look for three things:
- Interfaces that do the same job twice.
- Interfaces with no named owner.
- Interfaces with no monitoring, where the business finds failures before IT does.
The "what breaks today" column tells you where to start, and gives the strategy a business case people outside IT understand.
Integration patterns and when to use each
| Pattern | Best for | Avoid when |
|---|---|---|
| APIs (request and response) | A caller needs an answer now, such as a customer lookup or a quote. Exposing capabilities to apps, partners and AI agents. | Many systems need the same change. The caller does not need an immediate answer. Bulk data movement. |
| Events and streams | Many systems need the same facts. Replay and history. Letting producers and consumers change independently. | The caller needs a synchronous answer. There is only one consumer. No one is ready to run brokers and govern topics. |
| iPaaS or ESB flows | Connecting packaged and SaaS applications. Transformation and protocol mediation. Multi-step orchestration. | Business logic starts living in the flows. High-volume streaming. Every change must queue behind one platform. |
| Data integration and CDC | Moving data in bulk to analytics or a data platform. Keeping a read copy current from a database's change log without changing the source application. | Consumers need business events with meaning, not row changes. Anything that writes back to the source. |
A note on queues and streams: a queue suits work that one consumer must process once, such as a payment instruction. A stream suits facts that many consumers read in their own time, such as an order placed.
Most estates need all four. The strategy sets a default for each kind of work, so teams stop choosing case by case. Point-to-point integration is fine for one or two connections. It becomes the problem when every new system adds a link to every other.
Identity and security belong in the integration layer
Every integration is a trust decision. If each team secures its connections its own way, the estate ends up with shared service accounts, long-lived keys and no record of who called what.
Set these standards once, for every API, broker and integration flow:
- One identity provider, or a small federated set, issues credentials for every caller. Use OAuth 2.0 and OpenID Connect for callers and mutual TLS between services.
- Every caller has its own identity. No service account is shared across applications.
- When a call is made on behalf of a user, pass that user's context with OAuth 2.0 Token Exchange (RFC 8693), so a back-end system does not have to trust whatever the front end sends.
- Secrets live in a vault, rotate on a schedule, and never sit in code or integration configuration.
- Data classification travels with the interface. The inventory's classification column decides which flows need encryption, masking or extra approval.
- Every call is logged with the caller's identity, the operation and the result, in one place, for as long as your retention rules require.
If you work in a regulated industry
Banks, insurers and health organizations are asked to show their integration controls, not just describe them. Design the layer to produce evidence your team can show:
- Who changed an integration, when, and who approved it.
- Which identity called which API or topic, and what it was allowed to do.
- Which third parties connect, and what data they receive.
- How data moved from a source system to a report or a model.
A layer built for review turns each of those questions into a query, not a project.
AI agents are now integration traffic
AI agents call the same APIs, queues and databases as applications, usually through tools exposed over MCP, the Model Context Protocol, and increasingly to each other over A2A, the Agent2Agent protocol. Both are widely adopted open protocols, and both make an agent one more integration client. Treat agent traffic the way you treat any other caller: give each agent its own identity, scope what it can call, set rate and cost limits, and log every tool call along with the user it acted for. The MCP specification bases authorization for remote servers on OAuth 2.1, so the identity standards above apply directly. Many teams route model and tool traffic through an AI gateway so these controls sit in one place. A bank we work with runs several retail applications on an integration layer that includes an AI gateway.
Choosing platforms without lock-in
Choose platforms after patterns, not before:
- API gateways and API management: WSO2 API Manager, Google Apigee, Kong, MuleSoft Anypoint Platform, and the gateways built into AWS and Azure.
- Integration flows and iPaaS: MuleSoft, Boomi, WSO2 Integrator and others.
- Event streaming: Apache Kafka, self-managed, on Cloudera or as Amazon MSK, plus Confluent and cloud streaming services.
- Message queues: RabbitMQ, Amazon MQ and IBM MQ.
Duczer East is a WSO2 Partner and a Cloudera Premier Partner, and works across the other platforms named here. No single platform is required. What matters more is keeping the option to change:
- Describe APIs in OpenAPI and event streams in AsyncAPI, and keep those files in your own repository.
- Use standard identity, so changing a gateway does not mean reissuing every credential.
- Prefer containerized runtimes and policies kept as code.
- Price the exit before you sign: estimate what it would cost to move off each platform.
One insurer we work with runs WSO2 API Manager alongside RabbitMQ and Kafka across multiple initiatives. For teams already on WSO2, our page on integration on WSO2 covers how the products fit together.
Running more than one gateway
Most large enterprises run several API gateways, from acquisitions, cloud choices or team history. Several vendors now offer a control plane that reaches other vendors' gateways. As of November 12, 2026, according to each vendor's documentation:
- WSO2 API Manager can deploy APIs to AWS API Gateway and Azure API Management, discover existing APIs in both, and discover services deployed in Kong.
- MuleSoft says Omni Gateway applies policy from a single catalog across MuleSoft, Kong, Apigee and other gateways. Its API scanners show third-party policies as read-only.
- Apigee API hub ingests API metadata from AWS API Gateway and Azure API Management through built-in plugins.
- Kong Konnect's catalog discovers APIs in AWS API Gateway and Azure API Management, and can score discovered APIs with scorecards.
Reaching another vendor's gateway can mean three things: discovering its APIs, checking them against your standards, or enforcing policy on its traffic. Ask each vendor which of the three it does for each gateway you run. Where a control plane can only discover or check, enforce standards another way, as the next section describes.
Operating model: centralize control, federate delivery
There are three common operating models for integration:
- A central team builds and runs every integration.
- Every team builds and runs its own, with no shared standards.
- A central function sets standards and runs the shared platform, while domain teams build their own integrations on it.
The first becomes a bottleneck. The second produces the sprawl most strategies are written to fix. We recommend the third for most enterprises. It uses three roles, following the platform team and enabling team pattern in Team Topologies:
- A platform team runs the shared runtimes, the control plane and the catalog as an internal service.
- A small center of excellence writes standards and templates, reviews designs and coaches teams. Judge it by reuse, not tickets closed.
- Domain teams build and run their own integrations on approved patterns, including on-call for what they own.
| Area | Center owns | Domain teams own |
|---|---|---|
| Standards and patterns | Writes them | Follow them and propose changes |
| Identity and security policy | Defines it and runs the identity provider | Apply it |
| Control plane and shared runtimes | Runs them | Use them |
| Catalog | Runs it and sets the entry rules | Register their APIs and event streams |
| Building integrations | Templates and design reviews | Build |
| Running integrations | Platform health | Their integrations' health and on-call |
Centralizing control does not require one vendor. Most estates mix gateways, iPaaS tools and brokers, and some departments stream events while others do not. Where the control plane cannot reach, enforce standards three other ways:
- Identity: one identity provider and token standard for every gateway, broker and agent.
- Pipeline checks: validate each OpenAPI and AsyncAPI file against your standards before anything deploys.
- Catalog registration: nothing goes live without a catalog entry and a named owner.
API control planes cover Kafka topics and queues only partly, if at all. Govern streams through a schema registry, AsyncAPI contracts, topic naming rules and access lists, with domain teams owning their events and the platform team setting the guardrails.
Scale the model to the estate. With one platform and a few teams, a central team can build everything. With several business units, vendors or a recent acquisition, federate.
An integration roadmap: the first 90 days and the first year
In our experience, building the strategy itself takes three to six weeks, depending on how many systems and teams are in scope. The first 90 days include that work.
The first 90 days
- Build the interface inventory, agree the default pattern for each kind of work, write the identity and security standards, and draw the target architecture.
- Name the platform team and the center of excellence, even if both start small.
- Stand up the catalog and connect the gateways you already run, starting with discovery.
- Put pipeline checks in place for new APIs and event streams.
- Pick two or three integrations from the "what breaks today" column and rebuild them on the new standards. These prove the model and give teams working examples to copy.
The first year
- Move domain teams onto the model one at a time, with the center of excellence coaching each through its first builds.
- Retire point-to-point links and direct database connections as their replacements go live.
- Bring event streams under contracts and a schema registry.
- Route AI agent traffic through the same identity, logging and limits as every other caller.
- Review the strategy quarterly against time to deliver a new integration, catalog coverage, API reuse and integration incidents.
Choosing an integration partner
If you bring in outside help, look for five things:
- They work across platforms and will recommend the one that fits, including one they do not resell.
- They have run integrations in production and support what they build, not only design it.
- They put identity and security into the integration layer from the start.
- They know the review and evidence expectations in your industry.
- They leave your teams able to build without them, through templates, standards and coaching.
Duczer East is not the right fit for a single SaaS-to-SaaS connection that a packaged connector already handles, or for teams that need Confluent Platform support.
Where to start
An integration strategy is worth writing when integrations take months, outages cannot be traced, and each impatient team adds a platform. Start with the inventory and its "what breaks today" column. More guides on APIs, events and platforms are in our API Management & Integration series, and our integration consulting team can help build the strategy and the platform behind it.
How we built this
Written by David deBoisblanc, Co-founder and Managing Partner of Duczer East, and checked on November 12, 2026. The operating model, roadmap and timing draw on Duczer East integration work in banking and insurance. Platform capabilities come from each vendor's own documentation for WSO2 API Manager, MuleSoft Omni Gateway, Apigee API hub and Kong Konnect. Protocol details come from the Model Context Protocol authorization specification, the Linux Foundation's Agent2Agent project and IETF RFC 8693. Team roles follow Team Topologies by Matthew Skelton and Manuel Pais. Vendor capabilities change often, so check them again before you choose.
