Skip to content
Home » 8 Reasons Digital Commerce Leaders Architect For Composable Commerce

8 Reasons Digital Commerce Leaders Architect For Composable Commerce

Sennheiser is a major company in the field of consumer electronics for more than 70 years. However, their ecommerce sites that are highly-trafficked aren’t constructed in the manner you’d think. In fact, they were unable to create the experiences they want in ecommerce using a traditional platform. Instead, they’re part of the trend to abandon the old monolith and adopt the concept of a composable approach to commerce.

In Netlify’s latest Headless Commerce Summit, I spoke about the choices that are pushing companies like Sennheiser toward a more comprehensible architecture. Ecommerce is among the fastest-growing segments we’re witnessing at Netlify. Below are some of the industry trends we’re seeing across our client base.

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

In the last couple of years, the growth of e-commerce has been by 10 times the rate of the previous decade. It’s important to remember that it was already a growing segment. There remains a multi-trillion-dollar opportunity, with 81% of commerce still served by non-digital channels. It’s not just the volume of sales that is growing. With the growth of e-commerce and new sales channels have developed, new marketplaces emerged and the market grew overflowing with competition. Commerce teams who want to differentiate, increase revenue, and ensure margins realized that their internet monoliths were not able to keep up, since they had:

It is slow to adapt and scale up to new channels and markets.
It’s difficult to tell
Customers are slow to respond.
Costly to update and maintain

Composable Commerce emerged from the Remains Of the Monolith’s

Failures

There’s a huge change in the way we create commerce solutions. In particular, we’re seeing a massive shift towards composable commerce. According to MACH Alliance research, 79 percent of the tech leaders surveyed would like to incorporate more composable elements within their infrastructure over the next twelve months.

What is composable commerce stack? And what exactly is a monolith in the first place? Let’s get it down to a few definitions:

Monolithic commerce. Monolithic commerce occurs when a company takes various functions and features, usually none of them superior, and integrates it all together in a single, comprehensive solution. For instance an online shopping solution that is monolithic is offered by Adobe (Magento), HCL, Salesforce, SAP, or Shopify typically includes the information about products, images of products prices, price, payment functions and search capabilities customers, analysis of customer data and even front-end elements (such such as the mega-menus) with a limited and cumbersome customization. The issue is that if are looking to alter one element it is necessary to alter every single one of them. This can take years and you’ve already invested millions, so you can’t.

Headless commerce. Headless commerce lets you create a separate frontend, Web Experience Layer and the backend, which is a monolithic system. The benefit is that it allows you to swiftly modify the frontend experience, without affecting the backend. The disadvantages are evident when teams attempt to integrate particular components that meet business needs. Certain monolithic commerce backends are prone to make it difficult or impossible.

Composable commerce. Since retailers began to embrace headless CMS systems with optimized stand-alone search and APIs for specific applications such as product reviews and Product Information (PIM) personalization, and many more, we’ve begun talking about composable shopping. Composable commerce is where the functionality in the backend and frontend can be plugged in, scaleable as well as replaceable. It is also able to be improved continuously through agile development.

The Composable Commerce Tech Landscape Is Affirmed

At Netlify we’ve observed firsthand how the category of commerce is growing rapidly. The positive is that there’s more choice than ever before. However, the downside is that navigating the options can quickly become difficult, as more and new headless commerce tools arriving to market every year.

To facilitate the process of talking about, conceptualize and design the possible marketplace into three main three pillars:

Storefronts. Storefronts is the component of your solution for commerce that users see and engages. The web-based experience layer, or frontend. The majority of the time, this is created by using an JS framework and an Orchestration platform such as Netlify and, in a few cases, a storefront that is a separate service to your backend for commerce is also added. The options here are MACH solutions such as Vue Storefront, Commercetools Frontend (formerly Frontastic) and Nacelle. They are a part of a complete flexible commerce solution, but we typically see them as an added the top on monolithic backends. They differ in how non-code is their code, versus yes-code and this is a growing market.

Product Experience. There are several categories that make up the experience Content management (i.e. Contentful, Contentstack and Storyblok), and Storyblok) and stand-alone search (i.e. Algolia) and digital asset management (DAM) (i.e., Cloudinary) as well as Product Information Management (PIM) (i.e., Akeneo, Bluestone) tooling and services relating to personalization (i.e. uniform, Dynamic Yield), and then evaluations (i.e., Yotpo).

Layer of transaction. The transactional layer comprises pricing, order management (i.e., Commerce Layer) as well as payments (i.e. Adyen and Stripe) along with checkout options (i.e., Snipcart).

Many of these services are available in more comprehensive solutions, such as the headless options by Commercetools along with BigCommerce.

