 |
| Part 2 - Common elements |
The only thing left to cover was the order in which you'll be led through the 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 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 real-time stock control architecture.
Architecture 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 architecture that was uncovered researching those solutions. It's our intent to provide 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 architecture, 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.
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 architecture, 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.
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 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 architecture.
It's our intent to provide an example 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 architecture 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.
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 interact with various aspects of the real-time stock control features.
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 or for example a suppliers remote location.
Gateways and proxies
As in most organisational architectures, with this architecture we find a universal need for external system and application access. To ensure that proper authentication and authorisation is applied, most organisations are using API management and some form of reverse proxy setup.
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 real-time stock control 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.
The first group is referred to as payments microservices that ensure specific focus on consistent integration with the retail organisations preferred payment infrastructure. As payment systems vary widely around the globe and even regionally, it makes sense to ensure a separation of concerns by adding a manageable integration layer in this collection of microservices.
Another set of similar services are called the promotions microservices that allow the retail organisation to provide consistent integration with price and supplier fluctuations in stock they are maintaining. Imagine processes that monitor or trigger when stock becomes too great in a certain product line, leveraging these microservices to set promotions to deplete the stockpile more rapidly, all in (near) real-time.
Next, there are available to sell microservices providing retail locations and suppliers with consistent integration to stock information, such as depleted stock items, updating stock items, and more. All this can then be accessed by local retail stores for updating their product availability or for picking up newly available products coming into stock.
An interesting element is the retail processes where long running processes can be captured, implemented, and leverage tasks for retail associates at the store level. These processes can be tied to stores as they interact with stock control features and also include triggers to actions taken by external vendors, suppliers, and partners. On top of these features, you have reporting and monitoring tooling to help the retail organisation optimise their real-time stock control and processes as data is gathered on what sells, what does not, and how external relationships are performing.
A core aspect of this architecture is the use of event streaming or Event Driven Architecture (EDA). Any time an organisation talks about (near) real-time activities you are heading in the direction of an architecture that must react to events as they happen instead of queuing them for later processing. Using this element the entire architecture will tie together through the use of events and be driven to react to these events by executing on any of the mentioned microservices or stock control processes.
Infrastructure services
The next block you see is holding elements known for providing infrastructure services to the real-time stock control systems.
These elements in the common architecture were pretty consistent across all of the solutions researched. These tended to be infrastructure elements setup in the retail organisations central location or remote cloud providers with the ability to control communication and overall integration for the complete architecture.
The catalog management system element is used to maintain a listing of all the products in stock. The logistics system, supply chain system, and order management system are all used for interaction and management of external vendors, suppliers, and partners.
Storage services
The storage services uncovered in this solution space was a fairly diverse, from virtual block storage, container-native 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 for the real-time stock control use case.
An overview of this series on real-time stock control portfolio architecture:
Catch up on any past articles you missed by following any published links above.
Next in this series, taking a look at an example stock controle architecture.
Catch up on any past articles you missed by following any published links above.
Next in this series, taking a look at an example stock controle architecture.
(Article co-authored by Iain Boyle, Chief Architect Retail, Red Hat)