Month: November 2020

What do users and providers think about SASE?  Besides, perhaps, that they hate acronyms and the constant creation of “new categories” for the famous quadrant charts?  I usually try to get a feeling for this sort of question at the end of the year, because even where there’s no formal tech planning cycle at year’s end, there’s still a lot of anticipation.  The new budgets, after all, are coming.

Secure Access Service Edge is definitely draped with a healthy dose of hype.  Every vendor knows that it’s very difficult to sell anything into enterprise or service provider organizations without some editorial visibility to generate some sales interest.  Editorial mentions sell website visits, website visits sell sales calls, and sales calls sell products and services.  This direct (and cynical) connection makes it all too easy to miss some really important things that are starting to happen.  New terms, even without new concepts to back them up, generate media attention.  In the case of SASE, though, there’s a lot of reality that’s in danger of being buried in the hype.

What, first of all, is a “service edge?”  In traditional networking it used to be called the “dmarc”, short for “point of demarcation”, or the boundary between the operator service and business network infrastructure.  If you sell a service that doesn’t connect right to the user (which few business services do) then you have a problem of responsibility that can be solved only if you can point to a spot and say “my stuff starts here, and beyond that is your stuff”.

There’s still a lot of dmarc in SASE, but the SASE concept reflects the realization that connecting to the user is the real goal, whoever is responsible for it.  There’s a risk that by saying that carrier responsibility stops at a given point, an unwary buyer might think all responsibility stops there, and on-site or in-company networking is the wild west.  That’s particularly bad in a security sense, because nearly every business network today is connected to the Internet, and even non-Internet elements can be hacked.

SASE is a new kind of dmarc, a service portal that includes both traditional connection features and features that are required to make connected users and resources safe, prioritize traffic, optimize resources, and so forth.  The technical core of SASE is often SD-WAN, but it also includes web gateway security, cloud access security, firewall services, and other stuff.  It’s really this loose mixture that creates a lot of the hype and confusion on the topic.  We need to look at buyer views to get the truth.

One obvious truth is that SASE, which of course means Secure Access Service Edge, is largely about security as far as everyone is concerned.  Interestingly, though, there really isn’t a specific buyer view on how that comes about, on what makes SASE different from other kinds of service edges in technology terms.  They realize that edge security is important, but they’re hazy on how they’d get it.  Part of that may come back to the fact that SASE is functionally a bit of a hodgepodge of “product categories”, and part to the fact that the buyer has a goal but is still searching for how to fulfill it.

Beyond the obvious security point, what buyers say about SASE is that it’s comprehensive, it’s virtual, and it’s part of a harmonious vision of future services that we could call network-as-a-service or NaaS.  To understand what they mean, and what this means to the network space, we have to look at each of those terms.

“Comprehensive” is simple.  Enterprises want a secure access service edge strategy that works for all their edges, which means that it can’t be something that doesn’t handle branches, home workers, cloud hosting, data centers, or anything else that’s either a provider or consumer of services.  It’s this attribute that’s most often assigned to SD-WAN technology, but most SD-WANs aren’t secure.  In fact, security is the main thing buyers think separates SASE from SD-WAN.

The second piece, “virtual” is a bit harder to explain.  Buyers generally saw SASE more as an architecture or model that described a collection or distributed set of features, than as a single box that did everything.  They didn’t object to boxes where they needed a device, but they can’t put boxes inside the cloud and some aspects of SASE evolution seem to them to point to a more distributed model, which gets us to our next (and last) buyer point.

The third piece, a NaaS vision of the future of SASE, is more my characterization than a clear buyer-stated requirement, even though about a third of buyers will use the term at some point.  Most buyers will creep up on the NaaS notion in discussion, but not name it.  What they visualize is kind of what you could call a “cloud model”, where distributed pieces of stuff (the “virtual” part) are assembled by uniting the services these pieces create.  There’s a bit more, though.  That same third of buyers who think about NaaS are also seeing the role of SASE expand beyond security, and that may answer a lot of questions about what vendors seem to be thinking.

The clear goal, name notwithstanding, is to refine the notion of “services” by personalizing it to user and application needs.  Network as a service implies a level of customization, a means of setting enterprise priorities on user/application relationships and ensuring that the higher priorities get higher resource priorities.  In fact, prioritization or even explicit QoS is seen as part of SASE’s mission by almost all the users who recognize NaaS.  The “secure” piece is just a part of the issue of controlling information flows to ensure they meet business goals.

User-specific performance, whether it’s in priority form or in absolute QoS form, requires a way of identifying the user and what they’re doing.  In fact, what would be ideal is a framework where users and applications could both be grouped into categories that would allow for mass assignment of priority handling.  Location, home-versus-branch, role, and other factors are examples of user categories.  Many systems, including Microsoft’s Active Directory, provide a way of classifying users, but that doesn’t mean you’d be able to recognize their traffic.  It seems as though SASE evolution is going to have to lead to a place where user identification is supported at the traffic level.

That then raises a security question.  Do you base the “SA” in “SASE” on the current mechanism of intercept/blocking via firewall?  Permissive connection meets insurmountable object?  Or do you employ a zero-trust mechanism where only authorized connections are carried?  If you’re going to do explicit zero-trust security, it would make sense to have as much knowledge of both user and application as possible, so that you could infer default connection and priority settings based on what’s known about both users and the applications or sites they’re trying to access.

That raises the always-fun topic of support.  It’s always been true that to a user, “the network” was whatever wasn’t on their desk (or in their hand).  You could describe this view as a local-/distant-resource separation.  In our modern world, more and more of the experiences we’re seeking, the applications we’re running, involve distant resources.  This creates a growing problem with quality of experience management for the IT professionals who are generating what people are looking at.

A secure edge that can’t deliver applications with the appropriate levels of QoE isn’t an advance, according to a growing number of users.  In fact, over half of all buyers are concerned about the QoE impact of enhancing security.  They know they need security, but they need what they’re doing, running, viewing, to be supported, too.  If you take the security and priority/QoS stuff down to user/application granularity, the challenge of support explodes.

If users see IT as local/distant, then most of what they consider IT is out of sight, how does this impact vendors?  There seems to be a polarizing among network vendors, with most staying in their traditional lane and focusing on the transformation of the network as a connectivity framework.  The main outlier is Cisco, who may believe that by strengthening its position in cloud computing platforms, it can leverage the coming symbiotic relationship between network and cloud.

Juniper may be emerging as the most interesting player in this new game.  With their Netrounds and Mist acquisitions, they created an assurance-centric, operations-based, platform that combined with a Juniper edge to create the first “virtual SASE” model.  While the details of their handling of 128 Technology post-acquisition aren’t yet clear (because it isn’t closed yet), 128T has all the features needed to create a super-SASE solution when combined with Juniper’s other assets.  Could Juniper be thinking of a model of networking where the services themselves, and the experiences and applications the services connect with users, become the center of the network universe?  I think that may very well be what they have in mind, in which case they could become a true force in network evolution…if they get it right.

SASE is proof that the concept of dissecting unified missions into discontinuous product sets is good for analyst firms and vendors but bad for users.  The same forces that have acted to create SASE continue to operate, to add to the mission.  Might we end up with “Secure, Assured, Self-Managed, Access Service Edge”?  SASASE is a kind of catchy, musical, acronym, but I think we’re heading for “NaaS Service Edge” instead.

That might create an interesting market dynamic, because there are multiple paths to get to a NaaS.  An edge solution is logical because the edge can assemble functional pieces at the user connection point, but a deeper strategy could provide more efficiency, and introduce “cloud elements” of functionality more easily.  Whatever the pathway, it may be that the NaaS model is the real goal in the end, even for SASE.

Operators usually do a tech planning cycle that runs from about mid-September to mid-November.  The ones I’ve been tracking (about 50) are now done with their cycles, so this is a perfect time to look at what operators think they need to be doing, and facing, in 2021.

Tech planning and budget planning, I must note, are related but not the same.  Most operators will plan out any major technology initiatives or potential new directions, and then work their business cases in the budget cycle.  The tech cycle is designed to ensure that they understand how to acquire and deploy something new, and what they could expect to get from it in broad terms, before they spend a lot of time running numbers on the candidates.  Nearly all major network technology shifts in the past have started with a tech planning item.

One thing I find highly interesting (and unusual) in this year’s planning cycle is that two tech initiatives came up as not only tied for the top, but co-dependent.  The issues were 5G deployment and open-model networking.

Obviously, all operators are at least committed to 5G and 37 of the ones on my list were actively deploying 5G.  The reason this is important is that when you’re looking at operator technology initiatives, it’s not the brilliance of the technology that matters, but how well the technology is funded.  Nobody questions 5G funding credibility for 2021, period.  That makes 5G almost unique, and that makes things that are tied to 5G automatic concept winners.

The reason for the linkage between 5G and open-model networking is a winner for two reasons beyond simple association.  First, operators recognize that there is little or no near-term incremental revenue credibility to 5G deployment.  Of the operators I’ve chatted with, only 12 suggested that they believed they could see “new revenue” from 5G in 2021, and only 26 thought they’d see it in 2022.  Frankly, I think both these numbers are about double what’s really likely to happen.  Second, operators know that because 5G will happen, whatever 5G is built on will tend to get nailed to the financial ground with a stake about five to seven years long.  It’s easy to extend current technology directions, but much harder to change them.

One thing that this last point has done is to commit operators to standard first, open second in terms of planning.  They want to make sure that everything they deploy conforms to the structural model of the 3GPP 5G RAN and Core specs, and then then want to maximize the number of open components within those models.  This vision eliminates (or at least reduces) the risk that the operator might have to forklift an entire early deployment to adopt an open-model approach, if such an approach were to be unavailable or impractical at the time of the first deployment.  You can introduce new open-model solutions to 5G elements on a per-element basis because the standard guarantees the interfaces needed to connect them.

