Author: Tom Nolle

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.

 

If you want to make money selling carrier cloud infrastructure, you’re running out of time.  There are three Light Reading stories to buttress this view.  First, Verizon and AT&T are both working through plans to build private wireless networks for enterprises.  Second, IBM has joined other public cloud providers in going after network operator carrier cloud opportunities, and finally, Microsoft and Verizon are partnering for mobile edge computing services (MEC).

All of this is incredibly important, not only to cloud providers and network operators, but also to the vendors who had hoped to reap a piece of the one hundred thousand incremental data centers that carrier cloud could generate by 2030.  These signs, combined with others that I’ve covered in prior blogs, suggest that network operators are changing their thinking, moving to a “cloud-as-a-service” rather than building their own clouds.  Why?  Because nobody has shown them how, or why, they could do that.

All cloud applications pose two questions to buyers.  The first is the nature of the application itself, its functionality and the properties of its implementation that relate to its usability, scalability, and performance.  The second is the resources required to run the application, meaning the hardware, operating system, middleware, management and orchestration tools, etc.  If you want to do something “in the cloud” you need to answer these two questions with respect to your candidate approaches.

Problem number one for operators is that they often know little or nothing about the application side of their cloud plans.  Sure, they’ve heard that their stuff should be “virtualized” and “disaggregated” and “cloud-native”, but what the heck does all that mean?  What applications are out there that have these properties?  The operators may understand things like “SDN” or “NFV”, but they don’t understand how to convert these things, which are really deployment and management architectures and not applications, to the applications themselves.  Without actual applications in mind, it’s hard for them to answer the second question, which is what is needed to run those applications.

I think a big part of the operators’ recent infatuation with public cloud providers as a source of 5G hosting can be traced to this.  Many of these providers are offering not just a platform but a telco cloud application (5G), and so they’re a one-stop shop.  There’s no concern about the functionality or the compatibility of the application to the platform—it’s all integrated, from a single source, and one big enough to sue if they misrepresent things.

For the classic potential beneficiaries of carrier cloud, or the hypothetical beneficiaries thereof, these problems are big stuff.  If operators can’t build carrier cloud applications and infrastructure, the platform vendors lose revenues on a hundred thousand data centers.  Even chip vendors cringe at the thought of that kind of loss.

This is the context of the Samsung/VMware announcement, following a similar one with Samsung and Red Hat, is highly significant.  Absent applications, platforms for 5G are an intellectual exercise, which means that the platform vendors are in the drivers’ seat.  That may also explain Ericsson’s somewhat-late-and-somewhat-uneasy commitment to Open RAN with its “Cloud RAN” platform.  The lack of applications for carrier cloud puts mobile network vendors in an awkward position.  On the one hand, they stand to gain from selling their original proprietary solutions.  That’s particularly true with the pressure on operators to keep price-leader Huawei out of the market.  On the other hand, of operators want an open-model mobile network, the proprietary vendors are setting up non-network competitors to provide it, raising more competition at likely lower prices yet.

Platform vendors would, of course, rather see a bunch of application providers vying for their platform business, and operators pushing for the whole package, than a small number of application vendors all dealing on the same platforms.  That’s particularly true when 5G is the only target at this point, and it’s hardly the only driver of carrier cloud.  In fact, 5G is likely to reach its peak influence on carrier cloud decisions by the end of 2021, and (even then) account for about a fifth of the opportunity.  But 5G is important because it’s the “two-punch” of a “one-two-punch” driver set, the first of which has already failed to produce.

My original carrier cloud market model suggested that to get full data center realization from the opportunity, operators would need to prime the pump, first with NFV and then with 5G.  NFV hasn’t delivered any significant number of data centers, so 5G is the only “familiar” application operators could aim at with carrier cloud deployments.  All the rest of the carrier cloud drivers are things like advertising, streaming video services, and personalization/contextualization, things that the operators aren’t nearly as comfortable with.  If 5G doesn’t deliver some data center deployments, then these hazy and somewhat frightening drivers are going to have to pull the cart all by themselves.  That would make carrier cloud far less likely.

It would also mean that the network operators would be totally dependent on a combination of cost-reducing measures and the revenue for NaaS-type services to erase their profit-per-bit problem.  Neither of these approaches is ideal.  Cost reduction obviously vanishes to a point; you can only reduce cost so much.  NaaS-type revenues have a significant upside, but they also have a lower ROI than retail services would have.  Augmented reality and “contextual services” that build on what a user might want to know about their surroundings, based on where they happened to be, have a retail opportunity and also a NaaS opportunity.  Operators might find the latter more comfortable, but the former would be more profitable.

Would the profit difference between NaaS and retail OTT-type services be enough to make the difference between profitable operators and operators scraping by?  It’s impossible to answer that with any confidence at this point because we don’t know how much of the retail service could be subducted into NaaS features.  We also don’t know the cost of deploying NaaS, in no small part because there are multiple ways of approaching it.

NaaS is really built around what some (including the ONF) have called “programmable networks”.  If a network’s service features can be composed, then services can be based on this composition process rather than extracted from a common set of device behaviors, as they are now.  To make NaaS truly valuable, though, there has to be a way of absorbing new features into the network, features that today lie outside traditional connectivity features but which are mandatory for the network connectivity process to work.  Things like DNS/DHCP, CDN redirection, and the control-to-user-plane interfaces of 4G and 5G fit into this.

So could the AR and contextual services I mentioned above.  As I’ve said in past blogs, it’s totally unrealistic to assume that somebody is going to deploy a bunch of IoT sensors that could be exploited by anyone.  They would want to deploy services based on their own IoT sensors, and thus earn a respectable return on investment.  To do that, there would have to be a way of building those services, and the thing you built them on would have to be deployed.  That’s why the early applications like NFV or 5G are important to carrier cloud; they put the infrastructure into place to host additional “service middleware” features.

NaaS is important in part because it frames a plausible if not compelling revenue model that’s based on direct evolution from operator connection services of the past and present.  The other reason it’s important is because “network” in any form is, to the network consumer, whatever isn’t on my desk, in my hand, or on my wall in my TV mount.  Whatever services we get remotely can be considered network services, and so the operator could offer them without a culture-wrenching shift.

