 |
| Part 3 - Example data architecture |
In our previous article from this series shared a look at the logical common architectural elements found in a retail data framework 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 architecture.
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 architecture.
Having completed our discussions on the logical view of the architecture, 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 an example for your own stock control scenarios.
This article walks you through an example stock control scenario showing how expanding the previously discussed elements provides an example for your own stock control scenarios.
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.
Now let's take a look at the details in this architecture and outline the solution for a retail data framework architecture solution.
Retail data framework
This data framework presents an organisational wide view of how data is being managed and is lined to from many of the other retail architecture we've published. Those use cases are often feeding data into this architecture, and a few are depending on data provided back from this framework. Our first walk though this architecture is showing network connections only and will be followed by a data flow view in the next section.
Starting on the left side, we find all the actors such as shoppers, colleagues, and associates. Another user is the IoT devices that these actors are leveraging on the edge of the network to connect to the data framework. Finally, there are links here to the other actors that represent users of the data framework, such as point of sale analytics, customer analytics, market analysis, and central IT. This last group of actors is very interested in leveraging the data framework to gain insights into their specific retail organisational domains.
In the center of the diagram you find the data integration platform, a collection of services and applications owned and created by the retail organisation development teams. As the actors are interacting with all these services through the various web application. Before connecting with eventual backing services, the API management services ensure that only authorised and authenticated calls can reach those backing services.
With most of the applications needs being that of representing collected data, it's natural to find data visualisation microservices and data caching microservices backing them. Both of these microservice collections make use of the more generic integration data microservices to interact with the available storage services. These storage services can be any of the following depending on the retail organisations choices with regards to storage; data lakes, data warehouse, data hub, and data marts.
A very important aspect to these types of architectures is that of combining both messaging and event processing capabilities in a complimentary fashion. While events might trigger business automation processes and/or the need for compliancy and regulatory rules checks, they might be proceeded by message transformation before they can be consumed by the end service. In the process automation you'll often find the need to use integration microservices for access to the core platform systems and data science platform services.
Going to the bottom core platform you'll find internal tooling that can be from legacy systems or just a compilation of systems and tools used to cover one of the four categories of functionality shown here. First, there is the compliance and regulatory tooling, followed by governance tooling, then auditing tooling, and finally authentication and authorisation systems.
On the far right, the data science platform can contain any of the following systems or featured technologies to help discover the hidden gems in all the available data that the retail organisation has collected. There can be business intelligence tooling, or data visualisation tooling, and of course the core business of the platform has a data science (AI / ML) element.
All of these elements and platforms make up the retail data framework physical architecture. Next we'll take a nuanced look at the data flow in our architecture.
Retail data framework (data)
This look at a retail data framework architecture data flow is not meant to be an all encompassing view of the exact flow. The idea is to give a view that you use to understand how an actor and their data works through the entire retail data framework.
With that in mind, the data flow shown is from the actors on the right and works its way through the data integration platform and uses the storage services, core platform, and data science platform to provide the data views the actors are looking for. Most of the arrows indicate a data flow from the actors to the backend systems, though it's not hard to imagine the response data flows working back to the actors. This is left as an exercise for the reader.
This concludes the look at the most pervasive of the use cases we've discussed on our tours of the retail architecture. The retail data framework is a foundational need that most organisations spend a lot of time and investment to leverage.
What's next
This was just a short overview of the example data architecture that makes up our architecture for the retail data framework use case.
An overview of this series on retail data framework portfolio architecture:
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 for retail data framework in retail.
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 for retail data framework in retail.
(Article co-authored by Iain Boyle, Chief Architect Retail, Red Hat)