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 architectural blueprint.
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 architectural blueprint.
Having completed our discussions on the logical view of the blueprint, 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 a blueprint for your own point of sale image distribution scenarios.
Blueprints review
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 blueprint that was uncovered researching those solutions. It’s our intent to provide a blueprint that provides 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 architectural blueprint, 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 blueprint 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 blueprint, a separate and detailed architecture blueprint 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.
What’s next
This was just a short overview of the common generic elements that make up our architecture blueprint for the point of sale imaging use case.
An overview of this series on the point of sale portfolio architecture blueprint can be found here:
Catch up on any articles you missed by following one of the links above.
This completes the series and we hope you enjoyed this architecture blueprint for point of sale imaging in retail.
(Article co-authored by Iain Boyle, Chief Architect Retail, Red Hat)
Published on Java Code Geeks with permission by Eric Schabell, partner at our JCG program. See the original article here: Point of sale – Example image distribution architecture Opinions expressed by Java Code Geeks contributors are their own. |
