How should you start decomposing your eCommerce?

Composable commerce is picking up steam as the next step in the evolution of eCommerce. More and more businesses are considering decomposition projects to change their monolithic solutions in favor of a composable, or microservices-based, API-first, cloud-native, and headless (MACH), architecture. 

If you’ve decided that your eCommerce is ready for a decomposition project, you might be asking yourself what the next step is. How should you approach such a project correctly? MACH architecture offers many viable paths as well as end results, which makes the planning phase doubly important. 

Understanding the different alternatives you can take will help you understand the market better and choose the best approach for your company while mitigating risks. It will also let you be more in control of the process and talk to software development companies as equals instead of being told what’s best for you.

Here’s what you need to know to approach eCommerce decomposition confidently.

Planning an eCommerce decomposition 

As you know, composable architecture, as opposed to monolithic systems, provides you with nearly endless possibilities to customize your eCommerce ecosystem to your needs. You can pick and choose any modules that you like and use them in any configuration. This freedom means that there are as many viable paths that you can take while setting the ecosystem up during the process of decomposition. Once you’ve implemented the mainframe that all the different modules plug into, such as commercetools, you can move on to any module you like. You can also start with a simpler approach and use headless architecture rather than going the fully composable way.

Because of this, there’s no one “correct” path to decomposing your eCommerce infrastructure. It all depends on factors such as:

• What ecosystem you’re running at the moment and what possibilities it presents. 
• What your priorities, must-haves, and nice-to-haves are. 
• What your budget and deadline are.

Luckily, this is fairly easy to work out. With the way we handle decomposition projects, a single meeting with our experts is enough to cover all these bases and propose an optimal path for you. 

MACH tech market

There’s a lot to choose from in terms of both the process and the tools. The market offers many mature composable solutions, and you can be sure you’ll find one that suits your needs. MACH platforms offer modularity, flexibility, and scalability, which empower businesses to create tailored eCommerce ecosystems fit for a rapidly changing digital landscape.

A few important resources can help you select the right tools for you. First, make sure to check out our “Reference architecture for commercetools” eBook, which covers the key modules that go into a composable commerce implementation. Second, you can use our eCommerce Trend Radar to gauge the general direction the market is heading. Finally, there’s a good chance you’ll find this blog post useful. It goes over the key factors you should consider while choosing the right partner for your decomposition project.

Sample decomposition scenarios

There are hundreds of possible paths toward decomposition, so we can’t realistically provide a rundown of all of them. We still want to give you an idea of what goes into such a project, though. That’s why, in the next part of the article, we’ll go over three possible scenarios for such a project. These are all realistic paths that we proposed to a client of ours who wanted to start their decomposition with the front end. 

Separating the front end is a great angle to start a decomposition project. You’ll be able to see the results easily, and it will be a solid foundation for the next projects. That’s why, even though many paths are viable, we typically suggest this one. Here are the sample scenarios of how this might go.

First scenario: headless front-end decomposition

The first of our sample scenarios is the simplest one. It may be an attractive option if you’re looking for a less committed way to modernize your architecture and would rather test the waters with a smaller project. In this scenario, we’re not changing your current eCommerce platform, such as, for example, Salesforce. All we’re doing is attaching a new headless front end to the existing back-end system. 

Steps of decomposing a headless front end

For this decomposition scenario, you’ll only need to take two major steps:

1. Choose a headless front end

One of the key benefits of going headless is that you’re no longer bound by the default front-end client that your monolithic eCommerce solution comes with. So, the first thing you need to do is to pick a new headless front end that will suit your needs. If you’re after a customized solution with no compromises, building a tailor-made one will be the way to go. On the other hand, if a quick implementation is what you’re looking for, then you should consider Vue Storefront or Frontastic, which are popular and highly capable ready-made front ends. Here’s a short summary of how they stack up against each other.

2. Develop an API proxy layer

The second step you need to take for this kind of implementation is to develop a proxy API layer. Because you’re starting with monolithic architecture that’s not always meant to support headless solutions out of the box, you’ll need to make the two parts communicate with each other. This is where the proxy comes in. Its purpose is to translate the requests and data between your new headless front end and the eCommerce engine. It can be a fairly generic solution that will let you easily connect a different back end if you decide to upgrade it later on.

Benefits of a headless front-end decomposition

The simple decomposition of the front end is the least complex of our three scenarios. You’re just making the front end headless without touching anything in the back end. It won’t open up as many possibilities as the latter two, but it does come with a number of benefits on top of introducing a modern headless front end, which is a big step forward in itself. 

Simplicity

