Sometimes we don’t ask all the questions about an important issue, and so we miss ones that might be critical. IT always evolves, under various pressures. The direction it evolves in often depend on specific “forks in the road of possibilities” as one CIO described it. There’s such a fork coming into view now, as enterprises contend with a legacy path of application integration and an alternate path of process integration.
What’s the difference between a large-scale real-time application and a “digital enterprise” with its entire supply and distribution chain built by integrating its core applications, as a service bus might do? That may be a critical question in the evolution of IT.
Enterprises in every vertical (including telecom) have evolved a set of “core business applications”. These applications support their own supply and distribution chains, and also things like accounting, personnel and payroll, and regulatory requirements. There has been, historically, a trend to integrate these through APIs rather than having data passed between them by workers. In the early 2000s, the advent of “service-oriented architecture” or SOA led to the creation of various message-bus strategies to provide this integration. Think “Enterprise Service Bus” or ESB, or “API broker”.
The value of this sort of application integration is clear to everyone, but to many the limitations were also obvious. Many of the jobs critical to enterprises, and in fact to businesses of any size, are driven by human effort. I worked on systems that, where this happened, the software would crank out a work order to initiate the action, and then expect either some application message response or a human-generated “completed” transaction.
Real-time process automation systems have a similar problem. How do you align a bunch of manufacturing steps, or link them with the movement of parts/materials in and goods out? Manufacturing systems using automated process control did this first with custom applications, then with more generalized things like a numerical control language, and today with “digital twins”. Today, the concept of digital twins, though not even fully realized, has been caught up in the AI wave to become a “world model”, and the question it raises is less how AI might play, but what the fact that process automation evolution and application integration are colliding, and the winning concept could drive massive changes.
Today’s computing, and networking, is based on the integrated-application model. That model does not promote the expansion of real-time world-model thinking beyond process control. Thus, only an application evolution from the process control side would generate “world model” that was in effect a model of all aspects of a company’s business. The optimum approach, from a tech-spending-impact perspective, would be to apply the process automation/integration approach at a company (or even wider) level. The “world model” would model a larger world. The question is how this might come about, and whether those with an interest in raising tech spending in the long term might facilitate it.
We have process automation and process-contained digital twins today. We have service-bus-integrated applications today. Cloud providers, as I’ve noted in the past, have been deploying middleware tools that allow some cloud software to run local to processes (AWS Greengrass, for example). If we assume, as I think we should, that local process automation evolves both functionally and geographically, then the question is how the increased functionality and scope would be accommodated. That depends on the interplay between the two.
Suppose that we had to reflect a decline in parts inventory on the East Coast by ordering from a West Coast supplier. The time to transport the material would likely be measured in days, and so it would be a waste of money to build real-time coordination between the two sites; just generate an order from east to west. That is an application integration problem, not a real-time process problem.
A reduction in the geographic scope of this example would gradually reduce the transit time for fulfillment, and as that happened, the value of tighter coupling of the process automation tasks at each end of the chain would increase. Similarly, if the needed parts were not inventoried, but made to order, then there would be a value in expediting the linkage. At some point, having Process East signal Process West would be valuable enough to visualize the combination as a twin-of-two-twins, with automated process correlation.
What we can say, in general, is that real-time integration of two processes has to be justified by a value of real-time co-management. For processes, like transportation and utilities, that are already inherently distributed, finding that value is likely easier. If we looked at traffic management as an example in an age of autonomous vehicles, we can see that it would be very helpful to be able to look at all the vehicles in terms of their position, destination, and route, and adjust as needed to optimize traffic flow and minimize congestion. However, it’s obvious that this specific application would require a truly massive investment just to initiate (sensors for traffic, autonomous vehicles, then all the IT elements). I think this is something that would come along only at the end of a digital-twin evolution. Something has to get the earlier phases of that evolution started, and keep it moving.
I’d love to point out one or two compelling applications that could do that, but if such applications existed, even our hype-driven, short-term-obsessed-with-our-feet-not-the-future market would likely have discovered them. One example of a possibility would be specific product tracking. Suppose that a specific lot of a given part was found to have a manufacturing defect. Would it be best to pull the lot from every stage, to pull products it had been used in wherever they were found, or simply accept the cost of return/replacement in case of a failure? In most cases today, there would be no reliable way of doing anything other than inspecting for the problem in the final product, or letting users return failed products. With real-time tracking you could establish where each potential problem part was, what it was in if it was already through some assembly stage, whether other lots without problems were available nearby, and so forth.
One thing that I think this potential use case demonstrates is that the value of real-time process integration can likely be fully realized only by accepting greater complexity. I think that AI is almost a given in higher-level world models for that reason. Thus, I think this path of creating large-scale “hierarchical” world models is a major AI application.
If we accept this even as a potential future path, then we need to look at the evolution of current real-time applications of process control with the idea of asking whether the next evolutionary step could, at acceptable cost and delay, be made to prepare for this more radical outcome. We’re not doing that today, and enterprises say that they’d need their vendors to be willing to help with the assessment. Will they, or will they continue to be focused on the current quarter’s sales? That focus, I think, is why we’re not launching new tech applications, and why many promising technologies may not survive the hype phase of interest. We could do better.
