In our previous article from this series shared a look at the logical common architectural elements found in a store health and safety solution for retail organisations.
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 continued by 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 store health and safety scenario showing how expanding the previously discussed elements provides a blueprint for your own store health and safety 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 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 for two views of the store health and safety architecture solution.
Store health and safety
The first look is of the overal architecture for store health and safety with details filled in that were discussed as logical elements previously. Starting on the right there are two entry points for the array of actors you can expect for this use case. One group is requesting actions of your health and safety architecture; suppliers, customers, colleagues / associates, and a catch-all others group. The second are actors that are completing assigned user tasks from the various store processes or health and safety processes; customers and suppliers.
All these actors are provided applications that access the architecture through API management to ensure proper authentication and authorisation before processing their requests. A closer look at this architecture blueprint reveals that the main focus is centred around process automation and decision management. Both are clear winners for the management of rules, compliancy, and for creating consistency across the organisation with regards to health and safety management.
The first collection of business automation processes is found in the store processes, a collection of processes designed a a more generic level. To provide clarity and simplicity in this architecture blueprint, the supporting second level of process automation capturing health and safety processes.
Within the various processes there is always a need for validation, business rules, and compliancy with regards to health and safety laws that can be vastly different depending on your country or even region of operations. To that end, the local store rules and health and safety rules are collections designed to ensure standardisation and compliancy across the processes you’ve designed for your retail organisation.
Backing the various processes are collections of microservices that support connectivity and interactions with the various internal and external systems. The supplier microservices would be leveraged from processes and process information through to the backend systems as needed leveraging integration microservices specifically to directly connect to specific systems. Integration data microservices are used to ensure that the interactions with the Retail Data Framework remain consistent to ensure other areas of your retail architecture are supported (for example Real-time Stock Control) with up to date data.
Finally, there are three externally located systems; internal remote systems which are managed but the retail organisation, external systems managed by third-party vendors, and internal local systems. All of these constitute the backend systems for the retail organisation.
Next up, a look at the architectural solution with a focus on the data view.
Store health and safety data
Data connectivity through the store health and safety architecture provides a different look at the architecture and gives us insights into how the most valuable asset of a retail organisation is being processed.
It should be seen as the blueprint is intended, as a guide and not a definitive must-do-it-this-way statement on how the data is being routed through as actors on the front end are engaging with the systems, processes, and microservices in this architecture.
Note that many of the data flows only one direction while it’s fairly obvious it’s going to flow both ways. We’ve chosen to note that in the flows that do not disrupt the clarity of the architecture diagram, and chose not to indicate that where the intent is to show processing and flows for clarity from actors to systems on the backend.
It’s left to the reader to explore this data diagrams and feel free to send comments our way.
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:
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 store health and safety 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: Store health and safety – Example health and safety architecture
Opinions expressed by Java Code Geeks contributors are their own.