As a developer or manager of a SaaS platform, you will make certain decisions about what non-core functions to outsource to third party services. Why write your own billing or email delivery systems when there are excellent solutions available. Similarly, you shouldn’t have to worry about connectivity between SaaS applications either.
The current issue is that the creation and maintenance of integration with other apps and services is a developer-intensive task, which doesn’t scale well without additional or dedicated resources. Integration solutions exist, but how do you go about finding the best for your business?
APIs are just the first step
The next generation of API users are not programmers: they’re business users who understand their data and how to make better use of it. So how do you best meet their integration needs? While it might be tempting to let a third party take on the solution delivery task, in the form of a developer building bespoke integrations or an external third party integration platform, not only does this break your relationship with your customer (and potentially expose them to competitor services), but the third party makes 100% of the revenue on your API, paid for by your customer.
Embedded SaaS connectivity is here
An embedded integration platform (or embedded iPaaS) for SaaS companies is a relatively new proposition that resolves these challenges, enabling you to deal with your customers in a scalable, agile, fashion.
With an embedded iPaaS, the creation of integrations is split into two parts: the code and the solution.
The code creates the capability for application A to communicate with application B. Every SaaS company that wants to self-create a direct integration starts by understanding the third party application ‘B’ and coding the communication capabilities. An embedded integration platform removes that need to code, as it creates (and maintains) the building blocks, which means that this part is ‘out of the box’.
The solution is where APIs are instructed to interact to achieve a real-life objective (e.g. data movement or trigger-based action). Here, the embedded iPaaS will power the creation of the solution (using a GUI interface) but you, as the SaaS company, own and create the solution itself.
It means that SaaS connectivity becomes another service (like cloud infrastructure, documentation, messaging, helpdesk and billing) that you can drop in and build your business on, with a visual toolkit that can be used across a wide range of teams. An embedded integration platform, like Cyclr, enables you to rapidly deliver more direct integrations in an agile form, meaning you can adapt and change them quickly yourself.
One of the main benefits to this is that it requires less engineering overhead than if you were to create and manage them from scratch. You can focus on building your product, while simultaneously benefiting your API as it is moved from the cost side of your business to the revenue side. Launching integrations becomes a repeatable process which is no longer solely in the developer’s realm.
All or nothing?
Although an embedded iPaaS solution is powerful, you may not want to use it to deliver every possible combination of integrations that your end users require. Inevitably, over time, you will develop a strategy for how you handle an individual integration request depending on a combination of strategic value and likely demand.
There are three main choices in how you deliver an individual integration:
- Build – where you start from scratch and write code to achieve each integration;
- Design – where you design integrations using an embedded iPaaS solution within your platform (like Cyclr); or
- Outsource – where you deploy a ring-fenced solution that achieves the customer’s integration off-platform (like Zapier or IFTTT);
The best solution is usually the one that combines two of the above to give maximum coverage. Why does this provide a better solution? Principally because it is better to resolve the key integrations natively (Build or Design) and the long-tail off-platform (Outsource).
Choosing the right integration combination for your SaaS
Here are six key questions to help you decide what you should do:
1.
Q: Are my customers B2C or B2B?
A: B2B = build or design, B2C = build or outsource
2.
Q: Is it important that I resolve my customer integration at ‘pain point’?
A: yes = build or design, no = outsource
3.
Q: Is my application lightly or deeply enhanced by third party applications?
A: lightly = design or outsource, deeply = build or design
4.
Q: Are integration requirements consistent across all 80%+ of my customers?
A: yes = build or design, no = design or outsource
5.
Q: What is most important, the source code or the end-customer solution?
A: source code = build, end customer solution = design
6.
Q: Are my customer’s integration needs relatively fixed or do I need agility?
A: fixed = build or design, agility = design or outsource
If you answer all six questions you will see a general weighting towards build, design or outsource. Armed with this knowledge you can look at your platform, and your platform’s users’ needs, to work out the combination that’s best for you.
Daniel Twigg is Marketing Manager at Cyclr, an innovative embedded Integration Platform as a Service (embedded iPaaS) for SaaS applications. A white label and low code platform, Cyclr provides developers with an API connectivity solution that assists with the creation, publishing and maintenance of integrations within their own application, saving time and money in delivering integrations while also appearing to be an entirely proprietary solution.