With rare exceptions, B2B SaaS apps need integrations. They need integrations with industry-leading CRM, HRIS, and ERP systems. They need integrations with one-off systems your customers have built in-house. And they need integrations with scores of systems that lie somewhere in between these two groups.
So, why doesn't every B2B SaaS app come with a bunch of integrations out of the box? There are several reasons, but it comes down to this: integrations, in general, are difficult, and B2B SaaS integrations are more challenging than other types of integrations.
Why are SaaS integrations hard?
SaaS integrations are hard because 1) security is critical; 2) scaling is complicated; and 3) standards are all over the place.
SaaS integration security
SaaS integrations connect two or more apps in the cloud to each other for data transfer purposes. The cloud, however, is not a single secure location but rather an amorphous mass comprised of millions of servers.
Unsurprisingly, connecting servers (usually across the public internet) raises extensive security concerns. Here are some that you'll want to address for your SaaS integrations:
- Are you using the best available auth for your app? How about the app you are connecting to? Does it use proper auth?
- Are the APIs validating all the inputs?
- Are the requests passing between the systems passing encrypted keys in message headers rather than in the body?
- Are all the systems involved trusted? That is, do your SaaS integrations involve any unsigned or unverified apps?
- Are privileges defined appropriately for the APIs so no one has access to anything not explicitly required by the integration?
- Is all data passing through the integration encrypted at rest and in transit?
- Do you log and monitor essential integration and integration execution metadata?
Putting everything in place to answer these questions in the affirmative requires diligent planning and execution, followed by regular security reviews and updates.
SaaS integration scaling
It's not so hard to build a single SaaS integration. Teams do this all the time. The challenges arise when your team needs to move from building a single integration to building dozens of integrations for hundreds of customers.
Our post on how building an integration isn't the hard part gets into details, but here are some of the big questions you'll need to answer to scale your SaaS integrations successfully.
- How do you scale integrations without scaling all the teams (engineering, onboarding, and support) that work with integrations? You can't scale your teams linearly to match the number of integrations. You've got to figure out how to do more with less and execute on X times the number of integrations you have now, all while keeping your team within budget.
- How will you deploy and support your integrations and make them accessible to your customers? You need a process that lets you push out integrations (and integration updates) to X number of customers. And, your customers need to be able to see what integrations are available, which ones they have enabled, and what the status is for each. But they should be able to do this via some type of self-service, without needing to contact your support or engineering teams.
- How do you set up an infrastructure that works for 5 integrations and 500 integrations? You can go with one of several cloud providers (AWS, Azure, Google, etc.). But now, in addition to devs, you need DevsOps to set this up and ensure that everything keeps running smoothly. And if you are building your own infrastructure for integrations, how much of what you are doing has already been built by others?
- How do you manage tech debt when scaling integrations? Let's say you've got plenty of dev resources and are building multiple integrations simultaneously. How do you future-proof those integrations? Or are your devs simply writing as much code as they can as quickly as they can to take care of customers? If that's the case, what's the future cost of rebuilding those integrations? How will you manage customer-specific config for integrations without lots of branching? If you build each configuration individually for customers, how can you do that while not violating the DRY principle?
- How do you ensure optimal resources are available for your core SaaS product? While a single integration may not require many resources, building 20 or 50 of them changes the equation. How do you ensure that your devs contribute to integrations as needed, while still spending the bulk of their time and effort on your core app?
As you can see, scaling integrations for SaaS is not simple. Even to come close to building a long-term sustainable process, enormous investments in people and infrastructure can be required. Scaling integrations while maintaining coding best practices and taking care of your core product may seem impossible at times.
See how Sisu Software scaled its processes to provide integrations 6 times faster with Prismatic.
SaaS integration standards
Standards are wonderful. We may call them best practices or guidelines, but that doesn't change the fact that they help disparate tech teams work together to get things done.
Except that reality dictates a somewhat different story. While you control the standards used within your organization, that control stops there.
Let's say you've built your app with a standards-based REST API. That should make integrations straightforward on your end. But what if you need to connect to a system with an API loosely based on SOAP, GraphQL, or gRPC? Or maybe it doesn't have an API at all? Things just became much more challenging.
The same lack of standards applies to auth. Some APIs use OAuth 2.0, others rely on API keys, and still others use simple auth. Because real life works this way, you may encounter auth implementations that leave you scratching your head and wondering just what is going on.
Even the data formats you need to work with will vary. Some APIs will be happy to send and receive data in JSON format. Others will be constrained to XML (or SOAP XML). Still others may use CSV or something proprietary. Or you may find that data from one system uses a character encoding that must be translated into Unicode before the integration can process it.
The list goes on with API paging controls, timeout sequences, webhook configurations, and more. When it comes to SaaS integrations, "different" is more common than "same."
We can help you meet these challenges
Your SaaS company builds software. It's what you do. But trying to deal with all of these SaaS integration challenges at the same time can destroy your company's product roadmap.
Taking on these SaaS integration challenges without help is a burden that few SaaS companies are prepared to handle. The good news is that an embedded iPaaS is purpose-built to help your teams address these challenges without sacrificing your current market position and momentum.
Schedule a demo, and we'll be glad to show you how Prismatic provides the tools that will allow you to efficiently create all the productized, configurable integrations your customers need.
