DevOps

Supply chain integration – Common architectural elements

 In my previous article from this series I introduced a use case around supply chain integration for retail stores.

The process was laid out how I’ve approached the use case and how portfolio solutions are the base for researching a generic architectural blueprint. 

Part 2 – Common architectural elements

The only thing left to cover was the order in which you’ll be led through the blueprint 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 will start our journey into the logical elements that make up the supply chain integration architecture blueprint.

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 my 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 I’ve chosen a format that I hope makes it easy to absorb. Feel free to post comments at the bottom of this post, or  contact me directly with your feedback.

Now let’s take a look at the details in this blueprint 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 supply chain integration solution. It’s a collection of identified elements that I’ve uncovered in multiple customer implementations. These elements presented here are then the  generic common architectural elements that I’ve identified and collected in to the generic architectural blueprint. 

It’s my intent to provide a blueprint 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 my job here to describe the architectural blueprint 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.

Another challenge has been how to visually represent the architectural blueprint. There are many ways to represent each element, but I’ve chosen some icons, text and colours that I hope are going to make it all easy to absorb. Feel free to post comments at the bottom of this post, or  contact me directly with your feedback.

Now let’s take a quick tour of the generic architecture and outline the common elements uncovered in my research.

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  supply chain microservices for centralising all interactions with supply chain relevant systems of record and provides access to other services. An  api management element for well defined access to services and events, and both message transformation and
event streaming services to react and transform communication messages across the platform. 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 integration can be plugged in to an organisations authentication and authorization mechanisms.

Infrastructure services

These elements in the common architecture are found in the solutions 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  AI / Machine Learning platform, shown with a private cloud icon, can be any modern data platform  that are managed and deployed in this organisation’s infrastructure to support the retail usage of AI / ML by ensuring access to supply chain data.

External systems

There one more element that represents the external supply chain systems that are integrated with the core elements of this architecture. 

As there are often many  third-party systems, this element covers basically everything that customers use from partnering ventors. This can be SaaS solutions or any other third-party backend systems.

Storage services

The storage services uncovered in the research were pretty simplistic and for that reason there’s a single
physical block storage element.  In later articles, when more detail is shown, I’ll make a point to mention the link to a separate architecture blueprint supporting the retail data framework which is linked to this use case.

What’s next

This was just a short overview of the common generic elements that make up our architecture blueprint for the supply chain integration use case. 

An overview of this series on the supply chain integration portfolio architecture blueprint can be found here:

  1. An architectural introduction
  2. Common architectural elements
  3. Example supply chain integration

Catch up on any articles you missed by following one of the links above.

Next in this series, taking a look at an example supply chain integration architecture to provide you with a map for your own supply chain solutions.

(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: Supply chain integration – Common architectural elements

Opinions expressed by Java Code Geeks contributors are their own.

Eric Schabell

Eric is Chronosphere's Director Technical Marketing & Evangelism. He's renowned in the development community as a speaker, lecturer, author and baseball expert. His current role allows him to coach the next generation of technical marketers & evangelists helping the world to understand the challenges with cloud native observability. He brings a unique perspective to the stage with a professional life dedicated to sharing his deep expertise of open source technologies and organizations. Follow on https://www.schabell.org.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button