It’s also a way to transform to a wholesale model, if that’s the goal.  Operators’ resistance to higher-level services seems to be related as much to discomfort with the retail sales-marketing model for those services as to the creation of the services themselves.  NaaS could provide operators with the appropriate experience.

If, that is, vendors provide them with the tools and guidance.  Operators in general seem to believe that they’re bombarded by two opposing forces, the network vendors who want them to stay the course and suck up the declines in profit per bit so they can keep buying gear, and the transformation players who want them to quit the connection business and compete in the OTT space.  They’re not excited about either option, for obvious reasons.  Is there a solution that they can adopt?  If there is, then the cloud infrastructure vendors, the IBMs and Dells and HPEs and Red Hats and VMwares, will probably have to step up and make that solution clear and credible.  Otherwise those hundred thousand data centers are lost.

Ericsson says it will embrace Open RAN, via its “Cloud RAN” initiative.  That’s big news because Ericsson is a bit behind others in embracing the new open model.  But Nokia is planning a restructuring that’s not getting raves from analysts, despite having taken a positive Open RAN stance well before rival Ericsson.  Just how disruptive is the Open RAN model, then?  Is adopting an open-model network a sentence of chronic business illness for network equipment vendors, preferable only to the death sentence that not adopting it would impose?  Does Open RAN have what financial analysts call “Mo”, meaning “momentum”, as some articles suggest?

From a competitive perspective, and from a margin-protection perspective, network equipment vendors who provide mobile infrastructure have focused on the notion of a unified, integrated, mobile deployment, spanning everything from the broadband gateway to the radio network, the RAN.  Even data networking giants have been disadvantaged by this vision, because they’ve lacked the necessary 3GPP elements.  The RAN is a particular problem because of the skill specialization associated with the radio network.

Open RAN (or OpenRAN, whichever you prefer) is an initiative to address the RAN piece of the open-model puzzle.  The goal is to open up the RAN elements for best-of-breed competition, by defining an architecture model with specific interface points.  Logically, then, the best response for a mobile network equipment vendor to take would be one where they could present a best-of-breed solution that’s still “open”.  Like most network standards and models, Open RAN doesn’t dictate the details of application structure, or of the implementation overall.  You’re “open” if you meet the interface requirements.

The reason this is important to operators (and so, to vendors) is that a big part of 5G capex will be in the RAN.  If capex costs can’t be managed there, then there’s a good chance that there’s not much that can be done for capex overall.  Not only that, because you need a RAN in 5G before you need much else, it may well be that Open RAN initiatives will impact the early 5G strategy of operators, and follow along into the rest of 5G infrastructure, and perhaps into network infrastructure overall.

Ericsson and Nokia both seem to recognize that the trick is to be open but not to surrender all differentiation.  Both companies have phrased their support primarily in terms of supporting the interfaces, which is essential to be “open”, but which leaves them with a lot of wiggle room for differentiating with what’s inside those interfaces.  Let me illustrate with a reference I’ve made in the past.  Google’s B4 backbone is an SDN backbone network inside a quagga BGP “emulator” layer.  The interfaces are standard and open, but how the network works under the covers is both invisible to the outside and under the control of Google.

Ericsson’s differentiation strategy might well be emerging just in the name of their approach—“Cloud RAN”.  The term is unfortunate, perhaps, because it also refers to a China Mobile initiative called “C-RAN” or “Cloud RAN” or “Centralized RAN”.  In any event, Ericsson uses the term, and they also promise that they’ll be “cloud-native”.  While we all know by now that cloud-native claims are a dime a dozen in today’s hype-driven market, it does suggest that Ericsson thinks that the fact that they’ll cloud-host their solution to Open RAN is critical.  Some of that, of course, is just riding that hype wave effectively, but there may be more underneath.  One almost-hidden piece of Ericsson’s strategy is that they do not intend to support open fronthaul.

Nokia has been forthright about the “why” of Open RAN, most recently on their earnings call, where the CEO said “Telco operators will continue to need to support massive capacity demands without commensurate cost increases. As a result, we expect capex to remain constrained as operators will look to drive a step-change in cost effectiveness…The broad trend towards open architectures with increasing virtualization will accelerate. This will be driven by cost pressures as well as the need to increase speed and agility. Adoption will vary widely and a full transition is more than a decade away, but the shift to more open interfaces, virtualization and cloudification, network function disaggregation, AI-driven automation and optimization, is well underway.”

What this translates to is an admission that because of profit-per-bit compression, operators are constraining capex until they can adopt cheaper open-model solutions.  The question is what those solutions will look like.  While 5G specs generally admit to “virtual” or “cloud-hosted” solutions, they could be applied to white-box configurations too.  AT&T, in fact, is looking more to white-box RAN than to cloud, and they’re arguably the operator furthest along in the open-model networking space.

Nokia is also focusing on “Cloud RAN” and it says it’s going to support the full suite of Open RAN, Cloud RAN, and O-RAN stuff, including the fronthaul interface.  Nokia is also very active and very vocal in the Open RAN space overall, though the fact that Ericsson had a late start may explain its less-promoting approach.  Substantively, there’s not an enormous difference in their approaches, which opens the question of why Nokia has to restructure and Ericsson (who’s doing better) doesn’t.

Part of the issue here, according to operators, has been that Ericsson is said to have superior execution.  That may be due to the fact that it had a strong proprietary product line that was available for early deals, and had strong sales engagement in no small part because the sales organization understood everything well.  Nokia’s earlier Open RAN commitment might have complicated their own engagements by introducing an open-network approach that buyers might like but that raises a lot of questions.

Paramount among those questions is whether a vendor’s open-model approach means just opening those interfaces, offering their support in their own products but not really pushing on an open strategy overall.  Could Nokia’s sales organization have inadvertently fallen into a trap with the early Open RAN story, raising the possibility that Nokia was going to take a more 5G RAN integrator path forward?  Could Nokia actually be considering that?

