Well, we all saw it and heard it, the new commerce industry buzzword is unified commerce (pun intended with the title). We now see an evolution from last year’s omnichannel to this year’s unified commerce. For me, the main difference between the two is this: the latter will leverage a single platform that integrates all the data and processes to create a seamless customer journey. In order to do so, the commerce platform will have to provide multiple facets, including the integration of all systems involved in the commerce landscape. Let’s call this Commerce Orchestration™.
Why is Commerce Orchestration™ important? This is what makes the difference between omnichannel and unified commerce. Instead of replicating or defining the same data and/or processes in multiple systems, the unified commerce platform will integrate all of them under the same roof, thereby creating a single platform that can power multiple customer experiences across different touchpoints.
Integration is the key word here. With the evolution of retail and commerce, business and IT end up having a complex ecosystem of systems which needs to be considered when creating and implementing the different business processes required for digital commerce. By having a platform that seamlessly integrates those systems, it will allow the business to leverage their existing investments around those systems for commerce operations, while offering the necessary capabilities to follow the evolution of the customer and its shopping journey. In reality though, with so many different systems and the many approaches available to integrate those systems, how can a single platform orchestrate all of it?
Let’s first take a look at the different methods of integration.
Please take note that the ERP is used here as an example of a system that needs to be integrated. The same methods could apply to other systems as well.
1. Event-driven synchronization
This integration method takes its roots from the publish-subscribe pattern. It leverages techniques such as asynchronous message processing, best effort processing and retry mechanisms. This method assumes that the commerce platform (or the external system, depending on the direction of the integration), already offers event capabilities. This means that the platform already has a process that creates a message whenever a significant change of state happens, a message which gets published to a queue and for which the subscribers can register. The workflow is similar to this:
- After an action done on the platform has created a significant change of state, the client will publish a message on a queue representing that change of state.
- A process (subscriber) will register to the message queue to listen to the messages going through.
- Should the subscriber be interested by one of the messages, it will acquire the message and launch a process that will execute some business actions based on the content of that message.
- If the process is successful, the message will be removed from the queue. Should the process signal failure, the message will be put back in the queue to be retried after a configurable amount of time.
By using such an integration mechanism, the platform can support near real-time integration to third-party systems while at the same time having a minimal impact on the main process that takes care of the high throughput shopping experiences such as the website.
2. Real-time integration via web services
In terms of feature and business value, this kind of integration will give the most benefit to the customer. This allows the touchpoint to offer real-time information on various aspects of commerce: inventory, product information, customer profile, order status, etc. The commerce platform should offer out-of-the-box the necessary web services to create different shopping experiences or to communicate to other systems (remember unified commerce: one platform for multiple experiences). Now, to integrate an external system (such as the ERP), the service of the commerce platform could actually act as a relay to a web service that is offered by that external system. This would allow information maintained in the external system to be available in real-time by the shopping experiences.
Of course, this assumes two things: the integrated system offers web services that can be consumed easily and that those services will guarantee a performance that is required from high volume websites. Looking at the different types of enterprise systems such as the ERP and WMS, they were built to handle a more operational workload, where business users are the main people that interact with the system on a regular basis. This is a major difference from direct consumer interactions that result in a very high volume of interactions. Hence, this is another reason to use a unified commerce platform: to act as a highly available, highly performant point of interaction for the customer-facing shopping experiences.
3. Periodic batch files import/export
This method allows the integration of information based on the exchange of flat files on a predetermined frequency and format. This is a more broadly used approach as all systems, no matter their age or technology, usually support those kinds of processes. The requirements will identify what is the entity or aggregate of entities to synchronize with the third-party system, define the direction of the synchronization (from the commerce platform to the ERP or vice-versa) and determine the frequency. The process usually follows this flow:
- The source system will export the information in the agreed upon format to a flat file (e.g. CSV).
- The source system will notify the receiver that a file is ready to process.
- The receiver will retrieve the file and load its content.
- The receiver will perform the adequate process to extract the information, validating the data and finally updating itself.
4. Raw data level synchronization or ETL
This form of synchronization is less frequent as most enterprise platforms will usually not give direct access to their data structure or allow a systems integrator to extend their data model. But even so, sometimes the situation requires such an integration effort for multiple reasons: all the other options are not possible or the efforts in implementing the integration are much simpler this way. This type of integration will depend on the technology used for the principal data store, usually leveraging techniques offered by those technologies to send, receive and update data. One example in the Microsoft world is to leverage SQL Server Integration Services (SSIS) to synchronize information between two SQL Server relational databases.
Not all methods are created equal
Although all the methods mentioned above can potentially be used in a commerce solution, architectural considerations will make event-driven synchronization and real-time integration via web services preferred approaches when evaluating how to integrate a system. Indeed, the first two approaches will offer greater decoupling of responsibilities by ensuring that the subscriber or service being used will only focus on one responsibility while not requiring a full stack of dependencies. They both also allow for easier scaling by placing the subscriber or service out of the main process.
In addition, event-driven synchronization and real-time integration via web services will leverage an API that is offered by the external system, allowing the solution to work at a higher level of abstraction than working at the data level. Working at an API level will reduce the amount of effort in terms of development and maintenance of the solution as it usually exposes a business process while hiding the complexities of its implementation. More so, most platforms will have a better process for handling, exposing and documenting breaking changes at the API level than at the raw data level. Platforms usually want to control entirely how they store their data to create an optimized layer that fits the requirements and processes that they need to implement in the platform.
Of course, despite all of those considerations, sometimes the commerce solution will still integrate an enterprise system by exchanging flat files. A frequent example is a scenario where the enterprise system will export a large amount of data, like the full product catalog, to be imported on a daily basis by the commerce platform. In the end, the important thing is that the unified commerce platform supports all the methods and the solution leverages the proper method based on the requirements and constraints.
One platform to integrate them all
In order to provide a seamless customer journey across all touchpoints, a unified commerce platform must include or offer the possibility to leverage one or all of the above methods to integrate enterprise systems in the commerce solution. These options are part of a toolbox that a systems integrator can leverage when designing and implementing a solution that uses a unified commerce platform as the core of the digital commerce strategy. The benefits of being able to use any method(s) include the ability to easily meet the business’ unique and sometimes complex requirements and also to simplify the number of connections between the shopping experiences and the number of systems involved in the solution.
Another benefit of integrating the different systems under the unified commerce platform is that it can be used as live storage: a performant and efficient repository for data used in the different commerce processes. With enterprise systems not designed to meet the high throughput needed of today’s digital experiences, having the commerce platform integrate other systems’ data in its storage will give the solution the necessary performance to power any shopping experience. This is in addition to the various levels of caching, distribution and scaling capabilities a commerce platform must have to support the highest of traffic.
Commerce orchestration™, the capability for a unified commerce platform to integrate the necessary enterprise systems using any of the methods above, is a key pillar for a commerce solution to provide a seamless customer journey across all touchpoints. Of course, to be able to fulfill that promise, the unified commerce platform not only needs to be able to integrate the various actors, processes and data around digital commerce; but it also requires the possibility to be extended at various levels. Meaning that the platform requires an architecture that will allow systems integrators to develop customizations and business rules that will be used in the platform, but also expose customizations so that shopping experiences can use them. With a platform that has a foundation on a service oriented architecture (SOA) or microservice architecture, that would be possible. The different extensions that address the custom business rules and digital commerce workloads can be exposed to the shopping experiences via custom services.
By combining the capabilities of systems integration with extensions via custom services, the unified commerce platform will be tailored to fit the business requirements now and through their evolution. As for the shopping experience, the unified commerce platform will act as a broker that communicates to multiple systems underneath (enterprise or external). By minimizing the number of connection points from the shopping experience to other systems, business and IT will have an easier time maintaining the solution while enabling the evolution to follow the speed of the consumer. As well, it will allow them to go a step further by offering additional capabilities that will fuel the evolution of the customer-facing website as well as bring new and innovative ideas for other digital shopping experiences, all running on the same platform. And with that platform running in the cloud, the possibilities becomes limitless, as the business will be able to easily scale their solution to meet their growing needs and deploy new capabilities to attract new customers and expend their brands.
Although unified commerce appeared as a buzzword only this year, some retailers already saw the benefits of such an approach and already started working towards that vision. FGL Sports, a Quebec sports retailer of the Canadian Tire group, actually launched their first experiences based on a unified commerce platform for their Sports Experts brand: their new SportsExperts.ca website and an interactive in-store digital experience named the Shoe Wall. Their first step in unified commerce is a successful one, paving the journey for many other experiences, and hopefully other retailers as well.
Benoit.
