Composable Commerce: Everything You Need to Know

E-commerce has evolved once again.

Maybe you are already familiar with the Jamstack and headless commerce. But there is a new addition to modern web development architecture.

Composable commerce.

Craziest thing? You might already be using it without knowing.

So with no further ado, let's see how this new paradigm wants to push the limits of headless e-commerce.

Here's what we'll be exploring:

• What is composable commerce?

• What are PBCs (Packaged Business Capabilities)?

• What are the advantages and disadvantages of composable commerce?

What is composable commerce?

Composable commerce is a term that was first introduced by Gartner in a report from June 2020. It was used to define a new digital approach to modular commerce. Granted, like every modern approach out there, it comes with its load of “buzzwordiness”. But let's not be cynical and actually look into this concept.

Composable (or modular) architecture means that every component is pluggable, scalable, replaceable at any moment without affecting the other parts composing the application.

For those of you familiar with the Jamstack, composable commerce could be considered a next step. In fact, composable commerce is a broader category that encompasses the Jamstack and the MACH (microservices, API-first, cloud-native, headless) architecture (we'll explore that later on).

Unlike the Jamstack, there is no adamant focus on statically generated assets.

The whole idea behind composable commerce is to give brands (and their developers) the flexibility to adapt to technological and behavioral changes. It's all about enabling developers to select and assemble a customized solution that fits their particular needs.

The fundamental principles of this modern approach are:

1- Modular: All the components you use (shopping cart, shipping platform, CMS, analytics, etc.) can be interchangeable and deployed independently.

2- Open: You're not locked into any solution. Each "module" can work and be integrated with any app you're already using or will be using—bye-bye monoliths.

3- Flexible: You can create whatever solution you need. It's all about freedom and flexibility to customize your stack to build a solution specific to your business case. No more feature creep from "do-it-all" software.

4- Business-centric: Software and web apps that fit the business needs and not the opposite. Business and customers' habits change rapidly (we saw it particularly last year), the stack needs to adapt just as fast.

TL;DR:

The evolution of composable commerce

Monolithic e-commerce solutions are just starting to lose steam.

First, let's get our timeline straight.

1. Monolith

Not too long ago, you could find everything you needed in one place—but that came with drawbacks. For one, your website was subject to the offering of your chosen solution. You were restricted by what features your platform offered and had to carry the weight of all the extra unneeded features.

Front-end and back-end tied together also meant that customizing your store was a more arduous task. Technological advancements were also challenging because they depended on how fast monolithic platforms made the switch (if they ever did).

Since everything was coupled together, customizing your code and bringing in new features was a complex task. These dependencies meant that a small hurdle could impact the whole system. As the app gets bigger, simple change becomes are more complex because components are more tightly coupled and entangled. In my opinion, that's kind of a big no-no...

You're probably already familiar with classic WordPress. Well, that's a good example of monolithic architecture. It's the living part of your app and therefore shapes it. Need to add a feature? You need to install a new widget in your app or build it for WordPress, adding bulkiness and heaviness.

2. Headless commerce

Headless commerce came in to solve problems we were facing using those all-in-one platforms. Thanks to the decoupling of the front-end and back-end, control is given back to developers. All enabled a higher degree of customization & flexibility, portable backend data, better data structure, and better multi-platform experiences. It uses modern APIs, JavaScript frameworks, and sometimes static site generators to create fast front-end experiences.

Strapi is a good example of headless architecture. It's a headless CMS that generates rest API (a business standard that everyone can use), allowing you to retrieve the content you entered in any environment (SSG, SPA, SSR). Since it doesn't have a head and only serves you your data, making changes is a lot easier.

I like to think about headless commerce as a developer-oriented architecture.

3. MACH

The MACH architecture is an umbrella term, like Jamstack, for a new approach to building software stacks. The word itself is an acronym for the MACH stack:

• Microservices replace traditional monolithic architectures by allowing applications to use services that are uncoupled and deployable on their own.

• API-first exposes functionalities so services or applications can interact together.

• Cloud-native takes advantage of SaaS (software as a service), so everything is always up to date and scalable.

• Headless decouples the front-end from the back-end to give more flexibility.

The "decoupling" in a MACH architecture isn't solely about back-end (CMS) vs. front-end (JS frameworks/SSGs). It's more about independent units of functionality, hence the focus on microservices and APIs. It is a very enterprise-centric architecture.

It breaks down more traditional applications in favor of a modular architecture we've seen earlier. Comparable to headless, the key here is to decouple every component. It allows you to choose the best tools for your (or client) needs and deploy them rapidly.

As a developer building modern web apps, you're probably already aware that monolith products with all-in-one solutions are a thing of the past. Instead, modern stacks only contain features you need, allowing instant releases to production and fast changes to meet clients' needs.

The other advantages of using the MACH approach are similar to those you would get from the Jamstack:

• Flexibility

• Scalability

• Performance

And some new-ish:

• Always up-to-date

• Malleability

• Swappable solutions

As I like to joke with my colleague, Michael, the modern web is all about wrapping wrappers in new wrappers.

Let's take Algolia search as an example. It's a platform resolving one specific problem rather than being a solve it all solution. It's not a framework that shapes your app but a microservice for your app. If your app has some contacts or products, you can feed them to Algolia. The information is then classified on their end and made available as search results to your users when needed. It can connect to your app via an API, live in the cloud, and has no head.

As I like to think, it's an infrastructure-oriented architecture.

4. Composable commerce

And now for the main event. Think of composable commerce as a new layer wrapping the headless, Jamstack, and MACH together to build future-proof commerce solutions. Thanks to the lego-like components building blocks, developing applications that evolve with business needs and change the way people consume them are now easier than ever.

These business needs are solved using something called PBCs (packaged business capabilities).

Think of composable commerce as:

1- Business-centric

2- Modularity-focused

By its broader nature, it isn't as prescriptive as to the other approaches. It also aims at transcending the e-commerce experience and unifies all customer experiences, regardless of their touchpoint. It also puts business cases first, unlike the other approaches, which often put developer experiences first.

To fully grasp what this architecture is about, it helps to know that this is really business-oriented. As a web developer, it won't probably change the way you develop your next e-commerce app.

What are PBCs (Packaged Business Capabilities)?

Packaged business capabilities are building blocks for applications representing business components combined with APIs. Each of these software components can work as a standalone without direct external resources. They can also be served and used directly by the end customer. Each PBC solves one specific business problem.

They are composed of data schema and multiples APIs. Therefore, they can be considered as a cluster of microservices.

PBCs are headless, envelop the essential features to solve a specific business need (like inventory management), can be deployed independently, and are scalable. In addition, they bring the complexity of building an entire e-commerce application down by bounding all the microservices into a more straightforward unit, easier to deploy each with their own APIs and logic.

In a nutshell, PBCs are applications or services build for specific needs (CRM, shipping, inventory management, tax management, etc.). It's the way you bring your application to the market (how it's wrapped) instead of microservices used to design, compile, and implement those apps (how PBCs are built).

