The omni chaos: everyone thinks they know everything, but no one really knows anything. The reality of today's digital commerce.

The most common systems used today for retail and e-commerce were built from the time when things were more isolated. The store with its POS did not care about e-commerce, e-commerce did not care about stores, and so on.

For everyone except the consumer, that worked in many ways. The e-commerce team could focus on their own online campaigns, and the store on the other hand had great flexibility in handling purchases and returns (made in store). Monoliths in an isolated world.

The relatively few integrations that were offered were about periodically syncing products, prices, customers and the like. It was completely accepted that information could not be transferred quickly. In many cases we are talking about at most once every 24 hours.

Who does what?

As the various systems in use become more capable, the complexity of choosing where the information and logic should sit increases.

Let us take the example of creating a campaign for an omni player. The following are arguments or perspectives that the respective system owners might come with.

• The POS is the best place to create a campaign. Without delay, the store has the right prices and campaign info. With all data in the POS, staff can meet customers with the right information and flexibility in handling returns, gift cards, discounts and so on.

• E-com is the best place to create a campaign. Then we can control content and publishing easily. E-com also has the best campaign engine.

• ERP is the best place to create a campaign. Good for follow-up, and all systems integrate with the ERP anyway. 

• CDP / CRM is the best place for campaigns. Then we can create targeted campaigns for different customer groups. The CDP knows everything about the customer with the 360 view and becomes more powerful by collecting more data and steering the handling of all communication towards the customer.

The arguments above about where a campaign is created are typical of how things work today. It has now become very hard to draw a boundary between the systems. You simply have to think again. Do not focus on the boundaries, put the emphasis on which system is easiest to create the campaign in, and for other systems to integrate with.

Headless does not automatically solve your problems, but it has certain fundamental properties that can motivate placing, for example, the campaign in that particular system. The main properties in its favour are that it is easier to both save and retrieve information with guaranteed good performance. But also that headless is built to work with events and webhooks. The magic of events is that other systems can act when something has actually happened. And it is up to each listening party to decide what is interesting.  

So who should own what?

There are two aspects, the staff and the architecture.

The staff

How easy it is to work with the system, prioritising employees' ability to fulfil their visions and flexibility. Offering a system that enables and does not stand in the way of tomorrow's digital commerce.

With headless and composable commerce come opportunities not previously possible to redirect ways of working and processes. Now it is possible to focus on a system that is actually built for the respective area, rather than, as before, a system that solves everything.

With the new fast-moving and flexible world beginning to open up in the wake of globalisation, you should let go of the thought that "one system should solve everything". Instead, focus on each system enabling the requirements that different roles and departments need in their daily work to be successful.

If we take, for example, content, it should be done by people who work with it. That is why it is most important to find a system that meets the requirements set by the content team's needs. For example, perhaps Contentful or Sanity.io is the right system to work in. Now no consideration needs to be given to whether it also has to work for the product team, the campaign team or the loyalty team. They will make the same choice and pick what suits them.

The architecture

By using different systems, you will also give away a large part of YOUR data to another company. It is important to review who controls it. That can be about how and where the operation is placed, how easy it is to access and modify the information that is saved.

It is after all your information that you own. It is you who should have the power to define what is saved and in what way. The time when an IT vendor defined what a customer, order or product is, is past. Now it is your unique requirements that are the key to success. Commercetools is an example of a system that offers you as a user the possibility to control what, for example, a customer is.

Companies will increasingly be measured by their ability to adapt to change. When new legal requirements come, when a new pandemic is on the way. The winner is the one who sees it as an opportunity and can turn it to their advantage. With Covid we learned that companies with the best infrastructure and software could withstand both the change and scale up.

A final tip is to verify in new systems that there is the possibility to listen to events. A big part of smoother integrations and faster flows is about knowing exactly what happened, and precisely when it happened. By reacting to events you can get more precision and at the same time robustness through the queue systems used to handle this kind of architecture, which for example protects against traffic peaks.

What does this mean for us?

Analyse your requirements and how your architecture meets those requirements, to quickly identify which points you need to change to future-proof your business. Look at a multi-year horizon and draw up a plan for how to migrate systems and architecture to be suited to the omni world you meet today. Of course we at Commerce Mind are here to help if you want. We have many years of experience of building and tearing down modern e-commerce architecture.