Category: Uncategorized

I’ve done a couple of recent blogs on the elements of “contextual” services, and drawn on driving and walking as examples of places where they could be applied. This can, I learned, lead to intermingling the notion of “contextual” with another term, “autonomous”, and I want to clarify the separation.

“Autonomous” is a popular term these days, and it’s usually related to what might also be called “artificial intelligence”, but with a more specific focus. “Autonomous” seems to mean “the ability to do things in the real world without direct human control, but presuming some supervision and intervention.” We have relatively little high-level material available on the topic, even though one form of it (robotics) has been around for decades. I actually diddled around with robotics then, and since then, and I want to offer my own views of the subject of “autonomy” and how it probably needs to be implemented. I also want to tie it to artificial intelligence and even metaverse concepts.

To me, an autonomous-something starts with the presumption that there exists a “something” that’s controlled directly by humans. That’s obviously true of autonomous vehicles, for example, and from the first I’ve believed that the best way to address the design of something autonomous is to start with the human-controlled version, and with how human control works at a fundamental level. This latter thing can be understood best by looking at the ultimate human-controlled thing, the human.

When I started looking at this problem in the 1990s, it was my view that we could divide our “control system” into three layers. At the top was the mission layer, which represents the overall goal. “I’m driving to Cleveland” is an example of a mission. Next was the action layer, which determined what to do when the mission interacted with the perceptive process layer that paralleled and fed all three layers. “I’m turning on to the Pennsylvania Turnpike” is an example of an action. The final layer, also linked to the perceptive process layer, is the reaction layer, which represents imperative overrides of mission and action based on perceptions. “The car in front of me has stopped suddenly” is a reaction-layer issue.

My assumption was that the layers interacted among themselves, but I later decided that this interaction could only take place between adjacent layers (for those that followed my ExperiaSphere project, that’s why I specified that objects could only interact with subordinate/superior objects in the hierarchy). Interactions with adjacent layers, and the perceptive process layer that was adjacent to at least the action and reaction layers, could trigger the need for a control process.

The easiest way to understand this is to take something like our drive to Cleveland as an example. The mission layer here would be where trip and route planning took place, meaning that this is the layer that knows at the high level where we’re going. The mission layer, at the start of the trip, would signal the action layer to undertake the first portion of travel, meaning to the next point where action (a turn, for example) would be needed. At that point, the action layer would be signaled to make the turn (with adequate warning, of course). The trip, signaled as a number of specific “legs”, would complete using the same sequence.

It’s possible that traffic or road construction, signaled to the mission layer from the perceptive process layer, would require restructuring the route. In that case, the mission layer would send a new leg to the action layer, and the route change would then control movement.

At this point, our autonomous vehicle would look exactly like a human-driven car with a GPS. Where things get complicated is where our perceptive process layer signals the reaction layer, and there’s more to that than not hitting the car in front of you.

The highest priority behavior in an autonomous system is damage prevention and control, and obviously avoiding something falls into that category. Hitting the brakes is an obvious response, and in many cases would be an automatic assumption. However, how about if conditions are icy? Suppose that there isn’t time to stop at the current speed? We could assume that road conditions, stopping distance, and so forth could be used as input to a decision process. Even maneuvering might be automatic providing that the vehicle had “situational awareness”, which is clearly a product of a sophisticated perceptive process layer. I envision the reaction layer maintaining a list of possible reactions based on that situational awareness, including what do do for a flat, how to steer safely off the road, and more.

Obstacles aren’t the only complication either. Suppose you can’t make the next turn because the road is closed, but there’s no real-time notification of the sort that GPS systems get (or Waze delivers through crowdsourcing)? Could we have a computer vision system sophisticated enough to interpret a road-close condition? Eventually, probably, but in the meantime what’s needed is human input. Either a human signal that the road is closed (given verbally perhaps) or a situation where human control overrides the next action would be required.

Even terrain has an impact, and particularly if your autonomous-something is an anthropomorphic robot or an off-road vehicle. You have to regulate speed in general, but your perceptive process layer may also have to measure incline, bumps, etc. The more input you can get on conditions from an external source like a GPS and map, the better.

A final perceptive process layer requirement is addressing a malfunction of some sort. Things like loss of engine power, a flat tire, or other vehicular issue are fairly routine happenings, but the response to one of them would be similar to the response to an obstacle, qualified by taking into account the possible impact of the malfunction on the maneuvering required. It’s also possible that the autonomous-operations system itself could fail, and a complete failure would require a failover to manual operation. To avoid that, I presumed that each layer in the process described would be implemented by an independent device connected via a local interface, and that every layer would have to be able to take action based on cached information should one of its adjacent layers fail.

As I dug through the details of how this might be implemented, I realized I needed another layer, which I’ll call the “autonomic” layer, to abstract the actual motion-creating hardware systems from the higher-level structure. Without this, things become too brittle if you have to make changes in the hardware systems. You also need a “perception abstraction” layer to do the same thing for the perceptive process layer, to account for changes in sensor technology and the way you’d receive information from the outside.

What about “the outside”? Could we assume that autonomous operation was a cloud or edge computing function? I never believed that; you really need most of the intelligence resident locally to ensure that something awful doesn’t happen if you lose connection with the outside world. I think that you’d have to assume a local map and GPS were available, that current conditions (from the perceptive process layer) were cached to use as a last resort.

Does this all sound complicated? It sure does, because it is. It illustrates that true, full, autonomy in vehicles is likely to lead to safety issues, because it’s not possible to make the systems truly autonomous with current technology limits, particularly given the need to be fully redundant at all levels and to ensure that a fallback to human control is always possible. The value of an autonomous vehicle that needs a driver is limited, and if the vehicle is supposed to be autonomous then what are the chances that any driver involved is alert enough to take control in an emergency?

What was missing in my robotic experiments was the way of dealing with complexity, and that way is where new concepts like AI and the metaverse could play a big role. AI can support two important things, optimization and anticipation. When we move about in the world we live in, we instinctively optimize our decisions on movement and even body position to the situation. That optimization has to take into account our own capabilities (and limitations), the situation of the moment, and the way we see that situation evolving in the near term. That’s where anticipation comes in; we look ahead. You can’t catch a ball or dodge an object without having the ability to project where it’s going.

The metaverse concept is just as important, because effective AI means that we have a model of the aspects of the current real-world situation and can use that model to forecast what’s going to happen, and even to manage our optimized response. We could model the path of a ball, for example, to show whether it would intercept an autonomous element or not. Whether our goal was to catch or to dodge, the knowledge of the path could be used to activate movement controls to accomplish our goal. But the more complex the real-world situation, the more challenging it is to model it and to apply AI to the model to support realistic, useful, autonomous operation.

You might wonder how my contextual information fields could play into this. My view is that they would impact the mission and action layer and become an input to the perceptive process layer, but not the lower layers. I think it would be a mistake to have issues like avoiding obstacles handled through a lot of back-and-forth cooperative exchanges. However, I can see that in collision avoidance, for example, it might be helpful to coordinate what direction two vehicles might elect to steer to avoid, so that they don’t end up setting up another collision.

All this is complicated, but it doesn’t mean that autonomous operation and robots can’t work. The key is simplification of the environment in which the autonomous-something is operating. A robotic vacuum doesn’t require all this sophistication because even if it fails or runs amok, it can’t really do serious damage to somebody, and fail-safe operation consists of stopping all movement immediately if something goes wrong. Vehicles operating in warehouses or closed environments can also be safe without all the issues I’ve cited here. We should expect to walk before we run, in autonomy, and that suggests that self-driving vehicles may be more of a risk to the concept than an indication it’s advancing. The real world is a complicated place, and in autonomous operation, complicated may often mean too complicated.

Our podcasters review the week’s economic and stock news, and talk about some of the fuzzy, uncertain, aspects of tech.

Podcast: Things Past and Things to Come January 9 2023

Some of the questions and comments I’ve gotten on my blog on contextual services and point-of-activity empowerment ask at least implicitly for an expansion in one key point. I noted the importance of relating “location” of a service user to what is nearby, meaning “contextual location”. I didn’t note how one did that or how the capability would be used. Actually I did mention that back in 2019, and I did a three-part series on new contextual services in September of 2022 (HERE, HERE, and HERE). What I think people are asking for is an application of the concepts of those past blogs to the examples I presented on January 5^th, so let’s give that a shot.

My view of a service user driving or walking along is one of a digital-twin metaverse-like model that represents that user in relation to surroundings. Rather than offering user location in latitude and longitude terms, offer it relative to elements of the real world that are relevant to user interests, missions, and so forth. The question is how that relative/relevant property set is reflected in the metaverse of the specific user.

In 2019 I introduced a concept I called an “information field”. This is a data set that is asserted by everything that impacts the users’ metaverses. Some information fields are asserted by fixed objects like lamp posts or buildings or curbs. Others are asserted by other users, by moving objects, and even by things like time of day or weather. Information fields are asserted, and each user metaverse model includes what I’ll call an “information receptor”, which represents the things that the user is, explicitly or implicitly, sensitive to. When an information field that’s asserted meets the receptor’s sensitivity properties, the field becomes a stimulus input to the user’s metaverse.

Say our user is driving down a road, and there’s a vehicle approaching. That vehicle asserts an information field, and our user is deploying an information receptor. We might say that the receptor is sensitive to another vehicle if it is within a given distance or closing at a specific rate. If the field matches the sensitivity thresholds, then the “logic” of the user contextual metaverse gets a generated event.

Or let’s say our user is shopping. Stores assert information fields that represent what is available there, and at what price. Our user sets explicit sensitivity to the goal of the shopping trip, and if the information field of a shop matches that goal sensitivity, the user gets an event.

Or maybe our user is a worker trying to locate a valve to repair. The valve asserts an information field, and the state of the valve can be a part of it. If the state matches the worker’s receptor sensitivity, and if any other factors known about the target valve match too, the worker would get an event notice, and using it could home in on the thing that needs fixing.

What we could say is that in any given location there exists a set of information fields that could be relevant to a user in that location. This set would change over time as mobile elements shifted into or out of proximity to the location, and a given user’s focus location could also change if the user were mobile. The user’s receptor sensitivity would determine which of the information fields were relevant, so a user walking on the street toward a shop wouldn’t be bothered by the fact that they were passing over a manhole access to a wiring closet, while a repair team might be sensitive to that manhole and not to the shop.

You can see (I hope) how this relates to contextual services and point-of-activity empowerment. The approach would give a user an event, which could (in their metaverse model of their activity), trigger some information delivery. You can also see, perhaps, how this could be linked to some of my musings about a generalized architecture for a metaverse.

In early March of 2022, I did a series of blogs on modeling digital-twin systems and the role a metaverse architecture might play. One of the notions in the series was the “locale”, which I defined as a virtual place that collected inhabitants who could interact with each other. That concept could be applied to our contextual services discussion, with perhaps a bit more elasticity.

First, the locale in contextual services is a virtual model of a real place. One useful way to think of it is that a user of a contextual service is surrounded by a “field” that represents the user’s locale. The user can be aware of things within the locale, and would be expected to be unaware of things outside it. The exact size of a locale would likely need to be adjusted based on the user’s position, speed of motion, and mission. A driver, for example, might have a locale that’s perhaps a block or two around the driver’s current location. Other vehicles and pedestrians outside the driver’s locale need not be considered when looking at how their information fields matched with user’s receptors. That simplifies the processing of these intersections.

We could also consider locales to be fixed in location, based on a number of factors like traffic flow and direction, the nature of the structures, speed limits, and so forth. If this were done, then all of the vehicles within the locale would have the same information fields presented, and so sensitivity receptors for all of them could be matched against that set of fields in a single step.

I think the first of the models probably works best for vehicular motion because the pace of changes in conditions is faster and because maneuvering to avoid things is more critical. For pedestrian movement I think the latter approach is better, because it’s reasonable to think of “walking” as moving between locales, each of which has contents (shops, restaurants, service stations, banks, etc.) that would assert information fields. On entry, a user would then be “presented” with these fields to match against receptors.

Contextual services, obviously, require context first and foremost, and context requires both the assembly of information that is both physically and “philosophically” local to the service user. That’s more than just reading sensors, it’s interpreting the meaning of the relationships the data uncovers. It’s hard for me to see how this can be accomplished without a digital-twin concept, which is my basis for an entry-level metaverse.

But it’s also hard to see how you get all of this stuff in place. Certainly we can’t expect immediate wide deployment of this sort of thing, which of course relies largely on edge computing, at least “metro edge”. The good news is that a “locale” is inherently local, which means contextual services could be offered in a limited area to support limited missions. It may be that contextual services, metaverses, and edge computing all depend on identifying these local opportunities, then building on their success.

The next Things Past and Things to Come podcast will be posted on the morning of January 9th on the blog.tmtadvisor.com website, and the Mastodon chat on its topics will be held at 11 AM Eastern US Time on January 10th. If you have not yet sent me your Mastodon ID and followed the instructions in the email confirming your setup, please do so before then or you won’t be able to participate.

For Tuesday’s Mastodon chat on the TMT Advisor podcast, please make note of the following points, referring to the instructions you received on signing up to participate.

First, you must follow my Mastodon ID in order to see my comments and answers.

Second, you must ask questions and make comments with toots designated as public, and tag your toots with the TMT Advisor hashtag, so that others will be able to see your questions and comments. If it doesn’t interfere with your other uses of Mastodon, I recommend that you go to Preferences>Other>Posting privacy and set your default to “Public – Everyone can see”. Hashtags aren’t processed in Mastodon except for toots that are designated as “Public”.

In our first test of Mastodon chats on podcasts, conducted on January 4^th, I think that it would be fair to say that edge computing and its impact on tech spending was the big topic. Within that big tent, there seems to me to be two supports. One is just where “the edge” really should be. The further outward you go, the lower the efficiency and the greater the impact on sustainability. The other is what applications for the edge would need to have in the way of baseline “platform” services. Absent some middleware support at our hypothetical edge, it could become the grand and glorious mother of all silos.

I think most who follow my blogs know that I am not a subscriber to the “extreme edge” theory, of pushing edge hosting all the way out to the central office locations (roughly 14 thousand in the US) or even the cell towers. I favor the “metro” strategy, which would place edge hosting in population centers that could support low-latency connectivity to the access network, fixed and mobile. I’ve tried to model that placement, and come up with roughly 250 in the us and about two thousand worldwide. As I said on the Mastodon chat, the higher the overall demand density of a market area (like the US or any other country), the smaller the number of metro sites would likely be required for a given total population. Smaller area, fewer metro sites.

