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.
