written by Alain Veuve MD, Switzerland
Enterprise Service Bus: How to remain technically flexible in E-Commerce?
Enterprise Service Bus: How to remain technically flexible in E-Commerce?
About author Alain Veuve Alain Veuve MD, Switzerland

After the last posts in this blog were more of a strategic/entrepreneurial nature, I would like to raise a more concrete topic with this post. It is a topic that I believe hasn't quite yet reached most CIOs and those responsible for E-Commerce within companies. Yesterday, I was – as so often – at an up-and-coming E-Commerce pure player to discuss a possible project. The company operates a niche store and has continually increased its footprint in Europe during the past few months. They have also ramped up marketing and significantly improved revenue.

Regarding the infrastructure setup, I found a situation that I often encounter: One shop system, one ERP system, one CRM system, three external logistics partners, many external payment- and fraud protection systems. And numerous interfaces. It seems that almost every system is interconnected with every other system through one individual interface or another. Usually, this kind of setup isn't chosen deliberately; rather, it develops over time parallel to corporate growth.

Interface deadlock

Such a setup creates many dependencies and, as a rule, leads to an overarching system that can only be changed with great difficulty. Not to mention the maintenance, especially when APIs of individual systems are changed through upgrades – something that in theory should be avoided, but unfortunately happens quite often in daily practice. Whoever implements such a setup is quickly caught in his own technical structures. This means that changes, e.g. introducing new systems or replacing existing ones, usually degrade into large projects. The reason being that, for the most part, interfaces must be adapted to peripheral systems. It gets complicated as soon as processes and dependencies need to be fundamentally altered. It is at the latest here that you are trapped in your very own IT corset.

Frontend systems should be easy to exchange

Only few CIOs see or realize that the necessity to be agile arises out of the business itself. Whereas back office systems aren’t usually replaced, frontend systems are under considerable pressure to innovate. You don’t believe me? Picture this: You have a front-store system that delivers mobile and desktop content. In addition, you might also have a customer service app and maybe this system also provides in-store functionality and content for your brick-and-mortar stores (should you even have any). Are these touch points the end of your commerce development? Will there even be an end to this development? You know as well as I do that this is not the end. In the near future we will encounter new and improved touch points that we need to provision from our commerce systems. And you must be able to offer these touch points rapidly to your customers – after all, you don’t want to be left behind by your competition.

Enterprise Service Bus as the backbone of your commerce system

Enterprise Service Bus solutions bundle services from different systems in a company and systematically offer them to other systems in turn. In such a setup information can be aggregated, consolidated, based on events or transformed. Exchange formats can be changed. In addition, processes can be time delayed or subjugated to workflows. In this way, it’s relatively simple to integrate new systems or transfer functionality from one system to another. The following before- and after illustrations show the clear structure of an E-Commerce-IT system using ESB.

Increasing distribution of ESB systems

The vast majority of RFPs that cross my table don’t even consider implementing an Enterprise Service Bus. I can even understand such behavior if the RFP comes from a traditional, established IT department; if, however, the RFP involved or was even written by consultants, my only reaction is to shake my head. To not be flexible in E-Commerce is simply a fundamental disadvantage. For consultants to not consider this, if only due to costs (or maybe they should be especially diligent in that case), should not be accepted. My customer from yesterday, on the other hand, is exemplary. Though the company doesn’t have any immediate requirements, it clearly recognizes the necessity to be flexible. This has led the customer to begin methodically decoupling his systems. In this way, new touch points can easily be added and existing ones replaced. The customer will then be ready with his infrastructure to integrate innovations, and to implement them long before the competition, which will be busy with large migration projects.



Full article