The thing about metro hosting as “the edge” is that the positive of greater efficiency depends on having a fairly universal hosting model. If you have to subdivide your metro pool of resources into five or six mission-specific segments, you lose economy of scale. At the same time, though, tech in general and hosting in particular normally achieves universality through loss of specificity of features. If you have six missions, then you pick a subset of all possible middleware features that can support all six, right?

The problem with that is that you still need some uniform feature set within each of those six missions, and if you don’t provide that in the edge platform, you invite every collection of applications within every mission to build their own tools, creating more silos than before. Further, there’s a pretty good chance that within those six (or whatever number you like) missions, there are some common requirements for groups of two or three, and maybe even a few common to them all. A lot of development time could be wasted and resource and operations efficiency could suffer.

Again citing our Mastodon toots, “contextual” or “point of activity” services represent a general class of features, and my view has been that we should consider the edge as a platform-as-a-service framework that supports that general class of features, and that offers guidance on how the general feature set could be augmented with mission-specific capabilities. In short, we need a PaaS that has an inclusive architectural model that encourages extensibility, and those two terms define what our model has to supply.

The thing that’s common across our two terms is the integration of a hosted service into the details of our work and lives. Both involve “activities”, and in order to integrate something with those activities, we need to understand our “context”, which means the frame of reference into which we are placing events, objects, people, and (yes) assisting technologies. The baseline requirement for our model, then, is an understanding of our context and our activities. Place us in a mission (activity) and locate us in the real world in all the dimensions that our senses can register.

When I take a walk (or, as some of my detractors might say, a totter), my phone will make an assessment of my movement, and finding it taking me away from my home location, it declares it to be a walk. Thus, my location is a key element in both context and activity identification. In fact, I believe that location is fundamental to our new model, and the more precise it is the better.

We can establish location through GPS, through triangulation of cell signals, through proximity sensing using multiple technologies, and so forth. It would be madness to assume that all applications that needed location would have to be aware of all the possible options and the technology required to access each of them. A “location service” that presents user location via an API would be the smart way to approach this. But what does that location service deliver? Location is abstractly latitude and longitude, which almost surely does little good for most applications. We really need to think about location the way my phone did on my walk/totter, and consider location relative to something. Context.

I have the option, with my phone, of starting an activity explicitly, in which case my phone knows exactly what I’m doing. One essential input to our process of activity identification is direct identification by the user/worker. It may not be meaningful in all cases to get the sort of precision that direct identification brings; if I’m walking around the neighborhood does it matter whether I’m walking to “clear my head”, for “exercise”, or whatever? But if I’m walking down a street in a town or city, it might matter a lot if I’m strolling, heading to lunch, or shopping. Why, because what I get in the way of information from contextual point-of-activity services would vary across those options.

If I’m shopping, I’m probably shopping for something. Suppose my contextual service knows what that something is, and suppose it can use that to inquire into the websites of the places I’m passing or likely to pass in order to determine if they have an item I’m looking for and how their price compares. But of course I may be strolling, and have a few items I’m just thinking of picking up. If I happen to pass a sale on one, couldn’t it be helpful for my service to alert me?

Useful services that support work or life have to know what you’re working on and how you’re living. In order to do that in a practical way, we have to define a general process of gathering information about context and activity and presenting it to an application set through a standard set of APIs. We can’t allow those APIs to be too low-level (like presenting location as latitude and longitude) or we’ll make development of contextual applications horrendously expensive, and hosting them an efficiency and operations mess. We need that PaaS.

And, of course, we need a business case, and that’s another part of the reason for a PaaS. You can’t expect applications to develop in anticipation of both a suitable hosting platform and a reasonable ROI. Everyone accepts that “edge” differs from “cloud” primarily in that the former distributes hosting closer to the point of activity in order to ensure that the contextual vision of the applications is closely synchronized with the real world. A PaaS model, designed to get something into play, justified by current applications like NFV or 5G, could support gradual introduction of contextual applications, paced at the speed of acceptance and generation of returns.

The point here is that context is complicated, and so are the processes of identifying and supporting activities. This is why I’ve come to believe that all contextual services would have to be supported using a digital twin modeling, which would make it in my view a form of a metaverse application. I don’t know how to think of the challenge of contextual or point-of-activity services in any other way, architecturally speaking. To expand on what I said in the last paragraph, you need a model of at least an abstract piece of the real world to help people live and work in it.

Any fortune-teller loves it when their predictions come true, but they also love it when others begin to agree with some of their early-stage prognostications. So it is for me (being an analyst isn’t far from being a fortune teller) with the future of the metaverse. A VC-centric publication has picked up on many of the things I’ve said about the metaverse’s future, not necessarily because I said them but based on the view of another of those analyst/fortune-tellers. Could awareness be growing for some of the issues I noted yesterday? Let’s look at what was said and what it might mean.

