Composable commerce vs. traditional commerce — which approach is right for your business?

In today’s ever-evolving digital landscape, merchants face the challenge of staying competitive and delivering increasingly more sophisticated customer experiences.

As customer experiences evolve, merchants are presented with constantly evolving technical approaches and strategies. One architectural approach that has started to become more widely used by merchants is composable commerce. As such, there are many merchants trying to understand whether it’s a strategy that they should adopt or transition to — and if so, how they should go about making the transition.

This approach comes with clear advantages for several different use cases. However, as with any other architectural approach, it’s not a one-size-fits-all and thus comes with its own set of trade-offs that need to be carefully considered.

This article will explore the fundamental differences between composable commerce and traditional commerce models — and the pros and cons of each. By understanding these distinctions, merchants can make more informed decisions about which approach is going to best cater to their needs and requirements.

What is traditional commerce?

Traditional commerce refers to a conventional architectural approach of building ecommerce platforms as a single integrated system — often referred to as a “monolithic” system. In this approach, the front-end presentation layer, the back-end business logic, and the database are combined into a single unit. The defining characteristics of this approach include:

• “Headful” or “non-headless.” This signifies that the front end and back end are a cohesive, integrated, and unified platform.
• Single code base. The entire application is built using a single code base. Changes are deployed to the application as a whole, and you cannot isolate changes or deployments to certain parts of the application.
• Single infrastructure. The entire application is hosted on the same servers and infrastructure. Scaling infrastructure up or down is applied to the entire application.

What is composable commerce?

Composable commerce represents a departure from the traditional model. It includes a headless approach, decoupling the front-end presentation layer from the back-end commerce functionality. The back end is broken down into packaged business capabilities or services that can be “composed” together. These back-end capabilities are all accessed by the front end using APIs.

This decoupling of the front end allows for greater flexibility in using different technologies and applications in the back end to drive the front-end experience. The defining characteristic of this approach include:

• Headless. The front-end component of the application is decoupled and separated from the back-end components of the application.
• Modularity or microservice. Functionality is delivered in a modular fashion with the modules decoupled from one another, so each module can have changes deployed to them individually and be scaled up and down independently from each other.
• API-driven. The front-end and back-end modules and services interact with one another via API.

From an architectural perspective, the two approaches look like this:

Comparing key differences between traditional and composable commerce

Architecture

The most obvious difference between these two approaches lies in the architecture of each approach. Composable commerce follows a modular and decoupled architecture, where different components of the commerce stack are treated as independent services. In contrast, traditional commerce adopts a unified architecture, where the front end, back end, and other components are tightly integrated into a single platform.

Scalability

One of the key differences between composable commerce and traditional commerce lies in how the application can be scaled. With a composable commerce approach, the infrastructure is decoupled — allowing each component of the stack to be scaled independently. This means that if the front end is experiencing a higher load due to increased website traffic, it can be scaled with additional resources without the need to add additional infrastructure resources to the back-end components of the application. Such decoupling enables more efficient resource allocation, ensuring that compute power is allocated where it is specifically required. Traditional commerce, on the other hand, typically requires scaling larger portions of the stack collectively, which can lead to suboptimal resource allocation.

Considering that most merchants rely on ecommerce platforms that offer vendor-provided cloud services, where infrastructure scaling is included as part of the service, the practical implications of these scaling differences may not significantly affect the merchant nor be noticed. However, it is worth noting that some merchants handle the front-end component of their applications independently on their self-managed infrastructure. In such cases, the responsibility of scaling that specific part of the application falls upon the merchant themselves.

Multi-experience flexibility and innovation

By decoupling the front end and making the features and functions available via a front-end API — GraphQL API, for example — merchants can more easily support many different types of experiences ranging from web experiences to wearables, native apps, or in-store kiosks. This decoupling empowers large development teams to roll out new features as distinct microservices, which can be easily surfaced across the various front-end experiences that the merchant supports.

In contrast, the traditional approach is more constrained in its capacity to support multiple experiences beyond conventional web-based experiences.

Agility and time to market

Agility and expediency of the approach are driven based heavily on the size and complexity of the stack and the size and scale of the development team that is building and maintaining it.

For composable commerce to tip the scales as the more agile approach, merchants typically must have:

• Large development teams building and supporting the application
• Varied specializations across the development team with different coding languages
• Support for a large number of requirements, features, and complex functions — like unique and bespoke shopping journeys, third-party dropshippers, marketplaces, and multiple experiences and front ends

These may vary depending on use case but are a general guide to where most organizations will see the value of a traditional approach be outweighed by a composable approach.

Composable commerce architecture is inherently more complex than a traditional commerce approach. With complexity comes a requirement for more stringent project delivery governance and more time required to coordinate, integrate, and develop the overall application. For smaller teams (fewer than 20 developers) and less complex requirements, the composable commerce approach will often have the effect of significantly increasing the project delivery time and can make it harder to roll out new features and changes.

However, for larger development teams with varied specializations, a composable commerce approach can allow the teams to be more agile than with a traditional unified stack. Multiple developers can work independent of one another and deploy code to different microservices at the same time without as much coordination required between them.

