Sennheiser has been a major player in consumer electronics for over 70 years. But their high-traffic ecommerce properties aren’t built in the way you'd expect—in fact, they couldn't build the ecommerce experiences they wanted on a traditional platform. Instead they are part of the growing trend to leave the legacy monolith behind to adopt a composable approach to commerce.

At Netlify’s most recent Headless Commerce Summit, I talked about the decisions that are leading companies like Sennheiser towards composable architecture. The ecommerce use case is one of the most rapidly growing segment’s we’re seeing at Netlify. Below are the industry trends we’re seeing across our customer base.

Digital Commerce Is Exploding; Ecommerce Web Monoliths Can’t Keep Up

In the last few years, ecommerce has grown 10x compared to the prior decade. And mind you, this was already a fast-growing category. There remains a multi-trillion-dollar opportunity, with 81% of commerce still served by non-digital channels. But it's not just sales volume that is exploding. As ecommerce has grown, new sales channels emerged, marketplaces boomed, and the market became flush with competition. Commerce teams that want to differentiate, scale revenue, and protect margins found that their web monoliths couldn’t keep up because they were:

• Slow to iterate on and scale to new markets and channels
• Difficult to differentiate
• Sluggish for customers
• Expensive to update and operate

Composable Commerce Emerged From The Ashes Of the Monolith’s
Failures

We're seeing a massive change in how we build commerce solutions. Specifically, we're seeing a huge shift toward composable commerce: according to MACH Alliance research, 79% of surveyed tech leaders want to increase composable elements in their architecture in the next 12 months.

But what is composable commerce? And what is a monolith to begin with? Let's level-set with a few definitions:

• Monolithic commerce. Monolithic commerce is where one provider takes different functionality, often none of it best-in-class, and puts it in one big solution. For example, a monolithic commerce solution from Adobe (Magento), HCL, Salesforce, SAP, or Shopify will typically include product information, product images, prices, payments functionality, search, customer management, analytics, and frontend elements (such as mega-menus) with limited and clunky customizability. The challenge is if you want to change one part, you need to change all of them. Only that takes years, and you've already spent millions, so you don't.
• Headless commerce. Headless commerce is where you separate the frontend - the web experience layer - from the monolithic backend. The advantage is that you can quickly iterate on the frontend experience without impacting the backend. The disadvantages surface when teams try to plug in specialized components to meet specific business requirements. Some monolithic commerce backends tend to make that challenging or impossible work.
• Composable commerce. As retailers embraced headless content management systems, optimized stand-alone search, and specialized APIs for product reviews, product information (PIM), personalization, and more, we've started talking about composable commerce. Composable commerce is where functionality on the frontend and backend can be pluggable, scalable, replaceable, and able to be continuously improved through agile development.

Remember these monsters? Monolithic commerce software, like these
old convergence devices, tried to do everything—only to do nothing well.
(Credit Joe Cicman for the analogy.)

The Composable Commerce Tech Landscape Is Mature

At Netlify, we've seen firsthand that the commerce category is evolving rapidly. The good news is that there is more optionality than ever before, but the bad news is that making sense of the landscape can quickly become overwhelming, with more and more headless commerce tools coming to the market each year.

To make it easier to talk to, mentally model, and architect for, we've divided the composable commerce landscape into three main pillars:

• Storefronts. Storefronts, is the part of your commerce solution that the user sees and interacts with. It’s the web experience layer or frontend. Most often this is made with an JS framework and using an Orchestration platform like Netlify and in some cases a dedicated storefront service for your commerce backend is added, and the choices here include MACH solutions like Vue Storefront, Commercetools Frontend (formerly Frontastic) and Nacelle. These can be used as part of a pure composable commerce solution, though we often see them on top of monolithic backends. They vary in how no-code vs yes-code they are, and this is a rapidly growing space.
• Product Experience. Several categories makeup the product experience: content management (i.e., Contentful, Contentstack, Amplience & Storyblok), stand-alone search (i.e., Algolia), digital asset management (DAM) (i.e., Cloudinary), product information management (PIM) (i.e., Akeneo, Bluestone) tooling and services around personalization (i.e., Uniform, Dynamic Yield), and lastly reviews (i.e., Yotpo).
• Transactional layer. The transactional layer includes order management, pricing (i.e., Commerce Layer), payments (i.e., Adyen, Stripe), and checkout services (i.e., Snipcart).

A lot of those services are of course also provided in more comprehensive solutions like the headless offerings from Commercetools and BigCommerce.