The basic theme of the piece is one my readers will surely find familiar; the “metaverse” of the future is really about digital twin technology, applied to things other than social media. Since I’ve been blogging about this slant from the start of the metaverse hype (including just yesterday), it shouldn’t be a surprise that I agree with these points. The same can’t be said for everything in the rest of the piece, and my objections there may seem familiar too.

Let’s start with a positive, which is that the article divides the metaverse into three segments, “consumer” (what I’ve been calling the “social metaverse”), enterprise, and industrial. I’m not totally comfortable with the latter pair being different enough to consider them as independent segments, but there is a justification, which I’ll get into in a minute.

OK, let’s now look at some issues I have, starting with the definition. The article offers the following: The metaverse is a confluence of interconnected open platforms bringing the virtual world and the physical space together under a single technology ecosystem.” I’m far from sure that we could call the metaverse a confluence, interconnected, or open. To me, the metaverse is a model of elements of a real-world system, synchronized with that real-world system and used to facilitate control of aspects of that system through control of the model.

You can see from my definition that I believe that the essential element of a metaverse is the digital-twin notion. All metaverse applications will have to synchronize with aspects of the real world and model the relationships of the selected elements. The scope, in a distributed/interconnected sense, of a metaverse then depends on the scope of the real-world things it represents. For wide-scope metaverses, the property of interconnectivity is surely important, and there may be a value to open technology, depending on just what real-world systems the metaverse represents.

In truth, many industrial and enterprise metaverses, and maybe even many consumer metaverses, gain little from openness at the metaverse level. An industrial process is localized, and just as much of the industrial IoT today is linked to the machines used, we could expect the metaverse to be bound to the equipment. To require openness here would be to mandate standardization on which the interconnectivity and digital twinning could be based, and we don’t have that. Our industry has proven fairly ineffective in creating anticipatory standards; we do better trying to harmonize things once we have exemplars from which we can determine requirements and properties.

Even distributed metaverses don’t necessarily have to be open, as long as they can interconnect. We built almost every network today from devices that can interconnect and cooperate but are proprietary. There might actually be a benefit, particularly in “social” and “enterprise” metaverse models, of creating a metaverse by interconnecting proprietary components in a standard way. Competition among implementations could advance the process overall.

The next issue I want to raise with the article is the focus on visualization. At one level, any metaverse is a digital twin process and a model-representation process, but the latter doesn’t necessarily mean visualization is the key element in the representation, or is even present at all. A model of the real world (the digital twin) that, when it’s manipulated, reflects the manipulation results back to the real world depends on the reflection piece, and that in turn depends on what you’re trying to accomplish. If, for example, we had an industrial process we were looking to control via AI, visually representing the model wouldn’t facilitate the control, and it might be more work to visualize it than it’s worth if all you gain is letting a human watch what’s supposed to be a fully automated process.

This point illustrates my issue with separating “enterprise” and “industrial” metaverses. The way that a model is reflected back into the real world, for missions like education or process management, depends on the goal, and it’s a bit elastic. Might a warehouse metaverse, for example, provide a means of visualization given that workers in a warehouse might need to see what a given container looked like in order to ensure they have the right thing? On the other hand, the same application could require that an AI system route a forklift to the place where the thing is supposed to be, taking into account other forklifts in motion, optimum routes, etc.

This now raises the question of the “social” metaverse. Is it really justifiably separate from the enterprise/industrial metaverses? There is, I think, a major difference, and that is that creating a realistic visual experience from a distributed set of digital twins is central to the social metaverse. This is perhaps the clearest application of augmented reality to metaverse thinking, because absent a truly realistic rendering of the distributed model, the whole thing falls apart.

Even here, though, we can find other AR applications in the enterprise/industrial space, most significantly in health care specifically and robot control in general. Remote surgery demands good visualization, and you could say the same thing with remote repair. These applications could demand multiple synchronized AR visualizations and also model-driven process controls, so they may be hybrids of the other possible metaverse opportunity segments. Thus, we could rightfully say that there are three elements to a metaverse: 1) the digital twin model, 2) the process control interplay with the model, and 2) the AR visualization. It’s possible that the latter two may range from being minimal to being highly critical, and the mission frames the relative importance of each. Whatever opportunity segments exist, we can address them with a uniform technology.

Which, according to the article, involves Web3. I highly doubt that Web3 is actually a required element, and in most cases I’m not even convinced it’s a useful element. Unless we redefine Web3 to make it a success retrospectively, the concept is about a distributed form of validation/authentication. Obviously, only highly distributed metaverses would have any need for validation; it’s not a requirement for “industrial” metaverses. It also seems obvious to me that simple ID/password validation would be sufficient for most of those applications. Where a metaverse is created by “federating” different digital-twin instances, it’s hard to see how any would really benefit from Web3 blockchain-based authentication.

So, given my points, why did I bother to highlight this piece in a blog? The answer is that the startup community is all about exit strategies, and so it’s not surprising for it to validate thinking that led to some of the current startups, who will shortly need exits. However, that same community may be essential if we’re to make the metaverse, the realistic metaverse, a reality. It may be a good sign that it’s trying to wrestle some sanity out of the concept, and merge it with some healthy opportunism. As long as it doesn’t get stuck on the thorns of older concepts, that merging could lead to a good outcome.

