The Pros and Cons of System Connector Based iPaaS Integration

In the integration world, you'll see the word "connector" a lot. In some ways it's a really straightforward way to describe an integration capability. But, as you peel back the onion, it gets a bit more complex.

This post will help you understand what "connector" means and what a system connector based approach to iPaaS integration looks like. This will help you, as a software producer, understand the best way(s) to address connectivity for your users.

Warning: You aren't getting a straightforward, easy answer at the end of this post.

Quick Terminology Reminder

The rest of this article assumes some basic understanding a few terms. You can skip this section if you know what these are:

• Software-as-a-Service (SaaS) - Subscription based software accessed via the cloud.
• Integration Platform-as-a-Service (iPaaS) - Traditionally, a third-party cloud software product that connects business software products (also usually SaaS/cloud based) in service of an end user's business objectives.
• Embedded iPaaS - A new(ish) type of iPaaS that can be white labelled or embedded into a software product. If you produced and sell a SaaS application, you can "embed" someone else's iPaaS capabilities as if they are your product's own.
• Integration Framework - A more generic, lower-level term to describe code building blocks that provide integration capabilities.
• Endpoint System - Someone else's software product that you are connecting as part of an integration.

What is connector-based iPaaS integration?

Simplest definition: a connector is a software feature that allows the product that has the connector to talk to the other software product for which the connector is built.

You'll see "connector" used in two common ways: 1) a SaaS product marketing a connector to another SaaS product or 2) an integration platform-as-a-service (iPaaS) marketing compatible connectors to multiple SaaS products. Both can mean different things.

Connectors for SaaS

When a SaaS company uses the term "connector", it's usually more marketing-speak than it is representative of an actual software artifact that literally is a connector. There's nothing wrong with that, by the way! It's just a convenient term to represent the idea that "our product connects to that other product".

Under the hood, the SaaS vendor may be using an embedded iPaaS which does actually make use of connectors (see next section) or they are using "connector" as a shorthand for a traditional iPaaS partner. They may have also built or implemented an integration framework that introduces (or doesn't) the concept of connectors. They may have also just written code that talks to the other SaaS API, plain and simple.

The practical usage of "connector" and the technically accurate usage don't always align.

When you're evaluating a SaaS product for purchase, unless you're concerned about the underlying integration engine, whether a connector literally exists isn't that important.

If you are the producer of the SaaS product, the conversation is more relevant. It comes down to making a decision about how best to enable connectivity between your SaaS product and other on behalf of your users.

Connectors for iPaaS

The concept of a "connector" for iPaaS is a significant consideration. If you're considering an iPaaS approach to integration (traditonal and/or embedded), it's important to understand to what extent the iPaaS uses a connector model and how might influence your ability to use the iPaaS to meet connectivity goals.

An iPaaS basically contains two significant parts: an engine that knows how to move and transform data between endpoints and a set of connectors that know how to move data in and out of those endpoints. Without both of these parts, the iPaaS cannot do its job, which is to orchestrate data movement between two or more software products in service of a business objective.

To accomplish the latter (connecting to endpoints), iPaaS products will leverage one or both of the following strategies:

• A system connector approach where endpoint system-specific connectors abstract away the complexity of dealing with the specific endpoint system's API. Connectors make it so the iPaaS natively knows how to speak the language represented by the endpoints' APIs. That allows the iPaaS user to not care much about those APIs. You may also see terms like "adapter" or "gateway service" to represent basically the same idea. For shorthand, we're calling this a "connector-based approach".
• A type connector approach where generic connectors allows iPaaS users to build integrations against an external API in whatever way they want. Instead of a "Shopify Connector", for example, the user would leverage a "REST API Connector" to decide which Shopify API calls to make in what order.

It's important to remember that many iPaaS products support both approaches. It's not only a consideration at the time you evaluate an iPaaS for purchase. It's also a design-time consideration about whether either approach meets the specific business need for a specific integration project.

All of this might seem like weird inside baseball. Who cares whether an iPaaS uses endpoint system specific connectors or generic type connectors? Why does any of this matter?

System Connector-Based Integration Pros

There are distinct advantages to a connector-based integration approach. There are also some disadvantages, which are coming in the next section.

For clarity, these pros and eventual cons are from the perspective of a SaaS vendor leveraging traditional or embedded iPaaS or an integration framework to offer connectivity to users. If you are an iPaaS vendor, these pros and cons look a little different.

Makes Sense to Non-Technical Users

Connector-based integration approaches tend to make more sense to non-technical users. These users aren't thinking in terms of "making data from this SOAP web service move to this other REST API". They are thinking in terms of "moving customer records from my CRM to my marketing platform".

A connector to each product with functions to retrieve and save customer records aligns more closely with the latter.

This can be a huge benefit if the user base skews non-technical. Integration is already a difficult thing to do. Simplifying it for the people who aren't as passionate about or educated on how to do software integration eliiminates friction. (That's probably most of your users.)

