The TM Forum is a body that almost defines the love/hate concept. I’ve been associated with it for well over a decade, been a member twice and dropped it (or was dropped) twice. It’s done good things and it’s also been incredibly obtuse, difficult, and parochial. Now, according to a Fierce Telecom piece, it’s got another tick in the “love” column because I almost love what they’re suggesting. We’ll get to the suggestion and my “almost” qualifier below.
Operators have traditionally had three critical organizational divisions, each with a “Chief”. The main network body is run by the Chief Operations Officer, the Science and Technology piece by the CTO, and the OSS/BSS part by the CIO. In current practice, the COO and CTO tend to develop the main thrust of the network itself, choosing and deploying technologies. Standards membership is under the CTO. The CIO is almost a separate business, maintaining the software that forms the business side of the operator. There’s a healthy (or sometimes, to be frank, unhealthy) rivalry between the CIO and the rest of the organization.
What’s making the rivalry increasingly unhealthy is the fact that software-defined network features in any form mean shifting the network from a community of purpose-built devices (switches and routers) to one increasingly based on software-meaning-cloud-hosted features. In addition, the need to optimize both service agility and operations efficiency mandates a tight linkage between OSS/BSS software and the hosted elements of network services.
Up to now, the transformation to software-centric networking has been managed by the CTO organization in general, and more specifically by the part of that organization that hosts participation in formal standards groups. Neither the CTO nor the standards types have any real experience with software; nobody in a network operator other than the CIO has that experience. The NFV ISG has gotten off-track largely because of the lack of software-centricity among the operator representatives (and greed, perhaps, among vendor reps).
What the TMF wants to see is a merger of the CTO and CIO functions. That would bring an infusion of software knowledge to the CTO side, and break down a barrier to cooperation between service and network operations. I think this is a great step to take, even perhaps a critical one. I’ve seen the tension between CTO and CIO people in action for years, and it’s never been helpful. Having someone else tell them to play nice hasn’t worked, so combining the two functions seems the only step left.
So why is this an almost-love on my part? The reason is a paraphrase of the old adage “Two wrongs don’t make a right.” There is no question that the CTO organization is stuck in router-think, or at least box-think, and has no real conception of what a software-defined network would be. However, there’s no question that CIOs are stuck in OSS-think and have no notion of what a top-down, market-driven, world would look like.
Standards activities define the CTO and the organization overall. They’re relics of the supply-side thinking that regulated monopolies are almost forced to adopt. You build stuff and they come. There’s no need to figure out what “they” want; they’ll use what you supply because that’s all there is. If it takes you five years to get to where a commercially driven process would have gotten in six months, they’ll wait. There was a better, almost-optimal, model of NFV defined in mid-2013 and demonstrable by the end of the year, and it wasn’t adopted. The alternative that was is still unworkable, still in progress, entering 2019.
But the other side, the CIO side, has its own anchor, and ironically it’s the TMF. More than a decade ago, the TMF came up with what was literally the key and central element of the software-defined future, which was lifecycle orchestration of services by mediating the flow of service events to service processes using the service contract as a data model. “NGOSS Contract”, as it was called, was never widely implemented, in part because it was never effectively promoted.
Just this year, a long-standing thought leader within the TMF told me that the NGOSS Contract notion was getting new life. Well, it’s been over six months since I was told that. Where is it? Standards groups like the NFV ISG have taken way too long to come to a useful conclusion. You can make the same statement about the TMF with respect to things like the ground-breaking NGOSS Contract. Lengthy processes get behind the market, tax the ability of key people to contribute through the life of the initiative, and raise the cost of the work overall. Difficulty in participating is why I’ve not stayed with the TMF, and it’s also why I cut back on NFV ISG involvement. Only people paid to be standards-workers could possibly contribute the time needed.
What I’m saying is that neither the CTO nor the CIO processes of today have any positive record with respect to moving a good idea from inception to deployment at commercial speed. A public cloud giant like Amazon or Google would laugh at the processes of both bodies, and certainly their success in being market-driven can be said to derive from a determination to ignore the operation of CTO and CIO organizations alike.
That’s the source of my qualifier. Can a combination of a non-responsive CIO and CTO process lead to a “Chief Software Officer” or CSO that’s responsive? I give the TMF a lot of credit for coming up with the notion of a combined position, but just as defining the concept of the NGOSS Contract was a seminal leap forward that ended up being the only leap taken, the union of CTO and CFO could simply create one big insufficiency instead of two. The step beyond that’s needed is to direct the unified body at a valuable role and efficient model of filling it.
That model probably doesn’t include either formal standards bodies or industry groups like the TMF, unless the way those activities operate is radically changed. Open-source needs top-down guidance and it would be possible to frame either CTO or CIO processes to provide it, if we had industry forums that were designed the “modern software” way and not the old way—where “old” means both CTO-centric standards work or CIO TMF work.
It may well be that the future will be driven by and belong to a body who figures out how to be the driver of the software-centric future. Who’s up for the challenge here? We may find out shortly, because 2019 is a period when operators want to see some results. Here, the TMF may have an advantage because unlike the formal standards bodies, they’ve actually proven they can come up with something highly insightful. They just need to prove they can do something with the insight while the market need still exists.