But is open-model 5G a stepping-stone toward open-model networking overall?  That’s a complicated question that only about half of operators seem to have considered, or considered in any organized way.  Clearly the functional elements of 5G, the 3GPP building-blocks, are specialized and so not likely to be reused in non-5G applications.  What operators think should or will be reused are the tools associated with the deployment, operationalization, and modernization of open-model 5G.  The principles, then, of something like Open RAN or Cloud RAN or whatever, should be principles that could be extended to the network at large, to all its services and missions, in the future.

This point seems to be a goal flying in the face of details, or vice versa.  A bit less than half the operators had really looked at the question of the technology needed for open-model networks, both 5G and in the broader context.  The others were saying things like “both will be supported by virtual functions” or “we expect to increase our use of white boxes”, without the kind of details that prove careful consideration has been involved.

Among those that have actually thought things out, there’s a debate that’s not fully resolved, and a few who don’t think any resolution is possible.  They’re aware that there are NFV-style VNFs in play, and actually called out in the 3GPP 5G stuff.  They also know that there’s something called a “containerized network function” and something called a “cloud-native network function”, and it’s their view that neither of these things are defined with any rigor.  They also know that it’s almost certain that no hosted network function of any sort is going to replace high-capacity data-path devices like switches and routers.  Any open-model approach there will necessarily be based on white boxes.

To me, the white-box piece of this story is the most critical.  Networks carry packets, which means that virtually all network elements have a data-plane component.  It’s credible to think that a hosted function of some sort could provide individual user data planes (it’s not, to these key operators, credible that this would be a net savings for both capex and opex).  It is not credible, according to the operators, to believe hosted routers will replace all proprietary routers, where it is entirely credible that white-box routers could.  Thus, the open-model network of the future is going to have a large number of white boxes, and it’s likely that the biggest piece of that network—the aggregation and core IP stuff of today—will be white-box-based if it’s open.

For this group, the question is whether the source of the white-box router and the proprietary router are the only difference between the two.  Open, disaggregated, software running on a variety of white boxes that are 1:1 substituted for proprietary devices is one choice.  Router complexes (such as those of DriveNets, who won AT&T’s core) are another choice.  SDN flow switches and a controller layer are a third.

One operator planner put it very well; “The question here is whether an open network is open at the device level, [meaning] based on open implementations of traditional elements, or open at the functional level, meaning based on open implementations of service features, in non-traditional ways.”  Both paths lead to some white-box elements, but one path means a lot more of them.

Another issue that this “literati” group is beginning to deal with is the notion of the control plane as the feature layer of the future network, whatever the implementation model.  IP has a control plane, one that SDN centralizes.  5G (and 4G) separated the “mobile control plane” and the “user plane”, which means defining a second control plane.  Services like video delivery have a series of CDN-related features that could be collectively defined as a control plane, and cloud computing creates something like a control plane for orchestration, service mesh, and other stuff.  Are all these control planes going to get more tightly coupled, even as the data plane becomes more uncoupled?

This may be a question that’s tied into the other priority consideration from this tech cycle; “carrier cloud”.  Operators used to see carrier cloud as being their implementation of public cloud, justified by selling cloud computing services to enterprises.  They thought that hosting NFV or 5G on it was just a mission for an infrastructure they saw as inevitable and already justified.  Now, obviously, there is no realistic chance for operators to compete with public cloud providers.  There may not be a realistic mission to host NFV or 5G in the cloud at all; white boxes might be the answer.  Should operators even be thinking about carrier cloud as their own resource pool, or is “carrier cloud” the set of things they outsource to the public cloud providers they used to be thinking of competing with?

Almost all operators I’ve chatted with believe they cannot deploy “carrier cloud” to address any near-term service or technology mission.  That would generate an unacceptable first cost to achieve coverage of the service area and reasonable economy of scale.  They think they have to start in the public cloud, which of course makes public cloud providers happy.  But the big question the literati are asking is what is it that we host there?

Cloud providers want to provide a 5G solution more than a 5G platform in the cloud.  Microsoft is a good example; they’ve acquired both Affirmed and Metaswitch to be able to sell 5G control-plane services, not just a place to put them.  The smaller operators are increasingly OK with that approach, but the larger operators are looking harder at the risk of a major lock-in problem.  Better, they think, to create a 5G platform and 5G hosted feature set, and then have the public cloud providers host it with minimal specialization of the implementation to any given cloud.  That way, the operators can use multiple providers, switch providers, or pull everything or part of everything off the public cloud and pull it back to self-hosting in the original carrier cloud sense.  There will be an exploration of the business case for these competing approaches in 2021.

There’s also going to be an exploration of just what we’re heading for with all these control planes.  While it’s true that the OSI concept of protocol layering means that every layer’s service is seen as the “user plane” or “data plane” to the layer above, modern trends (including 4G and 5G) illustrate that in many cases, higher-layer control functions are actually influencing lower-level behavior.  Mobility is the perfect example.  If that’s the case, should we be thinking of a “control plane” as a collection of service coordinating features that collectively influence forwarding?  Would it look something like “edge computing”, where some control-plane features would be hosted proximate to the data plane interfaces and others deeper?  The future of services might depend on how this issue is resolved.

The unified control plane may be the critical element in a strategy that unifies white boxes and hosted features and functions.  If there’s a kind of floating function repository that migrates around through hosting options ranging from on-device to in-cloud, then you really have defined a cloud with a broader scope, one that is less likely to be outsourced to cloud providers and one that opens the door to new revenues via the network-as-a-service story I’ve blogged about.  About a quarter of operators are now at least aware of the NaaS potential, but nobody had it on their agenda for this year’s cycle.

The final issue that’s come along is service lifecycle automation.  This has the distinction of being the longest-running topic of technology cycles for the decade, illustrating its importance to operators and their perception that not much progress is being made.  Operators say that a big part of this problem is the multiplicity of operations groups within their organization, something that carrier cloud could actually increase.

Today, operators have OSS/BSS under the CIO, and NMS under the COO.  In theory, systems of either type could be adapted to support operations overall, but while both the TMF and some vendors on the NMS side have encouraged a unified view in some way, nobody has followed through.  The thought that NFV, which created the “cloud operations” requirement, could end up subducting both came up early on, but that never happened either.  The missteps along the way to nowhere account for most of the lost time on the topic.

Today, open source is ironically a bigger problem.  AT&T’s surrendering of its own operations initiative to the Linux Foundation (where it became ONAP) made things worse, because ONAP doesn’t have any of the required accommodations to event-driven full-scope lifecycle automation.  There are very few operators who’ll admit that (four out of my group), and even those operators don’t know what to do to fix the problem.  Thus, we can expect to see this issue on the tech planning calendar in 2021 unless a vendor steps in and does the right thing.

What is going to happen with information technology?  There are a lot of people who wonder about that, who have a significant stake in the answer to that question.  There are a lot of answers, too, most of which are simply guesses.  Well, there’s no way to make a forecast without an element of judgment, but as I said in a prior blog, it is possible to get solid government statistics on a lot of things, including IT.  If you use those statistics you can get a picture of the past and present evolutionary trends, and it’s those trends that create the future.

I’ve been working with US market data from government sources for decades, and recently I’ve been pulling together information on the broad set of changes we’ve seen in those decades, with the goal of determining just where overall IT spending and technology change might be heading.  The credibility of this stuff has to be established with past history, so I’ve started back in the early days of IT and taken things forward to today.  From today, I’ve tried to model objectively the decisive shifts that past history has offered, and from those to paint a picture of the future.

All of the charts in this blog are based on source data on private fixed asset investment by type, selecting the categories for computers and peripherals, network/communications equipment, and software.  Charts showing spending are representing billions of US dollars.  Those showing rate of change of spending show the ratio of increase or decrease, so a value of 0.1 means a ten percent increase over the prior year.

The chart above, which I’ve included in past blogs, shows the broad trends in IT spending in business IT since the dawn of commercial computing.  The three cyclical trends in the chart represent periods when a new computing paradigm enhanced business productivity significantly enough to justify boosting spending to accelerate the paradigm’s adoption.  This chart, showing the rate of change of IT spending, makes the cyclical trends clearer, and it’s these three cyclical shifts that have combined to drive our current levels of spending.  The primary technology changes representing each cycle are noted, and I’ll repeat them in other charts below for reference.

The problem we face in IT is also illustrated in the chart.  Since the last cycle crashed with the dot-com crash at the end of the 1990s, we’ve not had another productivity cycle.  Why that would be true isn’t obvious from the cyclical chart, so we have to look deeper.

The chart above is a busy one, but important.  It shows the rate of change in investment in hardware (computers and peripherals), network equipment, and software spending for the critical period from 1961 when large-scale commercial computing.  If you squint and look at the chart, you’ll notice that for the majority of the period, hardware and network investment growth tend to lead software investment growth.  That reflects a period when hard resources were the limiting factor in IT empowerment.  Starting after the 1999-2000 dot-com crash, though, we see a shift, one where software spending growth leads growth in both hardware and network spending.

Let’s noodle the meaning of the timing shift the chart illustrates.  In the period starting around 1977 we saw minicomputer technology explode, increasing hardware investment and lowering the unit computing cost to the point where true online transaction processing was cost-efficient as well as productivity-enhancing.  Software spending increased shortly thereafter as applications to exploit the new paradigm developed.  In 1994, we saw a boost in hardware spending launched by the personal computer’s adoption.  Software applications for the PC exploded in 1997 and beyond, and online Internet applications did the same in 1999-2000, increasing network equipment spending growth.