Simplicity can be even more of a benefit than a drawback. You’re not getting the most powerful product out there, but you’re getting it relatively cheaply and quickly. Based on our past similar projects, such an implementation shouldn’t take more than three to four months to complete. Then, you’re left with a capable proof of concept to experiment with and see how headless architecture performs for you. 

Expandability

If you want to go further with this scenario, you can also use the API proxy that you’ll develop to attach other independent headless modules related to the front end. These could be, for example, a content management system (CMS), newsletter module, or ratings and reviews module. 

Future-proofing

It’s also worth noting that if you decide to go further with decomposition, this project won’t go to waste. You’ll be able to easily attach the new front end and most of the proxy layer to a more robust back end when the time comes. In other words, you can consider this scenario a standalone project just as much as the first step to a full decomposition.

Risks of headless front-end decomposition

In comparison with the latter two scenarios, a simple headless decomposition is a fairly safe solution. There’s only one major risk you should take into account: the complexity of integration.

Complex integration

It can be a complex project to develop an API proxy layer to connect the monolithic back end with a new headless front end. You need to ensure seamless data flow and compatibility between two systems that weren’t designed to be connected. 

This may pose some unique challenges depending on the monolith ecosystem you’re running. In some cases, establishing the connection might be fairly straightforward thanks to ready-made connectors available on the market and our experience with many similar projects in the past. In other cases, however, it might be trickier, especially if you’re running an unusual, custom legacy ecosystem.

Second scenario: two back ends in tandem 

In the second scenario, you go a step further than decomposing just the front end. You’re setting up the entire headless ecosystem, front end, and back end while keeping it attached and synchronized with the old monolithic solution. You’re reading this right: in this scenario, you’re running two ecosystems at once. This lets you start with an MPV and gradually expand the new microservice architecture module by module without sacrificing any service uptime in the meantime. It’s the eCommerce development equivalent of doing Jean-Claude Van Damme’s epic split.

Source: Volvo Trucks commercial

How to implement a twin back end 

In the second decomposition scenario, you’re keeping some of the key components that went into the first one, but you’re shifting the focus in a few ways. Here’s what the process looks like.

1. Keep the old monolithic ecosystem

Your old monolithic eCommerce ecosystem remains the foundation of the project just as it was before. You’re keeping all the key systems running, but they’re no longer directly connected to the front end. Now the old back end only serves as a backup of sorts that stays synchronized to the new ecosystem.

2. Develop a new headless or composable ecosystem

On top of keeping the old monolithic back end running, you’ll also build the new headless one. It will need to include the main foundation that you plug the different modules into as well as the modules themselves, such as a product information management (PIM) system, promotion engine, and so on. This will be the default back end that supports your eCommerce, so it needs to be fully functional.

3. Introduce API layers

In this scenario, you’ll need an API layer and a microservice working in tandem. The microservice connects the two back ends and keeps them synchronized. The API layer, on the other hand, connects the headless front end to the new back end. You’re now attaching two systems that are designed to be connected from the ground up, which means that the process should be a lot simpler than in the case of our first scenario.

4. Implement a headless front end

For the most part, this step stays the same as in the previous scenario. You’ll still need to either install a ready-made headless front end or develop one yourself, and the same caveats apply. What changes are the front-end-related modules, such as a CMS and payment gateway, that you’ll also need to implement. In the first scenario, those were optional because you could fall back to the ones provided by the monolithic ecosystem. In this case, that’s no longer an option. You’re building a self-sufficient headless front end, meaning that all those modules need to be in place to make it run properly.

When to go for a twin back end?

While such an approach is unconventional, it makes a lot of sense in certain situations. In a way, it’s the best of both worlds. It lets you build an MVP for a fully decomposed solution at first and then gradually add the different back-end modules while the legacy monolith fills in when needed.  

Transitional solution

This is the perfect transitional solution. Because the two ecosystems are fully synchronized, you can turn off the legacy infrastructure as soon as you implement all the key features of the new ecosystem. Likewise, you can keep it going for as long as you need to complete the migration.

Direct comparison of two systems

This approach can also be right if you’re not sure which eCommerce ecosystem is optimal for you. You can read all the available reviews, check performance benchmarks, and watch all the demos, but in the end, nothing beats hands-on experience when it comes to choosing the right solution. This solution will let you directly compare them against one another and easily turn off the one that you’ll end up rejecting.

Risks of the twin-back-end scenario

The twin-back-end scenario comes with its own set of risks that you should keep in mind. Here are the major ones:

Sustainability

Simply put, this isn’t a solution designed for the long haul. Beyond the time you need to complete the migration, there’s little reason to keep both the systems running and maintained. You can certainly back up your data and infrastructure in a more efficient way. 

Synchronization challenges

It can be a challenge to keep the two back ends synchronized in real time considering they were not designed to work together. You’ll need to carefully plan and implement the synchronization mechanisms to ensure consistent and accurate data.

