Business optimisation architecture - Example planning optimisation

In our previous article from this series we shared the logical view of the business optimisation use case 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 architecture.

It started with 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 optimisation scenario showing how expanding the previously discussed elements provides an example for your own optimisation 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 my 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.

Now let's take a look at the details in this architecture and outline the solution.

Store optimisation architecture

The example shown in the figure titled Schematic - Business optimisation outlines how optimisation ties into your architecture. In this example, starting from the left we see a business owner and developer providing the input needed for the retail planning services. These inputs are constraints (both hard and soft), resource availability, and business goals to be achieved.

While this might look like something that the business owner and developer are doing into the fully deployed solution, it's really using the previously covered cloud native development showcased in that architecture. For simplicity, we've included the planning and constraint development aspects here to help with an understanding that business owners are involved.

The planning services would then be triggered by external systems that have been given access through the API management element to start, provide input, or retrieve planning optimisation results. It's also possible that the retail planning services are providing input into any number of retail processes. 

The retail processes leverage retail decision microservices that contain the centralised store logic for both process and integration microservices are making extensive use of. Integration microservices are also the integration point to all external communications with external systems and retail systems that might be internal to the store organisation but hosted external to the physical location of the business optimisation architecture.

Data access is shown at the bottom through the Retail Data Framework, another full architecture itself with details to be found how it's organised. This access for the retail planning services is arranged by the integration data microservices allowing for clean separation of integration points between critical demarcation lines of your architecture.

While the business owner and developer are working on the deployment of the needed retail planning services, at runtime the rest of the elements in this diagram are leveraging these optimisation planning services to achieve desired outcomes.

The diagram might give the impression that this is a single store solution, but it can also be seen in the context of a centralised architecture in the retail organisation where the external systems and triggers are those of satellite stores or warehouses. The stores and warehouses are all looking to make use of the planning and optimising services for better store delivery routing, planning more efficient staff rostering, and for improving efficiency of local tasks.

What's next

This was just a short overview of the common generic elements that make up our architecture for the business optimisation use case.