The dot-com crash caused all IT spending to drop, but it also represented a major shift in thinking to that software-defined era we’re now in.  At around 2000, advances in chip technology meant that we had the technology to create more computing power than we had productivity benefits to consume it.  There was a sudden stabilization in hardware spending growth, with little change in spending year over year.  This coincides with my own survey work’s identification of a sudden change in the source of IT budgets.  Prior to 2000, IT budgets tended to come from a mixture of modernization and project sources, with the latter opening new productivity-linked applications.  Beyond 2000, there was never again a significant contribution of new productivity-linked applications.

There was still software advance, as the chart shows, but this advance related to the fundamental platform shifts we saw—first virtualization and then cloud computing.  Software was building a new framework for hardware to run within.  That framework had the initial effect of dampening hardware spending because the new compute paradigm was more resource-efficient.  At the very end of the period, 2016-2018, we saw a big jump in hardware spending growth rates, coinciding with the massive build-out of hyperscaler public cloud technology.  The dip in 2019 isn’t a dip in spending, but in spending growth; public cloud built out its initial deployment and was now in a process of orderly growth.

The network spending curve also contributes insights here.  The shift to IP infrastructure during the 1970s coincided with the rise of OLTP, and the growth period in the 1990s to the shift to IP infrastructure from TDM and POTS.  Thereafter, network investment has been roughly aligned with computer and peripheral investment, which suggests that hardware and network are now slaved to software innovation.  Absent a new productivity paradigm, the result has been a focus on using software to reduce hardware and network investment.  We’ve seen the result of that for years now.

Software is what’s going to change, and the chart above illustrates that software is on approximately a shorter four-to-five-year modernization cycle.  That means that the next opportunity for a productivity cycle is likely to come at the point where the next software cycle could begin, which would be approximately 2022-2023.

The chart above shows my modeling forecast for the rate of change in IT investment by businesses, in each of the three categories, for the period beyond 2019 up to the limit of current data reliability.  The projection shows a significant uptick in software spending, the peak of which is in 2023, and it shows network and IT spending rising in synchrony.  This is because a real productivity-driven cycle requires collateral investment in all the elements to deliver empowerment to workers.

In fact, the model shows both IT and network spending increasing faster at the end of my forecast period, showing that the impact of the upcoming cycle is still advancing.  If the cycle starts in 2023, then it would be 2027 before it peaks.  By 2030 we’d have wound down the cycle, meaning that IT spending would then resume its normal modernization-and-replacement rate.

The question of what might drive the cycle, and even the question of whether anything will drive it, is something that statistics and projections can’t answer.  The best that I can do is say when the ingredients are right, but if you look at the earlier figures, you see that we’ve had software peaks in 2007, 2012, and 2018, and none of them kicked off a productivity cycle.  There is no objective reason for that, nor for an assumption that 2023 will be one, so we need to look at what’s behind the curves.

The past cycles were launched because of pent-up productivity benefits awaiting resources for realization.  We were applying IT to traditional business problems in evolutionary ways, so a cycle was in a sense a resource-driven paradigm.  Minis, then PCs, reduced unit cost of empowerment.  The problem now isn’t resources, it’s that we’re awaiting a model, an architecture, that links resources to productivity in a new way.  A new paradigm, in short.  My presumption (or prediction, or guess, or whatever term you’re comfortable with) is that the new paradigm is a continuation of the past trend toward successive cycles that bring computing closer to the worker.  As I’ve said in the past, this would make the next step one of point-of-activity empowerment.

Behind this new paradigm is a lot of technology.  What you’re trying to do is to construct a virtual world in parallel with the real one the worker, buyer, or seller inhabits.  This virtual world can be understood by and manipulated through technology, and it’s anchored to the real world through…you guessed it…the Internet of Things.  IoT provides us with the ability to sense the real from the virtual, to locate us and everyone we’re interacting with in both worlds, and to relate positions and relative movements to goals and tactics.  Augmented reality provides a window that lets us see the real world through or with the virtual-world overlay.

There are obviously a lot of moving parts to this, but the software needed could be generated easily with today’s tools, particularly cloud and possibly edge computing.  The challenge for today is the IoT framework.  We need sensors, we need the ability to analyze video to recognize things, and we need a business model that deploys the stuff.

The final chart above shows US market IT spending ($billions, US) in the US by major category, rather than rate of change.  It shows (if you look carefully) that we’ve already started to see a climb in computer/peripheral spending from the low in 2016, owing to cloud computing.  Network spending is also increasing, though more slowly.  My model says that both network and computer spending will accelerate starting in 2023 if the new paradigm arrives.

It’s less likely to arrive, though, if we keep groping pieces of it rather than addressing the whole picture.  The new paradigm could validate 5G investment.  It could create massive IoT spending, edge computing could become real, and AI and ML could explode.  Our mistake is postulating the gains of these technologies in the absence of a driver.  The value of computing is created by the combination of hardware, network, and software.  We have to get the technologies in all these areas singing the same tune, or we’re going to see stagnation.  Who will step forward to make this happen?  There is no question that someone will, but the “when” and “who” are still up in the air.

One of the factors that limits software portability is custom hardware.  While most servers are based on standard CPU chips, the move toward GPU and FPGA acceleration in servers, and toward custom silicon in various forms for white-box switching, means that custom chip diversity is already limiting hardware portability.  The solution, at least in some eyes, is an intermediary API that standardizes the interface between software and specialized silicon.  There are two popular examples today, the P4 flow programming standard and Intel’s new oneAPI.

The problem of hardware specialization has been around a long time, and in fact if you’re a PC user, you can bet that you are already benefitting from the notion of a standard, intermediary, API.  Graphics chips used in display adapters have very different technologies, and if these differences percolated up to the level of gaming and video playback, you could almost bet that there’d be a lot less variety in any application space that involved video.

In the PC world, we call this intermediation process after the name we’ve given to the piece of technology that creates it, “drivers”.  There are PC drivers for just about every possible kind of device, from disk storage to multimedia and audio.  These have a common general approach to the problem of “intermediarization”, which is to adapt a hardware interface to a “standard” API that software can then reference.  That’s the same approach that both P4 and oneAPI take.

The upside of this is obvious; without intermediary adaptation, software would have to be released in a bewildering number of versions to accommodate differences in configuration, which would likely end software portability as we know it.  Intermediary adaptation also encourages open-model networking by making lock-in more difficult and making an open-source version of something as readily usable as a proprietary product with a zillion marketing dollars behind it.

There’s a downside, too; several in fact.  One is efficiency.  Trying to stuff many different approaches into a single API is a bit like trying to define a single edge device that supports everything, the often-derided “god-box” of the past.  Jack of all trades, master of none, says the old saw, and it’s true often enough to be an issue.  Another is innovation; it’s easy for an intermediary API framework to define a limited vision of functionality that can’t then be expanded without losing the compatibility that the API was intended to create.  A third is competing standards, where multiple vendors with different views of how the intermediation should evolve will present different “standards”, diluting early efforts to promote portability.  We still have multiple graphic chip standards, like OpenGL and DirectX.

P4, the first of the two intermediation specifications I’ll look at here, is a poster child for a lot of the positives and negatives.  P4 is a flow-programming language, meaning that not only does it define an intermediating layer between chips and software, but a language to express chip-level commands in.  Since both “routing” (Level 3) and “switching” (Level 2) packet handling are protocol-specific forwarding techniques, P4 can make it possible to define forwarding rules in a way that can be adapted to all forwarding, and (potentially) to all chips, or even no chips at all.

The name is alliterative; it stands for “Programming Protocol-Independent Packet Processors”, the title of a paper that first described the concept in 2015.  The first commercial P4 was arguably from Barefoot Networks, since acquired by Intel, and Intel is arguably the major commercial force behind P4 today.  However, it’s an open specification that any chip vendor could adopt and any developer could work with.

A P4 driver converts the P4 language to chip-specific commands, in pretty much the same way that something like OpenGL converts graphics commands.  For those who are in the software space, you can recognize the similarity between P4 and something like Java or (way back) Pascal.  In effect, P4 creates a “flow virtual machine” and the language to program it.

The ONF has embraced P4 as part of its Stratum model of open and SDN networking.  Many vendors have also embraced P4, but the arguable market leader in the flow-chip space, Broadcom, started its own P4-like concept with its Network Programming Language, or NPL.  There’s an open consortium behind NPL just as there is with P4.

P4 and NPL aren’t compatible, but that may not be the big question in the flow-switch space.  A flow switch is part of a network, meaning that there’s a network architecture that aligns flow-switch behavior collectively to suit a service.  A good example is SDN versus adaptive IP routing.  You could build a P4 or NPL application for either of these, and the result would be portable across switches with the appropriate language support.  However, an SDN flow switch isn’t workable in an adaptive IP network; the behaviors at the network level don’t align.  It’s like metric versus English wrenches and nuts.

Intel’s oneAPI, like P4, emerges as a response to the need to support innovation in optimum hardware design while preserving software compatibility.  The specific problem here is the specialized processors like GPUs that have growing application in areas like AI and computation-intensive image processing and other missions.  As already noted, different graphics chips have different interfaces, which means that software designed for one won’t work on another.

This problem is particularly acute in cloud computing, because a resource pool that consists in part of specialized processors is likely to evolve rather than being fork-lifted in.  There may be multiple processors involved, some that have emerged as more powerful successors and others that have been empowered by some new specialized mission.  The result is a mixture of processors, which means that the resource pool is fragmented and getting applications to the hosts that have the right chip combination is more difficult.