The metaverse seems to be one of those topics you can’t stop blogging about. There’s a lot going on for sure, the concept is important for sure, and others keep writing about it and raising issues. For example, Light Reading talks about how telcos “marvel at the metaverse”. CNBC says that the metaverse is “off to an ominous start” because VR headset sales shrank in 2022. There have been many other tales, too, and another piece in Light Reading on SASE seems to invite some parallels. Can we navigate this mess?

Let’s start our journey with the SASE angle. According to the LR article, “The telecom industry could certainly benefit from resolving to clear up confusion surrounding SASE.” Darn straight; any industry in fact could benefit from resolving to clear up confusion in almost any new-ish tech concept. That’s surely true of the metaverse, and you have to wonder why concepts like these end up having confused definitions in the first place. PR and analyst firms, I think.

For a decade or more, a product manager or marketeer’s idea of nirvana was “creating a new product category”. If you announced a box or piece of software that fit into an existing category, you ended up being a slave to those who got there earlier and were able to define the category first. Analysts loved the notion too because it let them write another set of reports on the new category. For the media, a nice category name (like “metaverse” or “SASE”) made covering stuff easier. The problem is that haste makes waste, and with everyone jumping out to define stuff it’s no surprise that you end up with definitions in search of clarification.

At a deeper level, these new and loose terms are what I’ve been calling “UFOs”. A UFO is great because, since one isn’t likely to land in your yard and present itself for inspection, you’re free to assign one any characteristics you like. Telcos marvel at the metaverse, of course, because everyone is supposed to, but why in particular should telcos be doing that? Because they see 5G/6 G connections and a long-sought-after driver for new revenue from those services. Who guarantees that will happen? Nobody, but a metaverse is a UFO, so you can say what you like.

The CNBC story says that because artificial or virtual reality headsets have seen a sales dip, the metaverse is in trouble. Well, that could be true depending on what UFO-like characteristics a given vendor or provider happens to have assigned to it. CNBC is apparently taking Meta’s social-metaverse view, and that’s pretty clearly linked to VR headsets. But remember the “industrial metaverse” I blogged about earlier this week? You don’t need VR headsets for that, and it may well be a bigger contributor to the future of the metaverse concept than Meta’s own vision.

The problem with meta-fuzziness is that it risks a loss of credibility for a whole universe of concepts that might, in fact, not even belong together. Remember that we have another concept called the “Internet of Things” or IoT, and our industrial metaverse might be an IoT application. We also have the concept of “digital twin”, and that could be what industrial IoT is based on. Or maybe the metaverse is a digital twin and we shouldn’t be using a different name for it. Or maybe it’s virtual reality. We have at least three or four concepts that are kind of rolled into the “metaverse” term, and none of them are precisely defined either. Most of the “things” in our IoT reality, for example, aren’t on the Internet.

There are legitimate reasons for adopting collective terms, and they boil down to the question of whether the collection is actually a functional whole. Read Vonnegut’s “Cat’s Cradle” and you’re introduced to the concepts of kakrasses and granfalloons. The former refers to a group of people who are meaningfully if not always obviously collected, and the latter to groups that have no significance, only a name. The metaverse concept is valuable if it’s a karass, a significant grouping of functional elements that generate a higher-level something. All the current confusion over metaverse definitions, elements, or features is proof we haven’t achieved that yet. Today’s metaverse is a granfalloon. If that’s the case, then we either need to firm up our metaverse concept or stop using a collective term for something we can’t define as a real collection of stuff. In software terms, if we can create a metaverse architecture, then metaverses are meaningful.

Why do we have a term that we can’t really make into a karass? It goes back to the marketing angle. In today’s world, it’s common to announce things before they’re real, often even before we know how to make them real. Another thing I told consulting clients over the last couple decades applies here; “The truth is a convenient place from which you launch a good marketing fable.” Suppose you forget the launch pad and just concentrate on the fable part?

I think that a metaverse architecture can be defined in such a way as to include the missions that we normally assign to a metaverse, and also some missions I believe are related. A metaverse is first a collection of digital twins that represent semi-autonomous pieces of a real-world system. Second, it’s a model of models that describe the nature of that collection. Third, it’s a telemetry and control framework that synchronizes the model with the real world, taking data from the real world to alter the model state into correspondence, and taking changes to the model and communicating them to control elements that then bring the real world into synchrony with the mode. Finally, it’s a visualization framework that allows the model to be externalized, including making it or an abstraction of it visible to people.

You could visualize an implementation as a collection of “black boxes” or objects, each representing something, linked by APIs. If we were to define the objects and APIs, we could allow any implementation that met the specifications as being a conformant piece. Thus, a full specification of the architecture would allow people to build on an open framework and would not demand all implementations of each object be open-source.

