It is no secret anymore how fundamental it is for companies to become customer-focused and to move every possible transaction to a digital channel, to speed up efficiency and to free resources for innovation. But exchanging the underlying e-commerce platform every five years to stay up to date is neither efficient nor effective.
Often the complexity of the existing B2B rules, created in several years of exercise, make the perspective to replatform a daunting thought.
A traditional "lift & shift" approach requires to "bet" on the right platform and have an intensive phase of development and customization that does not start generating added value until an often painful go-live process. If you ask any tech-savvy architect today, the way to avoid those painful replatformings in the future is to migrate to a micro service architecture, obviously cloud-based. What does that mean?
Migrating to a headless, API-focused e-commerce platform
It means that the big "monolith" platform should be replaced by an orchestrated set of micro services that can have independent development cycles, and that can easily be upgraded and re-implemented to adapt to newly evolving business needs. There won't be a need to upgrade "the whole thing" times and times again.
Many major vendors nowadays offer a "headless cloud solution" for e-commerce: what that means is that they offer a set of APIs for e-commerce functions, nothing more, nothing less. Those APIs cannot be customized, at best: configured. If your business needs something different, of course your team can build a new micro service for that.
Actually, if you want to set up a state-of-the art-architecture, besides your commerce engine's APIs, you have to put together a quite extensive shopping list:
What do you need to set up a future-proof e-commerce platform?
- A frontend interface with one of the trendiest frameworks of choice
- A continuous integration environment with source code repository, build pipeline, test units, probably generating a containerized version of this frontend
- An API gateway to handle the public REST APIs, usually specific for your cloud platform
- Some configuration management tool for the gateway
- An O-Auth implementation to manage the access of the APIs to the underlying systems
- Realistically, a form of API aggregator/orchestrator like GraphQL to optimize the number of frontend calls
- A continuous integration of choice for your micro services. As for the frontend, you need a code repository, build pipeline, test units, containerization management
- All those services need to dialogue with each other: the best way probably is an asynchronous event manager like Kafka
- Of course at least one instance of a database for your data, probably more if you want to use RDBMS and NoSQL
- A storage solution to keep all the assets that cannot be in a db
- This complex structure needs advanced monitoring tools, to be able to identify the right source of problems.
- At least one log aggregator to be able to understand what happens in your ecosystem.
Don't get me wrong: all those things are really needed and represent the real state-of-the-art architecture. There are countless of papers and real cases where the advantages of it compared to "monolithic" solutions are very well explained. All those points require products, licenses, very specialized competences, and most of all: a powerful vision and agency to keep everything working smoothly coordinated. The point I want to raise is: How can a company, running a monolithic e-commerce platform today, get there?
What is e-commerce replatforming?
Gathering competences, building procedures, and designing an architecture from scratch can take a very long time until finally going live. Plus, along with more freedom comes more responsibility. What frameworks to choose? Will they all work together? I have been involved in different projects where a company was taking that journey.
Oftentimes getting to something ready for production takes waaaay longer than any lift and shift replatforming. To make things worse, in the meanwhile, it generates zero value add for the business. Furthermore, the focus of a manufacturer or retailer company should be to build and sell products and services, not to set up an extensive IT R&D department. Unless the name of the company is Amazon, of course.
Imagine you need a van for your business. A powerful, reliable, comfortable van.
When you go to a dealer, imagine what you hear was: "Here, I can sell you a very nice and well performing engine. Just add to it gears, distribution, tank, tires, chassis, body, tires and suspensions, seats, a dashboard, some windows, a coat of paint, and… voilá! You'll have your own perfect van. Sure, the engine itself costs almost as much as any average van. The total cost of the van and its maintenance, sorry, I can't tell." Is this something your company would be after? I hardly believe so.
So, what other options are there? Am I really saying that you should forget all this and that you should just survive through endless cycles of legacy replatforming?
No.
How to succeed in e-commerce replatforming
I really believe that the architecture described above is the way to go. But! I also believe that companies should not need to walk all the journey all by themselves. So, place your bets wisely. Out of experience, I believe in the Intershop platform for that matter. It provides a very reasonable way to achieve a dream architecture, and it takes care of most of the problems for you.
In previous projects, with the resources at hand, I would have never been able to set up a Continuous Integration infrastructure and automated deployments from scratch, until Intershop provided a working solution out of the box. Along with that, the Intershop ecosystem takes care of many aspects and still lets you choose something else if you want to.
The commerce solution itself manages the cloud infrastructure, monitoring, build, deployments, if you want it to. The provided PWA comes with a whole set of features and its own build/deploy process. Use it, or build your own. CMS, PIM, Order Management? It gets you covered, until you may need something more complex. Intershop has micro service templates and a discovery service. If you run Dynamics 365, integration micro services are at hand.
Do you think it’s not worth to redo an entire pricing model just to apply a small customization? - You can still customize the core instead.
Do you want to implement the services that really differentiate your offer? - Focus on that and develop a dedicated micro service.
Use Oracle or SQL Server as configured by Intershop. Or add your own if you have other preferences. All in all this approach makes more sense to me. The journey goes to the same direction, but you can walk it at your pace, and never be alone. In the meantime, you can have a time-to-market of 3 months (yes, it happened), and start generating business and revenue on your new shiny ecosystem, that will grow with you.
Probably it will be the last time you’ll need to replatform.
I put all my experience into a whitepaper that walks you through the most common scenarios of a replatforming project and shares practical insights on how to solve the replatforming dilemma. I really recommend for you to read it:
