Research from Gartner

Composable Commerce Must Be Adopted for the Future of Applications

FOUNDATIONAL Refreshed 25 August 2021, Published 18 June 2020 - ID G00721518 - 20 min read

Digital commerce platforms are experiencing ongoing modularization in a cloud-native, multiexperience world. Application leaders responsible for digital commerce should prepare for a “composable” approach using packaged business capabilities to move toward future-proof digital commerce experiences.

Overview
Key Challenges

• Monolithic applications and the technical debt they impose often prevent organizations from moving quickly and achieving their desired business outcomes.
• Delivering platform flexibility can be at odds with speed to market, and achieving an optimal balance of both is needed to succeed.
• Hype around “headless” approaches can cause organizations to lose focus when the actual requirement is for “many heads” when it comes to customer expectations for seamless multiexperiences.

Recommendations

To prepare for the future of digital commerce, application leaders responsible for digital commerce technologies should:

• Create a roadmap to strangle (or replace) your digital commerce monolith by adopting an incremental, modular approach using packaged business capabilities.
• Secure the future of your digital commerce strategy by developing a composable commerce platform.
• Maintain business agility and control by selecting delivery options that retain business user control of presentation.

Strategic Planning Assumptions

• By 2023, 50% of new commerce capabilities will be incorporated as API-centric SaaS services.
• By 2023, organizations that have adopted a composable approach will outpace competition by 80% in the speed of new feature implementation.
• By 2023, 30% of commerce organizations will require an API product manager role to modernize digital commerce applications and architecture.
• By 2024, 10% of digital commerce organizations will use packaged business capabilities (PBCs) to construct their application experiences.

Introduction

In this research we review a shift in thinking from an inward-looking “platform-centric” view to an outward-looking customer-experience-centric view. To achieve agility and flexibility in delivering experiences, modular packaged business capabilities (PBCs) are brought together to form composable digital commerce platforms that align to the future of applications.

When considering digital commerce and other associated digital experiences, it can be useful to think along three dimensions:

1. The customer journey
2. The capabilities required
3. The technology stack

Capabilities are built on technology “stacks” and customer journeys are supported by several different capabilities. At the top of the stack (see Figure 1) is an experience layer, via which the capabilities are exposed to customers. In a monolithic platform this is all tightly coupled, usually with extensions that can be native or integrated, external applications. In a composable application, this coupling becomes looser, and the integration of capabilities often occurs at or near the experience layer, and not within a monolithic application.

Figure 1: Three Dimensions to Consider When Creating Digital Commerce Experiences

Analysis

Create Your Roadmap to Strangle (or Replace) the Monolith

The Technology Stack

The technology stack comprises the layers of technology in an application: from a data layer, through business logic, to presentation orchestration, represented by the three vertically aligned boxes per capability in Figure 1. For presentation, digital commerce has, and to a great extent remains, a browser-based experience via HTML, CSS and JavaScript. However, the way enterprises build browser-based digital experiences has undergone rapid evolution. It has moved away from tightly coupled “server side” presentation to API-driven, client-side JavaScript web applications that enable flexible experiences via single-page applications (SPAs) and progressive web applications (PWAs) and beyond to native mobile app delivery (see “How Progressive Web Apps Improve Digital Commerce”). A loosely-coupled presentation tier has become the norm for digitally mature organizations. We have seen the rise of API-first digital commerce platform vendors in reaction to this development. More recently, the leading “full stack” digital commerce platforms have enabled support for the front-end frameworks. These remain nascent but include developer-facing environments such as Magneto’s PWA Studio and VTEX’s vtex.io, to code libraries such as SAP’s Spartacus. We are now seeing the utilization of “backends for frontends’ (BFF) supporting technologies (such as GraphQL in vendor’s platforms) to ease the job of decoupled front-end development and increase development efficiency against APIs.

Packaged Business Capabilities

We are already seeing a shift away from monolithic digital commerce application solutions toward modular platforms built from several discrete capabilities. This shift was fundamentally hindered by the full-stack approach. The decoupled nature of modern front ends has become an enabler for the acceleration of a composable application approach — as back-end capabilities can be developed and even launched independently of the front end.

