Taking a Portfolio Approach to Connectivity & API Integration

You know you need integrations--maybe a lot of them. You know that your team has at least some ability to deliver them. You know those integration needs are going to compete with other product roadmap items in terms of time and attention.

This isn't a unique reality. All software companies, especially B2B software companies, face this. However, not all software companies address it effectively. The ones who do are far more successful. And, those companies tend to take a multi-faceted approach.

In this post, we'll make a case for taking a portfolio approach to building out your connectivity and API integration program. Using multiple strategies to address your customer's integration needs is more effective than using one.

Let's dive into why and how to do it.

Individual Strategies for SaaS Integration

We covered six approaches to SaaS product integration in a previous post. That post dives into the pros and cons of each and shares which approach may be a good fit.

To summarize, the six strategies for SaaS product integration are:

• Partner with a solution integrator who will provide connectivity for your customer as a bespoke software development service.
• Partner with an integration platform as a service (iPaaS) provider who will include connectivity to your product in their offering, again to provide connectivity for your customers as a separate service.
• License and implement an embedded iPaaS to white label a commercial iPaaS's capabilities into your product.
• Build out individual, bespoke integrations to other software products using your own product development team.
• Build a proprietary integration framework on which you deploy product integrations using your own team.
• Implement an open source integration platform to use as a framework for deploying product integrations using your own team.

No single one of these strategies is right or wrong for every software team. Some are used more commonly than others. Often times these approaches are used sub optimally--when teams just don't know any better.

But, in this post, we'll actually make the case that building a portfolio of these strategies is the best way to enhance your SaaS product's connectivity, reduce cost/risk, and improve your overall customer experience.

Why a portfolio approach?

The six strategies above have various advantages and disadvantages to them. Likewise some are better fits for certain companies than are for others. Listing these strategies out implies that you have to choose which one is your strategy. Going all in on a single approach is usually not ideal, nor is trying to tackle them all.

One strategy isn't enough.

If you choose an approach that turns out to not to work well for your business, you'll have invested a lot of time and money (both of which are finite) into something that didn't move your business forward. Especially as a growth stage company, your go-to-market is a moving target. You will stumble upon new opportunities and learn from mistakes made. What looks like the right approach today may look very wrong next quarter or next year.

Not all integration needs are created equally. The one chosen strategy may be great for a set of your integration needs--maybe even a majority of them. But, it might simultaneously be really bad for others. This can cause friction and introduce costs that negate the otherwise "rightness" of the approach in other contexts. It can cause you to sink a lot of time and money in.

A single approach also limits your diversity of perspective. As noted in the linked post, these six strategies fall into two buckets: ones you deal with internally and ones you offload to an external partner. By limiting to a strategy that is of the former, you only have access to your team's knowledge of the ecosystem, which can be myopic. By only using an "external partner" strategy you outsource away something that is pretty critical to your growth strategy.

Every strategy is (probably) too much.

At the same time, you can't reasonably bite off all of these strategies. Each requires time and money. Each requires dedicated focus from team members, many of whom you'll need to hire. Unless you are really a full-scale company, you probably don't have the resources for all six.

All the same, you probably don't need all six either.

You can whittle down the list, recognizing that some of these strategies are probably alternatives to or incompatible with others. For example, building a proprietary integration framework and implementing an open source one are really two ways to solve the same problem. Unless you are a massive company (think IBM) you aren't going to do both.

But this begs the question, "How do you decide which strategies are the ideal fit for my product?"

Choosing the Right Strategies

Which strategies should you choose? There is no universal answer. The right portfolio of integration strategies depends on the needs of your business. Here are some things you should consider when building your connectivity portfolio for API integration.

Balancing Internal and External

Consider having at least one "internal" approach and at least one "external" approach. It still requires you to know which parts of your integration strategy should be handled by each. It also requires that you be careful not to over-reach (take "at least" lightly). But, this diversity of perspective and expansion beyond your four walls will help to mitigate some risk.

Integration Complexity

Consider how sophisticated your integration(s) are going to be. Do you require deep, complicated integrations that are perhaps a key differentiator? Or, is breadth more important? If the former, taking greater ownership of the integrations may be important. In the latter, maybe you partner them out to an iPaaS.

Partner or Partner Program?

For integrations that you are partnering out, should you find one partner that you work closely with or should you try to build a team of partners? The former allows you to establish a deeper, more strategic relationship. The latter helps you expand connectivity to the ecosystems of each iPaaS vendor you partner with.

Customer Expectations

What do your customers expect? Do all of your competitors provide a baseline set of integrations natively? If so, asking your customer to pay an SI to custom build an integration that a competitor just has probably won't fly. On the other hand, if you sell an ERP, such a requirement is generally expected.

Can you use any of these expectations to create a point of differentiation?

Double Down on iPaaS

Many embedded iPaaS vendors started out as traditional iPaaS. This means that their core business is to offer the iPaaS capability to your customers as a third party, but they've expanded to offer you (the software vendor) a white label solution as well.

In these cases, you might consider combining both solutions: 1) building your native product integrations on their "embed" solution and 2) using that relationship and your connector within that iPaaS to offer to the broader, traditional iPaaS customer base.