You can shield users from complexity.

One of the reasons a connector approach makes more sense to non-technical users is that it shields them from some of integration's complexity. The user doesn't have to understand what type of API it is or how to authenticate with it or how to combine multiple calls to achieve their goal. That's all encapsulated in this nice "connector" package.

There are downsides to this as well, which are described later. But, enabling someone who isn't an integration engineer to at least be a novice integrator has a lot of value.

Simplifies Integration Requirements

When built well, a connector exposes only the functions or operations (the things it can do) that are exactly necessary to achieve the business goal(s) the connector is built to serve. Sometimes there's a very close one-to-one mapping between those goals and the API, but often that isn't the case.

By shielding that complexity from the user (see above) and expressing the things the connector can do on the user's terms, not the API's terms, it makes it more straightforward for the user to map those things to actual business requirements. This means simpler requirements with less articulation of architecture or technical design

Alignment With Marketing Approach

This simplified list of things isn't just helpful for the end user. It's also helpful for the marketer.

Many marketers, even at software companies, are not all that technical, yet they are required to market highly technical solutions. This includes those that offer integrations. (Read: Your SaaS solution.)

This is not an easy task for the marketer. If they must understand the nuances of how choreographies of API calls and data transformations deliver on a feature promise, there's a lot of room for misunderstanding. Misunderstanding can lead to poor expectation setting with a user, even selling something you don't really offer. That usually doesn't go over well with those users.

However, if the marketer (like the user) is able to draw a straight line from the things it does to the business benefits, they are empowered to do a better job marketing the solution. The connector-based approach tends to lend itself to this benefit.

System Connector-Based Integration Cons

On the other hand, a connector-based integration approach is no Panacea. There are drawbacks, too...

Hardcoded Logic

There's a cost to shielding complexity from users and thus simplifying requirements. You trade off flexibility by hardcoding assumed logic.

Wrapping an API in a coded set of functions (things it can do) that best meet your user's requirements means there are some amount of those users who you will knowingly alienate. The connector probably works for 80% of your users, but those other 20% still need an integration too!

Noteworthy: Those 20% with "outside the lines" requirements will probably take 80% of the cost/effort to enable. Be thoughtful with how you address connectivity for them.

That means you need to decide what to do with those 20%. You might chose, usually validly, to simply not offer an integration to those 20% of users. They are welcome to use a different integration solution and/or work directly with your API to deal with connectivity. Alternatively, you might choose to react to those new requirements as they come, continually adding to the connector's coded logic. That's effective for a while, but it's a dangerous path towards a connector that simultaneously works for everyone and no one. If you keep adding "if this condition" code to your connector, you gradually reduce the simplicity advantage of having a connector.

These aren't always easy choices. It's also why we typically advocate for a portfolio approach to providing connectivity. This gives you options for helping the users with "outside the lines" requirements--who may, incidentally, turn out to be your most valuable users.

Connectors Can Bury Errors

This certainly isn't always the case, but coded connectors that encapsulate "how to work with this API" logic have a tendency to bury errors. While errors should be rare, it's important that they bubble up to an appropriate audience when they occur.

A connector approach requires the software developer who is writing the code for that connector to think through all of the ways his or her code could fail. All software developers do this and none are perfect at it. There's always one more thing you can think of, so eventually you decide the code is deemed good enough.

