Integration Platform as-a-Service, or iPaaS, has undoubtedly become one of the big buzzwords within the today’s IT industry. The current IT market is exploding with dozens if not hundreds cloud-based software solutions.
And while many companies readily jumped on this cloud train believing that using cloud application would streamline many business processes and, therefore, optimize their business, they had to realize quite soon that just “being in the cloud” doesn’t really optimize anything. Cloud applications should also be able to work together.
A software’s value is a bit above zero until it’s integrated with other softwares
All right, that was an exaggeration, but the truth is not really far away. The reason is because it’s not enough to have many nice and powerful software solutions helping you with managing your customers, your warehouse, logistics or marketing – you also need them to work with each other. Otherwise, how would you know that you better send your customer X a nice newsletter offering a discount on Nespresso coffee capsules, because this customer ordered a Nespresso coffee machine from you a few weeks ago and is very likely to jump on your offer?
Unfortunately, there is hardly a software solution that is built with the integration possibilities in mind; usually it’s like that: build it first, and then we’ll see if we can connect it to other applications.
An integration platform, which would provide, metaphorically speaking, doors to various software solutions as well as allowing to connect solutions with each other – plug them into each other, if you like, – does not only help optimize business processes. In the long run, such a platform is essential in order to get this explosion of software solutions under control, ensuring a consistent management of data flow, databases, reporting and monitoring tools, and so on.
Yet outside the big marketplaces that have already learned to appreciate the advantages of an integration platform as-a-service, the word iPaaS and the iPaaS concept are still either unknown completely or treated with caution, mistrust or utter rejection. The latter usually happens if there are in-house integrations at play. After all, what do I need an integration platform for if I can build everything I need like e.g. eCommerce integration with Salesforce myself? An objection that is fair enough, by the way, although not entirely farsighted. And I’ll explain later why.
So, what would you possibly need an integration platform for, you might ask?
Imagine you sell a great solution. Will that really guarantee lots of customers?
Ok, imagine the scenario: you are an agency providing online-shops built, say, on the basis of Shopware. In other words, you are a Shopware partner selling their solution to anyone who wants to set up an online shop for their business. You have the knowledge, you have the experience, you have the product that you know is great – how difficult can it be to sell your services?
Actually, it can be very difficult. Unless your client is a start-up, there bound to be some legacy software, either cloud-based or on-premise. If a company has already been using a certain ERP and CRM systems (let’s take Sage and Salesforce as an example) and you cannot provide a way for online shop integration with these systems… well, you can guess the outcome of your sales pitch. And no, it’s not them getting rid of their old systems, it’s you losing a project with them. So, how can you ensure it won’t happen to you?
Basically, you can offer your clients three ways for eCommerce integration:
First option is dead simple: You tell them that you can provide an online shop and you also know that there is a number of companies offering a way to integrate this shop with your client’s legacy systems. Less work for you, more detours for your client – another company to look for, another contact person, and they have to explain their needs all over again. Plus this other company may eventually “steal” your client – after all, they offer more than you do. Not so good.
Second option – what happens in Vegas, stays in Vegas: You perform online shop integration with their legacy systems yourself. Good option if you have the capacity to do that – enough expertise, enough time and the know-how in this domain. There is a way you can still profit from an integration platform, though. Remember, I called this decision to do only in-house integrations as not really farsighted? Here’s why.
If you have already built eCommerce integration solutions for your clients, most likely these were one-client solutions. An integration platform provides you a way to standardize components, making them easily applicable to other clients’ use cases. In addition to that, with all your solutions/ solution components stored on one integration platform, you have all the logs in one place, which makes the monitoring more manageable and the maintanence significantly easier.
And last but not least, your third option: You’ve already partnered with an integration platform provider on other similar projects, you know they have API connectors to the IT solutions in question. You tell your client that you can provide them with the eCommerce integration they need, go back to your partner, explain the case and make appropriate adjustments, e.g. add more custom fields to an otherwise standard eCommerce integration solution. You client is happy, because they get a new online shop that is working in harmony with their other systems, and you’re happy because you yourself have invested considerably less of your own time and resources on the integration, and won a project with the client.
And in fact, one of our current partners opted for the third option a while ago. So, after the idea for this article formed itself in my head, I decided to talk to Christoph Batik from Keynet, our partner and an eCommerce agency offering all-round services for online shops on the basis of Shopware and Commercetools. I wanted to find out how much difference it really makes – using an iPaaS for eCommerce integration needs.
The interview will be published as the second part of the blog article next Monday, May 11.
