This article was originally published on the MACH Alliance blog
In the last few years, e-commerce 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 e-commerce 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
- Prone to 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:
What is 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.
What is 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.
What is 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.
8 Reasons Digital Commerce Leaders Architect For Composable Commerce
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 of what 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.
