 |
| Part 2 - Common architecture 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.
Another challenge has been how to visually represent the architecture. There are many ways to represent each element, but we've chosen some icons, text and colours that we hope are going to make it all easy to absorb.
External systems
The first is third-party systems, covering basically everything that customers use from partnering ventors. This can be SaaS solutions or any other third-party backend systems.
The second is called internal remote systems, a broad element to contain all other types of backend systems that might be internal to the organisation, but deployed externally to to architecture in use.
It's also the one way to ensure you can uniformly leverage the same container infrastructure across a hybrid multicloud environment. It avoids becoming locked into any private or cloud infrastructure as you have an exit strategy with a container platform that's consistent across your architecture.
The storage services uncovered in the research were diverse and numerous. For that reason there is no single common architectural element shown at the highest level. Everything from container native storage to traditional block storage was found.
In later articles, when more detail is shown, we'll make a point to present a few of the options chosen by customers integrating data services with processes and applications.
Next in this series, taking a look at an example planning optimisation architecture to provide you with a map for your own optimisation solutions.
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.
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.
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 architecture 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 architectural 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.
Now let's take a quick tour of the generic architecture and outline the common elements uncovered in our research.
External systems
Starting at the top right of the diagram, which is by no means a geographical necessity, there are two elements that represent external systems that are integrated with the core elements of this architecture.
The first is third-party systems, covering basically everything that customers use from partnering ventors. This can be SaaS solutions or any other third-party backend systems.
The second is called internal remote systems, a broad element to contain all other types of backend systems that might be internal to the organisation, but deployed externally to to architecture in use.
Infrastructure services
These elements in the common architecture are found in every solution researched. They were mentioned by name and consisted of an single-sign-on (SSO) that ensures a smooth interaction between processes, authorisation, authentication, and integration services.
The internal local systems, shown with a private cloud icon, can be any backend systems that are managed and deployed in this organisation's infrastructure.
The internal local systems, shown with a private cloud icon, can be any backend systems that are managed and deployed in this organisation's infrastructure.
Container platform
Without a doubt, every modern organisation engaged in business optimisation has seen the value of containers and use of a container platform. The container platform provides for one consistent environment for developers and operations to manage services, applications, integration points, process integration, planning services, and security.
It's also the one way to ensure you can uniformly leverage the same container infrastructure across a hybrid multicloud environment. It avoids becoming locked into any private or cloud infrastructure as you have an exit strategy with a container platform that's consistent across your architecture.
There are a few elements here worth mentioning, first off the use of retail decision microservices for centralising all store business decisions for other services to leverage. An api management element for well defined access to services and processes, and a retail processes element to capture repeatable and sometimes long running store processes. The key element here in our business optimisation use case is of course the retail planning services, the powerful services used to solve many of the issues covered in this use case. Finally, there are elements representing collections of integration microservices and integration data microservices for storage service access.
The security aspect is interwoven in the container platform, as each container service, application, or process integration can be plugged in to an organisations authentication and authorization mechanisms.
The security aspect is interwoven in the container platform, as each container service, application, or process integration can be plugged in to an organisations authentication and authorization mechanisms.
Storage services
The storage services uncovered in the research were diverse and numerous. For that reason there is no single common architectural element shown at the highest level. Everything from container native storage to traditional block storage was found.
In later articles, when more detail is shown, we'll make a point to present a few of the options chosen by customers integrating data services with processes and applications.
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.
An overview of this series on the business optimisation portfolio architecture can be found here:
Catch up on any articles you missed by following one of the links above.
Catch up on any articles you missed by following one of the links above.
Next in this series, taking a look at an example planning optimisation architecture to provide you with a map for your own optimisation solutions.
(Article co-authored by Iain Boyle, Chief Architect Retail, Red Hat)