Build or Buy – Choosing an Integration Solution
3rd August 2018
The decision over whether you should build or buy an integration solution is an important one. In many markets the concept of ‘Build or Buy’ abstracts well and a choice between one or the other is easy.
In integration we would argue it is not so simple. We believe there are three viable ways to solve your integration needs. Jumping to the conclusion, we are going to recommend that you pick at least two.
What Types of Integration Are Available?
Importantly, there are three concepts of the type of integration solution you can adopt that we need to deal with:
“Outsource” – where you deploy a ring-fenced solution that achieves the customer’s integration off-platform e.g. Zapier
“Build” – where you start from scratch and write code to achieve each integration
“Design” – where you design integrations using an iPaaS platform, such as Cyclr, that is embedded within your platform
What are the Benefits & Disadvantages of Buying an Outsourced Integration Solution?
The benefit of buying a third party, off platform, solution is that it is massively scalable, and agile, without disrupting your UI.
The downside is that you are not necessarily addressing your customer’s integration requirements at ‘point of need’, the burden is on the customer to resolve any complexity.
What are the Benefits & Disadvantages of Building your own Integrations?
The benefit of building your own bespoke solution is that you own 100% of the code and you directly address a precise solution for your end customers. You are meeting their needs directly in a handcrafted manner.
The downside is that these integrations can be fragile and the cost of the human resource expense to resource and maintain the integrations is high. It is a challenge to scale and is not particularly agile.
What are the Benefits of Designing Integrations with an Embedded IPaaS toolkit?
Designing a solution is where you use a low-code solution such as an embedded IPaaS toolkit that already has the components for connectivity built. Here you can put your focus into designing the customer solution whilst the code grunt work has been done on your behalf. IPaaS solutions tend to be both agile and scalable whilst also resolving the customer’s need at point of requirement.
A Combined Integration Approach for Maximum Coverage
In truth when we speak with customers we always advise that they use at least two of the solutions above.
Design + Outsource
Build + Outsource
Design + Build
Build + Design + Outsource
Why? Principally because we believe that you should 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 the 5 key questions that we think help you consider what you should do:
- Is it important that I resolve my customer integration at ‘pain point’?
- Is my application lightly or deeply enhanced by third party applications?
- Are integration requirements consistent across all 80%+ of my customers?
- What is most important, the source code or the end-customer solution?
- Are my customer’s integration needs relatively fixed or do I need agility?
With these questions in mind, you can look at your platform, and your platform’s users, needs to work out what combination would be best for you.
The table below gives examples as to what combination of integration solutions would work for each use case.
|It is important to resolve the customer integration at ‘pain point’||X||Y||Y|
|My application is deeply enhanced by third party applications||X||Y||Y|
|My application is lightly enhanced by third party applications||Y||X||X|
|Integration requirements are consistent across 80%+ of my customers (focused)||X||Y||Y|
|Integration requirements are inconsistent across 80%+ of my customers (long-tail)||Y||Y||X|
|The source code is most important to me||X||X||Y|
|The end customer solution is most important to me||Y||Y||X|
|My integrations need to be agile||Y||Y||X|
Considering the Volumes of Required Integrations
Depending on the number of integrations you need, you cannot always resolve every single client integration requirement at point of need.
Why? Complexity of presenting an option for every single possible integration within your native UI. Here is a simple rule of thumb on which choices we would make:
|Total Number of Customer Integrations||How many to Build||How many to Design||How many to Outsource||Recommendation|
|3-10||1-5||1-5||0||BUILD + DESIGN|
|11-20||1-5||6-20||5+||BUILD + DESIGN + OUTSOURCE|
|21-50||0||1-25||5+||DESIGN + OUTSOURCE|
|51+||0||1-50||5+||DESIGN + OUTSOURCE|
The 80/20 Rule to Integration Design Success
We are proud of our solution and believe it is an intelligent away to scale your native integrations. But we also believe it is not necessarily the entirety of your integration ecosystem. You should consider the old 80:20 rule. Own the integration solution of 80% of your clients’ integration needs and outsource for 20% of your clients’ integration needs. It is all about efficiency and managing complexity.
If you would like to get a free trail of our embedded integration solution, apply here.