Guide to Composable Commerce

The world has changed, and gone are the days where traditional website only experiences are enticing for consumers. At the same time, modern digital brands want to find their unique advantage and bring it to market fast while IT leaders are looking for ways they can advance the business in step with the consumer demands, disruptive trends, and emerging opportunities.

To truly capitalize on your commerce strategy, you will need to ditch traditional commerce platforms and embrace an approach that will empower your team to take back control of your digital commerce strategy and execute at the speed of customer needs. That approach is Composable Commerce

According to analyst firm Gartner, becoming a “composable enterprise” is the innovation strategy of leading digital business organizations. This involves decomposing traditional monolithic systems by leveraging decoupled, packaged business capabilities (PBCs) to uniquely compose application experiences.

Traditional legacy solutions consist of rigid and opinionated architectures that prevent brands from having the control they desire to implement custom backend logic changes to satisfy their complex business requirements.

A Composable Commerce approach advocates moving away from full-stack eCommerce platforms, towards building a best-of-breed solution from smaller sized, “Lego block” components. Rarely does a full-stack, all-in-one application (whether home-grown or licensed from a vendor) fully satisfy the unique requirements of a business long-term, and therefore adopting a Composable Commerce approach ensures today’s solution can stay in-step with tomorrow’s demands.

There are four key tenets that define the composable approach:

In this guide, each tenet is dissected to provide a clear understanding of the importance of each one to the approach and the benefits associated. It is important to note that all four tenets working together cohesively is critical to receiving the full benefits that Composable Commerce has to offer. As we step into each tenet chapter, we will also provide best practices to consider and examples of how brands have already adopted and deployed the approach to elevate their digital strategy.

 

Chapter 1: Modular


web

 

Composable Commerce was designed to be fully modular, which means that each component is a self contained system that can be deployed independently. A modular architecture is key to supporting more agile delivery, faster time to market and improved customer experiences across all devices and touchpoints. Modularity has been difficult to achieve with traditional incumbent platforms due to its rigid architecture, but with the use of packaged business capabilities (PBCs), modularity is seamless.

 

Benefits of a Modular Architecture

It is loosely coupled

Unlike tightly coupled monolithic platforms where every service shares the same codebase, loosely coupled services can be independently updated.

For organizations developing services in house, this enables you to take advantage of DevOps and CI/CD (Continuous Integration/Continuous Delivery). If you’re using third-party, vendor managed services, you don’t need to modify any backend code, and you benefit from your vendor’s own ability to leverage DevOps and CI/CD to deliver updates faster than monolithic vendors.

Another benefit of loose coupling is the ability to integrate services closer to the experience layer or “head” through APIs, rather than in the code itself. This supports faster time-to-delivery without adding technical debt to the platform. Innovation can be rolled out to new touchpoints and rolled back just as cleanly.

 

It is independently deployable

Not only can independent components of a composable platform be swapped in and swapped out as needed, they can also be selectively applied to new experiences you build and and be consumed in multiple experiences.

With a monolith, a new touchpoint such as mobile self-checkout, curbside pickup  or voice-enabled chatbot must be hardwired to the entire backend system. Theoretically, the approach is achievable, but in reality, encoding these features in the backend is difficult and more time consuming because of the decoupling of internal functions required. This eventually impacts performance of your system which is unfavorable. With modular applications, only the required services’ APIs and logic are involved.

Independence also supports efficient reuse across touchpoints. For example, the same Catalog service can power multiple storefronts within your organization or partner network. This means:

  • Cart and checkout can be embedded into a wide range of content, apps and experiences.
  • Inventory can be extended to back office systems and dedicated apps for sales reps and dealers.
  • Data and logic can be shared and consistently maintained across touchpoints and channels, or configured with precision to unique requirements.

 

It is independently scalable

Modular applications are individually deployed to a public cloud, which means they can scale independently -- indefinitely. This presents a critical advantage over monolithic applications which can only scale up or down as a whole. With a composable application, a spike in demand for one component won’t slow or take down the entire app. Not only does this enhance uptime and customer experience, it keeps hosting costs under control.

For example, if you roll out a new mobile self-checkout solution to 100 physical stores, demand for the feature’s related services can surge, while other pieces of your composable commerce platform remain steady. Or, if you suddenly add one million new SKUs to your catalog with new attribute fields, complex pricing and discounting rules, Catalog and Pricing can scale accordingly, without having to scale Search, Cart, Checkout and Accounts.

 

 

How Stance Leveraged a Modular Architecture

 


web