Organizations are embracing this approach to increase agility and flexibility, and so are vendors. Cloud-native modular architectures are available from several vendors, with some mature platforms releasing new capabilities as multitenant SaaS capabilities only, resulting in hybrid cloud platforms. Thus begins the “strangling” of the monolith as first described by Martin Fowler.¹ This is an incremental approach to replacing a legacy platform by slowly reducing reliance on the core monolith.

Today, these modular capabilities are often called “microservices,” but while this usage is common in the market, it does not align to the technical definition of microservices² (see “Innovation Insight for Microservices”). The market usage is more closely aligned to the idea of packaged business capabilities (PBCs) that has arisen out of Gartner’s future of applications research (see below, and “Apply the Principles Behind the Future of Applications to Digital Commerce”).

Customer Journeys

A growing reality for digitally mature organizations is that digital commerce does not stand alone and should no longer be a monolithic silo of engagement. This goes beyond consistency across channels to mean a unified end-to-end customer journey, including engagement and postsales relationships and support. The simplicity of the “e-commerce” go-to-market is being challenged via requirements that go beyond the traditional core buying journey. Monolithic platforms may not easily integrate with these wider journeys, and productized connectors to ecosystem vendors are usually required.

Consider the following requirements:

• The integration of content and social narratives to drive engagement and conversion.
• For most retailers, the need to have a unified approach with store integration and returns management.
• The need to support customer inquiry, customer and product postpurchase service in the same experience.
• The need to support emerging hybrid digital-physical goods such as smart sneakers/trainers, that require both retail and subscription models and ongoing data services.
• The need to have a unified brand experience throughout the customer life cycle.

For B2B and digital business:

• Manage ongoing relationships with customers (usually via a “customer portal”) with supply chain transparency.
• Enable flexible integration with partners to generate new revenue channels (see “Scaling Digital Commerce Into a Digital Platform Business”).

To orchestrate and unify these wider customer journeys, organizations are taking control of the presentation layer making it the point of integration of capabilities, instead of the commerce platform. Figure 2 shows a simplified example of how a set of applications can support integrated customer journeys. In addition, because multiple touchpoints exist, applications must support “multiexperiences.” These may be delivered via a mixture of front-end/device-type-specific code shared — or not shared — between touchpoints.

Figure 2: A Single Platform for Experience Orchestration Is Optimal for Supporting a Seamless Cycle of Customer Journeys Beyond E-Commerce

Develop a Composable Commerce Platform to Future-Proof Your Digital Commerce Strategy

To understand your platform’s digital maturity see “Maturity Model for Digital Commerce Applications,” and to learn about what Gartner means by organizational digital maturity in digital commerce read the Evaluation Factors section of “Innovation Insight for API-Based Digital Commerce.” PBCs are the building blocks for future business applications such as composable commerce applications. PBCs are independently deployable capabilities that include self-contained business data, logic and processes to perform a business function. These interact with other applications via APIs and event channels. The appropriate granularity of these modules (they are not always “micro”) is defined by business needs, and must balance development flexibility/agility with governance complexity and costs. For an introduction to this idea see “Innovation Insight for Packaged Business Capabilities and Their Role in the Future Composable Enterprise.”

Monolithic digital commerce applications cannot support the agility and flexibility needed to support fast moving digital business. Organizations will need to move toward composable commerce to keep up with the pace of change in customer demand. Some organizations may choose to build their own solutions in this fashion, and may for example, already have established a “microservices” architecture. Others will rely on vendors to provide best-practice capabilities. Few commerce vendors have yet split their products into smaller modules (incipient PBCs) such as product catalog, shopping cart, promotion engine and product recommendation. To embrace this new paradigm, organizations need to select vendors who can show that they are embracing this future, even if their current product does not fully align.

In the future, Gartner sees the composable approach becoming the norm across enterprise applications. It just happens that, in the digital domain, especially around digital commerce, that future is already partially here.

It is already possible to buy or rent capabilities from a single larger vendor, or separate best-of-breed vendors to cover wide range of functions.

For example:

• Core commerce (shopping cart, promotions, check-out)
• Content
• Search and search merchandising
• Reviews and ratings
• Customer identity management (access and identification)
• Customer data platform (data/personalization analytics)
• Service (help desk, knowledgebase)
• Chatbot

The composition of these into an end-to-end digital commerce experience is the subject of the next section.

PBCs may be vendor-managed SaaS, in public or private clouds, or on-premises.

The approach described in Figure 2 can now be rearticulated using Gartner’s new visual paradigm for the composable enterprise (see Figure 3).

Figure 3: PBCs Allow Organizations to Compose Modular, Hybrid Experience Applications

Using the composable application approach, digital experiences are assembled as required, depending on the customer and touchpoint requirements, and delivery of an “e-commerce site” may be just one of these experience types. The focus shifts to a truly customer-centric view, supporting customer journeys as required, and a single PBC may support more than one.

Composition does not just look “outward” to the digital experience, but also “inward,” between each PBC and the back office. Integration itself remains one of the most complex parts of any commerce platform implementation.

In the future of applications, integration among PBCs will need to include low-code or no-code integration and pervasive API mediation to provide agility. For now, we often must rely on point-to-point, productized connectors or custom API integrations.

For more on integration in the future composable enterprise, see “The Applications of the Future Will Be Founded on Democratized, Self-Service Integration.” For more on using PBCs and how to prepare for this future, see “2020 Strategic Roadmap for the Future of Applications.”

Evolving Toward Using PBCs in Digital Commerce: An Example of Personalized Product Recommendations

The core commerce platform may include basic functions such as rule configuration to enable product recommendations — with differing degrees of sophistication. If a more sophisticated product recommendation capability is needed (such as a personalized recommendation based on the customer profile and clickstream behavior), it may require a dedicated personalization capability or additional module. The functionality of personalization engines is broad. Search results ordering, product recommendation and content layout, on-site content display, shopping cart abandonment, email marketing, and social media content may all be personalized. To compose a personalized product recommendation service from PBCs, organizations can take an incremental approach as they start, optimize and transform their digital commerce. For more on this stepwise approach, see “Scaling your Digital Commerce Into a Digital Business”. The steps align to Gartner’s maturity model for digital commerce (see “Maturity Model for Digital Commerce Applications”) and are outlined in Table 1.

Table 1: Incremental Steps Toward Implementing PBCs and a Composable Architecture for Personalization

Source: Gartner

Existing functional modules in the enterprise application portfolio can also be repurposed as PBCs within a composable commerce approach. This reuses existing features relevant to the business needs, alongside new ones (see Figure 4). To enable this, these modules would need to conform to the basic characteristics of a PBC, including an API or other interface for integration. The composable approach reduces duplicate investment in applications and gives greater agility in new service development. It would enable an organization to develop a personalization service differentiated from the default offering in off-the-shelf solutions.

Figure 4: Using the Composable Application Model to Compose a Personalization Application From PBCs

The ability to compose digital commerce applications from PBCs is the direction that digital commerce application architecture will move toward. These individual components could be provided by multiple vendors to formulate unique experiences. The granularity of each capability will depend on the structure and scope of the resulting composed digital commerce application. Organizations should not assume “the more granular the better,” because finer granularity (for example, hundreds of microservices) can increase development and operational complexity, inflate costs, and create governance challenges.

In the digital commerce and wider digital experience market we are seeing the emergence of initiatives and movements of groups of vendors and/or open-source communities with a particular approach to developing digital experiences. These include JAMstack³ (where “JAM” is JavaScript, APIs and Markup) and in digital commerce specifically, MACH⁴ (where MACH is Microservices, APIs, Cloud and Headless). In this approach, a single vendor is not necessarily at the heart of the digital platform, which is instead composed from an ecosystem of modular, best-of-breed applications from different vendors; the precursors of PBCs.

Gartner recommends starting the modular, composable commerce journey with low-hanging fruit, providing achievable goals that have clear business benefits. These are likely to be capabilities that already map to the PBC paradigm, requiring low effort to decompose or integrate. They can deliver business benefits by quickly supporting updates, improvement and innovation. Focus on capabilities impacting customer experience such as search, personalization, new touchpoint support, emerging ML technologies or UX/UI design.

The ability to compose new applications in this fashion today only exists within the most digitally advanced organizations. These early-adopting organizations tend to have bold digital business ambitions, advanced technical skills and governance practices, as well as higher maturity level with digital technologies. For most organizations using monolithic applications today, greater maturity of compositional tooling is required to compose experiences from PBCs. This should not stop them from beginning the journey. Indeed they will find that going some of the way begins to provide some of the advantages of the composable application. For advice on finding your organization’s “tequilibrium” between the composable approach and other options, see “Apply the Principles Behind the Future of Applications to Digital Commerce.”