The oneAPI framework supports GPUs, CPUs, FPGAs, and in theory, any accelerator/processor technology.  Intel calls this their XPU vision, and it includes both a library/API set designed to allow XPU programming in any language, and a new language for parallel processing, Data Parallel C++ or DPC++.  Like P4, oneAPI is expected to gain support from a variety of XPU vendors, but just as Broadcom decided to ride its own horse in the P4 space, AMD, NVIDIA, and others may do the same with oneAPI.  Intel has some university support for creating the abstraction layer needed for other XPUs, though, and it seems likely that there will be ports of oneAPI for the other vendors’ chips.  It’s not yet clear whether any of these other vendors will try to promote their own approach, though.

The presumption of the oneAPI model is that there is a “host” general-purpose computer chip and a series of parallel XPUs that work to augment the host’s capabilities.  The term used for these related chips in oneAPI documentation is devices.  An XPU server thus has both traditional server capability and XPU/oneAPI capability.  The host chip is expected to act as a kind of window on the wider world, organizing the “devices” in its support and blending them into the global concept of a cloud application.

I’m a supporter of both these concepts, not only for what they are but for what they might lead to.  For example, could we see Intel integrate P4 into oneAPI, creating a model for a white-box switch that includes both its “main processor” and its switching fabric?  Or, best of all, could we be heading for a vision of a “cloud hosting unit” or CHU?  This would be the abstraction of a true cloud platform-as-a-service, offering perhaps its own “Cloud Parallel C++” language and its own APIs?

Cloud-native development depends on a lot of tools, most of which have multiple open-source implementations.  Public cloud providers have their own slant on almost everything cloud-native too, and all this variability creates a challenge for development, forcing almost all cloud-native work to fit to a specific hardware/software model that locks the user in.  Since lock-in is the number one fear of cloud users, that’s a major problem.

I’ve said for years that we should be thinking of the cloud as a unified virtual computer, but the challenge with that step is that there’s no universal language or library to program that unified virtual computer with.  Could someone develop that, and so set the cloud on its own pedestal at the top of all these parallel/virtualized-hardware abstractions?  Could that be the dawn of the real age of cloud computing?  I think it could be, and I think that we’re seeing the early steps toward that future in things like P4 and oneAPI.

Probably the only election topic most agree on is polling.  For two presidential elections in a row, we’ve had major failures of polls to predict outcomes, so it’s no surprise that people are disenchanted with the process.  What’s more surprising is that many people don’t realize that all surveys are as inherently flawed as polling is.  If getting a view of the “future” is important to you, it should be important for you to understand why it usually doesn’t work out well.

I started doing surveys back in 1982; a big survey was in fact the first source of revenue for CIMI Corporation.  I had to identify 300 large users of digital data services (TDM DDS and T1, in those days) and get information on their use and issues.  The project worked fine, and because it was so difficult to find people to survey, I kept in touch with the survey base to keep them engaged for future projects.  To do that, I posted them questions twice a year on various network topics, and by 1997 I had a nice baseline of predictions on future network decisions.

Nice, but increasingly wrong.  In fact, what I found was that the data showed that by 1997 there would likely be no statistical correlation between what my surveyed users said they were planning to do with their networks and equipment, and what they actually did.  Obviously, that was a major disappointment for me, but it did get me involved in modeling buyer decisions based on more objective metrics rather than asking them to guess.

That’s the first key truth to surveys.  You can ask somebody something that’s objective and observable that’s within their own scope of responsibility, but don’t ask them for planned future actions or about things outside their own areas.  Few people or organizations have any skill at figuring out what they’ll do much more than a year out, and most have their head down, focusing on their own jobs.

The next key truth emerges from another set of experiences.  First, I was asked by Bellcore to look over a survey they’d done a trial run with, because there were some extremely troubling responses.  I did, and what I said was that the survey presumed that the person being surveyed was a specialist in the technology they were asking about, but they never qualified them.  I suggested that, instead of asking whether their company “used ATM”, they ask what speed the ATM connection was running at.  When they did, the great majority said they were using “9600 bps ATM”, obviously mistaking asynchronous modem operation with Asynchronous Transfer Mode, what Bellcore wanted to know about.

Second, a major network publication approached me on a survey they did, and as in my first example they were concerned by some of the results.  I looked things over, and sure enough, 33 percent of the survey responders reported they were using gigabit Ethernet.  At the time there were no gigabit Ethernet products offered; the standard wasn’t even fully defined.  What happened here?  What I found in my own survey experience is that people want to sound smart and involved when they’re surveyed.  Ask them about a new technology and about a third will give you the answer they think makes them look good, even if the situation they describe is impossible.

The third key truth is what I’ll call the “diamond in the rough” paradox.  A big organization has tens of thousands of employees, and in the IT part of the company alone there are hundreds of people.  What do you suppose the chances are that all of these people know everything a company is doing or planning?  Zero, but what percentage of surveys actually effectively target the questions to people who are likely to know the answer?  Zero.

A big network equipment vendor had a well-known analyst firm do a survey and report for them, one that cost a boatload of dollars.  As in other cases, they were troubled by what they saw in the results and asked me to audit the survey and results against my own data and suggest what might have gone wrong.  The problem was that the survey did in fact ask the right companies, but made no attempt to engage the right people.  As a result, fully three-quarters of those who responded had nothing to do with the technology at issue, and their answers to the questions were totally irrelevant.

Sometimes the survey people even know that.  While I was auditing a survey of LAN use in the early days, I happened to hear one of the survey people talking to a target.  “Do you use Ethernet or Token Ring?” they asked, and apparently the party they had called had no idea.  The surveyperson helpfully said, “Well, feel around the back of your computer.  Do you feel a fat cord?”  Apparently the response was affirmative, and so the user was put down as an Ethernet user (that’s what Ethernet was delivered on at the time).  In fact, the cord was likely the power cord, so I asked the person doing the survey, and they said that almost nobody had the answer, so they were given that follow-up to use.  Guess how good those results were!

Then there’s the “bulls**t bidding war” problem.  People like getting their names in print.  A reporter calls an analyst firm and says “What do you think the 2021 market for 5G is?  XYZ Corp says it’s a billion dollars.”  The analyst firm being called knows that the reporter wouldn’t be making the call if they weren’t interested in a bigger number, so they say “We have it as two-point-two billion.”  This goes on until nobody will raise the bid, and so the highest estimate gets into the article.  The same problem happens with reporter calls with users; “When do you expect to be 100% cloud?” or “What percentage of your computing is going to the cloud?” is going to generate shorter timelines and higher percentages.

I know there are a lot of people who believe in surveys, and I’m among those who do as long as the survey is designed and conducted properly.  I only survey people I know well enough to know their skills and roles, and with whom I’ve had a relationship for some time.  I try to use a stable base of people, and if somebody leaves, I get them to introduce me to their replacement.  But even with that, most of the questions that get answered in survey articles and reports are questions I’d never ask, because even the best survey connections couldn’t get a good answer to them.  Most businesses respond to market trends that are largely unpredictable and most often tactical, so why ask they what they plan to be doing in three or five years?

This is why I’m a fan of using data from the past to forecast the future.  If you’re careful in what data you collect and how it’s used, the past measurements and the trends they expose are more authoritative than anything you could get by asking somebody for their plans.  They can also tell you how the mass of companies in the area you’re interested have responded to changes, and that’s a better measure of the future than asking people to guess.

The data on IT spending growth cycles I blogged about HERE is an example.  I found that there was a cyclical pattern to the growth in IT spending, both year-over-year and 5-year-smoothed and both by itself or compared with comparable GDP.  I found that there were notable new technology advances in the early part of each cycle, and my own surveys showed that in those cycles, companies reported that a larger portion of their IT spending came from new projects rather than budgeted modernization.  All that suggests a productivity driver for each wave.  It was particularly significant that after the last wave, there was never a time when project spending (justified by new benefits) contributed significantly to IT spending overall.

You can get government data on an amazing number of things.  Want to know what industries are most likely to use cloud computing, adopt IoT, rely on mobile workers and WFH?  Massage the government data and you can find out.  Where might empowerment of workers focus, either in industry or geography?  It’s there.  Where will high-speed broadband be profitable, and so available?  That’s there too.  Best of all, careful use of the data generates results that tend to hold up.  My demand density work and IT cycles work started fifteen years ago, and predictions made from the work in the early days have come true most of the time.

The final issue with surveys and polls is that they tend to show what whoever is paying for them wants to see.  I used to get RFPs from some of the big “market report” firms, and they’d be in a form like “Develop a report validating the two billion dollar per year market for ‘x’”, which is hardly a request for an unbiased solution.  You could try to ask if surveys are really unbiased, if all those who respond are fully qualified.  Good luck with that.  A better way might be to get a quote on a report of your own.  If your company can go to a firm and request research to back up a position, you can be sure others can do the same, and you should therefore distrust the information that comes from these sources.  I stopped selling syndicated research because people didn’t want to pay for the truth.

No survey is, or can be, perfect.  No model will always get things right.  There is no absolutely reliable way to know what a given company or person or group thereof will do, even months in the future.  There are just ways that are worse than others, and the best you can do is to try to latch on to one of the less-worse methods, and if it’s not good enough, opt for flexibility in your planning.  So, the moral here is don’t tell me what your survey showed, or someone else’s survey showed, or what you project to be the truth, because I don’t believe it.  So, of course, you’re free not to believe me either.

If ever there was a clear picture of open 5G challenge, THIS Light Reading piece may provide it.  The chart the article offers shows the things that Dish had to integrate in order to build an open-model 5G network.  It doesn’t look like a lot of fun, and there’s been a fair amount of industry skepticism generated.  The old saw, “A camel is a horse designed by a committee” surely comes to mind, and that raises the question of how to avoid camels in an open-model network future.

It’s not just 5G we have to worry about.  The issues that created a table of elements for 5G has done similar things in other areas.  We need to understand why the problem is so pervasive, and what might be done about it.

