Integration partnership models

An integration partnership starts with the customer task that becomes easier when products work together. Choose a model based on the data path, the ownership boundary, and the operating burden each team can carry. The partnership connects products through an app between their systems so customers can use them together with less friction.¹ It lets customers access, share, and move data without taxing their developers or bringing in another party.²

The partner's technical boundary can settle the design before the teams discuss architecture. An external partner may require EDI, a fixed file format, or a specific API contract.³ Establish that boundary first because it can override the other choices.⁴

The models

Use the model that matches the customer job and the way the connection must be owned. The customer experience may look similar across partnerships, while the build and operating obligations differ.

Native integration

Choose native when the connection should feel like part of the product experience and remain a maintained product capability. Technology integration partners create ecosystem value by building native integrations between a platform and complementary tools.⁵

Ask where setup happens, which product owns authentication, who handles failures, and what the customer can configure. Continue when both teams can describe the customer path and ownership boundary in the same terms.

Connector or iPaaS

Use a connector or iPaaS when breadth matters and the connection follows patterns already covered by the platform. Mature integration landscapes often use iPaaS for the long tail of SaaS-to-SaaS connections and hand-built integrations for core, high-volume, differentiated flows.⁶

Check for coverage gaps, limits on data movement, and the work required to monitor changes. A series of integration steps can become messy as third-party needs accumulate.⁷ Ask which parts the connector owns and which still need custom work.

Custom integration

Use a hand-built integration when the connection needs direct control over behavior, performance, or change handling. This approach fits flows that are few but deep and specific, performance-critical, highly regulated, unsupported by available connectors, or too costly to run on a platform.⁸

For shared customers, the teams can collaborate on custom integrations that extend product functionality and the user experience.⁹ Ask who will build the connection, who will operate it after release, and how either partner can change the contract without breaking the customer workflow.

Shared API

Use a shared API model when both products need a durable contract for access, updates, or data exchange. Client libraries can provide programmatic access to products through their APIs.¹⁰ A Partner Procurement API can create linked customer accounts and send and receive updates about user accounts.¹¹

Set the direction explicitly. External applications are often integrated so data flows bidirectionally between systems.¹² Where the partnership needs cross-product consistency, shared authorization, APIs, and data models can make that integration possible.¹³ Ask which system owns each record, which events trigger updates, and what happens when both sides change the same data.

Layered or embedded capability

Use a layered model when one product needs to add a higher-level capability on top of another system. A higher-level API or orchestration layer can sit above an underlying database.¹⁴

For an embedded feature, identify where the host product ends and the partner capability begins. Confirm which product owns the user experience, permissions, data access, and support path. Continue when the customer can understand where the capability lives and the teams can explain how it receives the context it needs.

Run the choice in order

1

Partner boundary

2

Data path

3

Build path

4

Business horizon

5

Success measure

1. Partner boundary
2. Data path
3. Build path
4. Business horizon
5. Success measure

Treat the selection as a sequence of gates. Record the answer at each gate before choosing a model.

Partner boundary

Start with the formats, endpoints, and change rules the partner will permit. Ask what the system accepts today, who controls the contract, and what notice comes with a change. If the constraint is fixed, let it shape the shortlist.

Data path

Map how fresh the data must be, how much moves and how often, who initiates the flow, which direction it travels, and what the team can operate.¹⁵ Ask what stale, duplicated, delayed, or rejected data would cause. Continue when the customer job and the data behavior are described together.

Build path

Compare connector coverage, team capacity, and the expected number of integrations before choosing between iPaaS and hand-built work.¹⁶ Ask what the team can monitor during an ordinary week and during an incident. A model that saves build time while creating an operating burden has failed this gate.

Business horizon

Balance the immediate business requirement with the flexibility the partnership will need later.¹⁷ Ask whether the contract, ownership, and support model can survive a change in the customer workflow. Record the answer before discussing implementation detail.

Success measure

Decide how to assess effectiveness before work starts. Measures need to be available even though some significant effects can be difficult to measure.¹⁸ Ask what improvement the customer should notice, what operational signal shows the connection is healthy, and when the partnership should be reviewed.

What to measure

Measure the customer task the partnership was created to improve, along with the operating work required to keep the connection useful. Keep the measures close to the workflow so the teams can act on them.

An integration should become routine, seamless, efficient, and effective in supporting the customer's goals.¹⁹ Track whether setup completes, data reaches the intended destination, failures are recoverable, and the customer can finish the intended task without extra manual work. Review the measures with the people who own the connection and adjust them when the customer workflow changes.

What not to do

The common failures come from treating the mechanism as the partnership. Technology is a tool for improving productivity and practice.²⁰ Keep immediate build convenience from outweighing the current requirement and long-term flexibility.¹⁷ Keep measures available even when some effects are difficult to measure.¹⁸ A working test path does not by itself show routine, seamless, efficient, and effective support for the customer's goals.¹⁹

Before build work starts, take the boundary and data-path questions into the partner call and record who owns setup, changes, failures, and customer communication.