--
In this article series, we cover how we approached building a true global e-commerce platform and ecosystem for a large international FMCG company. The company wants to sell directly to the consumer in all of their countries and languages, for all of their brands, in any (existing) channel where adding commerce functionality is relevant.
In this first blog post we will cover the scalability requirements of such a system. The next part is all about technology and architecture and we end the series with a third post explaining everything about the business results and impact.
First of all, we should give you an idea of the scalability requirements of a global e-commerce platform. Or should we say, platforms?
Typically, large FMCG players have a presence in a lot of countries. In our case, the company has a presence in most markets in the Americas, Europe, Asia and the Pacific.
Local branches of these companies, called OpCo’s or CBU’s, are often self-directive and autonomous, meaning they will operate on their own, guided by a global headquarter. Possibly they were even acquired in the past and sometimes these CBU’s span more than one country. In other words: they have their own requirements and wishes that you should be able to accommodate for.
Different markets mean different products and brands. Sometimes brands are local, sometimes they are global. But all in all, a large FMCG player has quite some brands they sell throughout the world. And all of them can potentially be sold through online channels.
Besides that, CBU’s will probably want to ship their products using a local logistics partner that will take care of warehousing and actually shipping the product to the customer. A local ERP integration is often also a requirement as well, for accounting, forecasting, etc.
So to conclude: we want the platform to be homogenous to CBU’s and at the same time it has to be flexible enough to cater for local needs.
Above all it should be built to last!
In order to prevent reinventing the wheel for each e-commerce channel that is about to be opened in the company, and at the same time speeding up the strategy of global expansion of e-commerce channels, the company opted for a single e-commerce platform solution that is rolled out from a central organisation, and supported from the local level.
The solution should cover basic e-commerce primitives, such as front-end UI/UX, product catalogue, payment, order management, logistics, as well as the hosting infrastructure. This way local branches can focus on their business, instead of realising the technology (which is essentially the same for each country).
The idea is that we augment existing touchpoints with e-commerce functionality. Content and experience platforms are thus not within our scope — they already exist and we leverage them as a vehicle to bring commerce to the consumer. We deliver a complete infrastructure that enables e-commerce in a market.
The benefits are evident:
Time to market: we don’t have to build a solution per country or brand, just deploy an existing solution again, and tailor it.
Maintenance burden: only a single platform to maintain.
Contracting: global contracts with vendors leverage economies of scale.
Company-wide sharing of experiences with running e-commerce platforms and features that are developed.
We can leverage existing traffic investments to existing touch points .
Technology becomes a commodity, which allows a local branch to focus on the business instead of worrying about infrastructure.
All of this will result in a faster, more cost efficient and smarter approach to executing e-commerce within the company.
Centralised solutions like these however, can be very restrictive to local organisations. There are often local needs/requirements or business models that need to be embedded in the system. These kinds of requirements tend to end up at the bottom of the ‘global’ backlog and will never be prioritised by the ‘central’ team, as they are not a core feature. In the end local organisations are likely to eventually ‘bypass’ centralised solutions because they are simply too slow to address market needs.
So, how to acknowledge this potential restriction and create a system that is both scalable in terms of rollout, maintenance, its tenancy model and the costs involved, and at the same time offer flexibility towards local markets, allowing for (potentially locally built) deviations?
If you translate the organisational structure/model of the FMCG company to the tenancy requirements for our platform, we must consider:
Multiple countries & languages — both UX and product catalogues
Multiple brands (& accompanying product catalogue) per country, in multiple languages
Multiple currencies (& tax rules), sometimes even per country
Multiple/different logistic partners per country
ERP integrations that deviate per country
Payment providers based on market needs
And last, but not least: multi-channel/touchpoint integrations
Not to mention the non-functional requirements that we should take into account, a.o.:
Security requirements and standards
Local regulatory requirements (i.e. privacy & data protection laws)
Performance requirements — an e-commerce site should be fast
Unpredictable load on the platform — regardless of the load, we should remain fast
Browser & device compatibility — on any touchpoint
Integration requirements — we need to be able to integrate into existing IT environments (based on AWS)
The ability to extend the platform for local market conditions, by potentially local implementation partners
The ability to support the platform from a local perspective, by a local partner
And last, but not least, we want the platform to be cost-efficient
To build a platform that behaves like we want in all of the mentioned multi-tenancy conditions, while remaining maintainable and scalable, has been (and still is) quite a challenge!
In the next part of this series we will dive into the foundation of this platform, that is built using a combination of infrastructure-as-code, AWS, serverless microservices and a Headless Commerce solution called commercetools. Also, we will talk about how to scale that to lots of CBU’s in a maintainable way.
We also invite you to have a look at our blog, our website, and the roles we are currently searching for.