Six Approaches to Deploying SaaS Software Integration

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.

SaaS Integration 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
• Developer-based approaches

Vendor-Based 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.

Solution Integrator

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:

• SIs bring a diverse set of integration experiences to the table to help solve a wide variety of integration problems.
• They often specialize in integrations to a single or small set of software products (i.e. SAP) making them experts in those products.
• They are services-based businesses, so a good fit if you or your customer is not into the idea of paying a recurring fee.
• SIs tend to be more flexible in how they structure and monetize projects.

The following are some disadvantages of using a solution integrator:

• Repeatability of solutions is limited to the frameworks used by a given SI
• Project-based software development can have variable outcomes–some projects go well, others go poorly
• Reputation and ability vary across SIs and usually you have many options. Finding the good ones can be challenging.
• Being a services-based business may introduce conflicting financial incentives if you are a SaaS services provider.

Solution integrators are a best fit for:

• When integration requests are a minority of your customers
• Your product (or the one being integrated to) is highly customizable, complex, or domain-specific–again, think SAP.
• Enterprise technologies that are highly customer specific for every deployment.

iPaaS Partner

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:

• You can be hands-off with integrations, but still take advantage of the iPaaS ability to deploy repeatable and scalable integrations.
• iPaaS companies are experts in integration. You probably are not.
• iPaaS companies tend to be well-suited to react to individual customer requirements in an integration (and you don’t have to deal with managing those requirements).

The following are some disadvantages of using an iPaaS partner:

• You put a significant portion of your customer’s experience–especially during that critical onboarding phase–in someone else’s hands
• Customer success is likely to vary significantly (also, see last point)
• This typically adds customer cost of ownership. Simple iPaaS provider’s like Zapier are very affordable, but something more sophisticated will start at $500/month.

iPaaS partners are a best fit for:

• You have mostly customer-specific integration requests with certain pockets of repeatability
• You don’t have the skills or desire to take on integration work in any way.
• Your customers have some scale to the volume of data flowing through the integration.
• You can get the job done with a low-cost iPaaS like Zapier.

Embedded iPaaS

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:

• You get the codeless advantages of an iPaaS, but you get to embed the solution into your product (as far as the customer is concerned).
• Usually you can offer “prebuilt” integrations and/or customer-specific ones, all on one product and white labeled under your product
• All of the other advantages of normal iPaaS

The following are some disadvantages of using an embedded iPaaS:

• This might be perceived as displacing your development team
• You tie some part of your functionality, because it’s white labeled, to another commercial entity
• This is a relatively new concept, so the waters are somewhat uncharted

Embedded iPaaS providers are a best fit for:

• SaaS companies who need to deploy “point and click” provisioned integrations for their customers
• Companies that don’t have the capability or budget to build out bespoke integrations, but want the experience embedded within their product
• Digital commerce, martech, cloud productivity, and sales technology integrations (these tend to have a lot traction with embedded iPaaS vendors)

Developer-Based Approaches

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.

Bespoke 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:

• You get exactly what you want, and if you scope as such, your customer gets exactly what they want.
• You have the ability to deal with the really strange or difficult integration interfaces.
• You don’t necessarily need to make integrations part of your core product

The following are some disadvantages of deploying bespoke integrations:

• These are expensive to build and expensive to maintain.
• High levels of technical and business acumen are required to do this successfully.
• You are responsible for infrastructure and uptime.

Deploying bespoke integrations is a best fit for:

• Enterprise vendors that sell high dollar projects with many unique requirements
• One-off integrations for occasional, large customers
• Companies who have to use developers for their onboarding and delivery model–deeply technical products
• Companies that rarely have to provide integrations

Proprietary Integration Framework

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:

• Most of the advantages of bespoke integrations
• But, also you have some repeatability in terms of architecture
• If done well, the framework can normalize difficult operational concerns like how to monitor the integration and react to failures

The following are some disadvantages of developing a proprietary integration framework:

• Most of the disadvantages of bespoke integrations apply, but are lessened by the consistency the framework brings
• Achieving the abstraction required for a framework to produce value is an even more complex and expensive endeavor (an iPaaS provider’s entire business model is solving this problem)
• You build a large thing that isn’t your product, but your product team is required to understand

Developing a proprietary integration framework is a best fit for:

• There’s a small subset between “bespoke is too one-off” and “iPaaS is not flexible enough” and “our integration requirements are highly unique”, but it’s a very small population. This is generally not a great way to go.

Open Source Integration Platform

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:

• Most of the advantages of bespoke integrations
• Repeatability in architecture that comes out of the box
• The right framework can normalize difficult operational concerns like how to monitor the integration and react to failures.

The following are some disadvantages of using an open source integration platform:

• It requires your team to learn a new open source platform that likely has some complexity
• You are somewhat beholden to what the direction that the open source project takes (though you can contribute).
• Sometimes customization on top of an existing framework is actually harder and more expensive than building from scratch.

Open source integration platforms are a best fit for:

• If you have to or want to build your own integrations and deploy them at even modest scale, this is a best fit for you.
• You are a company that culturally embraces the open source concept.
• There are synergies between how you will use the open source application and how other companies in the same or similar industries are using it–you have a community for support

Choosing a SaaS Integration Strategy

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.