In the future of applications, Gartner predicts that developments around integration, for example via low-code application development platforms (LCAPs), will simplify composition. The lack of interoperability standards between incipient PBCs makes “inner” integration between parts of a composed application harder now. Initiatives such as CloudEvents⁵ are beginning to tackle this “standards” challenge.

Maintain Agility and Control by Selecting Delivery Options That Retain Business User Control of Presentation

Headless has become a buzzword in digital commerce and other customer-facing application segments. Headless is not a great name for this new approach, because of course there must be a head, or UI. In fact the challenge today is that there are many heads that can be seen as both channels and customer touchpoints. These heads must provide seamless digital experiences, which Gartner defines as multiexperiences (see “Transcend Omnichannel Thinking and Embrace Multiexperience for Improved CX”). Multiexperience commerce is becoming the practical reality for leading digital organizations and is the primary expression of the ongoing enablement of commerce in the customer’s context and at the customer’s convenience (see “Industry Vision: Commerce to You”).

To support these many heads, presentation is decoupled from the application logic via APIs. Hence, Gartner’s use of the terms “API-based commerce,” “API-oriented architectures,” and “API mediation.” To support the broad array of newer touchpoints such as chatbots, voice, smart TVs and AR/VR, the same presentation code that runs a website or native app is not always valid, but the same underlying commerce capabilities are required.

In Gartner’s research on the future of applications we specifically identify low-code application development platforms (LCAPs) as that potential experience-building and orchestration layer, and predict that vertical-specific platforms will emerge. Digital commerce appears to be a prime early adopter of a modular approach but no “LCAPs” currently exist, though it could be argued that some DXPs approach this capability. Fundamentally, PBC orchestration should enable a seamless customer journey across multiple touchpoints by enabling no-code integration at or near the presentation layer.

Currently, there are four main, nonexclusive ways to integrate and present digital commerce and related experiences. All of them require PBCs to be integrated via APIs, and ideally, mediated APIs (API mediation includes dealing with API orchestration, transformation, security and performance):

1. Direct integration to a JavaScript web application: JavaScript web application frameworks such as Angular, React and Vue are used to create SPAs, PWAs or generate sites via static generation tools such as Gatsby (see Figure 5). APIs support the creation of a BFF approach to supporting browser applications, for instance using a node.js server and GraphQL. These techniques provide major customer benefits such as enabling mobile native app-like experiences. Faster mobile performance is achieved by reducing the need for server-rendered pages, limiting application server calls to only the dynamic data needed. PWAs take this further by not only using the client device’s native capabilities, but by caching more content and code on the client side, further reducing internet traffic and making for faster app-like experiences.

Figure 5: No More Monolithic Platform, Shared Experience Delivery

We have previously characterized this approach to delivering the presentation layer as “custom front ends” (see “The Three Approaches to Digital Commerce Platform Architecture”). They are generally handcrafted in a front-end framework and not built using a commerce platform or DXP. As described above, several digital commerce platform vendors provide SDKs, samples or reference applications, or development environments. These are used as the starting point for the development of storefronts. There are also stand-alone code libraries such as Vue Storefront, which are platform-agnostic. When taking this approach, be wary of losing business user management of presentation (see point 4).

2. Use front end as a service (FEaaS): Front-end skills are in high demand and building an internal competence, or even outsourcing a development team, may be prohibitively expensive. We are seeing the emergence of “front end as a service” vendors, including Moovweb, Mobify and Frontastic. These provide FEaaS by bundling light serverside runtimes (often in node.js) and sophisticated content delivery networks (CDN) with storefront themes and coding services. Thus presentation design and code is provided as a service via best-practice themes and widgets. This is a standardized engine that is agnostic to the commerce capabilities underlying it. Commerce platforms and other capabilities integrate via their APIs.

