In our previous article from this series shared a look at the logical common architectural elements found in a real-time stock control 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 stock control scenario showing how expanding the previously discussed elements provides a blueprint for your own stock control 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 for a real-time stock control architecture solution.
Real-time stock control
The first thing you might notice about this diagram is that there are a lot of external actors involved with any stock control solution. There are customers, associates, vendors, suppliers, and partners all influencing the stock control in some way.
For these external actors to the stock control architecture it’s crucial to provide consistent authentication and authorisation through the use of API management elements that front all interactions with internal systems. On the left side of this diagram you see that this fronts the collection of available to sell microservices for the customers and store associates to access.
Any changes here are events, so these updates where stock is manipulated are processed through the event streams element and may enact further actions in any of the following elements. These events can trigger retail processes (which also can trigger events as they run) and interactions with any of the external systems through integration microservices.
The retail processes element make use of promotions microservices and payments microservices, both elements are related to how stock is being monitored for pricing changes such as when a product is over stocked. To ensure a stock reduction a promotion sale might be triggered. Payments are an integral part of the interactions with customers, vendors, suppliers, and partners that deliver or purchase stock items.
The vendors, suppliers, and partners interactions are event generators and shown to be using integration microservices and integration data microservices as the integration point with the Retail Data Framework blueprint, a separate and detailed architecture blueprint to be covered in another series. These interactions also create changes that propagate to the external systems such as catalog management system, logistics system, supply chain system, and
order management system.
All of these systems are external to the stock control architecture and might be internal systems hosted remotely or completely external systems such as a Software as a Service (SaaS) solution. For this architectural blueprint they have been noted as hosted in a private cloud environment, but that’s not a requirement.
What’s next
This was just a short overview of the common generic elements that make up our architecture blueprint for the real-time stock control use case.
An overview of this series on real-time stock control portfolio architecture blueprint:
Catch up on any past articles you missed by following any published links above.
This completes the series and we hope you enjoyed this architecture blueprint for real-time stock control 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: Real-time stock control – Example stock control architecture Opinions expressed by Java Code Geeks contributors are their own. |