Networking is perhaps the only technology space that can define ten products based entirely on open standards, and still find that there are almost no interfaces in common.  This sad truth arises from the fact that network transformation projects tend to be very narrow in scope, which means that they have to fit in with a bunch of similar projects to add up to a complete definition of a network.  Why is that, and what (if anything) can be done about it?

I recall a meeting of the NFV ISG in the spring of 2013, where the discussion of the scope of the project included the statement that it was important to limit the scope to the basic question of how you deployed and managed virtual functions as software elements, leaving the question of broader management of the network out of scope.   This was done, it was said, to ensure that the task would be completed within 2 years.  Obviously, it wasn’t completed in that time, and obviously the question of how a virtualized set of functions was managed overall was important.  We didn’t get what we needed, and we didn’t meet the timing goals either.

The decision to make the functional management of a virtual-function network out of scope wasn’t actually a stupid one, if viewed in the proper context.  The difficulty was, and still is, that these kinds of decisions are rarely put in any real context at all.  Without the context, there’s plenty of room for a non-stupid concept to be a bad one nevertheless.

We were, at that moment in 2013, managing real devices, meaning what the NFV ISG called “physical network functions” or PNFs.  The presumption that was inherent in the views of that meeting was that it was critical to preserve, intact, the relationship between the management system and the PNFs when the PNFs were virtualized.  Since the process of deploying and connecting virtual functions would clearly not have been part of the management of PNFs, that was what the NFV ISG ruled as its mission.  However, that decision created a second layer of management, adding to the number of things that had to be present and integrated for NFV to work.

Networks are collections of stuff (the name, in fact, implies that).  Each of the elements of the network stuff are subject to review in terms of whether it provides optimum cost/benefit for the network operator.  This means that there’s a strong tendency to look at stuff-change piecemeal, and to contain the spread of impact to protect the investment in technology areas where there’s no particular need for a change.  That’s the likely foundation of the thinking that led to NFV as it is, and the same pattern of thinking prevails in all areas of network transformation today.  That means that even things like 5G and Open RAN are, to a degree, victims of PNF-think or scope containment.

Does that mean that we’re so locked into the past that we can’t transform at all?  Is transformation possible if we do nothing but reshape the nature of the PNFs, the boxes, without changing anything else?  Those are really subsets of the big question, which is whether we can transform networks by organizing different forms of the same thing, in the same ways as before.  Or, do we have to rethink how networks can work differently within, to open new possibilities and new opportunities?  We need to create an agile model of the new network, somehow, so that scope gaps aren’t inevitable, so that we can fit things that belong together into a common model.

SDN was inherently more transformational than NFV.  Why?  Because SDN proposed that an IP network that looked like the IP networks of old at the point of external interface, but that worked differently and (in some ways) more efficiently within, was the best answer.  The black-box theory, in action.  What’s inside the box doesn’t matter, only its external properties.

Despite SDN’s natural transformation potential, though, it hasn’t transformed the WAN.  Why that is, I think, is that SDN is illustrating the problem of true transformation in networking, which is that spread of impact.  I build a network that’s not based on native IP within itself, but I have to interface with stuff that thinks it is native IP.  Thus, I have to build native IP behavior at the edge, which is a new task.  I can’t manage the SDN flow switches and controllers using IP device management tools because they aren’t IP devices, so I have to emulate management interfaces somehow.  More scope, more pieces needed to create a complete network, more integration…you get the picture.

Scope issues have left is with an awful choice.  We can either do something scope-contained, and produce something that doesn’t change enough things to be transformational, or we can do something scope-expanding, and never get around to doing all the new things we now need.

There’s been a solution to this scope problem for a long time, illustrated by Google’s Andromeda and B4 backbone.  You wrap SDN in a BGP black box, treat it as perhaps a super-BGP-router with invisible internal SDN management, and you’re now an IP core.  That’s a great strategy for a revolutionary company with ample technical skills and money, but not perhaps as great for network operators with constrained skill sets and enormous sunk costs.

This is where I think the ONF is heading with its own SDN and SDN-related initiatives.  We actually have tools and software that can create a thin veneer of IP over what’s little more than a forwarding network, something like SDN.  We can compose interfaces today, with the right stuff, just as Google did.  The ONF doesn’t include the capability now, but might they?

DriveNets, known mostly for the fact that their software (running on white boxes) is the core of AT&T’s network, is perhaps the dawn of another approach.  Rather than applying SDN principles inside a network-wide black box, why not apply at least some of (and perhaps a growing number of) those principles to building a kind of composite device, a cluster of white boxes that looks and works like a unified device?

SDN separates the control and data planes, and it’s this separation that lets it work with composed interfaces, because it’s control-plane packets that make an IP interface unique, that give it the features not just of a network but of an IP network, a router network.  DriveNets does the same thing, separating the cluster control plane.  It makes a bunch of white boxes in a cluster look like a router, so we could say that the SDN model is going from the outside or top, downward/inward, and the DriveNets model is moving from inside to…where?

The reason this discussion is important to our opening topic, which is the 5G challenge, is that 5G standards and Open RAN and other related stuff is making the same sort of mistake SDN and NFV made, which is creating a scope boundary that they don’t resolve.  We have 5G “control plane” and “user plane”, and the 5G user plane is the whole of an IP network.  We have interfaces like N4 that go to a User Plane Facility, which ultimately depends on IP transport, but the UPF isn’t a standard IP network element or feature.  5G’s control plane is an overlay on IP, almost like a new protocol layer, because that’s pretty much what it’s trying to be.  Mobility management by creating tunnels that can follow a user from cell to cell to get around IP’s address-to-location who-it-is-where-it-is dilemma.

Why not get around that by composing the capability via a separate control plane?  Today it’s hard to introduce things like segment routing into IP because you have to update all the devices.  If there is no knowledge of the control plane within the forwarding devices, if all control-plane functions lived in the cloud and controlled forwarding, couldn’t things like tunnels and segments be composed in instead of being layered on?

Separating the IP control and data planes is fundamental to SDN, and also to DriveNets’ software.  It lets you build up a network from specialized devices for forwarding and other devices for hosting the control plane elements, which means that you can do a “cloud control plane”, something that I think the ONF intends but hasn’t yet done, and something DriveNets has definitely done.  But the separate control plane also lets you compose interface behaviors like Google’s Andromeda B4, and it would also be a doorway to creating network-as-a-service implementations of stuff like the 5G user plane elements.

If you can create a forwarding path from “A” to “B” at will by controlling the forwarding devices’ tables, do you need to build a tunnel the way both 4G/EPC and 5G UPF do?  If you can compose interfaces, couldn’t you compose the N4 interface (for example) and present it directly from your transformed IP network to the 5G control plane?  Might you not even be able to host the entire 5G control plane and user plane within the same cloud?

I think the answer to layer complexity, scope complexity, integration complexity, and management complexity in 5G and all transformed networks is composability of the control plane.  Yes, it raises the question of whether this sort of capability could promote proprietary implementations, but if we want to create open yet composable specifications, we can work on that problem explicitly.  That at creates a plausible if not certain path to solution.  I submit that just multiplying elements, layers, and pieces of a solution doesn’t lead us to anywhere we’re going to like.

What can we learn from 3Q20 earnings?  Company reports on revenue and earnings often provide us with important information about the real market trends, not the hype trends we so often read about.  There were high hopes for this quarter from many companies, but did they pan out?  What can we read from the results that tells us what’s happening with the cloud, with 5G, and with the market overall?

Let’s start with the big network operators in the US, AT&T and Verizon.  Both operators suffered revenue losses in the latest quarter, with AT&T’s 9% drop outpacing Verizon’s 5% loss.  Both companies are maintaining reasonable performance given the pandemic, but neither is seeing any windfalls related to stay-at-home and work-from-home behavior.

For AT&T, the big problem is that the value of their purchase of Time Warner has been hurt by the pandemic, and in fact their overall media/content position is in what can only be called “disorder”.  AT&T’s wireline base is too distributed for traditional infrastructure to profitably reach it with high-speed Internet.  Mobile is their hope, and it seems very possible that everything at AT&T will focus on mobile technology, even what used to be “wireline” delivery.

Verizon has a better position with fixed broadband demand density, but most of their FTTH-suitable territory has already been served.  They also need to be thinking about 5G as a means of reaching those customers FiOS can’t profitably serve.  Since they’re not (currently) proposing to deemphasize content, they also have to ask what they’ll do for video to these non-FiOS customers—they may need a streaming service.

Moving along, how did the public cloud providers do?  Google Cloud had the largest revenue gain for the quarter at 45%.  Market-leader Amazon’s AWS sales were up 29% in the last quarter, and Microsoft saw 31% growth in sales.  All these are decent numbers, none show any massive shifts in market share (though obviously market-leading Amazon has a bigger barrier to increased sales than up-and-coming players).  I do think that both Google and Microsoft are benefitting from hybrid cloud, a cloud computing model Amazon doesn’t have enough premises street creds to support with a compelling story.

The big question among the three is really Google versus Microsoft.  Google is doing fairly well with hybrid cloud and enterprises, in no small part because it has a truly foundational vision for the cloud, embodied in things like Kubernetes and Istio.  While it doesn’t have the direct account influence of Microsoft (yet), it’s moving well.  Google, among the public cloud providers, best represents the leading edge of true cloud-native applications.  If there is a cloud-native wave, they may surf it best.

More significantly for the market is the fact that public cloud revenues didn’t explode in the post-COVID planning age.  Shifting compute from a capital budget to an expense would be a safe play if a major problem in the economy was expected, so it would seem that enterprise buyers aren’t yet saying that they’ll have to pull in their horns in a serious way.  That could mean that IT spending overall won’t be hit as badly in the last quarter and into 2021 as some had feared.