What I think might be the problem with Open RAN overall, right now, is that it isn’t nearly as compelling if you can’t assume it marries to “Open Core” in 5G.  We don’t have final 5G Core specs at this point, and the 3GPP is admitting that Release 17 probably won’t be available until 2022 due to a loss of effective collaboration created by the virus.  Quite a bit of early 5G effort has focused on the 5G Non-Standalone (NSA) approach, which combines 5G RAN with 4G IMS/EPC, which is not exactly open.  How a delay in Release 17 might impact full 5G Core availability, open and proprietary, is hard to say at this point.

And, of course, there’s long been a concern that many of the 5G Core features, like network slicing, might be a solution in search of a problem.  How far, and how fast, these native 5G features could drive the market will depend less on standards than on market opportunity.

What about “Cloud RAN” overall?  Nokia quotes an analyst as saying that Cloud RAN is transformational, adding things like agility and dynamism in service creation.  I think this point is one of the many in our modern tech market where what could happen and what will get a bit blurred.

Where are these new services coming from, and what’s their relationship to 5G itself?  If we presume that the services are coming from above, from over-the-top elements, then why is Cloud RAN a factor at all?  If those agile, dynamic, services are part of 5G, isn’t that the same standards set that’s not even been able to deliver on its core schedule?  How dynamic and agile can you be if you depend on standards to drive your technology, or what value is dynamism and agility in feature formulation, if your features are locked to a glacial process?

The 5G stuff we should be watching, then, isn’t the stuff from mobile vendors like Ericsson or Nokia, but stuff from players like Samsung, Red Hat, VMware, Microsoft, Amazon, Google, Rakuten Mobile, Dish, and other non-traditional players on both the vendor and operator sides.  It’s likely that both Ericsson and Nokia have supported Open RAN (and will support further open initiatives) more for objection management.  Mobile networks are ecosystems, and a traditional vendor can’t lose to a concept, they have to lose to another seller of ecosystems.  Blow a kiss at openness, and rake in the bucks while vendors who want to build on it assemble and integrate the pieces, then learn to sell them.

That ties in with operator comments that Ericsson was simply more effective at the sales level.  It’s sales effectiveness that will decide 5G winners, unless the operator buyers themselves commit to an open-model 5G network and are prepared to work with non-traditional players in non-traditional ways.  That why I’m listing all those non-mobile-vendor people as the ones to watch.  If they come up with a 5G approach that’s open, credible, and complete, then it’s going to be tough for the mobile network vendors to compete without facing significant commoditization.

What do operators think makes transformation difficult?  That’s a key question not only for operators, but for any who want to drive changes to fundamental network infrastructure principles and architectures.  There are technical elements that operators see as barriers, but the biggest ones are far more financial than technical.

I’ve gathered this information from 84 discussions with operators over a period of 11 months.  A total of 44 operators were represented, which means that I had about two discussions, on the average, with different people within the operator organizations.  All those involved were either CxO-level or senior planners.  As is always the case with these contacts, I’ve had longer-term interactions with them, and I promise full protection of identities to all involved, so they can talk freely.

The number-one barrier, one cited in every discussion I had, was residual depreciation on existing infrastructure.  Network equipment is written down at different rates in different markets, based on tax laws in each location.  On the average, operators report about a five-year depreciation cycle, which means that when they buy gear, they post the cost as an expense over a five-year period.  If they displace and dispose of a device before it’s fully depreciated, they have to take a write-down of all the depreciation not yet taken.  This write-down will impact the cost, and thus the justification, for any transformation project.

It’s clear that the presence of a lot of undepreciated equipment is a barrier to transformation, but what makes it a special problem is that networks typically evolve, so there are usually a number of devices in place at every possible stage of depreciation.  One operator said their equipment was, on the average, three-and-a-half years old, but they had a quarter of it in the final (fifth) year of depreciation and a bit less than that in the first year.  If you considered the network as having three layers—access, aggregation/metro, and core—the spread of depreciation across the three was very similar, though access networks were almost always at least slightly “newer”.

The depreciation spread is important because operators were generally of the view that it was “difficult” to displace technology with two years of depreciation remaining, and “almost impossible” to displace something with four or more years remaining.  Since none of the access/metro/core network segments were made up primarily of assets with two or fewer years of depreciation remaining, it was difficult to target a transformational change that wouldn’t involve “almost impossible” write-downs.

This raises the question of how transformation could ever be accomplished, of course.  One possible answer is the greenfield deployment of mass technology related to a basic change in the network.  5G is the example every operator gives for this kind of driver.  When a new service mission comes along, that mission drives greater willingness to displace technology, in no small part because the budget for the mission will include write-down of obsolete assets.  But this raises the second-most-cited barrier to transformation, lack of a strong profit incentive to justify new service missions.

Almost half the operators who have deployed 5G already, or who are scheduled to deploy within the next year, say that their deployment plans are hampered by the lack of a clear profit direction on the service decision.  All operators who are 5G or 5G-ready say that “competition” is either the primary or second-most-significant driver.  The next-highest-rated driver is “enhancement to current mobile network capacity”.  Expected new profits on 5G services is ranked third.

This is important because every single operator discussion demonstrated a view that since 5G “mandates” a transformed model of networking, broad adoption of 5G would have the effect of driving transformation through more of the network.  It also demonstrates that vendors who offer 5G have a better chance of engaging than those who do not, since there were no other new service missions with any significant credibility at all.  This, of course, is already known by vendors, and it’s why there’s such a furor around 5G positioning, not only for traditional network vendors but also for cloud-software and public cloud providers.

We now get to the first “technical” barrier to transformation, one cited by over three-quarters of operators as an “important” issue.  Loss of technical and operations continuity without compensatory features to address it, to operators, means that transformed technologies involve changes to network planning and operations practices that aren’t offset by capabilities provided by those technologies.  It was a bit surprising to me to hear this point stated this way; I’d expected them to say that “service automation” was a key goal and wasn’t being provided, but operators say service automation is an overall strategy (see below) and not an element of a transformation project.

This issue is most likely to arise in what we could call “point-project” introduction of new/transformed network infrastructure.  Router A is at end-of-life, so why not replace it with Transformed-Router B?  The problem is that the introduction of a single device within a web of legacy network elements has little chance of presenting any benefits and a significant chance of disrupting operations.  Interestingly, operators noted that this is one of the reasons why it’s so hard for a new router competitor to displace the incumbent vendor.  Absent a broad service mission change to drive broader change, you’re stuck replacing boxes, and for that, it’s hard to justify a vendor change.

