Just what is needed to broaden the potential revenue base for 5G. One idea that’s been gaining in credibility is a vertical-market focus. Both Google and IBM have taken vertical steps recently, and now we have an interesting article on the architecture of a vertical exploitation of 5G. You all know I’m a big, unashamed, fan of architectures and of vertical-oriented service strategies, so we’ll take a look at this one in light of both industry trends and industry needs.
The basic premise of the article is one I can surely agree with. Progress in network, cloud, and general IT these days involves adding new features that often end up adding new components from new vendors. There’s an expanding, even exploding, problem of integration that the buyer is stuck with. Not only that, if the application area being considered is new, as 5G surely is, there’s a major risk that all the pieces of the ecosystem needed to make progress at the application level won’t be in place at all.
The solution the piece proposes is an “Industry Digital Services Platform” (which I’ll abbreviate hereafter as ISDP to save me typing and you reading). The ISDP consists of a generalized gateway layer that feeds a three-layer stack that consists of vertical solution players, cloud providers, and network operators. All the layers are linked by APIs, and if the conventions of the architecture and the APIs are followed, specific vertical solutions would link into the architecture and work with little or no integration on the part of the user/buyer.
There’s a lot to be said for this approach. If applications that (in this case) were prospective consumers/drivers of 5G services could be fit into a composable framework that could then be used to support third-party providers and end users alike, the sum of the application software would surely be greater than the parts. Thus, the question is whether such a framework could be developed.
One obvious barrier to the development is the time required to do the job. You could argue that public cloud providers would have seen an opportunity for this sort of thing almost from the first. While there have been some vertical-market announcements by public cloud providers, none of them have really proposed to create any such framework. Even if they did, you’d surely end up with one framework for each provider, and that would likely mean that actual providers of vertical-specific components would have to integrate separately with each.
A formal standard might be the solution to this problem, but that creates problems of its own. There are standards groups that are associated with the structure the article describes, but each layer has at least one such group, and for vertical applications there’s arguably one for each vertical. It’s possible that a single group could take up the problem, but just what group that might be isn’t clear. Then there’s the question of time; standards processes are something I’ve been involved with for decades, and they tended to work at the pace of glaciation or the formation of stalactites. I doubt that the market would wait for the process, and certainly there will be a lot of embarrassed 5G proponents long before any hope of progress could arise.
The next question is how the “hybrid cloud” fits into the picture. Yes, it’s true that we’re talking about a way of creating driver vertical applications for 5G, but can we expect enterprise customers for these services to move totally to the cloud? Despite market hype to the contrary, I see no indication that this kind of migration is pending, or even contemplated. My own financial modeling suggests that it couldn’t be cost-justified. So, if there are data center pieces, how are they integrated? Are we then involving yet another set of players who have to cooperate in our architecture? And let’s face it, we don’t even have a standard way of doing hybrid cloud in general.
A final question is whether “vertical” in the sense of the article and the specific chart of the architecture is the best approach. The fact is that while industries all have their own core software set, built to support their specific mission(s), there are a large number of “horizontal” functions that could be used to compose at least a big chunk of the verticals. Someone, in a LinkedIn comment on the piece, made that point. Should we focus on creating components, horizontal components, from which vertical support could be composed, supplemented by specialized components for the vertical?
From these points, you might think I don’t like the idea, but that’s not the case. I totally agree that vertical market applications are the key to driving 5G-specific revenue opportunities. What I’m less certain of is that we have a path to achieve them, or the model the article presents. It lays out a good strategy, but there’s a lot of heavy lifting needed to realize it. I guess the big question is “What does that lifting?” I believe there are two options that could work; a cloud provider and open-source.
The key layer in the architecture the article depicts is the public cloud layer. The cloud provider has engagement with developers already, and it also has horizontal tools that could be put into play. Hybrid clouds are the key to their success, so they can be relied upon to come up with a workable hybrid strategy. These cloud providers are also already engaging (or trying to) with operators on 5G hosting (edge hosting).
If a cloud provider were to jump on this notion, they could address all the issues I’ve raised, save one. Their solution would be proprietary, and while other providers would surely make similar vertical moves, the software providers and users would have to either pick a single partner or customize for each public cloud platform.
The open-source approach has engagement at the vertical layer. We already have some vertical-market software available in open-source form, and we have a significant amount of horizontal software, including all the platform tools needed. A foundation like the Linux Foundation could certainly host something like this, and with proper design and development care, an open-source package could be portable to any cloud.
The downside of this approach is sponsorship of the open-source project, and the time involved in getting it to progress. Development times are notoriously difficult to estimate correctly; everyone tends to be too optimistic.
In my early career, I had a manager who became known for his ability to make uncannily accurate estimates of project times. I was working at a computer vendor, and attending a meeting with my manager and the systems programming team, who offered their estimate of the project. My manager shook his head and said they were about a third of the right number, which turned out to be correct. When the VP asked my boss how he estimated so well, he said “I use the Harvey Principle.” The VP was quick to ask what that was, and my boss said “I used to have an employee named Harvey, who was the dumbest SOB I ever worked with. When I estimate a project, I ask myself ‘How long would it take for Harvey to do it?’” Enough said; complications always arise and there are plenty of Harveys in the world.
So what’s the answer? Do we have to give up on the architecture? No, but we have to accept that there’s no perfect way to achieve it at this point; certainly no way that would advance 5G on the schedule that operators and network vendors hope. That doesn’t mean we should throw in the towel, only that we’re not going to get instant gratification. I’d say minimum 18 months, and that’s a lesson in itself. If we need new services and applications to drive a network technology, we need to work on them when we’re starting work on the technology they’re expected to support. Otherwise we’ll leave that new technology waiting at the alter.