Connected Retail Reference Architecture

There are many challenges an enterprise will encounter when trying to convert a retail business into a connected one. These include

• Creating a rich customer experience through fast delivery and checkout procedures
• Developing a transparent, collaborative, and real-time supply chain through seamless interaction with all systems to optimize underlying inventory stores
• Managing multiple channels through which data and sales management are performed. Given the proliferation of devices, multiple channels, such as web portals and mobile applications, are required to allow customers to purchase goods from anywhere
• Seamlessly uploading price updates so that it propagates to all parts of the retail ecosystem
• Moving away from point to point (p2p) links between POSs because they are brittle and not easy to troubleshoot or scale

As illustrated in Figure 2, a connected retail L0 Architecture comprises proprietary systems such as those required for merchandising, order management, supply chain, and distribution. These systems are backed by underlying databases that include multiple services hosted for various business domains. The main objective is to be able to integrate these disparate systems. The first step towards this is to introduce an integration layer that can talk to these disparate systems; it should be able to connect to the service layers, underlying web services, and all other business services. Moreover, the business intelligence aspect of the retail business needs to be facilitated as well via a business activity and analytics layer. All these layers would need to be managed and controlled with identity and access management as well as governance. The repository and the governance aspect of the entire ecosystem is handled by these two systems. One of the key aspects of a modern retail business is the API management layer because most of the functionalities exposed from the integration layer cannot be directly exposed to customers and external users. An API management layer would enable an enterprise to simplify business functionalities to be exposed to external parties. Another subsystem requirement is the business process layer because the integration layer would mainly provide stateless integration between disparate system and may not be able to address stateful business process needs; this can be done via adaptors.

The key functions of each of these layers are further explained below in Figure 2.

Proprietary systems: These include systems for merchandising, order management supply chain, distribution, and logistics among others

Business services layer: This includes web services and resource-oriented, REST-based services among others. There can be multiple services hosted for different business domains

Database: All these systems are backed by an underlying database

Data store and message broker layer: This guarantees message delivery

Integration layer: This solves the main challenge of integrating disparate systems in a retail business by acting as a mediation layer that helps each system communicate with each other. It also connects to the service layers, including the underlying web services and other business services.

Adaptors: These connect the proprietary systems to the integration backbone

Business activity and analytics layer: This facilitates all the business activity and intelligence aspects of the retail business

Identity and access management and governance registry: These two systems manage and control all the other layers and handle the repository the governance aspects of the entire ecosystem

API management layer: This is one of the key aspects of a modern retail connected business. Most functionalities exposed through the integration layer cannot be directly exposed to your customers and external users. The API management layer helps you to expose a simplified version of your business functionality without exposing all the internal implementation details and complexities. You can also expose simple interface to the client from this layer

Business process layer: The integration backbone mainly provides stateless integration between disparate systems. This layer can communicate with the integration layer and handle the complexities through adaptors. The main purpose of this layer is to keep stateful, long running business processes in the system

External cloud services: The integration layer can connect to these cloud APIs and integrate them with the internal systems

Stores (POS): These can leverage the API management layer when using internal functionalities

WSO2 Enterprise Service Bus (ESB) serves as the backbone of the integration layer to connect disparate systems of retail IT through available adaptors and can also communicate with all services in the business services layer. ESB cloud connectors are used to leverage any existing cloud service functionalities. Together with WSO2 ESB, you can use WSO2 Message Broker to implement guaranteed delivery scenarios. WSO2 Application Server is introduced in the business services layer to create and expose web and other types of service. In the business process layer, WSO2 Business Process Server (BPS) and WSO2 Business Rules Server (BRS) are added to manage long running business processes as well as stateful complex service orchestration scenarios. WSO2 Data Services Server is placed in front of the existing databases in order to expose them in the form of services so that external systems are not dependant on the underlying implementation of the database. For the the analytics layer, WSO2 Data Analytics Server provides batch processing as well as real-time analytics, such as fraud detection. WSO2 Identity Server facilitates the identity and access management of the entire ecosystem, and WSO2 Governance Registry acts as the repository and governs the system.

WSO2 User Engagement Server is used to implement various portals. An enterprise can expose APIs using WSO2 API Manager; this would act as the API façade for internal services that come from WSO2 ESB as well as WSO2 BPS and WSO2 BRS. Moreover, WSO2 Enterprise Store can hold your APIs or any other asset that you want to share inside or outside your organization.

One of the key advantages of using WSO2 middleware is that you can pick and choose which products you desire according to your business need because not all retail systems will need all of these components. Moreover, unlike any other platform vendor, WSO2 offers products that run on a single code base (WSO2 Carbon), which allows seamless integration and communication between each product.

Sample 1: This use case involves high volume message routing. The WSO2 ESB integration layer is used in the eBay system to achieve ultra fast message routing with minimum latency. Figure 4 demonstrates how the WSO2 ESB can be leveraged as a stateless message routing bus. The WSO2 ESB layer implemented in eBay is currently capable of processing over 6 billion transactions per day, which is the average eBay traffic. Refer to the eBay Customer Case Study for further details.

Sample 2: This use case consists of multiple products from the WSO2 platform as shown in Figure 5.

This retail business had several POSs that had their own databases. The databases are connected through WSO2 DSS; their online store, which has a separate database, is also exposed through the data services layer.

One of the problems that the WSO2 platform solved with this architecture was that the ERP system in use was SAP based whereas their POS were non SAP, which required an SAP to non-SAP integration. The ERP system sends price updates that need to be propagated to the POS. WSO2 ESB receives an iDoc from the SAP ERP system, which needs to be processed, transformed, and sent to the data service layer. Then this layer takes care of storing the information in the required tables of the databases. Any daily stats or sales details need to be sent to the ERP system. For this requirement, there are a set of scheduled tasks that run from the ESB layer, which communicates with the data services layer in order to obtain the required data from all POS systems. Then we perform polling and create the required iDoc at the ESB layer and send it to the ERP system across the SAP adaptor.

Another requirement was that certain POS systems were not available all the time, but the price update needs to be delivered to them. For this, we used WSO2 MB to achieve guaranteed delivery. The entire system is governed by WSO2 GReg.

A typical retail business has multiple transactions, which involve vast amounts of data being transferred and stored. This data would then need to be analyzed to derive business trends. To be able to do this effectively and efficiently, the retail enterprise would need to seamlessly integrate each component of its retail IT system. The internal systems, such as the enterprise resource planning (ERP) system or POS system, as well as the external systems, such as SaaS systems, needs to be connected in a way that they can communicate and interact with each other smoothly. The WSO2 platform allows you to build a comprehensive connected retail architecture with the use of its various middleware products; each product performs a specific function in the connected architecture, offering you a complete solution.