Daniel, Cyclr’s Head of Marketing sat down with Cyclr’s CEO Fraser Davidson and chatted about integration. Specifically about enterprise integration and integration creators and how they are helping to reduce development backlog.
Who do you see within companies becoming responsible for enterprise integrations when using an embedded iPaaS?
The great benefit of embedded iPaaS is that it is an entire ecosystem for your integrations. It is built solely for that purpose. There’s no custom development per se going on when you’re building integrations. It is a low-code, GUI environment first which means you don’t have to be a technical developer to deliver an integration. Instead, you’re someone who has an understanding of the customer’s needs, the data flows and data movements. This makes you an ideal integration creator.
In other words, an embedded iPaaS implemented by an enterprise can empower its customer success teams to create and build workflows or prototype them. As a result, integrations are brought to market rapidly.
As well as this while working with an embedded iPaaS, which is effectively acting as middleware between the enterprise’s API and the world. When customer success teams roll out a new integration there isn’t any fundamental development required within the architecture of the enterprise. This is because we are dealing with their public API. In the same way, anybody integrating with it will deal with their public API.
They can therefore add projects on a very tight timeline. These can be achieved without having to go into a development backlog. This means they can accelerate time to market and increase responsiveness.
Do integration creators bypass existing development release schedules/procedures?
Each enterprise is different in its approach to how they deliver integrations. From my experience and Cyclr’s customers, we’ve got clients whose customer success teams will use an embedded iPaaS in isolation. They do this to deliver integrations because they are simple or intuitive enough that they don’t need external input.
On the other hand, we have others that run very rigorous development processes. Whereby no matter who creates it has to go into a rigorous, create, test and publish process.
The beauty of what an embedded iPaaS does is that it joins systems up. So, no matter what your role within the organisation is, you’re looking at the same application. Everyone is documenting the same way. It’s the same methodology, so it’s easier to collaborate.
Whereas if you’re self-building integrations, which is often the case before we, an embedded iPaaS get involved. Then the customer success team will not be involved in the development process. Instead, developers will be building and there will be somewhat of a constant back and forth. Rather than looking at kind of that single pane of glass view of the building, creating, managing and delivering integrations.
How do you see enterprise integration creators from different areas of a business collaborate on their workflows?
I’ve been a bit biased towards focusing on the creation process of integrations rather than the management process. So, as I mentioned earlier an embedded iPaaS provides a single environment for both integration creation and management. This means everyone can see what is going on with the workflows. It also enables users to drill down and query the flows, as well as version and adapt integration flows. This means extending them without having to go through a full rebuild process, or send requests for amendments into the developer’s backlog and wait for them to be actioned at the other end.
People tend to focus on the beginning of a process. But, they’ll realise that integrations are going to be a three, four or maybe even five-year journey. Also, integrations aren’t going to be static over that period, they’ll be picked up and put down once in a white. The benefit of using an embedded iPaaS for integrations is that it enables you to do that easily. As well as be a monitoring system that proactively alerts you when things inevitably change. Things like authentication, data errors and so on.
An embedded iPaaS can tell you the error before your customer does. Thus proactively helping you to resolve the issue and satisfy your customer pre-emptively. A proactive approach rather than a reactive one is 10,000 times better than being reactive to problems.
When it comes to No-Code vs Low-Code vs Code options why should companies look for something that offers options for all three of these techniques?
Firstly, a full code platform takes away some of the speed benefits but it will appeal to deeply technical teams. As well as a lack of speed it’ll also have less flexibility. This means other teams won’t be able to get involved in the integration process. Compared to a platform that can encompass both low-code and full code or no code, low-code and full code. A variety of code options means different teams can view the single ecosystem. Resulting in a standardised approach and methodology to integrations.
On the other end, I think this option is very tempting, is to go down the no-code-only route. But the assumption is made that it’ll be easy. This is because with no-code/low-code everything’s modularised and allows users to simply clip workflows together. However, in our experience, every single enterprise has edge cases that need to be dealt with. It’s very hard, almost impossible to make components for everything to deal with edge cases. It is the edge cases that define a great embedded iPaaS.
At Cyclr we are somewhere in the middle, we are a low-code platform, not a no-code platform. We want integration creators to have the capability to add scripting around Connectors or workflows. This means they can manipulate data and logic to the nth degree that is required.
Are there any examples from customers about who benefits from an embedded iPaaS within an enterprise?
One example of those who benefit from an embedded iPaaS within an enterprise is product management. This is because it can give them a rapid-fire approach to product improvement. For instance, they can implement integration changes rather than add them to a development backlog. It can go into a release schedule much quicker and ensures rapid expansion of one or many integrations.
Another example is the financial efficiency an embedded iPaaS provides. This is great if you’re a CEO or CFO of an enterprise because the toolkit can help your team achieve more. Without you having to recruit more people to the development team. This then bypasses additional costs.
We are hosting a range of webinars discussing embedded iPaaS, integration building and more.
Check out the full list on our dedicated page.