Network equipment hasn’t been much of a bright spot in the recent past, and that still seems true.  Cisco beat slightly on earnings and revenues but disappointed on guidance.  Juniper beat on revenues and missed on earnings.  Nokia’s numbers disappointed, and the company announced some reorganization al moves.  Ericsson was the bright spot; they beat estimates and their guidance was reasonable.

Service provider numbers were generally disappointing for the vendors here, but Ericsson clearly has benefitted from the push against Huawei, the habitual price-leader in the mobile market, and from 5G interest.  The real story here, at least in the longer term, is likely to be the open-model networking movement.

AT&T has been an aggressive promoter of white-box networking in its 5G mobile space, and also announced its core would now run on DriveNets software and white boxes.  Open RAN is creating an explosion of interest and early commitments, and it seems very likely that in early 2021 it may be a major factor in the financial performance of network vendors overall.  Because operators have no clear source of improved revenue per bit, they’re putting increased pressure on costs, and the most reliable way to do that is to adopt open-model networks.

On the enterprise side, there’s still hope for the network vendors, but also the prospect of future challenges.  Enterprise spending on network technology has already shifted as businesses moved away from building private IP networks to consuming first VPNs and increasingly SD-WAN.  Cloud computing is likely to sustain some growth in data center switches and even some access routers.  Juniper did better than expected in the enterprise space, in particular.

The challenge for enterprise network spending is really the mirror image of the operator profit-per-bit problem.  Enterprises have, for decades, created IT budgets from a combination of “modernization” spending to sustain current applications, and “project” spending where new business cases could justify spending increases.  Nearly all of these are based on projected productivity enhancements (some relate to regulatory changes, M&A, and other factors), so in the long run it’s important to identify new ways that enterprises could use IT and networks to make workers more productive.

Juniper’s Mist-AI deal seems particularly promising, and they’ve augmented it with the recent acquisition of 128 Technology, an SD-WAN and virtual-network vendor who offers session-aware traffic handling and statistics and a platform strategy that starts with basic metrics and monitoring and moves upward.  The exact nature of the marriage isn’t known yet because the deal hasn’t closed, but it could provide at least a mid-term boost in the enterprise, and also translate into improved managed service platform sales to operators.  If they carry it further, 128 Technology’s SD-WAN strategy could become a centerpiece for network-as-a-service thinking, and combined with Mist AI, could give Juniper an enviable position in networking overall.

Moving on, let’s take a look at the IT side of the story.  IBM delivered better-than-expected results for the quarter, mostly because of Red Hat and (to a lesser degree) its cloud service and AI.  I think it’s clear that IBM is working harder to leverage Red Hat, but that the company isn’t quite there yet, in terms of culture and technology integration.  VMware, rival in particular to IBM’s Red Hat, also beat expectations.  The two companies are likely to collide directly with their carrier cloud aspirations, but carriers themselves seem lukewarm on making any near-term commitment to the concept, so that collision may not be realized until mid-2021.

I think the big question raised by the IT players is whether public cloud or cloud-platform software will emerge as the framework for future application development.  I’ve already noted that Google’s cloud story is the most insightful from a cloud-native perspective.  Who among the cloud-platform players can sing as prettily?  VMware and IBM are jousting now, and while carrier cloud and 5G may be the early battleground, a stronger, broader, more interesting cloud story will be needed for a clear win.

OK, if we throw all these data points in, like Yarrow Sticks in I Ching, what hexagrams can we read?

First, the US economy has proven more resistant to COVID than its population, perhaps.  The likely reason is that the greatest impact of the virus has been on service jobs, and these have less an impact on the consumer economy and B2B in at least the early stages.  The impact is likely to grow, however, if the problems extend beyond 2020.

Second, there is a general problem impacting business technology that’s harder to dismiss, and that problem is return on investment—business case, if you prefer.  People buy stuff on a whim, and as long as their income holds up, their buying holds up.  Businesses need a justification, and across the board, we’re running out of justifications for new spending.  The most profound truth of this century has been that we’ve been unable to produce new justifications for business IT and network spending, and that’s driving businesses overall to cost management measures for new projects.  “The purpose of this new spending project is to define and implement a model whereby we spend less”; that’s a bit of an oxymoron, and you can see the result.

Third, we’re firmly into a new technology age, one where software is everything and hardware is just something you run software on.  That’s been true in computing, and it’s becoming true in networking.  The shift to cloud-hosting of network features is, at this point, less important than the substitution of white boxes for proprietary devices.  “Disaggregation”, which in one of its flavors means separation of hardware and software, offers the opportunity for buyers to purchase generic devices that can run a variety of software packages.  If there’s a standard “platform”, meaning operating system, chip drives, and middleware (including operations and orchestration), then there’s more likely to be standardized software, software interchangeability, and investment protection.  None of this is guaranteed, so we need to be thinking more of white-platform than white-box.

Forth, we don’t know where operators really plan to go with regard to transformation.  While both public cloud providers and platform software vendors like VMware and IBM are positioning for the opportunities, nothing much is hitting the bottom line yet.  Operators may just be laying out postulates rather than making commitments at this point, which suggests that there’s still a lot that could be done to sway their decisions.  This is the largest pile of money on the table for the 2021-2023 period, so it’s worth going after.

Finally, we need to escape hype-driven, superficial, technology coverage.  I remember a conversation I had years ago with a self-styled industry visionary: “Your trouble is that you’re sailing at fifty thousand feet and your buyers are at sea level,” I said, and it was true.  Bulls**t has less inertia than real hardware and software, and less than real people.  We have to lead people to literacy on new technologies, and that’s not going to happen with some superficial crap like “How many new ‘Gs” can you postulate in wireless?”  Just because it’s easier to write a story that changes a “5” to a “6” than to write one that addresses the real needs of a mobile network evolution/revolution doesn’t mean we have to do that.

Why do automation projects, meaning lifecycle automation projects, fail?  A long-time LinkedIn contact of mine, Stefan Walraven did a nice video on the topic, something worth discussing not only in the context of lifecycle automation, a big interest of mine, but also in the context of any “transformational” projects, including virtualization, disaggregation, white boxes, and so forth.  I want to amplify some of Stefan’s points, gently supplement a few, but endorse this video for anyone in the business of changing networks.

Automation is a must, but also a disappointment.  That’s probably the key message, and the key truth, in the automation story.  Why is this?  That’s the question Stefan wants to address.  He starts with a cute and effective analogy on risk posture, the “Sumo” versus “Kung Fu”.

The Sumo warrior takes a posture to control and resist change, to stay balanced, to move deliberately but with power.  This is clearly the conservative/defensive mindset that’s often attributed to the network operators.  In contrast, the Kung Fu warrior uses change to advantage, responding to pressure by moving to take a more powerful position.  Speed, accuracy, and agility is the play.

Stefan says that you have to handle change as a Kung Fu warrior, because automation is really about change (since we’re not automated now).  You must take one position or the other, so you have to take the change-centric one.  But in the exercise of your agility, you have to confront the yin and yang of automation, which on one hand says you want to offer reasonable time to market with your solution but on the other hand have total stability in your result.  Here, I’d offer another point I think is related.  Time to market can induce you to pick an approach that doesn’t extend far enough to deliver in the long run.  Stefan says too much emphasis is often placed on TTM, but not for this reason.

His next point is the bottom-up versus top-down mindset, and here Stefan introduces the risk that a bottom-up approach, which is usually the result of a TTM focus, would create a jumble of things that don’t go together, a “tangle of local automation” to paraphrase the slide.  The problem with the top-down approach is that you can get so carried away with specification and design that you never get started at all.

Many, including me, would say that somehow the network operators have managed to get the worst of both worlds.  They almost always take a very bottom-up approach, but they get so carried away with specification—a risk of the top-down approach—that they reach a conclusion only after nobody cares anymore.  Harmonizing that seeming contradiction is the next point, the “ecosystem” in which the operators do their projects.

The recommendation that Stefan makes regarding the ecosystem or the external relationships that influence operator automation projects is to avoid technology choices driven by external opinions.  That’s probably good advice if you can take it, but that may not be possible because of the reality of operator culture and technology experience.  Not to mention that operators themselves are often guilty of spawning the most influential of those external relationships, the standards activities.

Standards have been a big part of operator behavior for literally decades.  The Consultative Committee on International Telegraphy and Telephony (CCITT) isn’t heard of much these days, but this group of standards-writers, collected from operator processes, were the word up to about 25 years ago.  In the days before deregulation of telecom, in fact, the CCITT rules had force of law in countries where the operators were part of government postal, telephone, and telegraph (PTT) bodies.  The CCITT gave us standards like international packet switching (X.25), so their work has in fact been involved in data protocol standards.

Operators still see standards as being a kind of touchstone to protect them through change.  They have to slip out of Sumo into Kung Fu, they feel threatened, so they launch a standards initiative to prepare a nice set of Sumo positions that the Kung Fu change process can then hunker down into when the change has been accomplished.

It’s here that Stefan makes his strongest point.  This is your business, operators, your ecosystem.  If you don’t know automation, you need to learn it, and learn it fast.  But while this is the strongest point, it’s also a vulnerable point, because the future of networking is so complex, and so different from the past, that learning it from scratch without reliance on some of those external ecosystem elements Stefan cites, is almost surely impossible.

Now, Stefan starts with some points or rules, each of which is highly interesting and worthy of discussion.  The first is that “We’re in this together”.  There is no middle ground.  All of the stakeholders, the members of the ecosystem, have to be integrated into the vision.  Thus, you need to build cross-functional, cross-organizational teams.  The members of this team, and any partners selected, have to be Kung Fu masters as well as people who know their areas and can get things done.

