Moving to composable commerce is a journey, not a project. Rather than jumping from one platform to many tools, brands can switch from one to two. Then, iterate in smaller steps, selecting only what is needed and evolving a stack over time.
Hello everybody, it’s so great to be here. Thank you for the warm introduction. My name is Filippo, the co-founder and CEO of Commerce Layer, which is a powerful and flexible commerce engine that can be the commerce component of your composable commerce stack.
Who in the room is working on e-commerce projects, like brands or agencies? Okay, cool. You may be familiar with this diagram, which illustrates how e-commerce development has evolved over the last 10+ years. Until a few years ago, brands used to buy a single solution, a platform that was supposed to do everything out of the box. However, the reality was, and still is, that these monolithic platforms can't provide everything you need.
Developers started looking for alternatives, leading to the separation of the front end from the back end, creating a faster website, adopting the Jamstack approach, and splitting the monolith even further through a composable architecture. Composability can extend to the front end with micro front ends. The benefits of this approach include flexibility, vendor lock-in reduction, and quicker time to market. We'll discuss these benefits in more detail during this talk.
One common objection is that this approach, while sounding great, can be complex. However, it's important to remember how difficult it is to customize a monolithic platform, leading to technical debt and a poor developer experience. Instead of thinking of composable as a big project, view it as a journey and take an incremental approach.
The Strangler pattern is a helpful approach. Instead of replatforming from one monolith to another, you take the monolith and gradually extract existing features into external components. You do this in iterations, moving from composable level one to composable level two, until the monolith is entirely replaced.
Composable begins with just two components. Starting at level one of composability, two components are enough to be composable. This is just the beginning, but you've already begun introducing the composable mindset within your organization.
Now, let's look at a practical example, specifically a product page. If you're working with a monolithic application, where do you start your composable journey? There are various possibilities, but following the Strangler pattern, you might begin with a quick win, like improving image delivery with services like Cloudinary or Imgix, which can enhance image quality and page load times.
The next step could be replacing the search engine with a microservice, such as Algolia. Another option is focusing on commerce by integrating Commerce Layer, which allows you to introduce pricing, availability, and checkout functionality while keeping the monolith.
Identity management is another component to consider, using tools like Auth0 to enhance security. Finally, changing the design and architecture by introducing a headless CMS can be a significant step, but it requires other components to be headless first. Consider making other components API-first before implementing the headless CMS.
There are many possibilities, and you can choose the order that makes the most sense for your organization. You might start feature by feature or go incrementally, focusing on international expansion, brand-specific implementations, or other strategies.
I write about composable commerce on my personal blog and at composablecommerce.org. Feel free to check it out and subscribe if you find the content valuable. Thank you, and I hope this information was helpful.