Enterprise Service Bus: How to remain technically flexible in eCommerce?

After the last few articles in this blog were of a more strategic/entrepreneurial nature, I would like to discuss something more concrete here, which I think has not yet fully penetrated the minds of many CIOs and eCommerce managers. Yesterday, I was once again visiting an up-and-coming eCommerce pure player to discuss a potential project. The company operates a niche store and has continuously expanded its presence in Europe over the last few months, increased its marketing activities and significantly boosted sales.

(Reading time 3 minutes)

In terms of infrastructure setup, the situation is similar to what I often encounter: a store system, an ERP system, a CRM system, three external logistics partners, many external payment and fraud protection systems. And lots of interfaces. It seems that almost all systems are connected to each other via some kind of individual interface. This setup is usually not a deliberate choice, but has evolved over time as the company has grown.

Interface dead lock

However, such a setup creates many dependencies and typically leads to an overall system that is very difficult to change. Not to mention maintenance, especially when APIs of individual systems are changed by upgrades, which should not be the case in theory, but unfortunately happens quite often. Anyone running such a setup quickly becomes trapped in their own technical structures. This means that changes, e.g. the introduction of new systems or the replacement of existing systems, always turn into major projects. This is because the interfaces to peripheral systems usually have to be adapted. If processes and dependencies are to be fundamentally changed, things get complicated. You are already trapped in your very own IT corset.

Front-end systems should be easily interchangeable

Few CIOs realize or see that the need for agility comes from the business. While back-office systems are generally not (or do not have to be) replaced very often, front-end systems are subject to a certain amount of pressure to innovate. Don’t believe me? Imagine you have your front store system that delivers mobile and desktop content. Maybe you also have a customer service app and maybe this system also provides in-store functionality and content in your brick & mortar stores (if you have any). Are these touchpoints the end of commerce development? Is there even an end to this development? You know as well as I do: No, we will see new and improved customer touchpoints in the near future, which we will have to supply from our commerce systems. And you need to be able to provide these to your customers in a timely manner. After all, you don’t want to be left behind by the competition.

Enterprise Service Bus as the backbone of your commerce system

Enterprise Service Bus systems bundle the services from different systems in the company and in turn make them systematically available to other systems. The information can be aggregated, consolidated, event-based or transformed. Exchange formats can be changed. In addition, the processes can be subjected to workflows or delayed. This makes it relatively easy to connect new systems and transfer functionalities from one system to another. The following before/after illustration shows the clear structuring of eCommerce IT using an ESB.

Before:

 

After:

 

Increasing spread of ESB systems

The vast majority of RFPs that I receive do not provide for the use of an Enterprise Service Bus. If the RFP comes from a veteran IT department, I can understand that. However, if it was created or accompanied by consultants, I can only shake my head. Not being flexible in eCommerce is quite simply a fundamental disadvantage. Advice cannot be given in this respect, even if (or especially if) for cost reasons. My customer from yesterday is exemplary in this respect. On the one hand, he does not have an immediate need for action. On the other hand, he clearly sees that his company needs to be flexible and is therefore pushing ahead with decoupling the systems so that he can simply add new touchpoints and replace existing ones in the future. With his infrastructure, he will then be ready to take up innovations and use them for himself when his competitors will still be busy managing large migration projects.