In this case study we'll talk about a fictitious retail enterprise, called JKHL Enterprises (JKHLE). Even though this company is a fictitious one, all of the use cases are based on real-life scenarios and projects. Imagine JKHLE as a company that deals with food and non-food articles at mid-size stores in more than 10 countries worldwide. The customer's strategy follows the principle of "non-complex store IT operations". JKHLE are concerned about all of the IT devices in stores and the complexity that might impose on local personnel. So they're trying to handle as much as possible at corporate headquarters and only absolutely necessary IT related integration at the stores themselves.
There are several integration solutions as part of IBM Retail Integration Framework, for example WebSphere Remote Server. It depends on customer's IT strategy (low-complex IT operations in store vs. complex in-store integration) and the hardware that may make the most sense. JKHLE has only small back office servers and as mentioned above, they pursue "non-complex store IT operations". Therefore a lightweight integration stack is an appropriate solution.
The following picture gives an overview of today's retail store environment and the current integration processes of the customer.
JKHLE's retail store IT infrastructure today
JKHLE has a heterogeneous environment at retail stores today. This consists of
- POS and POS Server (IBM SurePOS with a 4690 operating system)
- Back Office Server running other back office applications
- Self Checkout boxes with a custom developed interface to a matching back office application hosted by the Back Office Server
- Scales that get pushed current article data from Back Office Server's file system
- Label Printer that get pushed printing data in same manner as the Scales
The customer has already adopted an integration layer at the head office forseveral years now, called "Backbone Service Bus". This integration layer connects the different applications on the central site and provides an interface to send and receive data to and from customer's retail stores. The data transfer is handled using FTP, sending files to the POS Server (for example, price updates) and also capturing files from this machine (for example, retail transaction data). All other data is being sent by messages to the Back Office Server (encapsulated files within messages). A Custom File Picker (developed by the customer's IT department) stores the payload of the incoming messages in a local file system and triggers a file delivery to Scales and Label Printers at the stores.
There were a lot of problems encountered by the customer with their current solution. In the end, they are requesting a new solution architecture to replace the current batch oriented and unreliable data transfer between head office and retail stores. Some of the issues are:
- No chance to get near-realtime information of the daily retail transactions
- Lost of data. Sometimes the customer experienced that price updates were not available when stores open in the morning
- Security policy mismatch. The data transferred between head office and stores need to be encrypted
- Monitoring is only established at head office. All store related processes don't provide monitoring information