Point of sale - Example image distribution architecture
In our previous article from this series we shared a look at the logical common architectural elements found in point of sale imaging solution for retail...
Join the DZone community and get the full member experience.Join For Free
In our previous article from this series we shared a look at the logical common architectural elements found in point of sale imaging solution for retail stores.
The process was laid out how we've approached the use case and how portfolio solutions are the base for researching a generic architecture.
It started with laying out the process of how we've approached the use case by researching successful customer portfolio solutions as the basis for a generic architecture.
Having completed our discussions on the logical view of the architecture, it's now time to look at a specific example.
This article walks you through an example image distribution scenario showing how expanding the previously discussed elements provides an example for your own point of sale image distribution scenarios.
As mentioned before, the architectural details covered here are base on real solutions using open source technologies. The example scenario presented here is a generic common architecture that was uncovered researching those solutions. It's our intent to provide guidance and not deep technical details.
This section covers the visual representations as presented, but it's expected that they'll be evolving based on future research. There are many ways to represent each element in this architecture, but we've chosen a format that we hope makes it easy to absorb. Feel free to post comments at the bottom of this post, or contact us directly with your feedback.
Now let's take a look at the details in this architecture and outline the solution.
Image distribution architecture
This example architecture is focused on the solution to deliver images of both point of sale devices as well as store applications across a diverse array of store landscapes in a retail organisation. It's tackling the challenges of standardising how to support both legacy infrastructure needs at the point of sale, as well as positioning a retail organisation for the cloud native development future of their business.
When we talk about store applications we are referring to non-device image applications, for example the ones you could image in the stores supporting stock control, store health and safety, or other retail based activities aside from the point of sale devices.
Starting on the right side of this diagram, the developers and operations work together in their development and testing environments to produce working projects for images and applications. These projects are shown in the source code management (SCM) element as the starting point for delivery to the eventual remote store locations.
From there the project code is sent through the CI / CD platform of choice to ensure it passes all in house tests, compliancy norms, and security levels. This produces an image (or application) that is made available to the image registry for further distribution. Note that we are not outlining any form of tagging or versioning of the images and applications, leaving that for you to apply as your organisation normally works.
A central and important element, the image and data store, pulls the image or application from the image registry. This element makes extensive use of automation and playbooks to ensure the correct distribution of the images and applications to the needed remote store locations. This is also the exit point for our images and applications from the central IT infrastructure, with the next stop being individual store infrastructure.
In each store there is an image and data store cache which receives the images and applications to be distributed throughout the store to the target point of sale devices and other devices for running in store applications.
Each device in a store makes use of two elements, the first being the SKU Catalog which contains stock item information on all the items the store sells. The second is the sales data aggregation element where all the sales information is collected before sending back to the central IT infrastructure.
Back in the central IT infrastructure the sales data aggregation incoming data flow is processes by the sales data integration element which provides integration with the Retail Data Framework architecture, a separate and detailed architecture to be covered in another series. Finally, the last central IT element is the SKU Catalog that is used to sync the stock item information between the stores and the back end Retail Data Framework.
The core to point of sales imaging remains a solid fundamental need for infrastructure automation technologies and integration with the supporting Retail Data Framework to ensure the success of this solution.
This was just a short overview of the common generic elements that make up our architecture for the point of sale imaging use case.
An overview of this series on point of sale portfolio architecture:
This completes the series and we hope you enjoyed this architecture for point of sale imaging in retail.
Published at DZone with permission of Eric D. Schabell, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.