Stance is an American sock, underwear and t-shirt brand focused on their in store purchases. They recognized the need to eliminate lines and wanted to solve that issue by providing a self checkout experience. However, with the stigma surrounding downloading apps for shopping, Stance wanted to allow guests to skip the line and check out, using web-based checkout experience on their own smartphone.

Their existing infrastructure lived on a monolithic platform and adding this new user experience wasn’t going to be possible. They also didn’t want to start over from scratch with a new platform, just to launch a new experience that could take months.

With the modular architecture provided by Composable Commerce, services can be independently deployed. When Stance approached the problem with Elastic Path, there was no need for hard coding in the back end. With a team of 2 developers and a few api calls, Stance was able to launch their web based self checkout system just in time for the holiday season. What would have taken them 9+months with a legacy platform, took in 7 weeks to launch with Composable Commerce.

 
 
 

Considerations for Evaluating Modular Architectures

The key benefit of modularity is convenience. 

Well designed application architectures all contain a level of modularity to support future growth and flexibility as needs change. Great examples include traditional eCommerce applications such as search, order management, point of sale, kiosks, product information management etc. In these applications you have the choice to change from search provider A to provider B or introduce sophisticated product information management to feed your eCommerce applications to product taxonomies.

Some questions you can use as a guide to evaluate how modular your solution is include: 

  • How quickly can I switch A for B?
  • Can I reuse components multiple times and across multiple touchpoints?
  • Can I leverage the application in multiple channels with limited to no work?
  • What is the impact of my change?
  • How much regression testing will I need?

A modular eCommerce architecture has well defined strategic foundation building blocks to support broader enterprise needs. For example, a Product Information Management application can rapidly provide taxonomies for print, mail, marketing and eCommerce catalogs. Composable Commerce takes the modular approach and applies it to the heart of the eCommerce platform, demanding a decomposition of the platform to the sum of its part. While you can benefit from this component independently, it is still just a small piece in a bigger puzzle.

 

Chapter 2: Open


Now that you have a better grasp on using modular components to build your composable solution, the next question is - “How nicely do the components play together?”

Composable Commerce was designed with open standards. Open commerce technology enables interoperability between services for seamless integration (and removal) of components while also preventing vendor lock in. This eliminates the need to extend your platform through plug-ins, modify monolithic backend code or build siloed experiences.

web

This will be ideal for teams who want to pick and choose from the best vendors that have spent time to perfect their individual integration offering, rather relying on your platforms suggested proprietary vendors.

Open Standards are approaches, designs, and industry adopted ways to facilitate interoperability across different products and services. Generally open standards are publicly discussed, developed, approved, and maintained via a collaborative process. Hence open source communities are one originator of open standards.

When defining composability, a large variety of adopted and supported open standards are available. Generally, the more modular the architectural design can be, the more likely a user experience will be seamless, thus speed of build.

 

Benefits of Open Standards

Modular Integrations

Composable Commerce enables assembly of best-of-breed components around your core commerce service, including point solutions like Search, Tax, PIM and Order Management -- just to name a few. It also allows you to add proprietary solutions or apps developed by your technology partners and systems integrators.

Not all of these applications will have pre-built connectors to your backend systems, including your ERP, CRM and BI tools. For example, your ERP may not integrate with your Tax solution without workarounds. Your B2B instance many need to connect to its own Tax service. Or, your Tax application may not work well with subscriptions within your Payments service out-of-the-box.

Building custom connectors puts additional onus on your technical teams (or requires a systems integrator to build for you), delaying time-to-market and consuming budget that could be applied to innovation and delivery.

Open standards make integration easier and support technical agility, both in making connections and maintaining them as your ultimate composition evolves. For this reason, look for point solutions that are natively designed with open standards and MACH principles.

 

Extensibility frameworks

If out-of-the-box features don’t suit your unique business requirements, your solution must be customized. A solid extensibility framework including web-hooks and data extensions allows developers to quickly add capabilities to your backend, enhance front-end experiences, and configure standard commerce capabilities. This is critical for keeping your technology up-to-date with ever-evolving customer demands and market opportunities (with less time and money).

 

Open accelerators

Once you’ve heavily customized your backend systems such as ERP, CRM, DOM, PIM and BI tools, you want them to sync with your commerce technology. And maintaining point-to-point connections across your entire systems architecture can be a massive effort!

 

Prevent vendor lock in

If it’s easy to hook up, it’s easy to swap out. Openness keeps data and connectors clean, and ready to plug into the next application should you decide to swap in or out any backend system, large or small.

 

How Pella Leveraged Open Standards

