As a B2B SaaS software vendor, providing solutions to your customer’s integration needs is a must. Failing to do so will cost you wins in the sales cycle, increase churn, and lower your overall customer satisfaction.
You are not alone in this challenge, and because of this, your options for dealing with customer integrations needs are plentiful.
In this post will talk about six different ways you can deploy SaaS software integrations for your customers (to/from your product). Then we’ll talk about how you choose the right single approach or mix of these approaches.
Technology innovation for the past decade (enterprise service bus, open source, open API deployment, cloud integration providers) has created ample opportunity for addressing SaaS software integration needs.
The available approaches have their advantages and disadvantages. Certain ones are right for SaaS software vendors in certain situations.
In the next two sections, we’ll talk about six approaches for deploying SaaS software integration, across two types of approaches:
Vendor-based approaches to SaaS software integration involve a commercial relationship with another software vendor to deliver your integrations. These may be partnerships or you may be a customer of the software vendor.
In all cases, you leverage some amount of someone else’s capabilities and/or technology to deliver value to your customers.
A solution integrator (SI) is a third party services provider who builds and deploys integrations on behalf of you or your customers. Solution integrators typically deploy bespoke integrations per customer, but they often will use common frameworks or practices to reduce time and cost.
The following are some advantages of using a solution integrator:
The following are some disadvantages of using a solution integrator:
Solution integrators are a best fit for:
An integration platform-as-a-service (iPaaS) partner provides a configurable, cloud-based integration software product. These products vary significantly in how easy/simple or complex/robust they are. When partnering with an iPaaS provider, you’d typically refer integration requests to their team.
(Note: Most iPaaS products are also SaaS companies, so their financial incentives are likely the same as yours. That isn’t necessarily a problem or advantage, but it’s worth understanding.)
The following are some advantages of using an iPaaS partner:
The following are some disadvantages of using an iPaaS partner:
iPaaS partners are a best fit for:
In the last few years, a new breed of iPaaS providers has entered the market. These “embedded iPaaS” providers sell a cloud software product that allows software vendors to white label configuration-based integrations into their own product. The difference is that these products are very similar to standard iPaaS products, but they are built to be embedded and used by your customers.
The following are some advantages of using an embedded iPaaS:
The following are some disadvantages of using an embedded iPaaS:
Embedded iPaaS providers are a best fit for:
Developer-based approaches involve leveraging your development team (or an outsourced one) to deliver integrations. These are the DIY options for teams who have the engineering prowess and desire (or requirements) to deploy integrations.
The simplest developer-based approach to integration is to deploy a bespoke integration for each customer. This is straight up custom development, complete with project managers, QA testers, and software developers. Each integration is unique and deployed as such.
The following are some advantages of deploying bespoke integrations:
The following are some disadvantages of deploying bespoke integrations:
Deploying bespoke integrations is a best fit for:
Some SaaS software companies elect to build their own proprietary integration frameworks. If there’s enough repeatability between customer integration requests and commercially available options aren’t suitable, these companies build their own platform to gain the advantages of a reusable commercial option.
The following are some advantages of developing a proprietary integration framework:
The following are some disadvantages of developing a proprietary integration framework:
Developing a proprietary integration framework is a best fit for:
Another alternative to building bespoke integrations is to deploy and customize an open source integration platform. This is often a less technically complex alternative to building a proprietary integration framework, but likely meets all the same requirements. One notable open source option is the Open Integration Hub–a Germany-based open source project backed by the likes of Elastic.io. Another is Cenit IO.
The following are some advantages of using an open source integration platform:
The following are some disadvantages of using an open source integration platform:
Open source integration platforms are a best fit for:
There is no single right way to build out integrations to other SaaS products in your ecosystem. But there are some wrong ways depending on your business.
The following are questions you should consider when deciding among these strategies:
Is integration capability part of your core value proposition? Will your company valuation be based on how you’ve deployed those integrations? If not, then why are you investing in proprietary software to handle it?
Who do you have to deal with your integration challenges? Will this go to your development team? Do you have a product manager or technical analyst? The level of technical skill required to deploy an integration varies across these approaches. Align your strategy with your team’s abilities (or how you plan to grow that team’s abilities).
How many integrations do you need? Are there dozens and dozens of ecosystem products you need to integrate to? Are there just a handful? Over-investing in a well-abstracted approach may not be needed for five or six integrations.
How repeatable are your integrations? Does every integration product X look about the same? Can you handle the variation with a few configuration options? Or does every integration need to allow for significant variation from customer to customer? Variation gets expensive, but there are ways to handle it appropriately.
What does your onboarding process look like? If you’ve got a “flip a few switches and you’re good to go” onboarding experience and you try to run a fully managed integration project, you’ll create misalignment with your customer’s expectations. Outsource things that you don’t or can’t do well.
These are just a few questions you should ask, but they’ll get you a long way toward understand which approach (or more likely, approaches) is right for your business.