Integration and API news for developers

The Cyclr Onion – Unpeeling the Layers of Native Integration

9th March 2018

I wanted to write a layman’s guide to how Cyclr works. To describe what we do in simple terms and to describe the three ‘layers’ of the Cyclr onion that make up our product.

Firstly, what do we do?

When you buy any software application (eg. Salesforce) it typically works very well as a stand-alone solution. However it will work even better if it is can communicate with other applications you use. Just like dinner together is better than dinner alone!

For example, when a record is updated in Salesforce that it be automatically updated in your email application (eg Benchmark Email). You get efficiencies through integration. You save time and things work better. We enable integration, or in other words we enable communication between software applications.

However, our core business is not enabling integration for individual end-users themselves. Instead we focus on helping the software application companies deliver integrations to their own end-users from within their own platform. This means that software companies can better help directly resolve their end-users integration requirements without having to push them to another third-party to help them.

The software company could achieve this themselves by recruiting developers to self-develop an integration solution. But this can be costly in time, maintenance and financial expenditure. It is also sometimes rather tedious work (but we like it lol).

Cyclr sells an easy to use, robust, solution that saves software companies time and cost in delivering integrations whilst also appearing to be an entirely proprietary solution to the software company itself. This is often called IPaaS (Integration Platform as a Service). However, IPaaS is a general definition that catches many different methodologies, so we prefer IMPaaS (Integration Management Platform as a Service). This is what we do.

So how does it work?

Our ‘magic sauce’ is that we have a connector ‘engine’, with the ability to very quickly map and deliver against APIs, providing a workflow solution that can very quickly enable the end-users of software applications to ‘do stuff’. But that is not layman and frankly isn’t the ‘how it works’ bit.

There are three principal components to the Cyclr product.

Peeling Back The Layers of Integration

The Connectivity Layer

Component one is a ‘Connectivity Layer’. In here we have a pre-existing, ready-made, library of connectors that enable communication between software applications.

Think of a connector like being a plug at the end of a cable connected to the application. It is ready to be plugged-in to somewhere else. Developers can very quickly screw these plugs on as we have already done the work on understanding how to build the plugs (every plug is unfortunately different!). So if I am company X and I want to integrate with salesforce I just activate the pre-existing Salesforce connector/plug and *bam* my company X application can now communicate with Salesforce.

We also have the ability for developer to very quickly self-develop new proprietary ‘connectors’ and save time.

The Orchestration Layer

Component Two is an ‘Orchestration Layer’. What does this mean? Well basically it is all very well having a connector to company X and a connector to company Y. However, they actually need to do something with each other for it to be valuable. If they don’t do something it is like having two people in a room not talking to each other.

The orchestration layer lets you effectively instruct the connectors as to what you want them to do – eg. “Get me the list of people who have just signed-up on Mailchimp and put them into my New Customer Account in Salesforce, then please check this every day and keep it updated”.

We achieve this by enabling the developer, or any other member of your team, to draw workflows (think a typical flow diagram). This then instructs the Cyclr system what needs to happen and Cyclr makes sure it happens. It is called activating a workflow, or making the two ‘plugs’ talk to each other. Real world problems are now being resolved.

We can also get super complex and enable 3, 4, 5 ,6 7……. plugs/applications to communicate with each other in the same process, but that probably goes above the layman level and is for a later blog.

The Presentation Layer

Component Three is the ‘Presentation Layer’, or in other words the ‘How do you want it to look?’ layer.

Here we offer a variety of ways that the software company can display the Cyclr application and let their users ‘turn on’ or activate the integrations. The software company can either choose to completely design their own ‘skin’ or they can use some simple, brandable, components that we have already built. We are very very flexible, the client can basically choose their own outfit.

And that’s it………

We help software companies build and use plugs, resolve real world problems and deliver it as if it was a part of their own solution, which it is!

Sometimes these things are even clearer when explained one on one so don’t hesitate to get in touch!