The second point is “Fierce automation per service”, which means one service (business case) at a time, and it’s here that I must gently suggest that there’s a missing step.  Let me address that, then pick up with Stefan at this same point.

My “missing step” here is that there is no chance of harmonizing per-service automation, or even completing it effectively, if you don’t establish some architecture first.  That architecture is framed by a set of technology elements that are currently available, widely used, and have direct capabilities in the specific areas where the automation project must focus.  I believe that the public cloud technology base, the concepts of intent modeling, and the principles of TMF NGOSS Contract, are the minimum inventory of these tools.  I’ve blogged a lot about each of these, so I’m not going to go into detail about them again here.  Instead, I’ll rejoin Stefan.

Fierce automation per service, if done within an architectural framework that can address automation in general and leverage available technology, is indeed a very smart concept.  Pick something that completely exercises your proposed solution, and preferably something that’s fairly contained and that can be done quickly without collateral impacts on other areas.  Learn from that process, refine your architecture, and then proceed.  Stefan rightfully suggests top-down design for this first service (and others, of course).

Using what’s learned from this first automation exercise and using the software architecture that’s been created and refined, you now enter Stefan’s “Brutally automate everything” phase.  His point here is also a key point, most projects will fail because the scope of automation leaves too many loose ends, and manually addressing all these disconnected little leftovers will surely require an enormous human effort, enough to create a project failure.

In Stefan’s third point, he defines the “Kung Fu automation toolbox”, which is a good name for what I’ve just introduced here as a step to be taken before his second point.  I think this reflects the difference between my own view of this and Stefan’s view.  He’s framing a software architect’s vision of automation because he’s a software architect from a software organization, and so he intuitively uses this framework because it’s proved to be the right approach in cloud projects.  The problem is that the operators don’t have that background, and so they’re going to have to establish this toolbox, pick the right elements, understand both the choices and the way they’re applied to the problems of automation.

This isn’t just a semantic debate or the order of steps.  The reason why not only automation projects but virtualization projects and other “transformation” projects have been failing for operators is that they don’t know what the toolkit is.  Build structures with mud bricks for generations, and when you’re confronted with the need to build a bridge, there’s a lot of inertia driving a mud-brick selection.  Operators are box people, so if you don’t give them an explicit not-box toolkit, they’ll build whatever they’re building with box concepts.

I think the problem that operators have with automation, as well as with function virtualization and other transformation pathways, is that they don’t know anything about where they’re going in terms of basic tools.  Not-box isn’t an affirmative choice, or even a specific one.  What is the new model of networks that replaces the box model?  I tried to describe this in my ExperiaSphere work, and there are other initiatives using intent models and state/event processing, but whatever approach you like has to be an explicit one.  We need an architecture for the way networks are built in the age of the cloud and lifecycle automation.

Stefan is describing a basic approach, and one that could surely be refined and adopted.  If any such approach, any such toolkit, is in fact specified and used, then all his steps make perfect sense and would result in a successful project.  The key is to get that toolkit, and the biggest mistake we’ve made in transformation and automation is trying to move forward without it.

I want to consider, in this blog, a question that arises naturally from the debate on how operators respond to declining profit per bit.  Raise revenues or lower costs; those are the choices.  Operators seem to be focusing on cost reduction, which would lower cost per bit to improve profit per bit.  That would mean the most logical way to increase revenue would be to either add customers with newly affordable broadband, or upsell current customers to higher speeds.  What happens if this is the course operators take?  We’ll start with how it impacts the operators, and move to what it might mean to services and users.

It’s important to approach the operator impact step by step.  Reduction in cost per bit makes reduction in revenue per bit survivable, but what’s causing reduction in revenue per bit?  The answer is that users won’t pay proportionally for capacity or usage, and competition encourages operators to offer faster connections.  5G, for example, is “faster” than 4G despite the fact that there few if any smartphone applications where the extra speed would even be noticed.  Once you can stream video at the highest quality level that’s distinguishable on a mobile device, you’re at the end of the road, utility-wise.

The broadband market is competitive, so there’s little chance that a reduction in cost per bit would automatically improve profit per bit.  Operators would likely market improved broadband to a wider customer community, increase the capacity available to current users, or both.  Given this, we could assume that the result of our cost-to-near-zero hypothesis in broadband would be very high broadband capacity at costs comparable to those of today.  What does that do?  It enables new higher-bandwidth-demanding applications.  If not mobile ones, then what?  Obviously, broadband to the home and broadband to the business.

Let’s look at the home applications first, since most operators would agree that widespread consumer broadband applications are the most credible way to use capacity.  We couldn’t tell much difference (if any, candidly) between HD and 4K on a smartphone, but stick up a 70-inch OLED TV on your wall and give the two video options a go, and you’ll see the difference for sure.  Fill a house with teens who want to watch their own stuff, and you can easily end up with three or four or a half-dozen streams to the same home.  In short, entertainment focus shifts to streaming, as it’s already doing, and things like COVID (which makes theaters less popular) is a collateral driver.

Work from home is another obvious answer, one also related to COVID and its aftermath, but video calls are far less bandwidth-intensive than streaming entertainment video, so before this driver would be useful, I think we’d have to wait for applications to develop in the WFH space that were much more bandwidth-intensive.  It is possible that higher-quality conference video would develop out of lower unit bandwidth cost, but not certain.  It’s also possible that WFH might involve a mobile device, but far more likely it would be truly “from home” and be supported on a local PC.

Gaming is another application to consider.  Gaming can benefit from high-quality display, but most gaming generates the majority of the visual field local to the player.  Would high-bandwidth connections change that, perhaps encourage the cloud synthesis of a virtual world and from that “project” each player’s view?  If that were to happen, would the projection require a lot of bandwidth, or would we end up sending “avatars” and “objects” and have them rendered locally anyway?

The key point here, I think, is that there is no broadly interesting consumer of high-bandwidth services to consumers other than video.  An almost-as-key point is that the video driver for higher bandwidth is far more likely to relate to fixed broadband applications.  That doesn’t mean 5G doesn’t play in it, only that 5G’s role would most likely be in the delivery of bandwidth to homes rather than mobile devices.

Let’s analyze these points, then.  How much video quality can we presume a home user would notice?  We know 4K on a large-screen TV is noticeable.  I’ve seen examples of 8K, and for professional video applications like a theater they make sense.  For the home, it seems to require a very large screen placed fairly close, so I think it’s more likely that faster refresh rates and other video factors that would improve the viewing experience would be more likely to consume extra bits.

Home broadband enhancement based on lower bit costs doesn’t necessarily pull through higher-speed residential broadband.  “Cheap broadband bits” doesn’t necessarily mean “available broadband bits”.  A bit in the access line, to paraphrase the old saw, is worth two in the core.  If we did see a significant drop in cost per bit at the network (core) level, we could assume that the higher capacity could be offered at a small incremental price to those users with access facilities capable of carrying the higher speed.  Who has those facilities?  Today, it would be mostly cable subscribers and telco FTTH subscribers.  Tomorrow, 5G might add additional FTTN/5G hybrid customers.

Network operators could expect to monetize this situation in two ways.  First, customers with DSL-based broadband could certainly be induced to upgrade if the incremental cost was modest.  But absent a driver application that changes bandwidth needs, there’s less incentive for DSL users to upgrade, and operators would likely have to discount to induce them, which would mean they could actually drive down their own profit per bit further.  Second, operators could provide a high-bandwidth application and link it to higher-bandwidth service.  The two obvious options would be streaming video and some targeted WFH service.

Where an operator’s service area has high enough demand density (see THIS blog for an explanation), 5G in some form could allow broadband delivery to bypass limited DSL access solutions.  It’s difficult to model the impact of this generally without a lot of work, but it appears that a 5G solution could support at least 20 Mbps to most customers that don’t have cable/FTTH already, and 50 Mbps to most urban/suburban locations.  However, ROI on basic broadband access would be low (otherwise these users would likely have been connected with something else).  You still need a kicker service.

Streaming video is a logical solution.  Operators could either do it themselves or partner with a current streaming player.  The former could offer potential for a decent ROI, but it would involve a build-out of at least CDN infrastructure, as well as negotiating and maintaining the content licenses.  Partnering could provide a quick incremental revenue boost, but only a limited one because the operator is essentially getting just a sales commission.

The WFH target is a good way to transition to the business side of the bandwidth opportunity.  To me, it’s always been a mystery why more operators didn’t take up the opportunity to combine premium broadband with SD-WAN to support branch networking and WFH.  The beauty of this is that the business could be sold the service as an increment to home broadband.  WFH could be supported by an inventory of tools integrated with the basic NaaS/SD-WAN framework.  Where there are no regulatory barriers to the move, the QoS on the “business NaaS” could even be guaranteed.

Inevitably, operator desire to increase ARPU leads them to upsell capacity, which only hurts their revenue per bit and encourages OTT disintermediation.  It seems to me that to break this cycle, operators have to find something they can sell that uses capacity, not just the capacity itself.  While many operators won’t like the NaaS or streaming-video ideas for consumer broadband, I think they’re the only options on the table.

That suggests that the story that AT&T might be selling off a big piece of its video assets could create an issue for the company down the road.  To focus entirely on cost reduction to improve profit per bit is to cut your own broadband pricing in the long run, which encourages OTT services if you don’t have your own.  Sell your own off in that situation?  Seems problematic, unless AT&T has a service vision beyond streaming content.  We’ll have to wait and see.