The challenge we face, metaverse-wise, for 2023 is who might define the architecture. I don’t think that a working approach would be difficult to create, one that handled what we can visualize in the way of missions now, and that can be extended if we missed something. But who spends the effort? Meta, maybe, if it does spin out of Facebook overall, but would they just focus on the social angle and miss the rest? The cloud providers are probably a better hope, and I hear that all of them are at least exploring the question.

It’s tempting to see the metaverse as an evolution of a failing social-media-ad-sponsored past, and while that still may be an option it’s not likely to generate enough revenue in the near term to sustain technical investment. That would be short-sighted in my view, because the metaverse is the way forward for IoT and digital-twin concepts overall, and it’s those areas that hold near-term promise. We might see progress, even convincing progress, in 2023, and if we do then the metaverse could be one of the year’s most important developments.

With apologies to Arthur Guiterman.

“The Elon Musk whose Twitter Flaw launched Mastodon…has rubbed us raw.

The metaverse that promised much…has crumbled into cartoon dust.

The 5G wave that swept our shores…became the focus of our snores.

All tech seems locked in hype and fear…and so we hope for a better year.”

Starting in 2023 I’ll be adding some capabilities to our TMT Advisor podcast site, including scheduling Mastodon-based interaction on selected podcasts and adding a new podcast type. Please note that you’ll have to be registered to use the Mastodon capability and to listen to the new TechsRay^TM podcasts. Those who are registered on January 10th will be able to participate in the test of the new capabilities, but no new subscribers will then be added until the test is complete, at which time I’ll catch up on the registrations of new subscribers.

https://blog.tmtadvisor.com/?p=2535

We’re almost done with 2022, a year that a lot of people aren’t going to be sad to leave behind. The big question for us all is whether 2023 will be any better, and there are signs that point both upward and downward. The tech world is always a slave to the broad economy, but the two don’t move in lockstep so we have to look a bit deeper at the trend lines. To do that, I’ll draw on what I’ve learned from both buyers and vendors, and also on Street research.

Keep in mind that both these sources have potential issues. I don’t necessarily see a valid statistical sampling of viewpoints, because my contacts come from people who are likely following my views. Whether I influence them, or simply “pre-select” from the broad market because people who agree with my views are more likely to contribute to my information, there’s a selection bias at play. With regard to the Street, I’ve noted many times that there are things they’re good at (like whether budgets are going up or down) and things they’re terrible at (like almost everything relating to technology insights). With that in mind…

If we start with the enterprise, we see a convergence of views from both sources. My contacts tell me that budgets for 2023 are not under pressure, but it is possible that some projects will be pushed a bit toward the second half because of broader economic uncertainty. The Street view with regards to budgets is similar, but I don’t see a significant consensus on the project timing issue.

What is also consistent is the general focus of projects. There’s a lot of interest in vendor consolidation, which I see primarily at the hardware and platform software level but which the Street sees as a broader trend. The issue here is that enterprises think that integration of any sort has become a major problem, and they’re looking to reduce it by reducing the population of things that need to be integrated.

One insight I got from my contacts that the Street didn’t mention is that there’s a movement toward “full-stack” or suite vendors and away from the “best-of-breed” thinking. I think this will favor vendors like IBM/Red Hat, VMware, Dell, and HPE. All these players offer both hardware and platform software, and that’s looking increasingly attractive to enterprises. Part of the reason is that enterprises are reporting rapidly mounting difficulties in acquiring and retaining highly qualified technical personnel.

The highest priority for enterprises is the applications, though, not what they run on. There is still significant interest in using the cloud to improve engagement with customers and prospects, and also (increasingly) to support employees and suppliers. There’s also growing interest in using SaaS for horizontal applications, and in fact SaaS use is the largest reason for “multi-cloud”.

Things on the network side are significantly more muted. There is no budget increase on tap for network infrastructure among enterprises, only for security products. This is another area where my data matches that of Wall Street, and it’s hardly surprising, given that the role of the network isn’t changing and so major transformational investment would be hard to get past the CFO.

“Transformational investment” is a worthy topic in itself. My data has consistently shown that in both networking and IT, there’s less interest among enterprises in trying out new stuff than we’ve seen for at least a decade (in fact, since the downturn in 2008). New technologies, new vendors, new anything, is kind of out of favor, even with CIOs who are usually more interested in that sort of things than the rest of the C-suite. The Street has generally picked up on this point, too.

What the Street doesn’t validate specifically is the attitude enterprises have toward even identifying new technologies, and perhaps surprisingly, toward discovering new paradigms for the way that IT is applied to their businesses. “Stay the course” is the mindset, and part of the reason I’ve heard for this is that buyers have lost faith in many aspects of tech. The number who say that they trust the representations made by their current or prospective vendors has dropped by a third in the last five years. The number who trust media and advertising has been cut in half over the same period.