Pella is a window and door manufacturing company that was focused on bringing a more seamless commerce experience to their customers for their highly customized products. Before utilizing Composable Commerce-as-a-Service, they had chosen to embark on their commerce journey with a legacy platform . After a year of implementation they recognized that the solution couldn't be configured to fit their needs.

With a solid extensibility framework from Composable Commerce, not only were they able to build a custom configurator to solve their problem of complex product catalogs, but they were also able to launch three customer journeys across B2B and B2C channels with a single digital experience.

web

Pella’s overall goal is to rapidly and continuously adapt to keep up with evolving customer needs and outmaneuver competitors. Open standards grant the creative freedom for their team to try things and customize it to their needs with little to no risk.

 

 

Considerations for Evaluating Open Standards

The key benefit of open standards is the option to choose what you want, when you want it. You shouldn’t be boxed in by your vendor’s idea of how your commerce solution should function. Coupled with choice, open standards also provide a high degree of confidence in the your sustainability of your system. Changes are easily consumed and therefore you will never have worry about a change breaking your entire ecosystem.

Composable solutions move the needle on open standards adoption, putting flexibility forefront in every design decision.

To evaluate openness you should think about the things below which only scratch the surface on the topic:

  • Can I rapidly get my new Order Management System taking orders from eCommerce and reporting order history back to make customers in their account pages in matter of days or weeks?
    • If not, then the openness of your solution is questionable, the interfaces are tightly coupled and the message formats that have been used are not open enough to be reused. Meaning we now have to design new mappings, write functions, translate and test extensively.
    • A composable solution using design first principles starts with considering the common formats, standards, integration methods that will supporting you changing more rapidly without being hamstrung by complex custom logic.

       
  • Can I add new internal features without massive disruption?
    • Monolithic architectures need significant code deployment and rigorous regression. Which costs time and money.
    • An open API first approach allows you to change / extend and add components at all levels to the solution quickly without massive disruption to more positively impact end clients.

Open standards will be a key ingredient in your eCommerce strategy if you are committed to continuously iterating and optimizing your unique experiences for customers. 

 

Chapter 3: Flexible Technologies

web


In order to activate your freedom to choose and assemble your modular structure, you will need flexible technologies. For many ecommerce applications, “going headless” is the first baby step towards a flexible architecture. However, the next step beyond headless commerce towards ultimate flexibility involves adopting technology that embraces not one or two, but all MACH principles along with JAMStack.
 

What is MACH?

MACH stands for Microservices, API-first, Cloud-native, and Headless.

What are microservices?
Microservices are discrete “building blocks” of backend applications built around specific functions or business capabilities. Microservices are inherently composable thanks to their independent deployability and interoperability through well-defined APIs. This allows IT leaders to select the best “tool for the job” at any time, and add, remove or upgrade individual components as needed without compromising the full system.

 

What does API-first mean?
API-first means an application’s business logic is configured through APIs rather than built into the service code. This eliminates technical debt within the commerce platform, and supports unified logic across multiple “heads” beyond the online storefront, such as virtual catalogs/lookbooks, mobile apps, voice commerce, IoT, chatbots and back office dashboards.

API-first design is not only flexible, but more efficient. New touchpoints can be added or removed at any time without compromising code or requiring full system downtime. Eliminating channel silos and duplicated development efforts accelerates time-to-market and ROI.

However, API-first is not to be confused with modernized commerce platforms -- monoliths that have an API layer added to the application. While this is a start towards flexibility, these APIs are often not granular enough to support the degree of business specificity and extensibility that truly modern, technically mature organizations desire.

 

What does Cloud-native mean?
There’s a difference between an application hosted in a public cloud and one built cloud-native from the outset. While a SaaS vendor’s monolith may be able to scale with demand on AWS and receive seamless updates, it must scale as a whole (including the database). What’s more, full-stack platform vendors can’t take advantage of agile code delivery like microservices-based commerce service vendors can, meaning “seamless updates” are fewer and farther between.

In contrast, microservices and PBCs are always built cloud-first, whether developed in-house or delivered as-a-service from a vendor. Not only do cloud-native composable components enjoy limitless scalability and resilience (failures can be moved around the cloud as workloads change) they’re also more secure. Because microservices can be independently deployed to a private network within a public cloud, attackers can’t easily compromise the entire system if they gain access to one component.

An added benefit to cloud-native SaaS applications is on-demand consumption. No need to deploy your solution, you can subscribe or unsubscribe to modular capabilities as you wish.

 