Security and data privacy

As composable commerce involves integrating various components and services, data security and privacy become critical concerns. Those may include more user logins to multiple systems across the stack, so access governance becomes more important.

Organizations need to implement robust security measures, monitor vulnerabilities, and ensure compliance with data protection regulations. Each component in the ecosystem should have proper security measures in place to mitigate risks and protect sensitive customer information. Conversely, for traditional commerce, a unified application typically has more of the security and data privacy managed by the vendors, making this much more tightly controlled and less open for vulnerabilities that need to be managed by the merchant.

Vendor lock-in

Composable commerce, with its modular architecture and separated front end, can help reduce vendor lock-in by minimizing how intertwined each vendor becomes in the overall stack, allowing them to be more easily replaced.

In contrast, traditional commerce relies on a unified platform from a single vendor, resulting in a higher level of dependency on that vendor for the entire commerce solution. Migrating away from the vendor’s platform or switching to alternative solutions can be more challenging and resource-intensive in a traditional commerce setup.

What merchants report as the biggest benefits of composable commerce

Adobe Commerce has had merchants implementing headless and composable architectural approaches since the merchants’ inceptions 10+ years ago.

Through collaboration with several Adobe Commerce merchants who have adopted a composable commerce approach, we have gained valuable insights into the main benefits they have experienced. Interestingly, the feedback received from these merchants highlights distinct advantages that extend beyond the expected differentiators traditionally associated with these approaches. Here are some of the key benefits they shared:

1. An ability to bring the ownership of the front-end user experience in-house

In the traditional commerce approach, merchants looking to retain complete control over development and operational expertise often manage the entire stack in-house. This involves taking responsibility for both the front-end and back-end components of the application and everything in between. However, since composable commerce requires a headless approach, merchants now have an alternative option — only in-housing the front-end team.

This team controls the customer experience, including the look and feel, the user experience design, and the features and options available to the customer. As the pivotal element that drives the most significant differentiation for a business’s digital experience, it is arguably the most important part of the stack for the merchant to control directly and “own.”

By adopting a headless framework when using the composable commerce approach, merchants can now bring only the front-end development team in-house — allowing them to operate autonomously and independently from the back-end developers. This separation lets merchants use back-end developers sourced from external partners or agencies.

2. Resource ramp time and access to a larger pool of suitable developers

In the traditional approach, there is time required for new developers to become familiar with the different technologies used in the stack. With a decoupled architecture, a front-end developer who is well-versed in React can get to work almost immediately without needing to know much about the stack. It also makes it easier to find developers, as prior experience and skills in other platforms in your stack are not necessary.

What merchants report as the biggest risks to implementing composable commerce

One of the merchants that we work with likened architectural approaches to organizational structures. Startups often use a decentralized and flat organizational structure due to its simplicity, agility, and limited hierarchical layers. However, as organizations grow, this structure becomes less and less effective and starts to present new challenges — like decision bottlenecks or coordination issues. Growing businesses are faced with the decision of transitioning to more sophisticated organizational models, with rising complexity as a trade-off to solve issues that emerge when growing too large with a flat structure.

Similar to architectural approaches, there comes a point when the size of the application and development team necessitates a change in architecture. If Twitter or Facebook were not broken down into a decoupled, headless, and microservice architecture, their more than 3,000-person development teams could not feasibly coordinate all changes into singular releases. It would be too slow or impossible to update the platform. Thus, for a merchant to determine which architectural approach is best suited to their business, several considerations should be carefully weighed and considered.

Merchants we have worked with have shared these as key considerations when successfully moving to a composable approach:

1. Complexity and internal technical maturity

Composable commerce involves integrating various third-party components, microservices, and APIs. This can introduce complexity, especially when managing multiple vendors. Merchants need to have the technical expertise and resources to navigate the complexities of integrating and maintaining a diverse ecosystem of components.

Merchants cite requiring strong — typically in-house — development capabilities and an ability to house or “own” the solution architecture, which is often owned by one of three resources in the business:

• A dedicated solution architect
• A hands-on and highly technical CTO
• A senior lead developer who both codes and owns the solution architecture

2. Size and structure of the project and team

If your internal development team is more than ~20 developers, then moving to a decoupled approach allows them to be more agile as they can make changes to sections of the stack independent of one another — negating the need for large, complex deployments to the whole stack all at once in singular releases.

3. Customization vs. standardization

While the composable commerce approach allows merchants the flexibility to create separate microservices for all new functions and customizations, this can be a double-edged sword. Creating microservices in different languages, on different infrastructure, and to different standards can quickly lead to technical debt that needs to be carried by the whole stack. It is important to standardize this as much as possible, with a bias toward a standard language, framework, and infrastructure approach — only deviating where necessary.

4. Total cost of ownership

Of the two approaches, composable commerce generally has the potential for a higher total cost of ownership (TCO) compared to traditional commerce.

