Skip to content

ONEiO Unplugged: Thinking beyond the API

Hi Janne, thanks for joining us again for another ONEiO Unplugged. In your last interview we talked a lot about migrating services across different platforms, this time we want to dig a little deeper into the underpinning technology itself to achieve large multi-vendor solutions.

Q: Can you tell us about some of the challenges customers face with their more traditional uses of APIs?

Janne: In all honesty it’s really quite rare to see a good API. There is a common misconception – probably created by tool vendors – that APIs are a silver bullet for bringing complex systems together. In reality, in its most basic form; an API is just a means to enable external communication. It’s a socket to plug into, rather than an actual method of managing and integrating, so there is nothing more sophisticated involved in developing a passable API. This can often lead to sizeable difficulties around implementation with more complicated requirements, which I have seen cause a great deal of frustrations and delays for end users.


So the biggest challenges are often based around the customers’ expectations of what an API can do for them and within what timelines. I think this expectation comes from tools vendors over selling what their API can achieve for the customer ‘out of the box’. The configuration and implementation of a successful integration is underplayed in order to market the simplicity of a product. This is actually why many of our customers have ended up coming to us; in order to help them establish a more consistent and reliable method of genuinely managing their integrations.

Q: Interesting to hear. So when you are working with a new customer and looking at these sort of setups, what are the first opportunities you look for to speed things up and get some more reliable integrations in place?

Over the years we have developed a wide range of tools and functions, which can quickly mature the management of integrations. With that in mind, the first things we look for with new clients is how we allow them to let go of the technical complications and focus on what they actually want to get out of an integration. We do this by using our pre-existing adapters, which only take a few hours to tweak to work with any application and API to setup integrations, which would otherwise take days or weeks to do manually.

This is greatest kind of quick win for us, as it allows us to immediately take away the pain caused by complex integrations, some of which may have been hanging around for a year or more. There is nothing better than quickly turning a conversation about the technicalities of an API into a discussion about the goals and objectives linked to that set of applications.

In addition to this, it is really great to see how our customers light up when we get all their integrations running through a single system, which also isolates each connection and its communications. This is especially good when systems with seemly incompatible APIs can not only be quickly setup, but also managed through a single system allowing you to now connect that API to all your other systems too.

Q: So where does the modernising of API technology fit into this?

A: The APIs themselves are not really changing or modernising in any way. It is more about the technology and approaches we can now take to manage the data produced by APIs in order to create a single method of managing a huge amount of integrations and communications.

IT teams will often look at failing or underperforming APIs and ask ‘what changes can we make to the code here to make this work more effectively?’. On the surface this seems sensible. However, in reality by adding MORE CODE you are actually just making things even more complex and harder to manage later down the line. The real answer lies in using adapters like ours to link an existing API to a centralised place; where code, process, rules and changes can all be created, managed, tested and modified in one place.

Q: This sounds great, I can see why this is becoming more popular approach. What are the real life business outcomes you see coming from managing integrations this way?

Yes, we have seen massive increases in demand for this sort of solution in the past few years. Sometimes the results can be difficult to get your head round until you have actually seen it in action.

That said, the best thing that comes from adopting this approach is that more and more integrations can be implemented. When businesses spent months and months fiddling over complex integrations, the idea of adding can be pretty terrifying! So using quick wins with existing integrations is a really important part of the process to give the customer the confidence they need to start making the most of the systems they have invested in.

Simplifying the management of integrations also reduces the pressure of needing highly trained staff in place to maintain and troubleshoot them. Meaning staff of all levels can start taking on integration tasks, including large scale changes and new setups. The technology and the time required is no longer an issue, which is great.

Q: What does the future look like for traditional API integrations, will they still exist in a few years time?

As I mentioned, APIs are not going to, nor need to modernise much. APIs will be needed in the future for sure. They are an essential tool for 3rd parties to communicate with your systems and there is no way any vendor will risk isolating themselves from that method of integration. In theory as the middle stage and adapter style platform like ONEiO become more mainstream the vendors will be able to worry less about building on top of their own APIs to create these solutions and focus more on creating simpler and easier to use APIs.

Of course rubbish APIs are there very thing that keeps ONEiO in demand! But joking aside, we are working towards a future where great IT teams and businesses are built around seamless integrations and we will always play our part in carving out a better future for IT pros, whatever the technology presents next.