In Part 2A of this series, we looked at the origins and architecture of the two major types of supply chain networks (Integrator Networks vs. Real-time SVoT Networks) and the challenges of master data management in those supply chain networks. Here in Part 2B, we drill down into a comparison of those different types of supply chain networks.
Integration or Interoperability
Integration is an elusive concept. One of the obvious challenges in supply chain is that everybody has so many systems to support their unique needs that it can restrict what they are capable of—or willing to do. And that is not likely to change any time soon. 1 Enterprise systems have been developed around a construct of process (codified in the software) — do this, then do that. This rigidly reflects the “one” philosophy of the enterprise. They use APIs, workflows, and translation to bridge between agreed-to processes.
Nonetheless, in a world of infinite connections, we need the ability to connect and understand the other’s data or intent. For some activities, however, we need more. Partners may need to participate in a common process. That requires a lot more than translation. In highly complex processes where all participants need to conform to the agreed-to process, they need to interoperate. Technically, how is this achieved? A technique called process inheritance may be used (see definition in side-box).
Extending the Solutions
We often need to customize some of the services and integrations. We extend applications by integration to external apps and/or configuration, customizations, and development on the network platform.
APIs and Workflow Engines: For most tech companies, application expansion is enabled by providing APIs to allow customers to develop external code that can integrate to the application. These API libraries reduce the work involved (since someone else probably had that need and all sorts of objects have already been developed). Technologists’ goals are to create a low- or no-code environment to ensure standardization and make it easy for customers.
Workflow engines ensure that the human tasks occur in an agreed-to script. This needs to be easily adaptable for users to manage.
All supply-chain application networks will have at least some APIs and workflows, but may differ significantly in the type, breadth, and granularity of objects and functionality exposed.
SDK/aPaaS: Another approach is a software development environment that lets you develop within the platform. This is often called aPaaS (application platform as a service). Here, as well, the low- or no-code goal is sought, but the same development tools the network developers use are provided so that the final product is compliant and can work in the network. There can be multiple layers of capabilities within the SDK (software development kit) which allow for routines, workflows, and data model extensions, again, specifically compliant with the network architecture.
Summarizing the Networks—Capabilities and Examples
For quick reference, we will summarize some examples of supply chain application networks.
Table One offers a comparison of the technology options.
Additionally, buyers should consider the solution domain/focus of the network provider. Table Two highlights key examples of application networks we mentioned in this report. Figure four provides a market overview of various types of network options.
In Part 2C, the final installment of the series, we explore autonomous supply chain networks.
______________________________________________________________________________________________
1 Beyond software, each equipment provider (transport, manufacturing, or warehouse) uses its own standards plus many types of devices—mobile, GPS, sensors, RFID, ELD, and so on. All these need to be integrated together. Equally important is the explosion of new data sources from the web, as well as nonstandard data. — Return to article text above
To view other articles from this issue of the brief, click here.