3. Integrate to a DXP: DXPs provide out-of-the-box capabilities for many aspects of managing digital experiences, beyond their CMS/WCM or portal heritage. They have become mainstream for “experience driven” commerce, commonly used by established brands and lifestyle and luxury retailers. In this case, the commerce platform is integrated via its API and the DXP provides the front-end elements or “widgets” to support the UI. DXPs can provide integration points for other API-based applications (future PBCs) and can act as the integration and orchestration layer (see Figure 5). DXPs themselves often are “hybrid headless” today, enabling either the use of built in server-side templates, or APIs to drive JavaScript front ends (see “Hybrid Headless Content as a Service Is the Future of Digital Experiences”). Some DXPs include digital commerce capability natively. If taking this approach, be wary of platforms that might constrain you to a single method of experience management (for instance, they may lack a robust API for nonweb digital channels). Such a platform will not provide optimal multiexperience delivery.

Figure 6: DXPs Can Provide Experience Orchestration and Management Using a Mix of Native and Third-Party Components

However, DXPs can be another monolith, with few having cloud-native architectures. This brings more restrictions on agility, and potentially can increase complexity. Some vendors in this space are moving toward providing a “lean DXP” that focuses on a core set of experience orchestration capabilities without forcing the use of heavyweight embedded content management or similar capabilities, that in future will be defined as PBCs (see “Defining the Digital Experience Platform”).

4. Integrate into a custom app: This could be a built-in multiexperience development platform (MXDP) or a low-code application development platform (LCAP): DXPs and MXDPs differ in both their heritage and focus:

• DXPs focus on the web experience with a heritage in WCM or Portal, and are usually packaged application platforms that can be configured and extended. Experiences are managed via prebuilt admin GUIs.
• MXDPs have a broader focus of touchpoint support, with a heritage in mobile app development, and are usually software development platforms with differing levels of coding requirements. Experiences, plus any business tooling to manage them, must be built in or integrated to the MXDP.

Digital commerce experiences can be built using MXDPs, though the limitations of these environments for sophisticated experience orchestration may prove too restrictive. LCAPs are emerging as a new way to compose experience applications, but uptake and maturity remains low in digital commerce. Vtex.io is an early example of a digital commerce vendor providing such a tool.

The Challenge of Presentation in a Decoupled World

Modularity and loose coupling provide the ultimate flexibility and agility, but there can be a cost. In moving away from a mature space full-stack commerce platform or DXP, early uptakers of “headless commerce” or content quite often found that the business was no longer able to manage aspects of the digital experience.

Examples that were previously considered differentiators of tightly coupled applications include:

• Page layout management via WYSIWYG/drag and drop.
• In-context content preview
• Customer journey management

Too often, early adopters of headless approaches put these capabilities back in control of the developers. While this vastly speeds up initial development, future change once in production becomes an IT issue, and not self-service for the business user. Whatever the ambition of the digital team, developers end up with priority lists and queues of tickets, and business users get frustrated. To tackle this, business tooling must retain control of the digital experience wherever possible. Vendors in the headless content and experience space are tackling this challenge, providing layout metadata (that can be changed by the business via a GUI) to the front end, and/or providing JavaScript editing overlays for business users viewing production sites or preview apps. They are also extending their reach to navigation and third-party application integration. However, headless presentation orchestration functionality remains less mature in the digital commerce space. If you are looking to go headless but retain business agility, investigate product capability in this area.

A number of companies known to Gartner are already taking this approach, including:

• DFDS: The ferry and logistics company decided to compose its own digital commerce platform and is moving forward with a head-optional platform. Vendors included Contentful (CMS), Okta (identity), Algolia (search), Conductrics (personalization), and an API-first commerce platform (source: Client inquiry).
• Lego Group: The toy manufacturer is building out its next-generation B2C and B2B digital experiences using a (wait for it …) Lego bricks approach to the architecture, including Contentstack (CMS) and Commercetools (digital commerce) (source: Personal communication).
• The Spectator: The digital media company is building a new digital publishing platform using a “serverless” approach and integrating the following vendors: Contentstack (CMS), Swiftype (search), Disqus (reviews, UGC), Piano (publishing DXP), Braintree (payment) (source: LinkedIn).

Evidence

¹ Martin Fowler Strangler Application
² Martin Fowler Microservices
³ JAMStack
⁴ MACH
⁵ CloudEvents

Source: Gartner Research Note Refreshed 25 August 2021, Published 18 June 2020 - ID G00721518, Mike Lowndes, Sandy Shen