In the realm of the internet and software we see a continuous change, and every once in 10 years or so we experience more drastic shifts. I think this shift towards MACH along with the Jamstack is one such shift and that digital leaders driving this change since composable commerce can:

Speedier times to go on the market.

One of the major benefits of committing to MACH is that it allows your team to launch features 10 times quicker. When I talk with CMOs about their top main concern is time to launch. This isn’t surprising. The huge monoliths that comprise the commerce platform templates, template engines, glue codes and build tools, customer information personalization, framework for programming and infrastructure end up becoming unmanageable and incomprehensible. The unidirectional approach to commerce reduces the speed of iteration. I had a conversation with the marketing team of one the biggest corporations around the globe. They’d spent millions on a single platform which caused them to have a painful delay between the time when marketing was ready to go live and when they had it implemented, which was the equivalent of 32 days. 32 days!

Cost reduction.

It’s expensive to continue operating in the same way. One quarter of IT decision makers said they spent more than 50% part of their IT budget for updates for their old systems. In the average, businesses spend nearly two-fifths their budgets on these updates. A CMO I spoke to recently said that his single tech vendor has sold him “everything I require – and nothing I don’t.” The advantage of a composable system is that you can buy and build only what you require by implementing one program, you don’t require the expense of purchasing everything else.

Omnichannel experiences.

A monolithic approach makes it difficult to provide all the platforms that consumers use in the present. Every channel we use to share information must be available via an API. Teams need to separate the vastly various layer of presentation from their backend in order to provide the best experience for every channel. catering to the omnichannel consumer is becoming a huge concern for retailers in the present, because omnichannel customers spend more. Target claims that they have 40 million customers shopping across channels. Omnichannel customers spend more than customers who shop in stores only. Albertsons reported that households with omnichannels have three times the spending of those who shop in stores only. In addition, the number of households that are omnichannel grew nearly five times over the past two years. Macy’s claims that even in a mall-based environment, an omnichannel consumer spends 2.5x or 3.5x higher than an individual channel user. It’s safe to affirm that embracing omnichannel is the only way to go for retailers. The only way to expand that is to get rid of monoliths.

Differentiation.

One of the major issues for commerce experiences built on monoliths is the fact that there aren’t the same opportunities to create an unforgettable customer experience that you can in an actual store. This means that thousands of stores similar to yours are only a click away. The most important reason to move to composable commerce is what it’s not. It’s not the website presence. This isn’t the engine for templating built systems, glue codes or runtime. All of those pieces, as well as the technical decisions they make are completely under your control. This allows you to make sure that the technology utilized for your website to the needs of your own team and other projects. With a comprehensible commerce stack it is not governed by any specific designs or checkout procedures, and can customize the user experience to meet your specific requirements.

Faster web experiences.

The managers of eCommerce know the value each millisecond. Analyzing customer analytics across thirty million sessions showed that a speed of 100ms can provide retailers with an 8.4 percentage increase in conversion. Due to the versatility of APIs that are headless teams can make use of the Jamstack approach to web development to create and improve web assets ahead of time and then distribute them to nodes around the world. With edge functions, the prebuilt pages load content on the screen more quickly than monoliths due to the fact that they can eliminate the latency that comes with traveling roundtrip back to their origin in a different country, in which the pages need to be put together before being served. It is obvious that you’re browsing an un-headless Jamstack site by the fact that it is extremely quick and page changes are immediate.

Securer web applications.

The majority of malware that is created by automated programs is targeted at traditional monoliths since the process of building is always operating and is exposed. Through separating both the front and back end, and applying the most effective practices of Jamstack team, they can eliminate the biggest attack area they have. At Netlify we receive several hundred thousand requests per month that begin with “WP Administration” It’s malware calling your doorstep, asking “Hey do you have an unreliable WordPress installation that hasn’t been updated in one or two weeks?” A composable architecture that follows the most effective practices of Jamstack makes commerce-related web applications from being secured by design (at most) to being secure by default.

Scale.

Monoliths that are large-scale in size strain the web infrastructure as every request must be built dynamically each time. There are methods for caching and auto-scaling virtual servers but it becomes complicated. With the modular commerce architecture built on Jamstack web, online properties can have multiple sources of access and don’t require the same building cycle for every request. If your business is placed on the first page in the New York Times, you do not need to build a massive and expensive server infrastructure to accommodate the surge in traffic.

Employee retention has increased.

Developers who are skilled are highly sought-after and are looking to use modern tools. I talked to the chief architect of one of the biggest consumer goods manufacturers some time ago and he told me the fact that they lose a development team member during the midst of churning every week due to their outdated stack, which used outdated programming languages, tools and development environments that were extremely inefficient.