When coding a feature for an integration, the developer has an added burden: they have to expose those errors about a really technical feature (integration) to someone less technical than they are so that something can be done about them. The result can be that errors are unclear or show up in places the non-technical person wouldn't expect to look. They may not even show up at all. This makes the integration more difficult to manage.

Yes, you can reduce this risk when you have a developer building the connector who is experienced with these use cases. You can also reduce this risk by building connectors on a consistent, well archihtected framework. But, the risk is always there.

Heavier Reliance on Developers

Oh, by the way, have we mentioned the connector approach also requires a heavier burden on software developers?

With about a half dozen type-based integration connectors (REST, SOAP, SFTP, etc.), you can enable connectivity to most modern software products. You can probably do this with an analyst (or like skillset) or even a line of business user with reasonable technical training. You certainly reduce complexity and the need for technical skill with a connector approach, but to handle integrations to same (for example) 40 endpoint systems will require developers to build and maintain (same example) 40 different connectors.

Software developers are highly sought after and well compensated. The good ones are that, and then some. The extent to which you can reduce reliance on developers is reduced cost and risk. A connector approach tends to have a higher reliance on the developers who build those connectors. If you have the developers and they have the bandwidth, great! But, developer bandwidth is at a premium in most software companies.

Influences iPaaS User to Neglect Endpoint

Connectors tend to abstract away the endpoint system's API, and by proxy the endpoint system's actual functionality. This gives the user some advantage by simplifying the integration experience. However, it also makes the user ignore what the endpoint system is and does.

Not all endpoints are created equally. Even ones that share a common category (e.g. CRM) work very differently. They approach things differently. They have a different ethos, even!

Those are the things that a user considered when deciding to purchase that system. An integration (using connectors) that washes that away actually reduces value for the endpoint system, which is not something you want to do to your users.

Should you take a system connector approach?

With context for some of the pros and cons of a connector-based iPaaS approach, you may ask the question whether it's a good direction to go. Our perspective, which will differ from that of others, is as follows:

As a SaaS product team, looking to provide connectivity on behalf of your users, it's generally a better approach to default to a type-connector based approach without a specific reason to build/use a connector. Both are valid approaches, but a type-connector approach should be your first option.

Here's why...

• As a SaaS producer, you want to minimize the code that you have to write and maintain related to integration. You aren't building integration software. Minimize the extent to which you must act as integration software.
• Or, if you rely on an iPaaS vendor to maintain a connector, you are to some extent, beholden to them keeping it up to date. This risk is reduced if the iPaaS vendor has a model where others can contribute to exiting connectors.
• A protocol approach puts more burden on configuring the integration than coding it. That means you can have a less technical, usually less expensive person build and maintain the integration.
• It affords more flexibility to deal with unique requirements from your users. Depending on who you users are and what your product does, this benefit varies. If you sell into the enterprise or to users who still have legacy software systems that require integration, this is very beneficial.
• It doesn't punt on integration. You aren't an integration company, but integration is required for you to be successful. Don't just throw up your hands about it.

These decisions aren't binary, and here are some reasons you would take the connector-based approach:

• If you've already made the decision to leverage an iPaaS that has connectors, of course use them! Just make sure you understand the limitations and how those connectors stay maintained.
• You have relatively simple and consistent integration requirements times a LOT of customers and/or a LOT of other endpoint systems. This footprint is what makes Zapier so great for so many teams.
• You use an integration platform or framework that your development team is comfortable with. You might prefer to build a strong engineering discipline around connector deployment. Just don't start with assuming this is the way to go (or that your team can do it).
• The people building and/or using the integrations are REALLY low on technical skillset. In this case, the tradeoff between "simple" and "flexible" is much easer to make.
• You are choosing not to address "outside the lines" integration requirements (that 20% we mentioned earlier). This is a valid decision. Just consider what answer you will provide your users. "No, figure it out," isn't your best option.

This conversation is nuanced and the answers are not usually crystal clear. The goal for this post wasn't to tell you exactly what to do, but to take you through the thought exercise of figuring out what to do. Remember, usually taking a hybrid or multi-faceted approach is the best answer.