This problem seems almost insurmountable to operators when considering virtual-infrastructure transformation.  The problem is that hosted features mean cloud infrastructure, which almost inevitably means major changes in operations and planning.  A bit over two-thirds of the operators indicated that they found technical/operations planning and continuity a “major issue” with NFV, and why they believed that the ETSI zero-touch automation initiative really got launched.  Without service automation to take up the slack, it’s easy for integration and operations changes to create so much disruption that opex costs override capex reduction benefits.

Most operators don’t believe that we have an effective service lifecycle automation approach; only about a third thought that the ONAP model was workable, a quarter thought some TMF initiatives were the way to go, and the rest really had no useful notion of how to proceed.  This was (according to that group) the primary reason why they favored “white-box” networks as a transformation vehicle.  With white boxes, the operations could be presumed to be more or less equivalent to traditional operations and integration.

That brings us to what I’ll call the “technical strategy” issues, which really represent the basic approach operators might take to transformation.  The first of these, the service mission change has already been talked about.  The other two are the opex-driven transformation approach and the white-box transformation approach.  We’ll look at these now.

If the service mission change represents a revenue-side justification for transformation, the opex-driven transformation is obviously aiming at operations costs.  For the average operator, opex represents almost the same number of cents per revenue dollar as capex does, and when NFV came along, many believed that service lifecycle automation could eliminate the “opex tax” that the additional complexity of chained-virtual-function deployment and the maintenance of the hosting resource pool would necessarily generate.  One reason why operators have expressed so much interest in hosting 5G on public cloud resources is their concern over this opex tax.

Opex reduction strategies have other important backers.  Current router incumbents like Cisco and Juniper are lining up in favor of an opex-centric transformation because it doesn’t reduce their revenues.  In fact, by selling products (like AI enhancements to operations), they hope they might actually increase revenues.  The challenge here is that these strategies so far fail the “D4P” (Design for Prevention) test I blogged about last week.  It may be that the Juniper acquisition of 128 Technology was aimed at least in part at improving their AI/automation model.

The flip side of opex is capex, and the white-box transformation model is the poster child for capex-driven transformation.  About a quarter of the operators in my informal survey have taken a serious look at this, but commitment is still the exception.  AT&T is the only major operator who has endorsed, and actually deployed, a large-scale white-box-based network.  The majority of that network is deploying on a 5G-related mission, but they also recently announced a transformation of their core to white-box clusters provided by DriveNets.

The operators who are still dipping their toes in white boxes, so to speak, are deterred primarily by the broad question of risk versus cost impact.  Estimates of savings attainable via white-box adoption vary from a low of 25% to a high of 50%, and these generally assume minimal increases in opex related to the change.  There’s also at least some indication that operators are using white-box networks as a way of squeezing discounts from their incumbent vendors.  Even if they’re serious, operators appear to require a fairly significant study period in which to become comfortable with the white-box strategy, and a big part of it is aligning their current business, operations, and network management frameworks to the new model.

This alignment problem is currently the largest barrier to adoption of white-box technology, for two reasons.  First, it raises the risk that new operations tools and practices, including service lifecycle automation, will be required to prevent opex costs from overrunning the capex benefits.  Most open-model, white-box, solutions don’t as yet have full operations solutions.  Second, because current practices are set by router incumbents, it tends to put the white-box providers in direct conflict to the router vendors from the start of the engagement.  This changes the point of interaction from the strategic level, where executives who actually have purchase authority live, to the technical level, where router-certified technologists confront the impact of not-router on their own careers.

These two issues have impacted nearly all new operator technology initiatives, and you can see the results in deployment successes.  For projects with low-level initiation, meaning modernization and replacement initiatives driven largely by network operations, only 6% of new technology trials advance to production network deployment.  For projects with senior-level personnel driving consideration, 63% achieve production deployment.

We can say that, overall, transformation is deterred by risk/reward questions.  What contributes to the risk side are concerns about technology change, the need to trust new vendors, the lack of a clear architecture for the new network ecosystem, the need for a high first-cost commitment, and low in-house skill levels with the critical new technologies.  Risks are objections at the low level of an organization, and to overcome those “risks/objections”, vendors tend to try to underplay the changes they’re proposing.  Every white-box proposal I’ve seen has emphasized the similarity/congruency between white boxes and proprietary routers.  The problem with “subtractive” risk management is that the benefits are subject to subtraction too.  In fact, these kinds of proposals always end up in a discount war, where it becomes all about price.  In the end, the incumbents usually discount enough to win.

And that raises the biggest difficulty of all, a difficulty that operators don’t really mention.  Transformation usually doesn’t present enough clear benefits to make a business case.  The goal of transformation loses steam in the realization.  A big part of that is due to the fact that operators think of transformation as the elimination of a hazy problem of profit-per-bit compression.  Hazy problems begat hazy solutions, and you can’t buy those, you can buy only concrete products.  When you try to make transformation into a series of project steps, the steps don’t convincingly deliver the operators from that fear of profit compression.  Usually because transformation-oriented vendors end up, as I’ve said, focusing on simple cost differences.

Transformation, overall, occurs when you have a transformational technology that can combine with a transformational mission that justifies it.  It seems to me that if we assume that there are no credible transformational service missions from which operators could derive significant new revenues, it will be difficult to sustain momentum on transformation, even if it can be started.  Cost-driven transformation can only wring out so much from the cost side of profit-per-bit compression.  The revenue side must eventually play a role.

That’s why we need to keep working on this problem.  Operators have all manner of hopes about new revenue, but for the great majority, there’s absolutely no credible reason to believe in them.  One reason I’m so enthusiastic about the network-as-a-service model I mentioned in a blog HERE, is a that an aggressive NaaS positioning could transport some features, value, and revenue from the over-the-network space to the network itself.  NaaS is, in a real sense, potential “service middleware”, allowing operators to build components of higher-level service rather than competing with established players in that OTT space.  While this may not be the easiest thing to conceptualize or develop, it has the advantage of keeping revenue targets in the service comfort zone of the operators.  That may be the critical requirement if anything useful is to be done.

