DevOps

Point of sale – Common architectural elements

In our previous article from this series we’ve introduced a use case around point of sale imaging 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. 

The only thing left to cover was the order in which you’ll be led through the blueprint details.

This article starts the real journey at the very top, with a generic architecture from which we’ll discuss the common architectural elements one by one.

This will start our journey into the logical elements that make up the point of sale imaging architecture blueprint.

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.

From specific to generic

Before diving in to the common elements, it might be nice to understand that this is not a catch all for every possible supply chain integration solution. It’s a collection of identified elements that we’ve uncovered in multiple customer implementations. These elements presented here are then the  generic common architectural elements that we’ve identified and collected in to the generic architectural blueprint. 

It’s our intent to provide a blueprint for guidance and not deep technical details. You’re smart enough to figure out wiring integration points in your own architectures. You’re capable of slotting in the technologies and components you’ve committed to in the past where applicable.  It’s our job here to describe the architectural blueprint generic components and outline a few specific cases with visual diagrams so that you’re able to make the right decisions from the start of your own projects.

Now let’s take a quick tour of the generic architecture and outline the common elements uncovered in our research.

Point of sale

Starting at the point of sale location you have a block of three elements to consider. The first listed here is the catalog maintained with available items for sale in the running inventory known as the SKU Catalog. This is going to be tied directly into the  Retail Data Framework blueprint which is indirectly managing inventory and stock control through the
Real-time Stock Control blueprint (be sure to check out these article series as they appear).

Another important element on the point of sale end of this logical view is the sales data cache where all sales activities are collected and held here for sharing back to the retail organisation. 

Store server

Inside each store in the retail organisation can be found the store server, a part of the infrastructure that is hosting the elements needed to facilitate on site point of sale image pipelines and the daily management of communication, sales data, and stock control information.

Starting at the top with the element SKU Catalog, not to be confused with the same element found on a point of sale component, is taking input from each of the point of sale stations in a store. This information is communicated back to the main retail organisations stock control mechanisms. 

Next up, an image cache element is hosting the retail organisations centrally developed collection of point of sale images. They are collected here at the individual store server for use in updating and restoring in store point of sale devices. 

The next three elements are all related to sales data. There is an element for sales data collection which is used to cache all the point of sale incoming sale information throughout the days sales activities. The sales data aggregation element is ensuring all data collected can be transported in the correct format. Finally, sales data integration element is tying together the communication points from the on site stores to the retail organisations central data locations. There can be a lot of different types of integration needs making this one of the most flexible elements in the architecture.

The final element, application image cache, represents the collection of other not directly related to point of sale device images. Specific stores might have other application needs or make use of central retail organisation applications related to, for example, store health and safety (see the article series for Store Health and Safety blueprint as it appears).

Infrastructure services

These elements in the common architecture were pretty consistent across all of the point of sale solutions examined. These tended to be core elements setup in the retail organisations central location with the ability to control communication for point of sale images, store applications, and sales data collection.

The image automation element provides the core tooling for automating all aspects of their infrastructure delivery services. Together with their satellite server element, the retail organisation is capable of maintaining integrity of image distribution and application delivery across their store landscape.

Sales data integration element is the retail central organisation side of sales data collection from all the stores providing sales information.

This collection of elements gives some insights into the central retail organisations development origins used to deliver all their point of sale images and in store application needs.

A CI/CD platform is core to development, testing, packaging, and delivering point of sale images and store applications to the image registry. Core to this process is a source code management system (SCM).

Storage services

The storage services uncovered in this solution space was a fairly narrow single  physical block storage element.  There was not a lot of need for diversity in these services as the solution is squarely focused on the infrastructure development and delivery pipeline.

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:

  1. An architectural introduction
  2. Common architectural elements
  3. Example image distribution architecture

Catch up on any articles you missed by following one of the links above.

Next in this series, taking a look at an  example image distribution architecture to provide you with a map for your own point of sale.

(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 – Common architectural elements

Opinions expressed by Java Code Geeks contributors are their own.

Eric Schabell

Eric is Chronosphere's Director Technical Marketing & Evangelism. He's renowned in the development community as a speaker, lecturer, author and baseball expert. His current role allows him to coach the next generation of technical marketers & evangelists helping the world to understand the challenges with cloud native observability. He brings a unique perspective to the stage with a professional life dedicated to sharing his deep expertise of open source technologies and organizations. Follow on https://www.schabell.org.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button