Composable commerce involves integrating multiple components and managing API connections across various services. This complexity requires additional development effort, specialized skills, and resources during the delivery, which translates into higher upfront implementation costs. There is substantial complexity in having many different services, multiple vendors, coordinating separate integrations, addressing compatibility issues, managing API updates, and ensuring smooth interoperability between different components.

As a result, composable commerce often results in higher ongoing maintenance and support costs. Merchants may also need dedicated development teams or external experts to handle continuous updates, enhancements, and maintenance. Traditional commerce in a unified platform requires much less time, effort, and resources in both the setup and ongoing management of the commerce stack.

How Adobe Commerce makes composable commerce easier

Adobe Commerce has several capabilities to make composable commerce easier and simpler to adopt.

The Adobe Commerce composable commerce methodology

As a platform, we have developed several unique capabilities to support merchants who are looking to go with the headless and composable commerce path. We know where merchants can derive the most benefit from this architecture and understand the associated risks and drawbacks.

Adobe Commerce caters to both architectural approaches, allowing merchants to choose either approach or a hybrid combination that best suits their specific needs. This flexibility enables us to provide merchants with several unique capabilities that allow them to experience the best of both worlds and extract the maximum benefit and advantages from both architectural models.

Feature-rich with more out-of-the-box functionality

Our platform offers a comprehensive set of features accessible through our comprehensive GraphQL API. This enables merchants to minimize the number of vendors required in the delivery and in the entire stack. This significantly reduces time-to-market challenges typically faced in composable commerce implementations. We empower merchants to launch significantly faster while maintaining full flexibility to compose and integrate additional third-party services or capabilities as their commerce stack evolves over time. This can often cut in half the time it takes to get to market compared with other platforms.

Hybrid headless and non-headless front-end experiences

Adobe Commerce supports multiple options for delivering experiences to various customer touchpoints, allowing for the coexistence of both headless and non-headless front-end experiences within the same ecosystem. Merchants benefit from the flexibility to select the most suitable architectural approach for each specific front-end use case. Furthermore, this approach enables merchants to gradually transition to a headless and composable architecture without the need for a simultaneous migration of their entire system. This also allows merchants to start to see value much faster when going composable.

API Mesh

API Mesh makes it easier to bring together many different micro-services, third-party tools, and other applications into a single unified API endpoint for front-end developers to use. Put simply, it lets developers combine multiple data sources into a single GraphQL endpoint. If you are familiar with a back-end middleware used for integrations, it’s similar in concept but instead of facilitating back-end integrations, it’s a middleware for integrations from back-end capabilities to your front end. This negates the need for front-end developers to have to access several disparate API interfaces across multiple vendors, all with their own unique standards and ways of interacting. It also allows developers to customize and extend these APIs directly in the gateway without making changes to the API source.

This all has the effect of removing complexity in your stack and making it easier for developers to build and maintain new features and experiences in a headless and composable model.

Adobe App Builder

Adobe App Builder is a serverless extensibility platform for creating your own microservices, creating custom experiences and extending Adobe solutions. With App Builder, you can build secure and scalable apps that extend Commerce-native functionality and integrate with third-party solutions.

This is essentially an Adobe-provided serverless, micro-service container. Built on Adobe’s infrastructure, developers can build custom microservices and extend Commerce and integrate it across other Adobe solutions and third parties.

When going composable, merchants are expected to create, manage and maintain their own customizations and microservices. For other vendors, this typically means having to arrange your own infrastructure and then having to configure, manage, and maintain this infrastructure yourself. Many merchants don’t have deep DevOps expertise or don’t want to have to operate these functions themselves — but are forced to do so when going down the composable commerce route.

By providing App Builder to merchants, we further reduce the complexity of going composable by eliminating the need for the merchant to build, maintain, and operate the infrastructure for any customizations and micro-services that they build. It also has the benefit of keeping microservices to a consistent language and framework — to further reduce stack complexity, streamline management of the stack, and lower the total cost of ownership.

Final thoughts

The choice between composable commerce and traditional commerce depends on various factors and trade-offs. Composable commerce offers many benefits to merchants including scalability, greater resourcing flexibility, and better multi-experience support.

However, it doesn’t come without challenges. With the complexity of managing multiple components, vendors, and integrations comes the requirement for deeper in-house technical expertise and careful vendor selection.

Ultimately, the decision should be based on each organization’s technical maturity, the complexity of the project, scalability requirements, team expertise, and agility needs. It is essential to thoroughly evaluate the benefits and trade-offs and consider the long-term implications before deciding.

Adobe Commerce provides the best of both worlds with a feature-rich platform, headless commerce, and new capabilities that make composable commerce easier. As your organization decides a best-fit approach, Commerce is here to help you achieve your business goals and customer experience objectives.

Nick Hull is an ecommerce expert with over a decade of industry experience. Hull has worked across various domains of ecommerce, specializing in ecommerce strategy development, technology strategy, resourcing, SEO, PPC, and ecommerce marketing automation.

Throughout his career, Hull has collaborated with and advised a range of global brands in both the retail and business-to-business (B2B) sectors, including Nestle, Nike, Canon, and Coca-Cola, among others. He also spent five years running an ecommerce operation for a pureplay online retailer.