Over the years, we’ve had many different protocols, but the interesting truth is that within each of them, there’s a common element—the data.  Whether we’re transporting information in IP or SNA or DECnet or X.25, we’re still transporting information.  The protocol isn’t the information, it’s just a contextual wrapper that defines the rules for exchanging the information successfully.  If we accept that, then we have the beginnings of a truth about the way future networks might be built.

Let’s start with a reality check here.  Nobody is trying to get rid of IP or the Internet, as they exist as end-user services.  What they’d love to refine, or even get rid of, is the baggage associated with IP and router networks.  If you look at how IP has evolved, it’s hard not to think of it as being a very long way around the track to repurpose a protocol for stuff that was never even considered when the protocol was designed.  What we do with IP today is deliver multimedia content, support mobile users, and neither mission really existed back in the days when the protocol was invented.  The thing is, everything in a commercially useful sense that consumes data today is an IP device.  We have to do whatever we do to networks without impacting what uses the networks.

IP as an interface isn’t the same thing as IP as a protocol, and that’s not the same thing as IP as a network architecture.  IP networks are built with routers, which are purpose-built devices that talk not only the user IP interface but also “internal” interfaces that include features not made visible to the user at all.  One big problem with this model is that it’s difficult to advance features quickly or incrementally because the routers have to be upgraded to do it.

One of the big areas where network operators want to add features is in the area of traffic engineering.  Another is in fault recovery.  Both these were drivers behind the original concept of software-defined networking, and SDN started with the presumption that we’d accomplish IP advances by first separating the control and data planes.  The data plane would carry only end-to-end information, and all the rest would be pulled out and handled “over top of” the data plane.  Today, we’d say that “the cloud” would handle it, but in the original SDN approach (still the official one) it’s handled by an SDN controller.

A lot of people would say that a control plane in the cloud isn’t much of a leap beyond the centralized (and vulnerable) SDN controller concept, and that could be true.  “Could be” depending on how the concept is implemented.  Recall that I blogged a bit ago about “locality” as opposed to “edge” in considering the placement of computing resources.  A few people on LinkedIn have also noted that separating the control plane by simply hosting it somewhere on a potentially vastly distributed set of servers might not be optimal in terms of latency or stability.  I agree; there has to be a new way of thinking about the cloud if you’re going to deploy the IP control plane there.

In my blogs on the topic (especially the one referenced above), I noted that the missing ingredient in “telco-oriented” cloud computing was the notion of “locality”, meaning that some microfeatures had to be hosted proximate to the point of activity they served.  Something supporting Interface A on Device B has to be close to where that happens to be, if the “support” is expected to be near-real-time.  A randomly chosen resource location could be a disaster.

It follows, though, that if you’re actually going to have a “cloud” at all, you have to pull the microfeature-hosting resources from the device and place them nearby.  It would also be logical to assume that the operation of a control plane, especially the supercontrol-plane that I postulated as a combination of all service-coordinating features, would include microfeatures that wouldn’t be as latency sensitive.  Thus, we’d need to be able to ask for resources proximate to the point of activity but not joined at the hip to it, so to speak.

The point here is that “separating the control plane” and “virtualizing the control plane” aren’t the same thing.  If control planes did nothing beyond what IP itself requires, you could see that the implementation of a cloud-hosted control plane would likely involve a kind of local interface process set, resident with the interface in some way, and a topology-and-management process set that would be distributed.  The where and how of the distribution would depend on the implementation, which means that we’d need to think about how this new supercontrol-plane got implemented in order to decide where the microfeatures that make it up could be placed.

From what Google has said about its use of this approach in its B4 background, we can infer that Google saw separating control and data planes at least in part as a means of simplifying what goes on with IP, MPLS, and optical networking.  Each of these has its own control plane, and in a traditional large-scale application of router networks, each would be part of a layer stack in the order I referenced them.  Google, in B4 itself, didn’t integrate higher-layer services into the picture, because B4 was an IP backbone.  In the broader Andromeda application, which includes Google’s B2 interprocess network, they do network microfeatures directly.  The relationship, if any, between these two isn’t specified.

That may not be the best way to approach a commercial solution to optimizing the separate and supercontrol-plane concepts.  For that goal, it would be best to either integrate commercial tools (Kubernetes, Istio) to create a microfeature framework, enhanced to support locality, or to create a high-efficiency version of the two for specialized network microfeature applications.  This would be best done by integrating it with the architecture that separates the control plane in the first place, meaning the emulation of IP networking.

The role of B4 in flattening the IP, MPLS, and optical layers is an interesting topic in itself.  We’ve tended to treat layers as not only inevitable but mandatory since they came along with OSI in 1974, but that was then and this is now.  Is a layered approach really the best way to run networks today?  For example, if we have dynamic optical connectivity and dynamic connectivity at Level 2 or 3 or both, and if we have “control-plane” processes that can manipulate features at all the levels, are we really looking at layers in the OSI sense?  Are all the higher layers of the OSI models now subsumed into a supercontrol-plane approach?  That seems to be the goal of B4.

It may seem a radical thought, but it’s very possible that we’ve outlived the usefulness of layered protocols.  While the OSI model defined seven layers, those layers are divided into two “zones”, one (Level 1-3) representing the connection network and the other (4-7) the application relationship, meaning end-to-end.  We’ve seen the world focus its attention on IP-based connection services in the first zone, and we’ve seen the second zone compressed by things like 3GPP specifications, which create an interface point between a “network” and a “service”, meaning between the two zones.  In both cases, the specifics of the zones themselves seem to be getting lost.  Maybe, in fact, the zones themselves are starting to mingle.

What I think is happening is that we’re entering (perhaps unwittingly) the age of network-as-a-service, and what NaaS is a service to is applications, meaning software.  For those who need an OSI lesson, the Application Layer was the 7^th of those OSI layers, the top of the stack.  If NaaS presents a Level 7 interface to applications, then the entire OSI stack is subducted, invisible.  Present the right API at the NaaS top, and Tinker Bell can carry packets on little silver wings for all we care (as long as she can meet the SLA).