8 Reasons Digital Commerce Leaders Architect For Composable Commerce

“Arguably, the biggest reason for moving to composable commerce is what it isn’t.”

When it comes to the web and software, we experience a constant evolution, and - once a decade or so - we see more sudden shifts. I believe that this move to MACH and the Jamstack is such a shift and that we're seeing digital leaders drive this adoption because composable commerce enables:

1. Faster time to market.
   A huge benefit of adoption to MACH is enabling your team to ship features 10x faster. When I speak to CMOs, their number one challenge is time to market. And it's no wonder. The large monoliths that combine the commerce platform, template engines, glue code, build tools, customer data, personalization, programming framework, and infrastructure become bloated and ungovernable. Ultimately, the monolithic approach to commerce kills iteration speeds. I sat down with the marketing department of one of the largest companies in the world. They had spent millions on a monolithic platform that left them with a heartbreaking lead time between when marketing had something ready to go live and having it implemented of 32 business days. 32 days!
2. Cost reduction.
   It's expensive to keep doing things the old way. A quarter of IT decision-makers said they spend over half of their IT budget on version upgrades for their legacy systems. On average, companies spend almost two-fifths of their budget on these upgrades. A CMO told me recently that his monolithic tech provider had sold him "everything I need - and everything I don't." The beauty of a composable approach is that you buy - or build - only what you need: adopting one module doesn't carry the cost of buying everything else.
3. Omnichannel experiences.
   A traditional monolith makes it virtually impossible to cater to all the channels customers use today. Every place we share data needs to be accessible as an API. Teams must decouple the vastly different presentation layers from the backend to build the best experiences for each channel. Catering to omnichannel shoppers has become hugely important for retailers today as omnichannel shoppers spend way more. Target reports that they have 40 million guests shopping across channels and that omnichannel guests spend four times as much as stores-only guests. Albertsons shared that omnichannel households spend three times more than in-store-only shoppers and that omnichannel households grew by nearly five times in the last two years. Macy's reports that even in a heavy mall-based environment, the omnichannel customer spends 2.5x - 3.5x more than a single channel customer. It's fair to say that embracing omnichannel is do or die for retailers, and the only way to scale that is to move off monoliths.
4. Differentiation.
   One of the biggest challenges with commerce experiences built on monoliths is that you don't have the same possibilities for creating an immersive standout customer experience as you do in a physical store. As a result, thousands of stores like yours are one click away. Arguably the biggest reason for moving to composable commerce is - what it isn't. It's not the web presence. It's not the templating engine, build system, glue code, or runtime. Those pieces, and all the technical decisions behind them, remain entirely under your control so you can match the technology used on your site to your team and other projects. With a composable commerce stack, you are not bound by specific templates or checkout procedures and are free to customize the customer experience to your exact specifications.
5. Faster web experiences.
   Ecommerce managers know the value of every millisecond. An analysis of customer analytics across 37 brands and 30 million sessions found that 100ms of site speed gives retailers an 8.4% increase in conversions. Because of the flexibility of headless APIs, teams can use the Jamstack approach for web development to generate and optimize web assets in advance and then ship them to nodes across the globe. Coupled with edge functions, prebuilt pages load content to the screen much faster than on monoliths because they remove the latency of going roundtrip back to an origin in another country where the pages still have to be assembled before being served. You can tell when you are browsing a headless Jamstack site because it feels really fast and page transitions are instantaneous.
6. More secure web apps.
   The vast majority of automated malware in the world is targeted against the traditional monoliths because the build process is constantly running and exposed. By decoupling the frontend from the backend and using the best practices of the Jamstack, teams abstract away the largest surface area of attack that you have. At Netlify, we get hundreds of thousands of requests a month that start with "WP Admin": it's just malware knocking on your door saying, "Hey, do you have a WordPress install that you haven't updated for a week or two?" Composable architecture using the best practices of Jamstack takes commerce web solutions from being secure by design (at best) to secure by default.
7. Scale.
   Large-scale traffic on monoliths strains web infrastructure because each request needs to be dynamically built every time. There are strategies for caching and processes to auto-scale virtual servers, but it quickly becomes complex. With a composable commerce architecture on the Jamstack, web properties have multiple points of origin and don't need the same dynamic build cycle on every request. If your store gets on the front page of the New York Times, you don't need to have huge and expensive server infrastructure upfront to cater to the spike in traffic.
