Updated on by Fraser Davidson
If we had £10 for every time we heard a potential objection to Cyclr that was roughly ‘but by the time we have done that we could have built it ourselves’ we would have……… at least enough to buy a couple of new iPhones.
Development teams can have a tendency to want to build themselves and to have confidence that they could build quicker than by using a toolkit such as Cyclr.
And we are going to be honest here, it is possibly true………
……..but only for the first integration.
Slow Start Leads to Rapid Gains
Why lie? It is going to take a little bit of time to get familiar with a new toolkit. It is going to take a little bit of back and forth to build and test the connector to the client application. It is possible that there may be some tweaks the client will want to do to their API as a result of using Cyclr. If you embed templates into, or on-top of, your UI then yes there is going to be some UI work.
All in all this is going to take some time to get set-up and to get familiar with. So ‘yes’ it may take slightly more or slightly less time than creating your own native integration.
However…… (and there was always going to be a however)…… the big difference is for integrations numbers 2, 3, 4, 5, 6……… 10, 15…… 100+ – this is where and Embedded iPaaS platform is going to win every time.
Once you are set-up in Cyclr, the connector works, your API is tip-top, the UI works and you understand the tools (and the foibles), then activating a new connector is a matter of a few clicks. And you can’t beat that in development time.
Moreover when those integrations need to be adapted, amended, updated and wrangled – then Cyclr is also going to be quicker.
The Reduction in Maintenance Payoff
Much like investing you aim to set aside resources now so later on when you need them you have a matured pot to make the most of. Like this, Embedded iPaaS is a development investment that pays off in the long run through the significantly reduced integration maintenance costs.
All integrations require maintenance. This can be down to API deprecation (either your own or the third-party you’re connecting to), changing of authentication types or through user led improvement requests.
Embedded iPaaS platforms, such as Cyclr, centrally manage API connectors, so any necessary API changes are done at its core, allowing you to filter through the changes when you see fit. All without taking up developer resources or having to touch your application’s central source code.
So while your developer may say it’s no trouble to self build a native integration make sure they are taking into account the long-term maintenance.
Integration Standardisation for all the Team
Another key reason for committing to enabling integrations through embedded iPaaS is integration standardisation.
At the moment native integrations are manually coded with little in the way of ensuring code consistency from integration to integration. This can be down to the vastly different ways services have been created, forcing developers to get creative when it comes to creating useful integrations.
This leads to another blocker in code consistency; the developers themselves. All developers have their own slant when it comes to formatting and standards, so when it comes to maintenance it can be tricky for another developer to take ownership of another’s code.
If Bob was in charge of coding integrations and leaves, then Frank has to pick-up (and understand) Bob’s work. If Bob and Frank use Cyclr, then they use a common platform for integrations and if Bob leaves then Frank is already familiar with Bob’s methodology (though we would all miss Bob of course).
It is true, it does take some time to get your arms around Cyclr and in a straight race to that ‘next integration’ we might be beaten by an in-house team coding direct. But we know that we can beat on all the other ones that come thereafter.