NaaS, as a conception of delivered services, could free network infrastructure from strict conformance to IP behavior, even if the service delivery is made in an IP envelope.  Networks composed from microfeatures can have a variety of internal properties as long as they present the proper NaaS interface(s) at the top.  Are some of the challenges we have in network virtualization due to the fact that, by “virtualizing” router networks, we’re also codifying routers?

For service providers, network operators, NaaS could be a windfall.  The absorption of higher-layer features into “network” services lets them climb the value chain via a familiar ladder.  Connectivity is expanded to include application-specific elements—4G and 5G mobility-to-data-plane interfaces, CDN, data center interconnect, IoT services, you name it.  If the “service” serves applications directly, then a lot of application features that would benefit from as-a-service implementation can be absorbed into the service.  This might be the pathway to new revenue that avoids direct collision with the current cloud providers and OTTs.

Again, this doesn’t mean the death of IP, because network connections still require network services, but it does mean that the network could become (as I’d argue it has for Google Andromeda) almost a byproduct of a microfeature-connection architecture, an architecture that isn’t protocol-specific, but interface-defined.  I think that things like SD-WAN, SDN, and Andromeda are leading us in that direction, and I think that a shift of that sort could be the most radical change in networking that’s ever been considered.

It could also be fun; many of those who fought the transition from TDM to packet would have to admit that their lives have gotten more interesting under IP, in large part because IP is less constraining to applications.  NaaS could remove all constraints, both to applications, and perhaps to fun as well.

What the heck is an NGOSS?  I’ve used the term a lot, relating to the “NGOSS Contract”, but for those not familiar with the OSS/BSS space or the TMF, it may be mysterious.  Tata Consultancy Services, a large and active professional services firm, recently did a paper on “reimagining” the OSS/BSS, a TMF paper asking whether there’s life beyond connectivity services.  There are interesting contrasts and similarities between the two documents, well worth exploring.

NGOSS stands for “Next-Generation Operations Support System”.  It’s a term that’s been widely used for at least 15 years, and it’s often used by the TMF in their specifications.  A lot of the TMF stuff is members-only though, and so I can’t cite it (or, if I’m not a member at the time, can’t even access it) except by summarizing.  The TMF paper is particularly helpful because of this; it’s a public summary of the way the body sees the future of “transformation”.  The Tata paper is interesting because it reflects a professional-services view of the same process of transformation.

The opening of the Tata paper has the usual platitudes about bandwidth.  “As businesses increasingly adapt to a predominantly online model in line with the new reality, the need for high bandwidth and reliable network services is soaring. Consequently, communications service providers (CSPs) are experiencing exponential demand for services and are dependent on progress in virtualization technologies to continue scaling at current rates.”

The problem with this, besides it’s platitude status (one more “exponential” demand statement and I’ll puke), is that the real issue isn’t demand growth, it’s profit shrinkage.  No operator would be unhappy with growth in demand for bandwidth, if they could charge incrementally for the growth.  They can’t, so they need to either find something other than bandwidth to sell, or cut the cost of producing bandwidth to offset the fact that higher bandwidth services don’t generate proportionally higher prices.

This same issue colors the next section, which is called “Rethinking the OSS Function”.  It cites TMF objectives for OSS modernization, none of which even imply dealing with that profit compression problem.  In fact, that section of the document is why a lot of operator strategists are in favor of scrapping the whole OSS/BSS thing and starting over.  It’s not that no useful goals are set (automation is one of the attributes of a future OSS/BSS), but that nothing much is said about achieving them.

That comes in the next section, which is called “Driving Well-Orchestrated OSS Functions”.  This section finally makes a recommendation that’s useful; OSS/BSS has to be made event-driven.  I had hopes here, because the TMF was in fact the source of the key concept in OSS and operations automation—that NGOSS Contract I mentioned at the start of this blog.  Sadly, neither the term nor the concept is raised in the Tata paper.  What it says is that “future OSS functions must be created and offered as services composed of microservices to support automated end-to-end orchestration of hybrid (physical, logical, and virtual) network resources.”

The TMF paper, in contrast, opens with the statement that “connectivity is rightly seen as a low margin business and is rapidly commoditizing further.”  The goal of operators is “getting their interior world right with an agile technology foundation and operating model.”  The TMF obviously includes its primary OSS/BSS target in this interior world, but just as obviously the agile technology foundation has to extend to infrastructure.

The mechanism of getting their “interior world in order” is, by implication, 5G.  The TMF says that it’s critical in order “to make the most of the hugely expensive shift to 5G.”  But that seems to be contradicted by the next paragraph, where the former CEO of the forum says “For consumers and smart home individuals, ‘connectivity’ tends to have an intrinsic value and is a valid thing to be purchasing. As you go up the scale, however, into the industry transformation realm, connectivity is only valued in so far as it is tied into the solution: “They don’t want to buy connectivity from you, they want to buy a solution.”  5G is clearly a connectivity strategy for consumers, as all mass-market infrastructure is.  If we presume that to “go up the scale into the industry transformation realm”, meaning business services, the key is to sell solutions.

This seems to argue for the operators to focus their “digital service provider” business on enterprises, and to provide solutions there is to be a SaaS provider.  Is that really a smart approach, given that there’s a highly active and competitive public cloud business already selling solutions to those customers?  Especially when the majority of the profit-per-bit problems operators have comes from all-you-can-eat consumer services?

The resolution, says a Vodafone quote and other comments in the TMF paper, is that “what we now call ‘services’ won’t involve the telco alone, but will comprise a range of partners, including the telcos.”  Thus, the telcos aren’t really digital service providers at all, but digital service integrators or resellers.  Can a business that’s looking at transformation as a means of escaping profit squeeze afford to be a reseller of another player’s services?

It seems to me that the TMF vision is really not aiming beyond the OSS/BSS at all, but rather is suggesting that operations and services evolve to something above connectivity by partnering with those who supply services up there.  That could be defeating the whole purpose of “digital transformation”, locking the telcos into not only their current level of disintermediation and commoditization, but also in a whole new level.

