Embedded iPaaS is a class of integration software that allows SaaS vendors to "white label" or "embed" an existing integaration product's capabilities into their own.
This approach prevents the SaaS vendor from having to reinvent the wheel, building an integration infrastructure from scratch. It allows them to, instead, focus on the specific integration uses cases that address specific user needs.
Embedded iPaaS is a relatively fresh approach to integration, and many SaaS vendors are starting to consider it. The demand for more integrations isn't getting any smaller, and embedded iPaaS potentially offers a way to keep up with this demand.
But, no solution is perfect!
In this post, we break down some of the more important pros and cons of using an embedded iPaaS to enable connectivity for your SaaS product. We'll also talk about a new alternative that borrows from the pros of both embedded iPaaS and custom-built integrations.
Types of Embedded iPaaS
Not all embedded iPaaS products are created equally. Even though "embedded iPaaS" is a subset of iPaaS overall, you can actually break it down further than that. This is important, because it might have impact on your experience with the iPaaS and whether it'll help you achieve your connectivity goals.
Note: If you need a refresher on iPaaS, this is a decent overview.
Roughly speaking, consider these three types of embedded iPaaS:
- Purpose-built Embedded iPaaS
- Traditional iPaaS with "Embed" Features
- Covert Embedded iPaaS
No one type is necessarily better than the other. There are tradeoffs that will mean different things to every business. Let's dive a bit into each one to understand their differences.
Purpose-Built Embedded iPaaS
You might be able to gather by its name, but purpose-built embedded iPaaS products were always supposed to be embedded iPaaS. The white label, embedded, or OEM approach (whichever term you prefer) is core to their DNA. The product is fundamentally designed and architected around the SaaS connectivity use case.
Compared to traditional iPaaS, embedded has additional complexities to contend with.
- The per-customer transaction levels are an order of magnitude (maybe two) higher. Instead of serving 1,000 end users, you might be serving 100 SaaS companies all with 1,000 end users. This means your infrastructure cost and scalability is massively more important.
- Embedded introduces a two-tier tenancy challenge, which is not native to most software. You are serving your users who are serving their users. Requirements for data security, mutlitenancy, and segmentation are therefore doubly complex.
- Some amount of the integration deployment experience is unknown until implementation time. This is the "embed" part. As an embedded iPaaS vendor, you don't necessarily know how a SaaS vendor wants to merge your product into theirs, so you have to build APIs and dev tools that help in to-be-determined ways.
If you are evaluating embedded iPaaS products, you can generally consider whether its purpose-built for embedding a positive quality. That doesn't mean other models aren't valid as well, and it doesn't mean that every purpose-built embedded iPaaS is better than every traditional iPaaS for meeting your needs. You also must consider that, since this is a relatively new approach to SaaS integration, your options are much more limited.
Pro Tip: You may need to go beyond what the website says when you're evaluating what appears to be a purpose-built iPaaS. There are vendors who started as traditional iPaaS, but pivoted early to the "embed" approach. This means their product, at least early on, was NOT purpose built for "embed" use cases. Use the Wayback Machine to evaluate how they originally marketed their product to sniff out if this is the case. Then ensure they can communicate why they made the change and what the did with their product to ensure it's optimized for the "embed" use cases.
It's also not a requirement that you use a commercially available embedded iPaaS. You can consider embedding an open source integration framework, like Open Integration Hub, into your product. There are certainly trade-offs to doing so, but it gives you full ownership and control of the integrations and the data they move.
Traditional iPaaS with "Embed" Features
Many traditional iPaaS vendors now offer "embed" features that allow their product to behave as an embedded iPaaS. This is probably the most prevalent type of embedded iPaaS products out there, because 1) the iPaaS space overall is crowded and well-established and 2) many of these vendors are realizing that "embed" uses cases support better unit economics. Read: R&D and marketing dollars are funneling here.
With traditional iPaaS-turned-embedded vendors, you'll need to understand how far their "embed" features go. Sometimes vendors will market with "embed" or "white label" messaging, but their offering isn't much more than a different business arrangement (charging the SaaS vendor, not the end user). Others have actually built out some amount of features for embedding, like APIs and dev tools.
One advantage to this type of iPaaS is that many of these vendors have been around for a while and have demonstrated success. Going with traditional iPaaS with embed features opens your possibilities to more established players.
Covert Embedded iPaaS
There are also vendors who effectively offer embedded integration capabilities, but don't necessarily call themselves an embedded iPaaS. Typically, this is because, while SaaS integration is part of what they offer, their product vision is built around other related features. For example, some products market more around the fact that they help you build out an integration marketplace more than the data integration engine itself.
These are also vendors that might satisfy your connectivity needs, so they should be considered (generally speaking) as embedded iPaaS...at least for the purposes of this pros and cons list.
Pros of Using Commercial Embedded iPaaS
You've got options when it comes to the type of embedded iPaaS product you can choose. But, should you actually be using an embedded iPaaS in the first place? There are pros and cons.
Let's start with the positives! There are some significant pros to using a commercial embedded iPaaS to enable SaaS connectivity. The following are some of the bigger ones.
Consistent Workflow
Consistency is key when you are building a portfolio of integrations, and as a SaaS provider you absolutely are.
An embedded iPaaS, despite what it may or may not support in the weeds, will enforce a consistent "way" of building integrations for your product. This will help you scale your integration program.
In our experience, we find that early SaaS providers tend to start by custom building integrations. That's a natural starting place, especially when you're still in that scrappy "just make it work" mode.
We typically find that this gets very difficult around a dozen custom built integrations. This is where significant architecture challenges rear their heads. It's where the cost reality of owning homegrown integrations start to hurt. It's where progress slows, because too much engineering time has to go into managing the existing integrations and not buildinig new.
It's because homegrown integrations are rarely built with a consistent workflow on a consistent framework. This is usually where SaaS vendors look for alternatives, which might include embedded iPaaS and might include a fundamental (expensive) rearchitecture.
Large Connector Libraries
Commercial embedded iPaaS vendors typically have large libraries of connectors to commonly integrated systems. This is even more true of longstanding traditional iPaaS vendors who now offer "embed" features.
These connectors simplify the integration build process by normalizing common integration use cases. They help shield your integration team from having to develop deep expertise in whatever system they connect, which speeds up integration projects overall.
The possibility exists with every connector that it's not actually very well developed or not developed around your use case, but most commercial embedded iPaaS vendors also offer frameworks and processes for extending existing connectors.
If a connector-based approach is right for your integration strategy (read more here), these large, established libraries are a big advantage.
Warning: Do connectors get you what you need?
A large connector library might be a pro, but tread lightly.
Typically a large connector library has the following attributes:
- Someone else builds the connectors (either the iPaaS provider and/or its community)
- They are typically built to serve the needs of the first user, then added onto organically
- Someone has to keep them up to date and the majority of them are not closely maintained
- 80% of usage is among 20% of the connectors--many may not be used at all or only by one customer
- You still have to orchestrate data from/to the connector to/from your system
Certainly there is some value here. Someone else built integration functionality that you get to take advantage of. But, if the connector doesn't meet your needs, doesn't stay updated, or isn't reliable, did you really get what you want?
Furthermore, the existence of a connector does not mean you'll just have an integration. You are still required to build the hard part--the data orchestration between that connector and your API. Connectors just give you an ability to talk to the external system's API and deal with authentication.
Offload Infrastructure Responsibilities
A huge advantage of using a commercial embedded iPaaS is that you offload most of the infrastructure responsibilities to a third party. If you're a small team or you don't have the desire or budget to hire people dedicated to these areas, this helps you level up fast.
Moving data as a SaaS vendor on behalf of your users is not trivial. You have to move a lot of data without dropping it on the floor. This can be expensive if your team isn't experienced architecting these types of systems. It can send your cloud bill through the roof in the worst cases. It can also put you in a position to hire more cloud engineers than you'd otherwise want to.
With a commercial "as a service" product, you're effectively outsourcing your cloud management to that vendor--at least for the parts of your product that relate to integration. You're going to have it marked up (they are a business after all), but that still might be less expensive than you building the team and optimizing the cloud computing spend.
Warning: You're going to pay.
Compute costs what it costs. Moving data at high volumes is expensive because it uses a lot of compute resources from the cloud environment.
While offloading this responsibility to someone else might be a benefit to you, expect to pay for it. No embedded iPaaS vendor is passing infastructure costs to you without building in a profit margin.
Potential Overlap with Traditional iPaaS Usage
Many embedded iPaaS offerings started as traditional iPaaS. Some of them offer the ability to use their product internally (as traditional iPaaS) to integrate your systems and automate business software and externally by enabling connectivity for your product and its users.
This potentially allows you to kill two birds with one stone in terms of software integration. It expands the footprint of the new integration capability within your organization, helping you to automate internal processes. It also increases the overall awareness of and competency using the embedded iPaaS, because more people on your team will potentially be involved.
Optimized for Non-Technical Stakeholders (Maybe)
Often in a SaaS company, the engineering team's time is limited. That means when it comes to getting integration projects completed, often to primarily serve the needs of the marketing, sales, or partnership teams, there can be a lot of prioritization challenges.
Most embedded iPaaS products include low-code editors that help non-technical or semi-technical people build out integrations. Using an embedded iPaaS opens up the possibility that you don't need an engineer to build every product integration. This potentially reduces that prioritization friction.
Now, this is a big MAYBE in terms of whether it's a pro or, as you'll read shortly, a con.
Low code tools focused on non-engineering team members are right for some organizations and wrong for others. Don't just take it as gospel that this is necessarily a win. You must really think about who's on your team and how they want to operate. If your team wants to keep integration within the product and engineering teams, there are other ways to get similar effort reduction advantages that don't involve using tools that aren't really built for and will often frustrate engineers.
Cons of Using Commercial Embedded iPaaS
With every decision there are downsides as well. The following are some potential cons to consider when looking at using an embedded iPaaS to enable SaaS connectivity for your software product.
Limited Control
Your user doesn't care that you use a commercial product for integration. They expect the integration that you provided them as part of your product to just work.
Things go wrong with integration. Data falls on the floor. Servers go down. Someone responsibly managing integration software can reduce the risk of bad things, but not to zero.
Consider what happens if things go wrong. Do you trust that the vendor is going to be there to solve it quickly? Are they even capable of doing so? What will their perspective be on your customer's experience?
You are giving up a huge amount of control about a critical part of your product to another vendor. Integration is fundamentally different from email or payments or the other types of features that you might outsource to an embedded offering. Integrations are primary features for your product, and if you implement them on embedded iPaaS you have much less ability to ensure their function.
Vendor Lock-In
Connectivity is an important, fundamental set of features for your product. You don't get to choose whether it's important, because your users demand that it is.
Choosing to use an embedded iPaaS product to build out those connectivity features has advantages, but it also means that you've locked yourself into a vendor for a very important part of your product. This is a decision that is not easy to undo, and it's very expensive to undo.
People rarely rip out a working integration for the sake of replacing it. That's because migrating or redoing an integration is hard and sometimes expensive work. And, ripping out to replace an existing integration means spending that money and doing that work to end up roughly where you started. Unless you are replacing a failing integration, the juice is often not worth the squeeze.
If you use an embedded iPaaS to set a bunch of your users up on a bunch of those integrations, you've now signed up for the responsibility for what happens if your relationship with the embedded iPaaS vendor sours. What if they go out of business? What if they're acquired? What if they triple their price?
Committing to an embedded iPaaS is more like a marriage than it is like a friendship, so the appropriate due diligence should be taken when considering the approach.
Potential for Higher Cost Overall
It's generally less expensive to make your dinner at home than it is to buy the same meal at a restaurant. You go to the store, you buy the ingredients directly, and then you do the work yourself. The restaurant has to pay someone to make the food, pay for the rent, and all the other expenses a restaurant takes on. So, on a per meal basis, you're exchanging your time for a marked up meal and a different experience.
The same is true when using a commercial embedded iPaaS for your integration approach. There is a lot you don't have to do (like architecting a high scale integration framework), but you're going to pay for a marked up version of it.
The tradeoff is worth it if the embedded iPaaS significantly reduces your time to market for the integrations (it takes you three hours to make microwave macaroni and cheese). The product might also offer benefits you couldn't build yourself (a gourmet meal beyond your home cooking skills). But, if your team is pretty integration-capable without that extra commercial product, you may take on unnecessarily marked up costs in addition to the vendor lock-in.
Open source alternatives do limit your exposure here as well.
Impact on Enterprise Value
Both the vendor lock-in and the potentially higher operating costs that embedded iPaaS brings may also have an impact on the value of your business. This is particularly important to consider if you are backed by investors who expect a return on the investment they put into your company.
If you build integrations on an embedded iPaaS, you do not own the integrations. You are borrowing them (and paying to do so). This creates a critical single point of failure for the business, which adds risk. It also means you are effectively renting what might be seen as an absolutely fundamental set of features. A potential acquirer or investor may flag that, causing the company's value to be perceived as lower.
This is a big reason why venture investors should care about integration too.
Optimized for Non-Technical Stakeholders (Maybe)
Depending on the makeup of your team, the problems your product solves, and how you get work down, the low-code, non-technical focus that many embedded iPaaS products offer may not actually be a benefit. It might be quite the opposite.
You'll often hear engineers scoff at low-code tools, because they make the job harder to do. When you're using a low-code tool to make something happen, you're still programming. You're just doing it using a visual editor, not literally writing lines of code (that's happening under the hood).
If your team is skilled in writing code, the low-code tools actually might get in the way. They give an engineer an unnecessary added layer to think through and it prevents them from solving the problem directly. If you have an engineering-heavy team, this might be a non-starter for the embedded iPaaS conversation. They may simply be more effective without it.
A New Alternative to Embedded iPaaS
Embedded iPaaS is a good solution, but far from a perfect solution. Yes, we are biased, but there are definite cons that you'll want to consider. However, now there is a novel alternative to consider as well.
The biggest advantage to using an iPaaS to build your product integrations is that it gives your team a workflow for doing so. The iPaaS forces you to build all integrations the same way. Hopefully that iPaaS "build" experience covers everything you need, but at the very least, every integration will be built with consistency.
We aske, "Why do you have to give up all of that control just to have a consistent workflow?"
We offer an alternative that sits between the two extremes: giving up control with embedded iPaaS or custom building integrations. It's best for a product team that needs a consistent framework and workflow for integration but who doesn't want to give up control to an iPaaS vendor.
(We're biased, but that is more product teams than you may realize.)
We provide Doohickey, a set of software tools that provides a streamlined integration workflow, but decoupled from the integration software itself. Doohickey is built to run on Open Integration Hub, an open source integration framework that we deploy into your cloud environment, allowing you to keep control of the fundamental integrations, auth credentials, and data.
This solution gives you the pros of embedded iPaaS without most of the cons. It's not right for every team, but it's an alternative that most didn't realize was available. Let's schedule some time to talk through it.
