Headless commerce has gone mainstream. In its narrowest sense, it’s defined as the separation of the front-end and back-end aspects of an eCommerce experience into separate applications that communicate via APIs. Headless commerce has been cited as everything from an important way to level the field against Amazon to a crucial approach for retailers to respond to rapidly changing consumer expectations.
These and many other descriptions are true. Headless can and does deliver enormous benefits for Isobar clients and beyond. At the same time, it’s important to understand some caveats to do it right.
Why Headless is popular
Separating the presentation layer of a website from the rest of the site – or making the site headless – technically goes beyond eCommerce sites. A brand site with zero eCommerce functionality can become headless. In the context of an eCommerce site, a headless approach makes it easier for a business to add, say, a payment feature to a website or an improved shopping cart functionality more easily. Especially in 2020, with consumer shopping behavior shifting dramatically online amid plunging offline retail sales. Businesses need ways to make updates more quickly and in a less risky fashion to their sites.
By encouraging modularity, separation of concerns, and the implementation of features using well-defined APIs, headless can make it easier to build and deploy new user interfaces for traditional commerce capabilities. Doing so can also enable quickly modifying the experience for a core feature such as shopping cart, often avoiding the complex customisations and long design, build, test, and deploy cycles of tightly coupled commerce platforms.
As we discuss in a recently published white paper, traditional approaches to eCommerce have tended to deploy a single, integrated platform. Although these applications enabled brands to get to market quickly and penetrate a single Web channel, they had significant drawbacks, not least of which was their inability to integrate Content Management Systems (CMS) and eCommerce platforms in a seamless way.
Headless commerce breaks the barrier of having a brand site and a commerce site, by enabling the brand experience to co-exist with the shopping experience in one site. Headless commerce also provides a more agile approach to integrating front-end experience delivery with the back-end technology that surfaces content and data by allowing the two ends to work together in harmony. This approach also ensures that the enterprise puts the experience first.
By putting the customer at the heart of its philosophy Headless commerce is a compelling way for brands to build a flexible technology infrastructure that can deliver an outstanding customer experience within the new digital economy. And, the good news is that businesses can embrace headless without tearing up legacy systems. As Jeff Skowron, senior research director at Gartner, told Which-50.com:
“If you are using an all-in-one commerce app, you don’t have to throw away the sites that you are managing out of that application. At this point most all commerce vendors in the market offer API integration layers that enable a headless architecture. The shift is more incremental and can be done without disrupting existing sites, assuming your commerce app has the necessary functional API/integration capabilities. ”
Caveats to consider
But if you’re going headless, it’s also important to bear in mind some caveats:
You’ll need to invest more effort to pull it off successfully
As Skowron told Which-50.com, a website team needs to work hard to support the integration required between separately deployed user interfaces and systems. The decoupled approach increases the effort required to deliver functionality because teams must create and support integrations between separately deployed UI applications and systems. It also requires managing multiple application stacks.
Weigh the pros and cons of going headless carefully
IT decision-makers may have to balance flexibility against the potential to lose some of the integrated OOTB functionality of platforms. A business must decide if going headless introduces limitations or complexities that take away some of the convenience that business users, content authors, etc., might rely on from an integrated software offering.
The points of potential failure increase with the decoupled architecture
When the experience layer is hosted separately from the ecommerce engine and several services are introduced to the ecosystem, a business can incur an increase in the risk to the overall uptime
Finding the right resources might be challenging
As you get into the headless architecture, your resource requirements will change from needing front-end developers and back-end developers who specialise on platforms, to needing a combination of specialists, enterprise developers (front-end and back-end) and also DevSecOps for managing the infrastructure.
How to get started
Along with the change in architecture, a cultural shift is also equally important in order to successfully build, deploy, support, and continuously improve a large-scale headless eCommerce solution.
Some of the foundational steps towards this journey are:
Change in culture
Build a team internally to support and maintain the experience layer, services layer, and underlying infrastructure as some of the responsibility shifts from the eCommerce vendor to the client.
Create an experience technology roadmap that addresses all the ways you’d want to surface content and data (glass, IOT, and conversational).
Investigate how you can use underlying platform capabilities like personalisation to surface personalised content in headless fashion. Doing this can help maximise your investment in expensive but feature rich platforms like Salesforce.
Pick a primary front-end library or framework that meets your requirements and that your team is comfortable with.
Change in implementation methodology
Build a UI toolkit with reusable web components.
Break down the business’s monolithic architecture into functional services with mediation infrastructure that integrate with an eCommerce engine’s API (e.g., OCAPI in Salesforce Commerce Cloud) to enable core commerce functionalities.
Design services to be highly resilient, fault-tolerant and scalable, as every service is most likely a critical service in the eCommerce space
Design and Build discoverable, well-documented, secured domain APIs using API Gateways like Mulesoft for consumption from agnostic channels
Use pre-built Accelerators and Connectors from Mulesoft to enable commerce features and experience in an agile manner with minimal time to market
Build your front-end applications in a way that are decoupled from the underlying systems feeding them content through interfaces.
Additional considerations
Design and build a caching layer for the services to provide optimal performance to users
Build a CI/CD pipeline that does thorough code scanning, security, and performance testing, with QA Automation built into it
Additional SEO considerations will be necessary for SPA.
Final thoughts on Headless Commerce
Overall, headless allows businesses to proactively meet consumer needs as an alternative to the analyse, plan, design, build, and launch approach. Even though the headless architecture may require additional upfront work to lay the foundation, it pays off really well in the long run because headless enables businesses to continuously experiment more and try out new ideas. Headless also allows technologists to help the enterprise maximise experiences and differentiate their brands while still taking advantage of powerful platforms such as Salesforce.
The headless approach enables businesses to build a rich experience, and quickly try new ideas. It provides businesses with maximum flexibility to have best-in-class commerce functionalities backed by a leading CMS system.
Get all the benefits of an integrated platform while taking advantage of the core strength of Salesforce Commerce Cloud!