Resource consumption

You don’t need to pay for two licenses since the MVP development can happen using a trial account, but you can still expect higher costs. Running two back ends means extra costs for hosting and maintenance at the very least. The more robust your system, the more costs will be effectively doubled.

Third scenario: all-in composable eCommerce

Lastly, we’ll take a look at the third scenario: the full composable implementation. It can be both the simplest and the most complex one at the same time. It’s simple because it’s the only solution that’s fully self-sufficient and doesn’t rely on keeping the old monolith running. On the other hand, it’s complex because it doesn’t offer a transitional period. The new solution will need to be fully ready and functional before you release it to your customers. This should be the right choice for you if you’re completely decided on going all in on composable eCommerce and aren’t pressed for time to release it quickly as an MVP.

Implementing a composable eCommerce ecosystem

1. Choose the components

Choosing the right systems and solutions is obviously a part of all three scenarios. However, it’s doubly important in this case because you’ll be setting up the target architecture from the very beginning. If you end up unhappy with some of the smaller modules, they’ll be fairly easy to swap later, but the decisions about the composable foundation and front end will be much harder to go back on. That’s why you should take your time to choose those that best match your needs. You can find tips on what to look for when choosing components in this article.

2. Set up the systems, modules, and APIs

This step follows the standard composable commerce development path that we presented in detail in our “Reference architecture for commercetools” eBook.

3. Migrate your data

Lastly, you’ll need to migrate all the data, such as product information, content, order history, user accounts, and so on, from the old monolithic ecosystem that you’re leaving behind. This might get a little tricky. If you were migrating from one monolith to another one, it might be possible to transfer all the different types of data in bulk. But because of the new composable architecture, different types of data will be going into different specialized modules, meaning that it might need some extra work from you. The migration mechanisms will vary depending on the solutions you choose, but there’s a good chance you’ll find some applicable tips on our blog.

Benefits of the all-in composable scenario

With this scenario, you’re getting the most powerful, uncompromising eCommerce solution available. As you might imagine, this comes with a big set of benefits. Here are the most significant ones:

Complete separation from the old monolith

The previous two scenarios rely on keeping your old monolith up and running. It serves an important role in both cases, but it’s still an element of technological debt that, in a way, will keep looming over you. With this scenario, you eliminate this problem completely and can fully enjoy cutting-edge eCommerce architecture.

Easy integrations

Once fully implemented, the microservice ecosystem offers a unified and streamlined integration approach. With all modules designed to be connected from the ground up, the integration process becomes smooth and intuitive.

Scalability and performance

Microservice systems are designed for scalability and performance. The ability to scale each module independently ensures that the platform can handle growing traffic and customer demands effectively.

Cost

This point might be a little deceptive. Going for an all-in composable MACH implementation obviously won’t be a cheap project in itself. However, if building such an architecture is the end goal for your decomposition, then taking the direct route without any transitionary half-measures will be the cheapest option with all things considered.

Risks and drawbacks of all-in composable

This scenario also poses its own unique risks and drawbacks. Here’s what you’ll need to be mindful of:

Lack of a transitional period 

This scenario requires a complete migration before going live unlike the second one, which allows for a transitional period where both the old monolith and the new ecosystem coexist. This lack of a transitional period might pose some challenges if issues come up during the deployment.

Complexity and development time

Implementing a full composable eCommerce ecosystem is the most complex implementation of the three scenarios. It means setting up the entire MACH architecture from scratch, including both front-end and back-end modules. Because of this, the development process may take longer and be more resource-intensive compared to the previous scenarios.

Higher initial investment

The initial investment in building an all-in composable eCommerce platform might be higher than the other scenarios. After all, you’re building the whole product from scratch all at once. Developing and integrating a complete ecosystem involves significant costs for development, testing, and deployment that you’ll need to take into account.

How to choose the right approach for you

As you’ve probably noticed, there might be some head-scratching involved in choosing the right approach to eCommerce decomposition for you. All of the sample scenarios come with their unique sets of benefits, risks, and drawbacks that you’ll need to weigh against each other. They also answer different needs and priorities: businesses that decide on a simple proof of concept with the first scenario are very different from those that decide to go all in with the last approach. And remember that these are just sample scenarios and not a complete list.

So, where to go from here? If you've already decided on decomposing your eCommerce ecosystem in some way, it might be the right time to schedule a meeting with your composable partner. You can go over your current ecosystem, needs, and priorities together to find the optimal solution for you. MACH architecture offers nearly endless possibilities and viable paths, so it’s doubly important to lean on the experts in choosing the right one for you. Make sure to get in touch once you’re ready to take the next step toward a microservice-based future.