This article is an excerpt from the report: Supply Chain Networks Revealed — Part One: What They Do
A copy of the full report can be downloaded here.
This is the first installment in our series on supply chain networks. Here we look at the evolution of architecture, a definition of what a supply chain network is, and different approaches we’re seeing to solve multi-party challenges.
It’s All About the Architecture!
There is an architecture for each epoch. In the 70s and 80s, there was limited computing power and no internet;1 EDI was used to transmit data point-to-point — one-to-one. Within the enterprise, departmental system modules2 were strung together like a vast spaghetti of custom-code libraries. Things moved pretty slowly. System maintenance was a bear!
Today, we are living in a world of complex relationships with billions of connected nodes: organizations, processes, people, places, and things. This is a world of many-to-many. Our customers and partners require an always-on, instant response, and with that expectation of instant responsiveness, the lines have been blurred between planning and execution. As we share processes, information, and goals with our partners, we need a technology architecture that supports these complexities, this need for speed, and the supply chain’s collaborative requirements. That architecture is a shared operating3 platform to enable supply chain partnerships.
Supply Chain Networks: A Definition
When we say supply-chain network, what are we really talking about? (See definition in the side box.) EDI, visibility platforms, and commerce sites, though they may be used by supply chain operators, are merely features of a supply chain network. They do not constitute a supply chain network in and of themselves, as they provide only one function. The supply chain you manage every day includes a lot more than one capability.
There are significant differences in the market among supply chain networks, which are important to understand if we are to make good choices. In previous reports, we covered the breadth of networks. However, in this report, we focus on networks that support processes — that is, the applications that run our supply chain.
We will explore and explain the different approaches to supply chain networks from a process and technology perspective, providing some examples that help differentiate and clarify how the technology enables specific outcomes. We will then paint a picture of the future, which is rapidly becoming part of our present.4
Solving the Multi-Party Challenge
There are various ways in which solution providers attempt to address the multi-party challenge. We present a quick overview of the basic approaches offered in the supply-chain market today.
Enterprise-centric Applications and Suites
— today, these may be offered in the cloud or on-premise, but fundamentally, these are not networks. They try to solve supply chain visibility problems by layering a control tower on top of an enterprise instance, using B2B messaging to collect supply-chain data. In the enterprise-centric world, though, we are forced to go it alone a lot, connecting and reconnecting to a variety of systems and trading partners with varying protocols. This can lead to a very unsatisfying scenario5 with challenges in synchronizing partner data.
— these are the EDI, AS2, and other vehicles for B2B communication (API, workflows, and web services tools that are internet resident). B2B networks are all about moving data.
— these are application networks that are based on a messaging paradigm. The Integrator Network (IN), as distinguished from a B2B network, is an advanced approach whereby there are shared business applications and in-cloud business data. Examples are eProcurement, Transportation Management, e-commerce, and so on. These web-resident solutions provide a significantly more consistent way for trading partners to work their processes. Each tenant will have its own database6 (in the cloud or on-premise) supported by common master data (MDM) and/or canonical data models.
Real-time SVoT Network
— the real-time application network (RSN) is based on a single database/single processing engine (single version of the truth, SVoT). This is a many-to-many approach in which all tenants share the same data store — ledger-like,7 as well as sharing the same multi-party process execution. Partners can create/share a network-wide workflow, and all the particulars for that transaction are visible (given permission).8 For example, multiple locations of inventory, multi-mode locations of conveyances, changing data, changing conditions, and so on across multiple legs or multiple parties are visible. Figure One shows an overview comparison between these two supply chain application network approaches.
As we continue through the report, we will clarify the terms used in this figure to more deeply define the various attributes. Going forward, this report focuses on the IN and RSN supply chain application networks.
Now we will look at why supply chain application networks are important and examine some simple examples of how they support advanced supply chain objectives.
In Part 1B, we look at how a supply chain network can support end-to-end demand through fulfillment processes.
1 Though the internet started in the 70s, it was used almost exclusively by government and academia until the 90s when businesses and consumers started connecting and using it. Before that, businesses used point-to-point, teletype, and dial-up, which replaced the physical delivery of magnetic tapes, punch cards, paper, or snail mail. — Return to article text above
2 which have grown into ERP and Supply Chain suites — Return to article text above
3 By operating platform, we mean a platform on which to do work at any level in the enterprise. — Return to article text above
4 NOTE TO READERS: In this report, we have attempted to not use deep technology terminology wherever possible, so supply chain professionals with only some technology understanding will be able to read this. — Return to article text above
5 For more on supply chain network evolution and approaches, you can read: Multi-party Solutions for Supply Chain. — Return to article text above
6 Generally, these are called hubs. When supporting entities (partners such as suppliers or transport) connect, they are called spokes. — Return to article text above
7 Not to be confused with Blockchain — Return to article text above
8 When we talk about shared data, visibility, and so on, in all cases, it is based on the granting of permission by the relevant parties. We will discuss the concept of permissions in Part Two. — Return to article text above
To view other articles from this issue of the brief, click here.