As a vendor of a Digital Commerce platform we are often asked for our opinion on the characteristics of a modern Digital Commerce platform and how does HCL Commerce fit into and API-First or Hybrid architecture.
In this article I’m going to try and provide my point of view by
- Taking a look at how Digital Commerce platforms have evolved;
- Exploring how this relates to the trends in the industry, what I’m seeing from clients and the evolution of API-First and hybrid architectures;
- Reviewing how HCL Commerce aligns to this new paradigm.
The Digital Commerce Puzzle
A lot has happened in the industry in the last thirty years. The internet went online to the public in 1991, Google was invented late 1990’s and the iPhone was first released in 2007. All these innovations have had a significant impact on my life and how I now purchase and consume goods and services. The last ten years has seen many more advances in software engineering with the broad adoption of open-source software and the near ubiquity of cloud native technologies, changing forever with words like docker, helm, whisk, puppet and many others taking on new meanings.
However, despite these advances, the way most Digital Commerce solutions and their underlying Digital Platforms are built, run and managed has seen little change over the same period of time.
“Gartner defines a digital commerce platform as the core technology enabling customers to purchase goods and services through an interactive and self-service experience. The platform provides necessary information for customers to make their buy decisions, and uses rules and data to present fully priced orders for payment.
The platform must have out-of-the-box capability or the APIs to support a self-service, interactive commerce experience that includes:
- Product catalog navigation
- Product pages
- Shopping cart
- Customer account
The commerce product must support, out of the box, the ability to search for a product, add products to a cart, and fully price an order inclusive of product-, customer- and order-level discounts or promotions. The commerce product must support interoperability with customer, product, content, and order functionality and data via APIs.”
Gartner – Magic Quadrant for Digital Commerce – 22 August 2019
This definition forms the basis of many commercially available Digital Commerce platforms that are, typically, made up of a number of components with capabilities that manifest themselves as a set of business services. In many organizations these platforms don’t exist in isolation but instead are part of a complex eco-system of both internal and external business services. As such the interoperability of the platforms capabilities and business services are of extreme importance. As the overall Digital Commerce solution is made from a combination of many components.
Historically vendors of Digital Commerce platforms have tried to simplify the platform selection by offering all the capabilities as part of a single application. A bit like a puzzle. An application formed of many pieces with lots of interdependencies that can only be put together in one way. It is true this application could be extended using traditional programming techniques to create points of differentiation but over time this has left many organizations with significant technical debt further increasing the burden of managing a large monolithic application already expensive to run, maintain and difficult to upgrade.
This dated approach also frustrates the business as capabilities within the application can be hard to separate and replace with others that may be more functional – in the same way that you can’t mix puzzle pieces from different puzzles and achieve the same result. For example, many organizations have a need for search with the ability to understand natural language but if search is an integral part of the platform it may be hard to replace with another solution.
From an architectural perspective the following diagram illustrates a traditional implementation of a Digital Commerce solution.
It may look complicated, but I’ve broken it down into three tiers: The Digital Commerce platform and related applications, the front-end applications and the supporting corporate applications.
Let’s start at the bottom. You don’t need to worry about the detail, but the Digital Commerce solution needs access to a whole host of corporate data and systems for things like product data, product pricing and order fulfilment. This information is exchanged with the Digital Commerce solution via a number of integration technologies depending on the interface availability.
For me, the interesting bit is in the center of the diagram. In this deployment model the Digital Commerce solution runs as a single application. The Digital Commerce platform capabilities all run within the same environment and co-exist with extensions to support things like payment and fraud. Some of these may exist as third-party solutions, for example content, but these integrations can be complex and hard to maintain.
These core capabilities also co-exist with the front-end applications user experience components which run server side.
In summary, most Digital Commerce solutions based around a Digital Commerce platform run as one single monolithic application. This makes it extremely hard to bring in new functionality and to combine capabilities and services developed both in-house and by third-party providers.
It also means that any change to any component requires extensive regression testing of the entire solution.
Modern Digital Commerce
With recent advances in software engineering and the broad adoption of open-source technology this no longer needs to be the case. A new breed of Digital Commerce platform has evolved. One that is based on the concepts of microservices and real-time event-based architectures. These new platforms are typically based on modern open-source technologies that allow the platform to be formed of a granular set of components and business services that are self-contained and, via APIs, can work together as one or be replaced with others that may be more functional if required. For example, the search service can be easily replaced with another from any 3rd party solution.
Further advances in the industry have also seen software development lifecycles shift from waterfall to agile to ones that are now continuous in nature via the adoption of a set of practices that automate the processes between software development and IT teams (DevOps) and the practices of continuous integration and either continuous delivery or continuous deployment (CI/CD). It’s the combination of both the granularity of components and the adoption of DevOps CI/CD principles and technologies that are providing organisations the ability to innovate and differentiate themselves at a speed that has previously been un-achievable. For example, with an upgrade to a Digital Commerce platform based on the principles of microservices and with the adoption of modern DevOps CI/CD principles and technologies, Abercrombie and Fitch was able to reduce the amount of time it takes for a new release candidate to be moved into production from four to six weeks down to four to six days due to efficiencies in the build, deployment and automated testing processes.
An API-First strategy
In my experience this is leading more and more organisations to adopt an API-first strategy.
With an API-first strategy everything is developed around the idea that it will be consumed via an API regardless of the consuming application. So, for example, the same business function could be consumed as part of an end-user experience application on web or mobile via the same API. In this scenario the API is the primary user of the business function forcing the developer to consider the needs of the API ‘first’.
Having business functions exposed via a REST API that is complete, responsive, and well-documented allows an organization to implement a hybrid Digital Commerce solution. A solution that combines the capabilities of a commercially available Digital Commerce platform with those that have been developed both in-house and by third-parties.
A hybrid approach
Let’s compare what the architecture looks like in a hybrid deployment model with the one we saw previously.
Again, the diagram is split into three tiers. The integration to the Corporate applications stays the same but both the middle and top tier are significantly different. The middle tier is now providing back-end services via an API to be consumed by the front-end applications. These are no longer part of the Digital Commerce platform but instead standalone applications consuming the back-end services via the API. These services are managed by an API gateway which enables a hybrid approach by enabling loosely coupled services from multiple sources to be combined by the front-end applications. It’s this approach that allows the services provided by the Digital Commerce platform to be combined, or replaced, with other business services that have been developed by the client and other third parties.
The loosely coupled nature of this architecture enables these to be combined in many and numerous ways by the front-end applications achieving complete separation from the back-end business services.
One major advantage of this approach is that each component is autonomous and so minimal localised regression testing is needed when a change is made.
Why invest in a platform?
These advances have also caused some organizations to question the value of commercially available Digital Commerce platforms. Given the finite list of capabilities needed for Digital Commerce and the speed of development for some organizations a ‘build vs buy’ approach can seem very appealing. For others though a commercially available Digital Commerce platform still offers a number of compelling benefits.
Firstly, there is the cost and effort of developing and maintaining a set of capabilities that simply provide the basis for trading online. Two examples from Gartner’s list would be Shopping cart and Check-out. Both are critical for online trading, but both are complex when combined with the need for them to be secure, scalable, responsive and available at all times. Teams worrying about complying with PCI legislation, cross site scripting and vulnerabilities in the underlying technology stack aren’t innovating. They’re also not providing the business with the same level of indemnity a third-party vendors’ solution developed, test and used by hundreds of other organizations would.
Then there are the addition capabilities included in a Digital Commerce platform. For example, HCL Commerce supplements the capabilities that Gartner list as the basis for trading online with the following services allowing complete Digital Commerce B2B and B2C solutions to be created within the same platform:
- Search & navigation
- Identity & session management
- Marketing & real-time personalisation
- Order capture & status
- Entitlement based catalog & pricing
- Product & ranging
- Subscription & promotion management
- Multi-site and locale
- A/B testing
And finally, these capabilities are all pre-integrated with a common, consistent and backwards compatible API and data model that removes any need for regression testing between the services they provide. All built on an enterprise grade platform that can deliver under the heaviest of demands. This then frees development and testing resources allowing them to be focused on the differentiating features of the user experience.
HCL Commerce, API-First and hybrid approach?
So is HCL Commerce a modern Digital Commerce platform that has an API-First strategy and can be used in a hybrid approach? In one word – YES. HCL Commerce has an API-First strategy and supports a hybrid approach by offering a comprehensive set of capabilities exposed via a modern REST API. These capabilities have been grouped based on business functionality and can scale independently based on demand. Via the use of cloud native technologies these components can be deployed in a number of ways to an on-premise, private and public cloud IaaS and PaaS infrastructures.
HCL Commerce v9 was released in December 2018 with clear upgrade paths from previous versions. Since then HCL Commerce has continued to evolve and now has five separate components each of which support multiple capabilities. Each component runs as a docker container and uses a well-defined REST API for communication. In the current version the transaction, storefront and search capabilities are deployed independently of each other allowing each to operate autonomously.
HCL Commerce v9 embraces and encourages the separation of business functions enabling organisations to release components when they become available independently of each other. With the adoption of good engineering practices: deployment pipelines, automated testing etc this can lead to shorter development lifecycles and rapid innovation. A good example of this is storefront separation. Now independent, all communication to other components is via a REST API. Changes can be deployed into the storefront with minimal regression testing of the other components. In a similar way to Abercrombie & Fitch another user of HCL Commerce has radically changed their approach to releasing changes into their production environment. Follet who support 2000+ college bookstores in the USA using the multi-site capabilities of HCL Commerce deploy changes throughout their peak processing time due to efficiencies in the build, deployment and automated testing processes that this separation allows.
With this modular approach the same is true for the other business services. Only minimal regression testing is required outside of the changes made to that business service. This accelerates the overall deployment of new features and functions and introduces greater resilience and scalability with errors or demand isolated to specific services.
The transformation of HCL Commerce is yet to be completed and over subsequent product releases in addition to adding new features and functions HCL will break out more and more business services into their own components. In my view it is likely that Identity, Cart and Pricing will be introduced as separate components within the next few releases.
In my experience the evolution of Digital Commerce platforms and the adoption of new technologies is allowing organizations to adopt a new, more modern, approach to their Digital Commerce solutions. This API-First strategy and hybrid approach is allowing businesses to combine capabilities in ways they haven’t been able to before which in turn is allowing them to innovate around the products and services they offer. It is, however, causing some organizations to re-evaluate the need for a Digital Commerce platform but many find significant value as long as that platform has also evolved to participate fully in the hybrid model. HCL Commerce is one such Digital Commerce platforms that has evolved and many of our clients should find themselves well placed and ready for the demands of Modern Digital Commerce.
If you’d like to find out more, register for a demo or download a whitepaper please visit us here https://bit.ly/HCLCommerce
You may also be interested in our YouTube channel which hosts our weekly Tech Talks which recently included an introduction to Docker and Cloud Native technologies https://bit.ly/HCLCommerceYouTube