Just the other night I was having dinner with a friend of mine, who has little knowledge of the IT industry in general, let alone the “application integration” part. And so when I tried to explain what kind of an animal integration platform as a service – i.e. iPaaS – is, she asked me quite a justified question, “Why would anyone buy a product like yours, isn’t it easier to just build it yourself? I mean, especially if a company has quite a number of developers, they sure can assign some of them to make such a… what was the name again?, instead of spending extra money on you.”
One might say she thinks this way because she is not from the industry and has no clue about the whole ‘as-a-service movement’, when you rather rent software instead of building it. But strangely enough, it is not uncommon to see this kind of attitude from people who actually DO work in IT, and DO understand the importance of syncing various data sources. Indeed, why on earth would you want to buy someone else’s integration platform if you can, theoretically, build one yourself for more or less the same money?
Well.
The real-life integrations story
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. That is, unless your company’s name starts with S, ends with P, and consists 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.
I won’t bore you with all the details, I promise. I wouldn’t want to give away everything anyway, 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. Here’s juicy part of the story, and you can 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. Now, you’re 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. 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. You might get some inspiration from the story and come up with some new ideas 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. 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.
[click_to_tweet tweet=”At least 50% of #software implementation projects involve some kind of #integration. #SaaS #API” quote=”At least 50% of software implementation projects involve some kind of integration.”]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 should have been able 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.
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.