Be careful about over-investing in a single iPaaS vendor in this case. That single point of failure could introduce risk for your business.

Team Capability and Capacity

Who do you have on your team currently and what is their experience with API integration? Are they hardcore developers who will be more comfortable and productive writing code or are they more product- or business analyst oriented, perhaps more comfortable in a low code environment? What does your partner team look like--can they manage many partners or is it best to keep the number small?

You should definitely consider the makeup of your team today, because if your team can't execute, what does it matter which strategy you pick. But, don't over-optimize for the present if you have plans to grow the team.

How far along?

There's a practical matter of where you are as a business to consider as well. Spending tons of time to implement abstract integration frameworks or build out huge integration partner programs may not make sense while you're validating your product in the market. Sometimes you need to build the first integration or two, quick and dirty, to get it done.

We don't usually recommend this approach, because it can create problems down the road. But, it can be the right move if you don't have a clear path to success otherwise. (By the way, you do have a clear path available using Blended Edge + our integration solution built around an open source framework.)

Connectivity Portfolio Examples

The following are some examples, inspired by real companies, but specifically describing any one actual company.

Example 1: Ecosystem + Long Tail

ABC Software is building their product around an existing tech ecosystem that centers on an "App Store" model (think Salesforce, Shopify, etc.). However, in addition that that primary integration, they also must offer their customers integrations to a long tail of legacy and lesser known software products.

For this company, it makes a lot of sense to build their core integration natively versus outsourcing the integration. This product is literally an extension of that much larger integration partner. Come time to expand to other ecosystems, you're making the bet that you'll have the revenue or invested capital to abstract away from that product. And, this primary integration must be as deep, natural, and sophisticated as possible.

On the other side, a long tail of integrations is a danger zone. You could spend a lot of time and money building out integrations that few people use, per integration. tTo lesser connected and legacy systems, each integration will tend to take longer to build. Furthermore, ABC's product is a "stand up and go" product, which has minimal implementation work. So for ABC Software, it makes sense to provide a proper API and outsource to various iPaaS vendors who can help you extend your integration presence.

Example 2: Hub of Operations

DEF Software provides a product that serves as the hub of operations for customers who otherwise have to operate across separate specialized systems. It strives to be the single source of truth for customers who usually don't have that information ins a single place.

This company has a serious case of the integration conundrum--they don't provide integration as their core value proposition, yet for their core value proposition to be realized, integration is an absolute requirement.

This company cannot ignore or outsource integration, because it'll put their growth potential in the hands of others. But, if they get roped too far into integration, they risk just becoming an integration platform and not an operational hub. If that were to happen, the core value proposition would be washed out.

For DEF Software, it makes sense to leverage existing integration technology to build native integrations to the handful of systems that 80% of their users will need integration to. But, DEF will also need the capability to say "yes" to more than that. The integration technology they choose should give them the building blocks to handle bespoke integrations successfully. You should also partner with some SIs and or iPaaS vendors to handle the edge cases.

We tend to be partial to taking an open source approach here, but using an embedded iPaaS is also appropriate. For the latter, consider the risk you introduce if leasing your integration capability from someone else.

Example 3: I am ERP, so you build to me.

XYZ Software provides a highly configurable ERP for manufacturers. While it does have some standards for its API, the actual implementation is very dependent on each individual implemenetation. XYZ sells mostly through a value added reseller (VAR) channel instead of direct to their customers.

XYZ represents a classic situation with ERP, but this isn't unique to that software category. Each implementation is so specific that it's hard to build standardized capabilities. Furthermore, the software publisher themselves (XYZ) doesn't really take ownership of the customer implementation or maintenance experience. Their channel partners do.

In cases like these, the bulk of the integration strategy should be around enabling a portfolio of solution integrators to provide integrated solutions. Typically these are the channel partners, but those who resell the software may not necessarily be the same team that integrates the software. It also makes sense to partner with one or more iPaaS vendors who may even also work with those SIs.

Supporting this type of program means your integration strategy is much more about improving the developer experience and supporting those who will build integrations to your product.

XYZ may also consider providing their own integration framework as part of the solution. (Again, as an example, many ERPs offer such a module.) Typically the vendor will acquire an iPaaS to embed into their solution or will build the solution natively. If doing the latter, we are strong proponents of the open source approach.

Having this "built in" integration capability gives your resellers another SKU to sell. It also gives you a more prescriptive way to require your SI partners "build" integrations to your product.

Now what?

The goal for this post is to encourage you to diversify beyond a single approach for your integration stategy. But, it also intends to give you concrete strategies to choose from. You don't want it to be an undefined free-for-all.

Taking a portfolio approach to integration is a more complicated way to go. It probably takes more time and thought than the single approach. But, we strongly believe it has an outsized value to your customers and on your company's financial future.

Taking this approach also means that sometimes you'll get it wrong. You are taking more swings at the plate, so you're going to strike out more frrequently. That's ok, as long as you have a process for learning and adjusting. Take care not to pursue obviously incompatible strategies. Recognize that even within a single strategy there's a lot of room for adjustment.

As always, we're here to help, if you need it.