One interesting thing I’ve noticed over the last couple months is a growing sense among enterprises that they’ve taken root in some obsolescent technical paradigms. We’ve used networking and computing in business since the 1950s, and a surprising amount of what we do and how we do it would be familiar to professionals of that period. Why tech has stalled, in at least some sense, and where it should be now are only vaguely understood.
The “business” of tech adoption is surely one issue, both on the vendor and the buyer side. IT gear is a capital asset, meaning that a buyer pays for it but doesn’t write it off immediately. Enterprises say that they write down most tech gear in three years, and almost all of it is written off within five. Until the gear is fully depreciated, a project that displaces it has to pay off the residual value, making it harder to meet ROI targets. Vendors say that they’re rewarded for current-quarter performance, which favors shorter selling cycles, which favors staying with current tech models rather than introducing new ones.
Another issue, I think, is a tendency toward “monolithic thinking”, not to much at the level of software or computing but in terms of how we think about it. You can see this in AI; the buzz has always been about whether “large language models” doing generative AI could replicate human intelligence. From an enterprise perspective, that’s a useless way of thinking, given the resources needed to run that sort of AI. What they need is specialized agents to undertake tasks within a web of human-and-IT cooperatives.
You can see the same thing with the cloud. When it came along, despite the fact that it was clear that cloud computing was not, in terms of units of processing power, cheaper than data center computing, “everything is moving to the cloud” was the presumption. Now we know better (or at least many do).
In networking, we’ve built networks for ages based on the presumption that we had to conserve capacity by aggregating traffic to maximize efficiency. We are now starting to realize that managing aggregation is more expensive than creating the bandwidth needed to make aggregation unnecessary. Yes, there are still values to aggregation, but there are more-than-compensating values in burying networks in bandwidth; one approach doesn’t fit all.
This may help explain why we’ve not had a net IT spending wave. Years ago, I did an analysis of the rate of growth in IT spending versus rate of growth in GDP, and found there were three “waves”, or periods in which IT spending grew 40% faster than GDP. The last of these ended roughly at the end of the last century (in 1999), and we’ve never had a period as long as 25 years between waves before. But past waves were driven by what could reasonably be called “distribution” or “closeness”, meaning they were inherently decentralizing in nature—minicomputers and PCs. If we’re hung up on monolith-think, then perhaps we can’t properly plan for (or even see) the next step.
Which, I think more and more enterprises are realizing, is linking computers to “real work”, meaning work in the real-world sense rather than work in processing information. In the last week, though, we’ve had major movement in real-world applications. NVIDIA’s Cosmos is one, and so is their investment in MetaAI, a startup that uses AI to build digital twins of real-world systems. We also had announcements on organizing human/agent cooperation and agent/agent cooperation. Could it be that vendors are finally moving AI in the right direction?
Enterprises see their business as a set of coordinated activities, each of which are divided into tasks, and each of those assigned to workers. This is all linked by a series of “flows”, one of which is the flow of IT information over network connections that we call “workflow”, but which also includes flows of real products or components, people, and equipment. When IT steps beyond managing records of activity and into the process of actually controlling physical processes, alone or in support of human workers, we tend to site IT applications proximate to those processes, and if we presume that AI is the basis for this process control, then we’d expect to put it where the work is, or nearby. There is no more justification for centralizing all AI in a super-model any more than there is to eliminate PCs, smartphones, and local-edge process control hosts in favor of one giant data center computer.
One CIO characterizes the business as having three layers. At the bottom is the physical layer, where people, facilities, and machinery reside. The next is the control layer, where application elements manage or assist in managing the physical stuff, and the last is the records layer, where the information needed to run the business and coordinate control features resides. This seems to me to be a good way of thinking, but it also exposes a basic truth, which is that we don’t really think in these terms today.
What’s different in this CIO’s approach is that it emphasizes functionality requirements over implementation solutions. You worry about what’s going on in the real world in which your business functions, you create control/agent processes to optimize work in that real world, and you manage the whole process from the top. Where all these pieces go depends on the economics of hosting and the efficiency of managing the various flows this all creates. This is the “operational structure” of a business, which is the structure that the enterprise needs to optimize.
A human worker, a machine, an application, and an AI agent are all a form of processor, doer. You should be able to represent a business without presuming that one specific type of processor goes in one specific place; it’s the process itself, the functionality, that matters. Flows connect functionalities, and they have to be capable of connecting in a way the functions can understand. Flow connections and function requirements determine what you need to actually realize the function and move flows along, and constraints of both determine what’s optimum in terms of implementation and placement.
I submit that this is the way that enterprises really need to think about business processes, automation, AI, the cloud, and networking. It’s not how we think of these things today, and that’s a big factor in limiting our ability to use hosting, AI, and other resources efficiently. There is a growing interest in integrating AI into business processes, though, as this article shows. I also think that the way to describe, to model, this on a company-wide scale is the digital twin, and that the way to create and optimize digital twins is via AI agents. AI can help frame the solution to process modernization, and contribute features to the processes as well.
The technical pieces of all of this are falling (slowly) into place. It’s a bit more difficult to say whether realization and acceptance will keep pace, but there may be good news there too. I’ve gotten three times the number of enterprise comments on digital twins in my most recent blogs as in the early ones, and the number of articles I’ve cited here is only a partial inventory of what’s emerging. I think that many generative AI players, including the big public-model proponents, are now gradually positioning themselves to apply their infrastructure to AI-agent-as-a-Service applications, simply to realize a decent ROI. That, if it’s really happening, is the best news of all.