What are the advantages and disadvantages of composable commerce?

Why would you want to build your next e-commerce solution with compostable commerce? And what are the challenges you could face?

The advantages

Here are the benefits of composable commerce:

• Build a customized customer experience all over the board: Since you cherry-pick the best solutions for your need, you can tailor your final applications to fit your customers' needs the best. You'll also ensure that the UX is the same independently of what end-point your application will be served on.

• Gain more flexibility: Much like with headless commerce, you are free to build something you really need and make changes along the way. Everything is customizable as opposed to the strict cookie-cutter templates you get from monolithic platforms.

• Faster and easier to grow and scale: Business' needs and customers' habits evolve quickly, and composable commerce architecture enables you to do so. You are no longer locked with the solutions offered by big platforms and can swap solutions components to suits your needs.

The Disadvantages

• Manage multiple tools and platforms: One thing we can give to the all-in-one platforms is that information and data are not segmented in multiple tools. Using microservices means that you'll need to manage many different solutions for each specific need you'll have.

• A more DIY approach: You need to be ready to build your solutions on your own and connect every component. It's not as easy as using a tool with everything built-in. And since you have multiple services coming from multiple places, you'll need to ensure that the design and UX are uniforms across the board.

Closing thought

Well, how to get started, you might be wondering? The good news is that you probably already are. If you use the Jamstack approach to web development and already use headless solutions, you are, in some way, using a composable commerce architecture.

It will be interesting to follow where this new approach will take modern e-commerce in the future. Going headless has already changed the way we build the web, let's see if we can bring it to a whole new level!

What are your thoughts about this new approach? Let us know in the comments below.

Liked this article? Hit the share buttons below.