Both papers seem to suggest that OSS/BSS transformation is essential, and at least imply that an event-driven approach is the answer.  That’s actually a good idea, but it misses the challenge of “how?”  In order to be event-driven, a system has to recognize both the concept of events (obviously) and the concept of “state” or context.  Anyone who’s ever looked at a protocol handler knows that the same message, in different contexts/states, has to be processed differently.  For example, getting a “data packet” message in the “orderable” state for a service is clearly an error, while it’s fine in the “data transfer” state.  For there to be states and events and related processes, you need a state/event table.

State/event tables are descriptions of the collective contexts of a cooperative system, and thinking about building them is useful in that it forces software architects to consider all the possibilities, instead of having something happen that falls through the cracks.  However, there’s a potential conflict between the value of state/event tables and the number of possible states and events.  If you look at a complex network as one enormous, flat, system, you’d have way too big a table to ever implement.  The TMF and my own ExperiaSphere work dealt with this by dividing complex systems into “intent models” that each had their own state/event relationships.  Hierarchical composition, in short.  That’s what NGOSS Contract described.

The point here is that both papers miss what should be its own strongest point, which is that data-model-driven steering of events to processes via component-aligned state/event tables is the way to create both event-driven behavior and microservice-compatible design.  If a service data model drives an event to a process, the process can get the information it needs from the service data model alone, which means it’s stateless and can be deployed as a microservice or even in serverless form.

If you pull the NGOSS-Contract approach out of the OSS/BSS modernization story, you’re left with the thing that has plagued the whole notion of OSS/BSS modernization from the first—platitudes.  We can talk about bottom-up and top-down as long as we’re focusing on project methodologies, but a project methodology drives a project, it doesn’t write software.  A software architecture should emerge from the methodology.  That’s a separate element, a result of the right process, but it’s not the automatic consequence of waving a wand over a bunch of data and chanting “top-down, top-down!”

That sums up my problem with the Tata paper.  Project methodologies in IT and networking lead to application or service architectures, which then frame the requirements for the components of the solution and the way they’re integrated and managed.  The project is not the output, it’s the path to the output.  The problem with the Tata paper is that it’s yet another description of a project methodology (a good one, but not a transformative one), at a time when we’re long past looking for a path to OSS modernization and instead are looking for specific products, or at least architectures.  The TMF seems to be heading to the same place by a different path—transform by partnership with your former enemies.

The Tata paper does, in the section called “The Role of Industry Standards”, call out an important problem, one so important it might actually be the barrier to progress toward the OSS modernization goal.  The paper cites the TMF and ONF models for top-down design, but throughout the paper it’s clear that the “modernized” OSS/BSS has to be more tightly integrated with the rest of the network and service ecosystem.  We have standards for every possible piece of every possible network strategy, and in some cases the standards even compete.  We recently heard applause for the unification of two different operations API specifications, for example.  We should be asking how we came to have them in the first place.

The TMF paper seems to not only accept this fragmentation of the future, but depend on it.  Cede the mechanization of stuff beyond OSS/BSS, and focus on harnessing that “beyond” stuff to create services as a pseudo-integrator.  OK, that may not be an unreasonable view for the TMF (an OSS/BSS-dominated body) to take, but it’s a formula for staying disorganized while facing what almost has to be a unified initiative—transformation.

It’s my view that the TMF was the logical body to modernize the OSS/BSS, and that the TMF did (with NGOSS Contract) devise the central paradigm of event steering to processes via a data model, that’s critical to this modernization.  Everything else the papers describe, every API anyone is developing or harmonizing, every standards activity aimed at any aspect of operations and management, should be fit into that NGOSS Contract framework.  If that were to be done, the result would be exactly what “NGOSS” stands for.

The model of the TMF NGOSS Contract is just as valuable, or even more valuable, if you step into the network domain.  A true “contract” state/event process could manage everything about the service lifecycle, including the network piece.  It follows that a network-centric solution could easily be extended into the service, the OSS/BSS, domain.  The universality of the approach is good for the industry, because service lifecycle automation should be universal to be useful.

It should also be based on state-of-the-art cloud-think.  Both papers seem to agree with that, and yet both skirt the question of how to bring that about.  If you’re planning to use current tools to accomplish something, you have to frame your approach in terms of those tools.  You can’t accept the notion that you can write specifications for everything, or simply translate goals at the top to arbitrary features at the bottom.  That’s especially likely to bite you given that the standards processes take years to come to a conclusion.  We’re deploying 5G today and the standards aren’t finished, and likely won’t be until 2022.  I wonder if there’s time for that stuff, given that operators are already facing falling infrastructure ROIs that are nearing the critical point.

NGOSS Contract has been around for about 13 years now, and the TMF once told me that it had gained very limited traction.  It doesn’t seem to be played in the current TMF material, though as I’ve said, I don’t have access to the members-only stuff.  The question, then, is whether the TMF is prepared to promote its own (dazzling and unique) insight, first within the narrow OSS/BSS domain and then in the broader lifecycle automation mission.  If it does, the TMF takes its rightful role in NGOSS evolution and defines the basis for service lifecycle automation overall.  If it doesn’t, the it will be up to some other standards body or open-source group to pick up the torch, and the TMF will then have to fight for relevance in its own space.

Did Juniper pay too much for 128 Technology?  That’s a question that’s been raised by some financial analysts, by some who hold Juniper stock, and by at least one industry pundit, HERE.  It’s not unusual for some to question the value of an acquisition like this, particularly in an industry that’s not been a dazzling success at exploiting the M&A they’ve done.  It’s a good thing, in fact, because the best way to prevent failure is to understand that it’s possible.

Since I blogged that the Juniper deal for 128T was a smart one, it’s important that I have a response to criticisms of the deal, not only to justify my view but also to guide the two companies toward the symbiosis that could make the deal a great one for all involved.  I’ll do that by looking at the article and dealing with its comments.

To me, the article is questioning three points that justify the deal, and the implication that the justifications aren’t compelling.  Let’s look at them, then, first as a list, and then in detail.  The first is that the 128T deal is part of Juniper’s desire to be more software-centric.  Second, it’s a way of exploiting the SD-WAN market, which has a very high growth rate.  Finally, it’s because 128 Technology’s smaller compute footprint makes it an ideal SD-WAN solution.

