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.
The rest of this article assumes some basic understanding a few terms. You can skip this section if you know what these are:
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.
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.
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:
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?
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.
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.)
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.
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
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.
On the other hand, a connector-based integration approach is no Panacea. There are drawbacks, too...
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.
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.
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.
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.
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.
These decisions aren't binary, and here are some reasons you would take the connector-based approach:
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.