Just the other night I was having dinner with a friend of mine, who has little knowledge about the IT industry in general, let alone the “application integration” part. And so when I was trying to explain what kind of an animal iPaaS is, she asked me quite a justified question at some point, “Why would anyone buy a product like yours, isn’t it easier to just re-create it yourself? I mean, especially if a company has quite a number of developers, they sure can assign a few to make such a… whatever that is, instead of spending extra money on you.”
One might say she thinks this way because she has no clue, but strangely enough, it is not uncommon to see this kind of attitude from people who actually DO work in IT, and even DO have some understanding what syncing various data sources means. Indeed, why on earth would you want to buy someone else’s integration platform if you can, theoretically, for the same money build ten such platforms yourself?
I haven’t started this article to list a number of reasons why it’s probably not a great idea to build an integration platform from scratch on your own, unless your company’s name starts with S, and ends with P, consisting of three letters in total (in case you think I’m being sarcastic here – I’m not). After all, it’s everyone’s own decision whether they want to make life more difficult for them or not. All right, just kidding. Sort of.
What I would like to share with you is a story why IT guys who actually WANTED to build their own integration platform, gave up this idea in favour of using a ready-built iPaaS product.
No worries, I won’t bore you with all the details in this article. I wouldn’t want to give away everything anyway, especially considering that this is actually part of a customer’s story, into which I personally invested quite some time and efforts. It would be unfair to just throw it around, wouldn’t it? So, let’s compromise: I’ll publish some juicy part of the story here, but you’ll have to download the full version if you want to read the rest.
But before that, let me outline a few scenarios to see if we are on the same page.
Scenario #1: You are a SaaS company, and you are looking to build out a number of integrations for your customers. You have your own core product you need to take care of, and so you’re now looking for a solution that will allow you to more easily manage integrations for your product.
Scenario #2: You already have clients for whom you develop integrations between certain systems, let’s say between e-commerce platforms and ERP solutions. But something bugs you. You notice that these integrations follow the same pattern again and again, and so you ask yourself if there is a way to create some kind of integration templates, which you will be able to reuse for next clients after a subtle tune-up.
If these scenarios somehow resonate with you, then we are definitely on the same page, so keep on reading. And even if they don’t, you can keep on reading anyway. Maybe, you’ll get inspired by the story and come up with some new, brilliant idea for your own business.
Who the story is about:
The protagonist of this story is Ben Burch, CEO and Founder of Infinite Codeworks, a UK-based systems integrator, though they are so much more than just systems integrators, to be fair. The company was founded in 2010 and has a solid reputation in the UK for system integrations and custom software development, not least due to their business-oriented approach to problem-solving. Now enough of the foreword, here’s what Ben shared with me in an interview.
What’s wrong with re-building integrations from scratch?
At least 50 per cent of all the projects we have involve some kind of integration. The problem was that we were able to carry out such projects only as point-to-point integrations.At least 50% of software implementation projects involve some kind of integration.Click To Tweet
This meant that each single point-to-point integration was its own version for just one particular client. For another client, we had to build the same integration from scratch, as a completely new version. Then yet another version for a third client, and so on.
As a result, support became harder, and rebuilding the same integrations over and over again cost us a lot of time and effort.
Coming up with the ‘integration layer’ idea
We realised that the majority of our customers shared a core business logic, for example getting product updates. But every situation was slightly different.
So, we decided that we want to get to a point where we have a series of integration templates, or connectors, for the systems that our clients use, mapping common business logic. So that when a client comes with some specific requirements, we are much faster to adapt our out-of-the-box templates to what they need.
As a matter of fact, we actually decided that we needed some kind of an underlying integration layer, and that was what we were literally about to start building right before we came across elastic.io iPaaS. We wanted to be able to push any kind of data from one system onto the layer, transform it there if necessary and get those elements on the other side of the layer in another system.
Specific requirements for specific needs
It was necessary that integrated systems were to be connected not to each other, but to the integration platform. The reason we want it this way is because, once we have built a connector to a system, we want to be able to reuse that, which means that it shouldn’t be fixed to a destination.
Therefore, we wanted to have a disconnected input and output so that we have a much more flexible tool.
From the technical perspective, the integration platform was supposed to provide many different ways to collect data: either via polling, or fetch the data, or having some kind of an API or a Webhook. We have always advocated for the API-based integration, so that criteria, too, was an important part of the solution we envisioned.
Investing efforts into re-building integration platform is counterproductive
Our business is all about delivering the right solution to our clients, that is what we focus on. Whilst we have the technical ability to build the underlying messaging and integration platform, it would be diverting us away from our core business. […] I liken it to using cloud servers vs. building and configuring your own hardware: Sure, we can do it – but should we?
* * *
I said I wouldn’t give away everything, so I have to make a break here. But you are all too welcome to find out about the whole story after downloading the full interview on its dedicated page.
In the meantime, let me finish this article with Ben’s quote that, in my humble opinion, simply nails it.
We want to be certain that all our efforts, all our energy goes into making sure that the clients get the solution that they need, and not into building an infrastructure for ourselves.