On the ever-popular topic of zero-touch automation, Light Reading has an interesting piece that opens what might well be the big question of the whole topic—“What about the TMF?” The TMF is the baseline reference for OSS/BSS, a body that at least the CIO portions of operator organizations tend to trust. The TMF has also launched a series of projects aimed in some way at the problem of zero-touch automation. As the article suggests, there are two in particular that are currently aimed at ZTA, the Open Digital Architecture (ODA) and the Zero Touch Orchestration, Operations, and Management (ZOOM) initiatives. Could the TMF resolve everything here? We need to look at the assets and liabilities.
Engagement is critical with anything in the zero-touch area, and the TMF has both plusses and minuses in that category. Among CIO organizations the TMF is generally well-regarded, and it has long-standing links to the OSS/BSS vendors too. The body runs regular working group and plenary meetings, the latter being mega-events that are as much trade shows as technical meetings (not unlike MWC).
Outside the CIO area, things are a bit different. Among the rest of the C-suite executives, the TMF is held in lower regard than bodies like ETSI, and there are some in the staff of CTO, CMO, and COO execs that think the whole OSS/BSS program should be scrapped and redone, under different industry bodies.
This division is critical at this particular moment because the zero-touch initiative really demands a solution that crosses the boundary between OSS/BSS and the COO/CTO missions of network technology transformation and operations transformation at the NMS level. The barriers to having just one C-suite exec take over the whole ZTA space are profound, in operator political terms.
Technology is also critical to ZTA, of course, and there the TMF has made the greatest single contribution of any body. The so-called “NGOSS Contract” (where NGOSS means Next-Gen OSS) established the first recognition of event-driven operations and the use of a model to steer events to processes. I think it would be appropriate to say that if this model had been developed and accepted fully and logically, we’d have the right solution to ZTA already.
Why didn’t that happen? That’s a very difficult question for anyone to answer, but one for which many people have contributed one. What I hear from others is that 1) vendors obstructed the vision, 2) operators were reluctant to adopt something that transformative, 3) TMF people never articulated the concept correctly, and 4) the TMF never really saw the connection between NGOSS Contract and later ODA and ZOOM work.
I was a member of the TMF at the time when the NGOSS Contract work came to be, though not a part of it. I was also a member when ZOOM kicked off, but engagement in TMF activity (like engagement in any standards activity) is both time-consuming and frustrating, and I couldn’t commit the time and energy as the work formalized. I was never involved in ODA in any form. I mention this because my own view, drawn from my exposure and the comments I’ve gotten from operators, suggests that there is some truth in all four of the reasons why the TMF NGOSS Contract stuff didn’t go where it might have.
The thing I think is critical here is that there is no reason why the TMF couldn’t now do what it didn’t do a decade ago when NGOSS Contract was hot. At least, no new reason, because those same four issues are still pushing just as hard as they did a decade ago when all this started. Not only that, the same four issues will have to be addressed by anyone who thinks they can make ZTA work.
The simple truth is that zero-touch automation can be made to work easily if a service model (like the TMF SID) is used to describe the elements of a service as functional models that contain the way that “events” within the scope of each element are directed to processes based on a state/event model of some sort. That’s what is needed, and to the extent that you can describe ODA or ZOOM that way, they can be made to resolve the ZTA problem.
I believe firmly that there are probably a hundred people in the TMF (or affiliated as one of their levels of professional partners) who could do exactly what is needed. I believe most of them were involved through the last decade, too, and somehow they didn’t do what they could have. That’s another “Why?” that probably has lots of opinions associated with it. The short answer is that the projects like ODA and ZOOM weren’t launched to specifically build on NGOSS Contract. There were TMF Catalysts (demos, usually involving multiple vendors and given at one of the big TMF events) that showed many of the critical steps. What was lacking was a nice blueprint that showed everything in context.
This is a failure of articulation, again. For the TMF, articulation is hard because the body has created a kind of micro-culture with its own language and rules, and they don’t make much effort to communicate outside themselves. Remember that most of the C-suite is outside the TMF, so that failure to speak a broadly understood industry language is a major problem. But even when I was involved in the early ZOOM work, I didn’t see much attention being paid to NGOSS Contract, even when I brought it up as part of the CloudNFV work.
The Light Reading article raises a good point, or question. “But is there not,” it asks, “a risk that yet another initiative sows confusion and leads to fragmentation, rather than standardization?” Darn straight there is, but there may be another bigger issue. Framing a simple but not fully understood solution like NGOSS Contract inside something else risks losing touch with what works. Every new layer of project or acronym may lead to new claims of relevancy, but they move further from that basic truth that could have worked a decade ago.
The TMF has issues, in my view, and I’ve never shied away from that point. It also has the most important core asset of all, the core understanding of the relationship between events, data models of services, and processes. They’ve under-used, or perhaps even ignored, that asset for a decade, but they could still make truly explosive progress if they just did what should come naturally, and exploit their strengths.
To do that, they have to explicitly go back to NGOSS Contract, and they have to accept the fundamental notion that a service model (pick your modeling language) is a hierarchy or topology of element models, each of which obey the NGOSS-Contract mandate to mediate the event/process relationship. Forget all the TMF-private nomenclature for a moment and just do this in industryspeak. Once that’s done, they need to frame their ODA work first in that model, again using common language. Only when they can do that should they dive into TMF-oriented specifics. That makes sure that what they do can be assessed, and appreciated, by the market overall.
Can they do this? Bodies like the TMF tend to fall into their own private subcultures, as I’ve already noted. That’s what contributes to the problem the Light Reading piece cites, the tendency for new stuff to build another floor on the tower of babel instead of simplifying the problem or presenting solutions.