Updated on by Fraser Davidson
If we had £10 for every time we heard a potential objection to Cyclr, an embedded iPaaS (integration platform as a service), that was roughly ‘but by the time we have done that we could have built it ourselves. We would probably have at least enough to buy a couple of new iPhones.
It is quite common that development teams want to build tech themselves and building their own integrations is no exception. However, developers may start out confident that they can build quicker integrations than using a toolkit such as Cyclr. We’ll be honest it is probably true, BUT only for the first integration.
A Slow Start Leads to Rapid Gains
Let’s face it honesty is the best policy, so yes it is going to take a little bit of time to get familiar with a new toolkit and there will be some back and forth to build and test application connectors for the client. There will also be some tweaks to the client’s API as a result of using Cyclr. While I don’t forget, if you embed templates into or on top of your UI then there will also be some UI work to complete.
So, there is some set-up required, but that is normally for any software you use, the TV you install etc. Therefore, ‘yes’ it will take slightly more time than creating your own native integration. However, here comes the big BUT and the big DIFFERENCE which is, for integration numbers 2, 3, 4, 5, 6 and so on this is where an embedded iPaaS will win. EVERY TIME!
Why is that I hear you ask? Well, once you are all set up in Cyclr, connectors are working, API is in tip-top shape (thanks Connector Team), the UI works and you now understand the integration tools. All you now need to do is activate that connector in a few clicks, and you can’t beat that in development time.
Not only will the development be quicker, but when those integrations need to be adapted, amended and wrangled then an embedded iPaaS (cycle) will be quicker.
The Reduction in Maintenance Payoff
Much like investing you aim to set aside resources now so that 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 significantly reduced integration maintenance costs.
All integrations require maintenance, and this can be down to API deprecation (either your own or the third party you’re connecting to). As well as the 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 the core, allowing you to filter through the changes when you see fit. This is achieved without taking up developer resources or having to touch your application’s central source code.
Therefore, 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 with Embedded iPaaS Platform
Finally, another key reason for committing to enabling integrations through an embedded iPaaS platform is to introduce integration standardisation. When native integrations are manually coded there is little way of ensuring code consistency from integration to integration. This can be down to numerous reasons such as the different ways services have been created. As a result, developers are forced to get creative when it comes to creating useful integrations.
This can also lead to another roadblock, developers themselves (sorry!), it is because developers are all beautifully unique and have their own slant when it comes to formatting and standards. Therefore, when it comes to maintenance it can be tricky for a different developer to take ownership of another’s code.
For example, Bob was in charge of coding integrations, but he sadly leaves the organisation. This means Frank has to pick up and understand Bob’s work. If Bob and Frank use Cyclr, then they use a common platform for integrations. So, if Bob leaves, 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 (embedded iPaaS platform) and in a straight race to that ‘next integration,’ we might be beaten by an in-house team coding direct. However, we know that we can beat development teams on all the other integrations that come thereafter.