I’ve blogged a lot about “transformation” of network operator business models, and also about transforming infrastructure.  That’s an important issue to be sure, but there’s more to the cloud, network, and computing market than network operators.  We know operators are responding to falling profit per bit.  What’s driving the enterprises?  Operators invest in IT and networks for cost reduction, more service revenues, or both.  What do enterprises invest for?  The answer, I believe, is clear.  It’s productivity.  That’s what I want to cover today.

What should we call the effort to improve business productivity via information technology?  “Transformation” or “digitization”?  Just the fact that we have to think of a name for the thing is a bad sign, because a name trivializes something that we’ve not really gotten around to defining.  Say the name, and you identify the concept.  Sure, but you don’t architect it, and that means that the fact that all real “transformations” are broad ecosystemic changes is lost in the hype shuffle.

What made the Internet transformational?  The original Internet protocols, and even the original services of the Internet are totally unknown to the vast majority of Internet users.  Was it the invention of the worldwide web?  Sure, that was important, but suppose that all those consumers who jumped on the benefits of the web had nothing to get online with in the first place?  So was it the Steve Jobs or the IBM PC that created the wave?  I think the point is clear.  The transformation happened because a lot of things were in place, not because one thing came about.  We can’t pick one of those things and say it’s a revolution, or assess its market impact, without considering the sum of the ecosystemic parts.

This is why so many market forecasts are…well…crap.  You can’t forecast the market for a piece of a suppositional ecosystem, and if you can’t make the suppositional ecosystem real you can’t even say what the pieces are or how they’d play in the final assembly.  The good news is that while foresight may fail here, hindsight offers us some hope.

The chart above is a modern version of one I produced for the financial industry 15 years ago, based on data from the US Bureau of Economic Analysis.  This version is the rate of change in core IT spending per year, based on a five-year moving average to reflect depreciation cycles.  The chart shows clearly that there were three distinct periods when IT spending rose more than average.  If we align industry technology events with the same timeline, we’d see that the first of these peaks coincided with the adoption of data center computing and batch processing, the second with the adoption of distributed minicomputers and online transaction processing, and the third with personal computing and online Internet information delivery.

I submit that each of these periods, periods when IT spending was above average, represented periods when the benefits associated with incremental IT spending were above average.  Put another way, they represented times when a new paradigm for worker empowerment came on the scene, and companies exploited that by building out more infrastructure to gain the benefits.  When they’d fully realized those benefits, spending fell back to normal patterns.

At the time of my first presentation of this data, I told audiences that unless the IT industry devised another empowerment paradigm, IT spending growth would stagnate.  The modernized chart above shows that’s just what happened.  During the period since 2005, companies saw the share of IT spending associated with “budget” maintenance of current applications grow, because the number of new productivity projects to inject new funding declined.  No new benefits, no new spending.

In each of the periods of past productivity cycles, IT spending grew more rapidly than the average rate, a result of the injection of additional project budgets to drive spending overall.  The rate at which spending grew (on the average, the growth rate tripled at the peak) seems related to the complexity of planning for and adopting technology to support the new paradigm, but in general it required only three or four years to reach peak.  The declines in spending growth representing the maturing of the new technology, took longer than the peaking process did.  It’s important to note that spending growth didn’t decline below norms (roughly a 5% rate per year) between cycles, which shows that once the equipment/software associated with a new paradigm was acquired, it added to the base of technology to be maintained through orderly modernization thereafter.

The chart suggests that if we were able to define another productivity investment cycle, we could triple IT spending growth, keeping it above average for about ten years.  Is this almost a statistical validation of the “next big thing” theory?  No, it’s a validation of the next big paradigm, a paradigm made up of many things, which individually might not be transformational at all.  Even to describe the waves on my chart, I’ve been forced to trivialize the nature of the technology changes that led to each wave.  Otherwise my legends wouldn’t fit on the chart.  We need to get past the labels, even mine, to see some truths.

The truth, I think, is actually simple.  This hasn’t been about computing or software or networks at all, but at getting information processing closer to the worker.  Data centers in the first wave were doing batch processing of records for transactions already completed manually.  In the second wave, we moved processing to the transactions themselves through online transaction processing (OLTP).  In the third wave, we gave workers their own “data center” (even the first IBM PC had as much memory and processing power as a data center system in 1965).  IT is migrating, approaching, and the vehicle is just a convenient set of tools that fit the mission.

So what’s the mission?  I’ve used this term before; it’s point-of-activity empowerment.  We need to get information not to the desk of the worker, but to the worker at the time and place where work is being done.  That’s what the other waves did, and it worked.  5G isn’t the wave, nor is the cloud, nor mobile devices, nor IoT, augmented reality, robotics, or the other stuff often suggested.  Those are just part of that “convenient set of tools”.

How, then, do we get things started on that wave, if what we need is a set of mutually interdependent pieces?  What egg or chicken leads the charge to the future?  What is the binding element of the ecosystem we’re trying to create.  I think we know the answer to that, too, from chart-hindsight.  It’s applications, and (of course, you know me!) application architectures.

What’s the difference between the hypothetical point-of-activity-empowerment wave and other waves?  The answer is what IT is doing for the worker, which is also the difference from wave to wave overall.  But in past waves, we had an advantage in that we could conceptualize the application from the first, and so we were simply doing the tool-fitting process iteratively as technology advanced.  Processing an invoice in the mainframe age was reading a punched card with invoice information, prepared from actual paper invoices.  In the OLTP age it was reading the data from a terminal as the transaction was occurring.  In the PC/online era, the buyer entered the order and nature took its course from there.

There is no invoice in the next wave, because what we’re doing is, in a sense, getting inside the work process to deal with the job overall and not the final step in the job-process.  What that requires, I think, we have to approach deductively, and I propose to do that by referencing something I’ve been calling “jobspace”.  The “jobspace” for a worker is the sum of the information content of their job, from all sources including their own senses.  Point-of-activity empowerment means projecting more/better information into worker jobspace, and presenting the contents of the jobspace better.

One obvious thing is that we need to have a portal to information in the hands of the worker, which means a smartphone or tablet with ubiquitous broadband connectivity.  We have that now, but we’ll have to see whether what we have is enough by looking deeper.

The key element to point-of-activity empowerment is knowing what the worker is trying to do without having to force them to decompose their activities into steps and ask for the associated information.  This has three components.  First, knowledge of the environment in which the worker is moving.  That would be a mission for location tracking (GPS) and IoT.  Second, a knowledge of the assignment, meaning a goal or sequence that the worker’s job will necessarily involve.  Finally, a means of presenting information to the worker contextually, meaning within the real-world and assignment context.

It’s long been my view that the broad benefit of IoT is to create a computer analogy of the real world, a parallel universe in a sense.  This information has to be presented, not requested, or the process of empowerment will take up too much time.  However, the idea that we can obtain this by reading sensors is silly.  My suggestion was, and is, that sensor information, or any other kind of “real-world” information, be visualized as an information field.  A worker moves through the real world, and intersects a number of information fields, from which information is “imported” into the jobspace, based on what’s needed.

The “what’s needed” piece is an important one because it defines the information content of the worker’s mission.  Think of it as a pick list, an inventory of what conditions or information is required or to which the worker must be aware.  If the worker is looking for a carton in a vast warehouse, they need running directions on getting to it, which means a combination of its location and their own.  Point of activity empowerment demands not just that we define what we want the worker’s end result to be, but also what we expect the worker will have to do, and use, to get to that result.

The “information manifest” for this will have to be produced by line organizations using a tool to describe things.  For those who have used UML for software architecture, my diddling suggests that it would be pretty easy to adapt UML to describe a job sequence and information manifest.  However, the creation of this might well be an AI/ML application too.  You can see, in particular, that having a worker go through something under ML observation, then having ML create the necessary descriptions, could be logical.

For the third element, contextual presentation, we have multiple options that are likely arrayed in one direction, which is augmented reality.  In point-of-activity empowerment, the information channel has to combine the jobspace and the real world, which is what an AR device does.  This isn’t to say that every point-of-activity empowerment project has to start with AR, only that we should presume that AR is the end-game and frame our application architecture around that presumption.

What’s important in the AR model is the recognition that the level of integration between the real world and the jobspace will depend on the specific visual pathway to the worker.  Our visual sense is the only one rich enough to convey complex information, so we should assume that contextual analysis of worker position and information fields would provide us jobspace content.  Displaying it depends on how capable the visual pathway is.

If the worker has a tablet or phone and nothing else to look at, then we can’t integrate things like what direction the worker is looking to determine what they want.  In this case, we could presume that the worker could use voice commands or screen touches to convey their focus of attention.  If we have an AR headset, then we need to link the jobspace elements of a given object in the real world, with the place that object takes in the worker’s visual field.

The key point here goes back to my comment on the “Internet transformation”.  Suppose we had no PCs in place when Berners-Lee developed the web.  Would the Internet have taken off?  Or suppose we didn’t have the web, even though we had PCs.  Or broadband to the home, without one or the other.  Sure, there are things that might have happened to allow something less than the full ecosystem we had to develop into something, but it surely would have taken longer.  The same will be true with our next wave of productivity, and it’s certainly possible that because we as a market seem incapable of deep thought, we won’t develop any new ecosystemic support for point-of-activity intelligence.  What happens then?  I don’t know.  I have no idea what could create the next wave of productivity empowerment, if it’s not what I’ve described here.  Perhaps other smarter people will have a notion; surely many will claim they do.  I’m doubtful there is one, but you’re free to bet as you like.

Five good architects in four months could design all of this.  It’s far from impossible, and my view is from the perspective of someone who spent years as a software architect.  But to be “not impossible” isn’t the same as being automatic, and as long as we believe that all we have to do is mouth a marketing slogan and the technology it represents immediately becomes pervasive, we’re lost.  There’s real work to be done here, and that’s the bad news.  The good news is that I think that—eventually—somebody will do it.