What does Headless mean?
Like cloud-native applications, to qualify as truly headless, an application must be designed as such from day one, rather than decoupling the head and slapping an API on the side. Decoupling the front end from the backend frees the business from the restrictions of an eCommerce platform’s limited front-end capabilities, and ensures front end developers can work independently from back end teams without cross-functional coordination and introducing risk to an already fragile and bloated monolith. This supports interoperability between components and compatibility with any front-end or touchpoint.

 

What is JAMStack

Javascript, APIs and Markup put the JAM in JAMstack. Like MACH for the back end, JAMstack is a modern architectural pattern for building front-end applications.

And similar to the concept of headless commerce which separates the front end from the backend, JAMstack separates the front end presentation layer once more, this time from dynamic functionality within the “head” application. This supports lightning-fast performance and optimal customer experience.

 

How is this achieved?
Markup refers to your static HTML files (typically your templates). In a headless environment, these files may come from your static website generator like Gatsby, React, Vue or Angular, or advanced CMS / DXP. Because these files are static, they can be pre-rendered from a CDN cache so users see content as soon as possible.

However, many components of ecommerce are dynamic -- think price, promotions, inventory availability, average star rating and product carousels. With JAMstack, Javascript dynamically inserts content after essential markup, while APIs pull relevant data from back end services.

 

How Deckers Brands Leveraged Flexible Technologies

 


web


Deckers Brands is a multi-brand footwear designer who was in need of a solution that would help them to quickly create an experience that would turn sponsored events like marathons into transactional moments to unlock new revenue streams.

Similar to Stance, they were also already using a traditional platform and needed to move quickly. The API first approach allowed the Deckers team to call a few APIs and enable the microservices they needed to extend their existing platform and launch their self checkout application.

Due to the openness of the architecture, they were able to seamlessly integrate their platform with their new application and achieved a launch in two weeks. With this new ability they were able to cut operating costs by eliminating POS and have been able to sell thousands of products at dozens of events with numbers growing weekly.

 

Considerations for Evaluating Flexible Technologies

Can my technological ecosystem change course quickly and easily to meet our market needs now, tomorrow and into the future? If yes, you’re on your way and have a flexible solution to support your business.

If you're now thinking, that means there is doubt and somewhat like open standards you need think where to we need flexibility:

  • The touch point?
  • In capturing the order?
  • In processing the order?
  • In managing fulfilment?

Though this isn't an exhaustive list, each has technology underpinning the business need, which may change in an instant. For example, can you:

  • Rapidly plug’n’play best of breed solutions in a matter of days or weeks?
    • If not, then the flexibility of your solution is questionable and you most likely have tightly coupled integrations which affect your ability to change.

A composable solution using design first principles starts with considering your businesses need for flexibility / agility and choice.

Flexible technologies are needed for both the frontend and the backend to ensure that your business’ customization won’t be compromised. The addition of MACH and JAMstack to the Composable Commerce equation provides the grounds for teams to be able to rapidly build and deploy, but there is one more component that we need to tie the story together.

 

Chapter 4: Business Centric Solutions

To close the gap of Composable Commerce, we need business centric solutions to allow IT and business teams to collaborate on large projects and digital transformation, while also leveraging composable technology to support business users’ day-to-day activities.

Beyond the application itself, how can composable components give business leaders end-to-end control over new experiences? By Providing business user tooling, supporting evolving business models and fostering Business-IT collaboration.

 

web

 

Is “Going Composable” Right For Your Organization?

Change comes at a cost in time / effort & money. And the larger the change, each of those factors are increased. Combining these factors with clear business needs and drivers, go a significant way to helping answer the “going composable” question without extensive analysis.

So if we:

  • Have a rapidly changing/competitive market that needs innovative experiences which can be designed in a persona centric way, deployed quickly anyway and use a few common features to help sell (Product). Composable Commerce is a must.
  • Are a growing business who today have an ecosystem of open source and simple integrations as we like to control our ecosystem and in the future may change a piece, but must have a cart and payment to sell. Composable Commerce is a must.
  • Run our business on a complex set of applications that takes months to change, simply to provide product & inventory updated to our sales reps / buyers and dealers in different experiences quickly. Then it’s time to look at Composable Commerce.

A Composable Commerce application allows an organization to be more flexible and adapt to business change rapidly with less friction, and less risk introduced into the backend environment. Because “Lego bricks” can be swapped in and swapped out for best-of-breed, a composable enterprise can stay perpetually modern without having to endure a rip-and-replace re-platforming or full-stack upgrade ever again. To learn more from one of our internal experts book a meeting with us today.