Daniel, Cyclr’s Head of Marketing sat down with Cyclr’s CEO Fraser Davidson and chatted about integration. Specifically about enterprise integration and the considerations they need to take when accelerating a SaaS product roadmap.
What do you define as a large enterprise in the context of integration and services?
From the perspective of Cyclr’s customer base, at one end we deal with young startups. These young SaaS organisations have an MVP or a very early-stage product. They are principally interested in amplification. This is the number of connectors/connections and integrations they can put behind their own VP or product. They will then accumulate a customer base over time, as they then grow.
On the other end, we deal with very large enterprise organisations. These have a degree more maturity, quite a degree more maturity. This means it can be very difficult to define ‘enterprise’ in terms of time because some businesses accelerate enterprise quickly, and some take longer.
Generally, an enterprise is going to have hundreds and 1000s of customers. As a result, it’ll be processing data at scale. Unlike a young startup, they’re already going to have an integration suite that they’re managing and dealing with. Rather than amplification an enterprise will be more interested in growing their connectivity suite.
Any size of SaaS is going to have different kinds of considerations when looking at Embedded iPaaS.
What are the key enterprise integration considerations for a larger enterprise concerning integration and connectivity?
There are several key considerations an enterprise will be looking for regarding an integration service provider. This is because they’ll already have a suite of integrations. As well as a team applied against those integrations. This team is building the integrations and managing them. Those of you who are familiar with integrations, know that there’s no such thing as a single integration. They are constantly being adapted through customisations and extensions.
As a result, they’ll have different and specific buying criteria.
Standardisation
Firstly, they will look for applications with a standardised approach to integration delivery. This means an organisation with a common methodology such that each of their developers or whoever’s using the platform will take the same approach. Therefore work can be inherited from one person to the next.
Data Volume
As well as integration standardisation they’ll also be considering data volume. This is because they’ll inevitably be dealing with millions and millions of API calls. They will therefore want to keep things as efficient as possible from a processing and cost perspective.
Data Processing
Next, they’ll consider data processing. There will inevitably be a preference for keeping data processing under their umbrella (private cloud).
Scalability
Finally, the last consideration is the scalability of integrations. Developers are phenomenal at integrations and usually, integrations sit within the development process. However, they can often be encumbered from a time perspective and take longer to achieve. This means an enterprise needs to utilise other teams. Typically customer success teams understand the customer’s needs, goals and data to increase integration delivery speed.
What types of enterprise integrations should organisations avoid relying on an embedded iPaaS to deliver?
Often people confuse an embedded iPass for a high data volume pipe, which an embedded iPaaS isn’t suited to. For example, if you’ve got incredibly high volumes of transactions flowing through. These transactions are being pumped into a database. This data is being analysed and you hope to pick things out from it. An Embedded iPaaS wouldn’t be the natural conduit for that.
Instead, that is much better suited to that type of IFTT type of methodology. When A happens, B needs to do something. Alternatively, C happens over here and D responds in this fashion, with an element of logic involved within the process. This means you are still helping your customers use your product, or their third-party product by sharing the information. However, this type of data throughput is not well suited to an embedded iPaaS.
Should an organisation look to use an embedded iPaaS, like Cyclr, to deliver all their enterprise integrations?
Funnily enough, I wouldn’t recommend that you use an embedded iPaaS, to do everything. If you imagine you’re an enterprise, you’ll already have an ecosystem of integrations and a large client base. Some of these existing integrations are technically critical to your product.
For instance, the enterprise has developed a calendar application. It is technically critical for the success of your product that you integrate with Google Calendar seamlessly. This technically critical integration is something I suggest should be built by yourself and be native to your platform.
In comparison, I think when integrations are commercially critical but not technically critical is when to implement an embedded iPaaS. Taking the previous example further, your calendar application needs to integrate with a CRM. This will add meeting details to a calendar invite when one has been booked. This is a commercially critical integration which should use the embedded iPaaS to extend and amplify it to the nth degree. This means increasing the number and variety of CRM integrations you can do.
An organisation can also start expanding their integrations with the likes of apps such as Zapier or IFTT. Prior to committing to an embedded iPaaS. These applications can be used to call APIs and build simple integrations. Then when more customers adopt a specific, new or niche Connector (API) the enterprise can move towards an embedded iPaaS.
The brilliant thing about Cyclr is that it can do both the technical and long-tail. As well as the commercial integrations an organisation requires. I believe that an organisation should have an integration strategy that spreads integrations based on priority. I can see a point in the future where large enterprises will use multiple embedded iPaaS systems. For instance, a highly vertical-focused iPaaS that is designed for specific integrations such as financial services. Then more generalised embedded iPaaS options this is where I’d categorise Cyclr. An embedded iPaaS that can achieve generalised requirements with a variety of different integration verticals.
We are hosting a range of webinars discussing embedded iPaaS, integration building and more.
Check out the full list on our dedicated page.
