From monolith to composable: how to successfully move your e-commerce website to the cloud without losing specific developments?

That said, most current SaaS solutions limited by standardized APIs no longer allow added personalization. 

So how to make your move to cloud a success without compromising on the uniqueness that your company’s value is built on? Follow these steps to meet the challenge.

Specific developments in SaaS: what are the restrictions?

What are the most common specific developments?

The most commonly deployed specific developments include:

• Integration of third-party solutions offering enhanced features over the solution provided natively in the monolith (often beginning with new search and product recommendation engines).
• Implementation of specific management rules built into interfaces for data import/export or post-integration product data reconciliation.
• Creation of personalized data reports.
• Development of features to build business-specific scenarios, including packaged solutions, specific ways of accessing products (selection assistance, product configurators, etc.), pricing and loyalty management rules...
• And the list goes on!

What challenges come with these specific developments?

By opting to replatform to a composable commerce architecture, companies face several major challenges:

1. SaaS solutions currently provided by publishers do not allow for integration of specific developments at the core of platforms. They only offer configuration and a visual design to match the brand identity. They often provide comprehensive functionality to cover business needs, but they will not host specific developments or the additional features previously available to customers or employees: this means you will need to conform to a standard.
2. These SaaS solutions now interface through standardized APIs. When called by a solution, APIs supply or integrate a predefined data schema. It is no longer possible to develop these flows on the e-commerce server, to transform entry files into data expected by the database or to reconcile files from different sources: these platforms expect to receive these inputs from an external source in a pre-processed form.
3. APIs generally need to be called in order to respond and supply or integrate the requested data: very often, they will not take the initiative to export a given order. Another system must “give the order” for APIs to perform a task.

Given the constraints imposed by these new standards, the following steps represent a solution to avoid pitfalls when moving to cloud in the transition from your old monolithic e-commerce website to a SaaS solution.

Move to cloud | Step 1: Build a target architecture around a middleware solution

SaaS e-commerce architectures, particularly MACH (Microservices, API-first, Cloud-native, Headless), break functional domains down into components that need to be made to communicate with one another.

▲ Breakdown of e-commerce platforms into components in composable commerce architectures

These components mainly interact through API calls. This means that you need to have middleware: acting as a coordinator, it will provide instructions to each component and gather their responses.

Make sure that your middleware is able to:

• coordinate API calls and flows for each component;
• consolidate and map out data from various sources into the formats expected by recipients;
• create “buffer” databases that consolidate different pieces of information and then supply them, once complete, to the various recipients, such as the e-commerce website.

As for front-facing APIs, they will be called directly by the headless front to present the data.

Move to cloud | Step 2: Break away from specific developments in e-commerce websites

The headless approach offers the chance to deploy highly varied user experiences. It provides great freedom in terms of brand identity and feature scenario building.

At the core of SaaS solutions, however, there is little or even no room for business-related specific developments: developments involving a logic, management rules and data that lie beyond the native scope.

The central question to ask yourself now is: “how to manage our specific development legacy? ”.

Several answers are possible depending on the specific case, and one analysis method is to categorize features into application domains:

• CMS (Content Management System), where editorial and promotional marketing content is produced and published;
• PIM (Product Information Management), where the product database is managed, and products are enriched and published in channels like e-commerce;
• OMS (Order Management System), where the consolidated view of stocks and their locations is managed, as well as dispatching of e-commerce orders to be handled;
• Search (search engine), where product lists, search results, thesauruses, boosting and burying of products in natural results, etc., are managed;
• Pricing;
• Promotions;
• CRM (Customer Relationship Management), customer accounts and loyalty programmes;
• “In-house” features that set you apart from the competition;
• Front end (the e-commerce website presented to the customer), where scenarios and highlighting of content, products and promotions are found.

The method to apply is as follows: 

1. Identify and classify specific developments carried out

2. Measure their business value (e.g. improved referencing and visit numbers, higher average basket value, increased add-to-basket and transformation rates, reduced number of returns, streamlined tasks for employees, simplified coordination of sales activities, and so on)

3. Decide on the future of these developments, which will take one of the following paths:

• Decommissioning

Many of these developments are legacies of the past, or obsolete methods that now form part of a technical debt to be cleared. Moreover, remember to rethink your business processes so as to do away with some of these developments.

• Reorientation to the right tool, to be more in line with the technical and functional scopes of specific information system components

Some specific developments were carried out on the e-commerce platform with the aim of compensating for information system shortfalls. For example, a development that groups together products into packaged offers actually falls within the scope of a PIM solution, now essential; or a heavy workflow for stock management is the responsibility of an OMS.

• Transposition of pure front-end scenario building to the headless front provided for that purpose

Developments specifically linked to your brand’s user experience are transposable to the headless front, without difficulty, as long as it only involves page performance according to the browsing context (who is the visitor? what is their behaviour on the website? etc.)

• Ring-fencing of business critical developments, representing specific knowledge or contributing expertise-based value that are part of the brand’s differentiating factors.

Some specific developments do not fit into any of the above categories. Take a typical example of an online feature that perfectly illustrates a brand’s expertise: a technical configurator for snowsports products that ensures compatibility between skis and bindings, taking into account the customer’s height, weight and skill level. This kind of development must be kept as it is part of the brand’s DNA.

The correct approach is to ring-fence this feature: 

• Extract it from the e-commerce website;
• Make it a standalone application within the information system and expose it using an API via the middleware;
• Consume it via the e-commerce website, as well as in the shop, the fitting area, and so on, as this feature has now become intrinsically omnichannel! 

Move to cloud | Step 3: Plan and implement

The fundamental transformation of the architecture, required by new e-commerce platform standards, means that a large part of the information system itself will need to be updated. Consequently, you will also need to create an IT roadmap, the complexity of which will vary according to the IS architecture’s level of maturity, make the related technology choices, and then implement the roadmap. 

As e-commerce has now become crucial for most brands, “big bang” approaches are often ruled out. A step-by-step approach to feature decommissioning and relocation, in small groups, by reimplementing them on the existing solution, is a secure approach that ensures you can: 

• Gradually check feature transfers and the robustness of the new architecture through A/B testing;
• Progressively unload specific source code from the existing platform and improve its performance more rapidly;
• Try out the new architecture and exposed services on different channels (such as a sales application) before deploying them on the e-commerce website.

So the key to a successful move to cloud for your new SaaS e-commerce platform is to adopt a composable commerce approach built around services exposed by middleware.

This SaaS direction is becoming increasingly widespread among publishers. It concerns e-commerce, as we discussed in an initial article, but also a growing number of functional domains in your information system – Product Information Management (PIM), Order Management System (OMS), Warehouse Management System (WMS), Middleware, Enterprise Resource Planner (ERP), Marketing Automation, Customer Relationship Management (CRM), etc. – that are speeding up digital transformation towards composable, service-oriented systems.