Original post here by Gary Kirschner, Senior Director, Product Management, Oracle

One of the biggest topics in digital Commerce technology is using a headless architecture when developing ecommerce sites. Broadly speaking, a headless approach separates the UI layer from the underlying backend services, and connects the two through a set of web services. Contrast this with a more ‘traditional’ approach where the commerce system manages not only the services, but also the front-end UI, with technologies such as JSP pages.

Benefits of headless commerce

Development efficiency. UI development teams can work on changes to the UI layer, using the commerce backend as a set of services. In doing so, the UI can be updated and changed without updating and retesting all the core commerce logic and integrations. Likewise, with two separate code bases, teams have greater ability to work in parallel.

Simplified integration via the UI layer. Deploying a flexible UI layer that is consuming services from backend systems allows it to pull in data and services from a range of systems. The UI layer can act as a ‘mash up’ of various sets of services to present a coherent experience to the user, essentially moving much of the integration to that layer.

Add commerce into any front end or existing UI. Similar to the prior benefit, with a separate UI layer, commerce functionality can be inserted into any other system quickly and efficiently, without having to disrupt the overall approach and architecture.

With the above benefits, many merchants are faced with making key decisions on their technical direction. Significant market pressure requires that teams innovate more quickly, yet this innovation must be in the context of the overall brand experience and differentiated from competitors. Will a headless approach help meet those goals? And will existing back end systems enable and simplify implementation, or be a barrier? 

Beyond the broad definition provided above, there is actually a spectrum of possible approaches to running headless, and it is valuable to look at them to understand each.

Types of headless commerce

1. Non-headless commerce

In a non-headless approach, the UI layer and the commerce services layer are tightly connected and typically run as a single system. While this approach allows a tight integration between commerce tooling and experience management, it also means that all aspects of the commerce site are in the same system, causing inefficiencies in large development teams. Further, it does not necessarily require that services be exposed for commerce services, as they may only be accessed internally between the commerce application’s UI component and the application’s services.

2. Headless, Non-integrated

There are a range of UI layer tools and platforms available to developers for building the front-end UI for a commerce application. These approaches include using a web content platform outside the commerce platform, or even developing the UI layer in house. 

Without integration with the commerce platform’s tools, users have to rely on the UI layer’s tools for creating and managing the user experience for the site. If developed in house, that means there is a need to also develop tools to allow business users to manage the experience as much as possible.  Further, some UI platforms may not give you the flexibility to integrate and allow the commerce platform to influence the experience, even if the time and money is available to do the work.

Whenever either of these approaches is taken, unless it is an explicit goal and extra effort is undertaken, the UI layer will not be able to be managed from the commerce application.  Page layouts, content selection, personalization, testing and more will all be driven by the UI layer, and its tools.

3. Headless, Integrated UI Tools

With this approach, the UI layer is separate from the set of backend services and communication is based on web services. However, unlike the prior approach, the UI layer is still integrated with the commerce application, such that commerce application capabilities, like site design tools, personalization, A/B Testing, etc. can all be leveraged.

In this approach, the UI layer can be provided as a part of the commerce application, it could be a custom developed UI solution, or it could be a platform provided by another vendor. However, the latter two approaches require extensive work to leverage all capabilities of the commerce solution.

Headless commerce with Oracle Commerce Cloud

Oracle Commerce Cloud gives you the flexibility to choose either of the headless flavors described above. Critical for these headless approaches is a robust set of REST web services (which helped us score very highly in the latest Gartner Magic Quadrant for digital commerce). Oracle Commerce Cloud has been designed from the bottom up to take an “API First” approach, ensuring that all functionality is available via services. This presents a very wide range of options for implementation.

Out of the box, Oracle Commerce Cloud provides a storefront UI layer and application that is brandable, extensible, and fully integrated with the commerce application tool set. It is a single page application that communicates with the platform through a complete set of REST services, and allows customers or their implementation partners to use Oracle provided building blocks (“widgets”) to build up pages, or create their own widgets and place on appropriate locations on the site. In a similar manner, all the other capabilities of the Oracle Commerce Cloud solution, such as personalization, AB Testing, Recommendations, responsive site design, and content capabilities are made available through the storefront framework and tools, and provided widgets.

Just as Oracle has provided a storefront application in a separate UI layer, using REST services and being tightly integrated with the Commerce Cloud tool set, an implementer can build their storefront application using the same REST APIs that Oracle uses. At a minimum level, the storefront can use these APIs only for core commerce services, such as catalog browse and search, cart, checkout, and so on. However, just as Oracle has used these APIs to leverage the commerce site design tools, so could a custom UI layer, albeit with more effort. Check out our public API documentation here.

The choice is really for the merchant to make, depending on what best fits with their strategy and capabilities.

Is headless commerce right for my organization?

The choice to go headless, and the selected approach to headless, are not easy decisions to make. While there are benefits, such as improved independence of development teams, there are a number of challenges that customers have run into that are worth review.

Headless sites typically rely on JavaScript technology for much of the site functionality. While doing so can give a great user experience, it does present challenges for search engine bots, SEO, and other web technologies. Oracle Commerce Cloud’s storefront leverages a number of different approaches to handle bot traffic such that the site’s pages are rendered correctly and indexed appropriately by external sites. 

Unless significant effort is made to integrate the UI layer with the commerce platform tools, business users will end up with two systems to use, with two sets of tools, and the need to copy paste between them. Even if fully integrated, from an IT perspective, the group will need to understand, manage, and test an additional application, associated integrations, etc. for two platforms.

Essentially, running a second platform is not free, either technically or from a usage perspective. If your IT capacity is not sufficient, or your business process is not flexible enough for use of two systems and tools, a non-integrated UI layer, headless approach may not be right for you.

Integrating a completely separate UI layer with your backend commerce services can be more difficult than expected. While usage of standard commerce services is usually straightforward, to get the most benefit and not have business users jumping between multiple tools, you want the UI layer to leverage customer information, including commerce activity, and other commerce data, to present the best experience. That data either needs to be shared between the commerce platform and the UI platform, or query/used as needed. Either way, it is a more complex integration effort and can extend deployment times and costs.

Conclusions

While headless approaches for commerce sites can provide a range of benefits, these benefits do not come without costs or risks. These costs and risks should be evaluated by each individual merchant to understand which is the best approach for them.

Oracle Commerce Cloud provides a unique set of capabilities that gives merchants a great deal of flexibility in choosing the approach that best meets their needs. That could be using the Commerce Cloud storefront provided by Oracle to get the benefits of a headless approach, with Oracle doing the hard work around integration, common tools, SEO, and more. Or, it could be leveraging a third-party platform or technology that utilizes Commerce Cloud’s REST framework, allowing implementers to leverage these same tools, or run in a non-integrated fashion.

Watch a recording and demo about Commerce Cloud’s API and innovations for developers from the Modern Customer Experience conference.

Get the latest Gartner Magic Quadrant for Digital Commerce 2018 report.