1. Introduction
Retail is all about selling goods and services to the end-consumer - it’s everywhere and is a
vital part of our everyday life. And with the availability of mobile and internet connectivity,
the concept of e-retailing has become increasingly popular. All of these developments have
led to the rapid expansion of the retail business domain. In other words, there’s a significant
number of transactions that take place with a vast amount of data transferred and stored.
Thus, various data analytics are required to understand the business trends in a retail
business.
2. Overview of the Retail IT Landscape
Figure 1 shows a high-level overview of the various systems that come together in a typical
retail IT landscape.
Figure 01
Stores - this is where all the goods are stored and presented to customers; typically there
would be a warehouse and an e-commerce web portal to cater to consumers who come via
web and mobile devices as well as a central place where all the data is stored, such as data
centers located in the head office.
The system itself is a very complex IT landscape consisting of multiple disparate systems
linked together and exposed through several interfaces and channels. It includes
-
Stores - point of sale (POS)
-
Back offices for each store (linking the POS and the central data center)
-
Central data center or head office containing
-
Proprietary systems (e.g. ERP systems)
-
Data repositories
-
External data sources
Retail IT comprises several legacy or proprietary systems, such as product, order inventory
and supply chain management systems, each one focusing on a particular business domain.
It is a distributed deployment where each part is usually located in different geographical
locations. Retail IT focuses on various business technologies in order to increase revenue,
such as market analysis and transactional trends. Most retail businesses opt for cloud
services because a major portion of the retail business is driven with mobile and web based
portals due to the advent of mobile devices and APIs. Through this, software as a service
(SaaS) systems, such as Salesforce and PayPal, are introduced to the retail business.
3. Connected Retail - An Introduction
The concept of building an internally and externally connected business is applied to the
retail business. We need to integrate each component of the retail IT system. 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.
Some of the main objectives of building a connected retail include
-
To have a competitive and globalized retail business through which products and
promotions can be launched quickly in order to improve customer experience
-
To engage with customers in a more consistent manner where they receive
personalized attention and memorable interactions with the external systems in
order to provide them with a seamless shopping experience
-
To increase the reach of the business so that you can explore and discover
business opportunities and increase revenue
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.