In the network operator space, things are way more complicated in some ways, and much simpler in others. Complicated because there are many different types of operators, and many different sized. Complicated because an operator organization is like a government; huge, monolithic in some ways and yet home to radically divided opinions. I described the latter phenomena as the young Turks versus the entrenched conservative management establishment, but in fact you could divide operator organizations up in three or four different ways, which shows just how hard it is to establish a perspective on “plans”.

Let’s cut through that, though, but admitting that senior management falls into the “entrenched and conservative” part of any division, and that this group is still driving the bus. If we do that, we can see some surprising congruencies with enterprise management.

The Stay the Course mindset is one. It may be that management thinks that all the current tech market confusion is something that will pass away without any need for them to act in any particular way. It may be that they don’t think that they can sit on their hands, but don’t know what to do when they stand up. Understandable, when you have asset useful-life expectations that are on the average from 50% to 100% longer than you’d see for the same assets in an enterprise deployment.

This attitude is prevalent in both vendor and technology selection, but in both areas there’s a bit more of a split view among operators. There are some who are eager to change both vendors and technologies, in order to better manage costs, but for most this attitude is confined to areas of the network (geographic or service segments) that are largely greenfield or are undergoing major modernization. 5G is a good example.

Cost management, in fact, is the only consistent driver I see among operators I’ve chatted with. There is really little interest in “new services” beyond making some largely inconsequential tweaks to existing services and calling the result “new”. That’s focused operators more and more on the cost side, but at the same time ensured a collision between their goal (reduce costs) and their technology intransigence (don’t change vendors or technologies radically). Part of that, of course, can be attributed to the long capital cycles operators have to deal with, but part is just the traditionalist bias of senior management.

There are some things we can expect to see changing in 2023, though, but in a more evolutionary way. For consumer services, we’re recognizing that faster/better Internet sells, even if the claims are vague. As a result, there’s interest in pushing fiber broadband further, even if it means that there are little broadband enclaves where demand density is high, surrounded by areas where broadband is relatively poor. There’s also interest, and rapidly growing interest, in using 5G in general and millimeter wave in particular, as an alternative to fiber/wireline.

Consumer broadband, the Internet, and the cloud, are now linked in a powerful symbiosis. Over the last two years, we’ve seen the value of engaging users online to promote, sell, and support products. That has led to a demand for richer online experiences, which has led to both a need for cloud-hosted front-end elements to applications and better broadband to deliver richer visualizations. As a result of this, business networking is being transformed, in a multi-dimensional sort of way.

One obvious dimension is that better Internet and consumer broadband will make better low-cost connectivity available in more and more areas where there’s a population concentration that raises demand density. Since those are the same areas where business sites are likely to be located, it’s pulling businesses toward Internet exploitation rather than specialized business Ethernet/fiber access and MPLS VPNs. Major sites aren’t likely to end up on consumer-driven broadband infrastructure, but any smaller sites will be better supported there, and so the migration of small sites toward consumer broadband is almost assured.

The other dimension is the cloud/Internet role in supporting application front-ends. If customers, partners, and (increasingly) workers are all supported via the Internet and the cloud, then “cloud networking” or the connection of data center sites with the cloud for hybridization, becomes the primary incremental enterprise network requirement. Even alternative VPN technologies like SD-WAN are more and more likely to be deployed as virtual-network SASE instances in the cloud than as branch appliances or services. If workers access their business applications through the cloud, then all you need in branch locations is an Internet connection and security tools.

All this adds up to the need to create a unified virtual-network model for enterprises. I think that the announcement made today by Red Hat and Juniper is an example of that; Juniper has both SD-WAN and general virtual-network technology (from their acquisition of 128 Technology and via Contrail, respectively), and the paper posted today is an example of how we might see networking transformed by the combination of the cloud, the Internet, and even consumer broadband.

Security is the final point here. We have been practicing incrementalism with respect to security, like a crowd of children with fingers at the ready to stick in holes in our dikes. It’s time we fix the leaks holistically, but that’s been difficult to do given that the evolution of the cloud front-end hybrid model has created new attack surfaces, that network connection options are evolving, and that vendors tend to introduce band-aid fixes rather than asking buyers to start their security considerations over again.

Years ago, I pointed out that security really has to start with session awareness, meaning that network services that can identify a specific user-to-application relationship and match it against what is permitted and what isn’t, should form the foundation of a security model. We are starting to see that, and starting to understand that some form of virtual networking, which elevates connection management above transport connectivity, is essential. For business services, then, virtual networking is the most important thing to consider in 2023.

We’re not going to see a network revolution, or a tech revolution overall, in 2023. Economic concerns and central bank tightening will ensure that growth questions will haunt some economic sectors through the year, and that will make both businesses and consumers a bit more cautious. What we will see, I think, is a number of evolutionary changes in our tech ecosystem converging to create some trends that are a bit more visible, and thus perhaps more addressable.

I’ve tried this year to present an objective view of tech, offending some along the way and perhaps exciting others a bit. I’m pledged to do the same thing in 2023. This is my last blog of 2022; I’ll resume after the first of the year. Meanwhile, have a Happy Holiday season!