8. Increased employee retention.
   Good developers are in high demand and want to work with modern tools. I spoke to a chief architect for one of the largest fast-moving consumer goods companies a while back, and he shared that they lost a developer in churn every week because of their legacy stack that used outdated tools, programming languages, and developer environments that were incredibly inefficient.

Start Your Monolith To Composable Journey By Choosing A Path That’s Right
For Your Organization

There are many good reasons to embrace composable commerce, but how do you get there? You can:

• Start by just chopping off the head. If you are on a monolith from a provider that offers a headless version such as Shopify or BigCommerce, you can start by simply decoupling the frontend. For example, PrettyLitter, a large D2C retailer, kept their monolithic install of Shopify, including the checkout experience, but decoupled the frontend. In a few weeks, they were able to build and deploy a headless proof of concept that increased conversions by 10%. Having success with the approach, they progressively broke out other portions of their backend monolith, using Cloudinary for images, Contentful for content, and additional services to optimize the checkout and post-sell customer experience. Today, they mostly use Shopify for only the order management component of the solution.
• Dip into composable from the get-go. It may make sense for your team to adopt multiple composable elements at once. For example, Flaconi, one of Germany's leading online beauty retailers, used commercetools for product information, order management, and the transactional layer and commercetools Frontend (formerly Frontastic) for decoupled frontend layer, but also used the best-of-breed services for search (Algolia) and CMS (Contentful). Hilding Anders, a leading sleep retailer in 40+ countries, continued to leverage BigCommerce for their checkout and some commerce capabilities while adding more advanced capabilities like personalization from Uniform and content via a CMS (Contentful).
• Go full composable. Going "full composable" isn't generally an option from the get-go. It requires a high level of digital maturity, significant resources, and large scale. But it can be done: Salling Group, the largest retailer in Denmark, has come close with a centralized digital team of more than one hundred members focused on building and sharing packages of functionality using best-of-breed technologies and customer data that are used and reused across multiple brands' sites, mobile apps, and in-store experiences.

Best Practices For Composable Commerce Architecture

As you adopt the composable commerce architecture, seven recommendations go for all solutions regardless of your approach. Teams moving to composable commerce should:

• Always use the best practices of the Jamstack. If you decouple the frontend from the backend and compose a world-class commerce backend that is pluggable, scalable, replaceable, but you fail to deliver it on the edge, use modern build tools, automate builds, and enable a git-based workflow then you miss out on many of the benefits of going composable. Maximize the benefits of composable by using the best practices of the Jamstack.
• Get a Proof of Concept into the wild ASAP. The traditional way of adopting new software is building it out, porting the content over, and then - years later - flipping the switch and going live. By then, so much has gone into it that it seems daunting to go anywhere. However, one of the most significant benefits of going composable is that you can do so gradually. For example, using Netlify, teams can proxy to your legacy app or your new page for every visitor without any performance loss. You can quickly slice out a page and publish a new project within weeks. Many teams spin up proof of concepts in weeks: PrettyLitter was able to get a proof of concept up in less than three weeks, and Sennheiser was able to get a production-ready proof of concept up in less than eleven weeks.
• Make sure you're not building out another monolith. As you adopt composable architecture across your organization, make sure that you are not building out another monolith in your attempt to tie together all those new APIs, components, and services.
• Avoid building out an operational spider web on AWS. Free your developers from needing heavy DevOps to deploy so they can focus on delivering better customer experiences instead of orchestrating infrastructure. Simplifying operations is one of the reasons many teams that move to a headless or composable architecture leverage Netlify.
• Avoid integrating too heavily into any tool. Your strategy shouldn't revolve around a flavor of JavaScript or any single module. Try to ensure that you don't integrate too heavily into the modules you want to be interchangeable as you go along. A great example is JavaScript frameworks, an area of web development with very high iteration. It used to be all about Angular until one morning, it was React. Then Gatsby was very popular a few years ago, then Next.js, and now all the hype is around Remix; who knows what it will be a year from now.
• Have a strong leader to drive and propagate organizational maturity. You do need some organizational maturity for composable commerce. A composable stack enables best-in-class functionality for all your needs, but there are more components, and you need to be more intentional with your architecture.
• Ask your existing tech portfolio tough questions. Quite frankly, you need to be able to call BS. As composable architecture is winning, you see tons of vendors calling their services MACH-ready or composable when they are not. Some of the legacy digital experience platforms are technically becoming a bit more modular. Still, they are not natively composable and are only meant to work with the other modules provided by the same software vendor.