Home » DevOps » Store health and safety – Common architectural elements

About Eric Schabell

Eric is Red Hat’s Portfolio Architect Director. He's renowned in the development community as a speaker, lecturer, author, and baseball expert. Follow on https://www.schabell.org.

Store health and safety – Common architectural elements

In our previous article from this series we introduced a use case around headless e-commerce 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.

Part 2 – Common architectural elements

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 store health and safety 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.

Another challenge has been how to visually represent the architectural blueprint. There are many ways to represent each element, but we’ve chosen some icons, text and colours that we hope are going to make it all easy to absorb.

External applications

Starting on the left side of the logical diagram you’ll find the external applications holding two elements. These are the
mobile applications and web applications, used to represent any front end applications used to access the store health and safety infrastructure. 

By including the mobile applications, we’re representing the possibility of supporting any type of device from workstations to portable devices that might be used while roaming a retail store location.

Container platform

The largest collection of elements can be found in the container platform, where processes, services, and rule compliancy tools are provided as independent elements.

To support external interaction throughout the store health and safety platform there are collections of microservices, each focusing on one aspect of the customer interaction.  These are very generic descriptions as each retail organisation can determine what they consider core services. It all starts with authorisation and authentication tools found in API management, ensuring proper safe access to services and tooling.

Another set of services are called the  supplier microservices that focus supplier access to the functionality they need around store health and safety compliancy. 

Next, there are store process microservices and local store rules microservices, both providing local store locations with consistent processes and standardised rule based compliancy frameworks for operating consistently across the retail organisation.

Finally, both  integration microservices and  integration data microservices are elements that consistently provide access to backend organisational systems, data sources, and other aspects of the retail organisation such as the retail data framework. In other articles, we’ll cover that architecture blueprint. You can search for that blueprint on this site for more details.

Infrastructure services

These elements in the common architecture were pretty consistent across all of the store solutions examined. These tended to be core elements setup in the retail organisations central location with the ability to control communication and overall integration for the complete architecture.

The internal local systems element covers all the various systems that might be used for interactions across the retail organisation, and that covers store health and safety too.

It almost goes without saying, that a  single-sign-on (SSO) server is essential for tying in the organisational tooling for authorisation and authentication to make use of components in the architecture.

External systems

There are always going to be external systems of record such as  3rd-party systems, which are anything from SaaS offerings to offsite platforms hosting any number of applications.

The internal remote systems would be applications and systems that are situated physically outside of the store health and safety architecture, but are of significant interest to be captured in this element. They might be back office systems, a customer management system, payment system applications, etc.

Storage services

The storage services uncovered in this solution space was a fairly diverse, from  virtual block storage, physical block storage, and object-based storage used in this solution architecture.  

What’s next

This was just a short overview of the common generic elements that make up our architecture blueprint for the store health and safety use case. 

An overview of this series on store health and safety portfolio architecture blueprint:

  1. An architectural introduction
  2. Common architectural elements
  3. Example health and safety architecture

Catch up on any past articles you missed by following any published links above.

Next in this series, taking a look at the example store health and safety architecture for this blueprint.

(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: Store health and safety – Common architectural elements

Opinions expressed by Java Code Geeks contributors are their own.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....


Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions


Notify of

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

Inline Feedbacks
View all comments