If anyone out there doubts that networking is getting to be more about software than hardware, they’ve been living in a time warp.  AT&T made a public decision to move to white-box-and-software networking a couple years ago.  Even the 3GPP standards, never ones to be on the leading edge of technology shifts, embraced a virtual implementation.  OpenRAN is software-centric.  It would be truly frightening if Juniper didn’t think it needed to think more about software, but the fact is that they’ve been doing that for some time, and so has arch-rival Cisco.  I don’t think that they’d use the “we-are-software” argument to justify a deal like this, but let me get back to this point.

OK how about the SD-WAN market, which the piece says is growing at a CAGR of 34%.  Could Juniper be jumping onto the 128T bandwagon to get a piece of the action?  Actually, Juniper had an SD-WAN solution already, but it certainly wasn’t something that was sweeping the market.  The biggest consideration, though, isn’t as much to grab a share of the market, but to track where the market is going.

SD-WAN is a terrible name for a market that’s actually evolving to be something very much more.  My own regard for 128 Technology was based on its potential for that “very much more”, which is (and was) “virtual networking”.  The majority of SD-WAN products and services don’t do anything more than connect small sites to a company VPN, or perhaps offer some cloud networking.  That’s shooting way behind the market-evolution duck at this point.

Networking has never been about sites, it’s always been about people.  Companies pay to make workers productive, and because workers are concentrated in workplaces, we networked workplaces.  The thing is, the goal was never to make networks about sites or traffic, but to make networks about facilitating relationships, relationships between people, between people and applications, and even between application components.  If you read what I’ve said about 128 Technology, that’s what they do, and what they’ve done from the first.  That’s their strategic story.

Which leaves us the last point.  The article quotes Andy Ory, co-founder and CEO of 128 Technology, saying ““What separates us from every other SD-WAN player in the world is that we have a much, much smaller computational footprint and we leverage the underlay. We don’t instantiate really costly, computationally expensive tunnels.”  If this is their true differentiator, it means that 128T offers better plumbing, which might not be a great basis for a deal with Juniper.

It isn’t the true differentiator, in my view.  From the very first, well over two years ago, I pushed back on even 128 Technology’s own quotes and stories about “lower overhead” and “no-tunnel” differentiation.  The reason is that to take SD-WAN into virtual networking, those aren’t the right drivers.  The key to 128 Technology’s value is session awareness, as I’ve said from the very first.  There is value to lower tunnel header overhead, and to lower compute overhead in terminating tunnels, but the value is derived because of the limitations that high overhead could impose on session awareness.  Without session awareness, those other points are like arguing over plastic or copper pipe in the wastewater plumbing mission.

A session is a relationship, a communications path that carries some kind of value.  For enterprise applications, sessions represent information flows that support (in some way) worker productivity.  They are why we have applications, why we build networks, because without them we can’t deliver information to information consumers and enhance their productivity, their value.  Sessions are, in the OSI model, a “higher layer”, and in the OSI model, we often forget that the lower layers (including Level 2 and 3 where all the attention in networking is focused) are just plumbing to carry sessions.

Every application access is a session.  Every video you watch is a session, and so are your Zoom conferences or VoIP calls.  Given that sessions are the foundation of network value, you could almost be justified saying that something that was aware of them, could handle packets based on that awareness, had to be better than something that wasn’t, and couldn’t.  You don’t have to, though, because there is solid value to both session awareness and session-based handling.  If Mist AI is about optimizing, then what better goal to optimize toward than sustaining the combined value of sessions?

The quote that sums up the piece is this: “Raymond James analyst Simon Leopold reflected my thinking, saying the deal was expensive but that Juniper pretty much had to do something to stoke growth in its software story.”  I can’t understand that view at all.  Most enterprises probably wouldn’t even classify SD-WAN as “software” since they’d get it delivered on a device.  In any event, there is no network company on the planet who has a “software story” in a cohesive sense, because there’s no cohesion to network software.  Finally, if all you want is software, simply adopt some open-source tool and sing like a bird in front of the media.  The whole “software” story for network companies was pushed out by stories, not by network companies.  They’re just going with the flow while they work feverishly behind the scenes.

Toward what goal?  What network companies are trying to do is to reduce their dependency on proprietary appliances, things like switches and routers.  They’re doing that because switches and routers are the target of buyer initiatives to reduce cost and vendor lock-in, in a market that seems to buyers to be demanding higher prices when there’s no compensatory higher value obtained.  White-box switches and open-source software are eating what we could call “vanilla” routing and switching, because everything with a static feature set gets commoditized.  There is now, and there never has been, any escape from that.

That means what you need is a dynamic feature set.  Dynamism, though, has to mean changing in the right direction, not just blowing hype waves out of your PR department.  If there is a right direction in networking today, it’s maximizing the application of resources, and the response to problems, based on the revenue associated with what’s being impacted.  That’s just another way of saying “session awareness”.  If you know what relationships a session is supporting, and if you know what sessions make up a particular assembly of “traffic” that needs handled, you know the value of the traffic and how to trade resources against it.  Juniper’s Mist AI platform is all about using AI to manage networking.  Wouldn’t adding session-awareness to that be a big step forward for Mist AI, and for Juniper?

The last sentence of the piece is “Long-suffering Juniper investors may now have to look out to 2022 to see the elusive boost in earnings and growth.”  If the article is correct, and if Juniper is doing the 128 Technology deal to get a “software story”, they could be right.  I’m hoping, and in fact I’m predicting, that the story is really about session awareness.  I’m also hoping that Juniper is as insightful about the potential of 128T’s stuff as they could be, need to be.  That they might not be is the biggest risk to Juniper’s investors, not the deal.

There’s an alternate story here, another possibility for the ending that the ending; “long-suffering Juniper investors” may now have a credible path to the differentiation that the securities analyst told.  One that could lead them to a boost in earnings, growth, and share prices.  A path they’re never going to have if they keep hunkering down to defend the box business or mouthing silly platitudes.  I’m not saying that this is a slam dunk; Juniper doesn’t have a good record on M&A, and because there are financial analyst mutterings about the price, it’s incumbent on Juniper to deliver some clear value here.  But this is the most promising thing Juniper has done so far, period.