I’ve been involved in industry forums and standard bodies for many years. I’ve had experience in creating industry standards and getting them adopted. I’ve seen many successes and failures of these standardization efforts. It’s never easy to get agreement and even more difficult to get the right standards created and adopted.
Having just come back from Management World Americas in Orlando, the largest OSS/BSS (Operations Support Systems / Business Support systems) event in the industry, it’s gotten me thinking about the standards and frameworks set by TM Forum, and how they might be improved.
For those of you who are unfamiliar, TM Forum, or TMF, is a communications industry forum with over 750 members worldwide that include most of the communications industry ecosystem: service providers, equipment providers, software vendors, and system integrators. Amdocs has been a long time key contributor in the forum and are deeply involved in much of the programs of the TMF with active contribution and numerous contributors. I’ve personally been involved in TM Forum for some time, having attended and presented at the Management World for the past several years, and am personally involved in TM Forum’s leadership of activities, including committee and industry discussions—currently I’m serving on the TMF Technical Committee and TM Forum Advisory Council.
How TMF helps shape the industry
TMF has historically focused on helping service providers realize leaner operations by “nudging” the industry to normalize and optimize internal operations as much as is feasible. The outcome of adopting TMF endorsed practices theoretically leads service providers to be more effective companies. The forum has created several frameworks that form the cornerstone taxonomy of our OSS/BSS landscape – these frameworks describe what business processes are involved in service providers operations (eTOM), what data models they use (SID), and what sort of applications are needed to implement them (TAM). While there are some interfaces that were created or adopted over time by the forum, such as OSS/J, MTOSI, and IPDR (which I was personally deeply involved in creating), most of the work, and success in adoption of the forum’s work, has been focused on frameworks. The frameworks used to be collectively called NGOSS (for New Generation OSS), now they are all collectively referred to as Frameworx.
The case for interface standards
Though TMF’s framework standards have been widely adopted, its interface standards typically have not. There are many reasons for this, which I discuss often within the forum’s committees and activities. I believe that until we generate relevant interface standards, this trend won’t change. What I mean by an interface standard is one that if two separate systems each implement their side of an interface, integration between them will be almost “plug-and-play”. I say “almost” because OSS/BSS integration is so complex that true effortless plug-and-play is unlikely—but it can certainly be much less costly, risky, or time consuming than usual for our industry, where system integration is notoriously long and complex.
That said, it’s not enough to create standard specifications for interfaces, nor is it enough to even have working code to implement them or test them. The timing needs to be “just right”. Like with innovation, one must “surf the wave”. These standardized interfaces need to be created just in time for when they will be needed – not years too soon nor months too late. If the wave is missed or pre-empted the standardized interface will never get used and, possibly, years of work to create them will have been in vain. Timing is critical, but not sufficient – there must be a business rationale for implementing them. And even if interfaces are created at just the right time, there needs to be sufficient business reason for the key actors (vendors and buyers) to implement them—otherwise, once again, the effort to create them is wasted.
My experience has led me to three key criteria that determine whether standards get adopted:
- Critical enablers – the best and most widely adopted standards are when they are critical enablers of the industry, not just a “nice-to-have”. Standards are usually not in the best interest of industry players, as each wants to create a unique solution that is differentiated from its competitors and bestows upon them some competitive advantage. However, there are many cases that without industry agreement, an industry does not get develop at all. Examples of this are many of the standards around us such as VHS, CD, DVD, BluRay, USB, HDMI, GSM, TCP/IP, HTTP, HTML, WiFi. In each of these cases, proprietary systems may have existed prior to the emergence of standards, but the market really couldn’t take off without them. There would have been no interoperability between vendors, which splits the market and keeps it from developing.
- Timing – if standards are developed years too early—or, these days, even months too late—that standard may never get adopted. A good-enough alternative might be found, whether from a competing standards forum or even a proprietary solution. The absence of a standard can even hold back industry progress until a single format “wins”, such as in the “format wars” of VHS vs. BetaMax, as well as HD-DVD vs. BluRay.
- Market force alignment – when different parties cannot agree on standardization, they resist adopting competitive specifications and go with proprietary specifications or even create competing standards. For example, these days, cloud services are growing rapidly, particularly Infrastructure-as-a-Service (IaaS). Amazon, Google, Microsoft, EMC, and many others are providing computing and storage resources in the cloud. While their business clients would benefit from standardization, perhaps allowing them to easily migrate IT operations between providers, it’s not necessarily in the best interest of the innovators leading this space. Each of them would like to “lock in” their clients to their services. So the leading IaaS providers are probably the least inclined to align on standards that would effectively reduce their competitive advantage. In this case, standardization might benefit the newer players to allow them to play. But if the market-leading players do not open up to such standards, this market will delay, perhaps indefinitely, adoption of these standards.
So while standardization is never easy to achieve, it has many benefits. For buyers, standards imply reduced risk, cost, and time associated with implementation – this is true for consumers as well as business buyers. For system providers, it implies reduced engineering costs – rather than customizing systems to conform with unique needs of each client, systems can be developed once and deployed many times – increasing reusability and hence profit margins. Overall, this reduces engineering costs. I am a big believer in standards. But without delivering the intended value, they can wind up as wasted efforts. Therefore, adoption is critical.
So when do standards work? When they’re specific.
There’s another critical distinction between standards: specificity. Standards that are not specific enough may create the opposite of the intended value, or even cause unintended damage. While high-level framework standards may make discourse and understanding between parties easier, enabling different parties share the same terminology and taxonomy, this is where the benefits end. They do not necessarily reduce the risk, cost, or time of implementation. This is because framework standards have a lot of flexibility in interpretation. Even if everybody conforms to framework standards, it doesn’t mean that two separate conforming systems will interoperate. The intended benefits of standardization—both to the buyers and to the suppliers—are simply left unrealized. Such standards can even cause harm as they create unmet expectations by the buyers that if they buy a system that conforms to the standard, it will bring the benefit of interoperability with other conforming systems—which is simply not the case.
Interfaces make the best types of standards because they can be very specific. If two sides of a particular interface conform to a standard, and the interface standard specific enough it might also be testable with a “pass/fail” criteria, it implies that the two systems would interface with each other at vastly reduced risk, cost, and time of implementation. Therefore, wherever possible, interface standards — typically between different vendors’ systems — are the most effective way to achieve the benefits of standardization.
Planning standards for the future
In the past few years, the focus of the TM Forum’s activities has shifted from helping streamline the internal operations of service providers to enabling their growth into new businesses by offering new services and business models. Dealing with the existing operations of service providers is much easier than planning for their future, and planning standards is going to become even more difficult. The future can take different paths, and initiatives are at higher risk – some activities may pan out while most will not. Furthermore, planning the timing and effectiveness of standards for future initiatives is especially tricky. All this makes the criteria I suggest above even more acutely needed by TMF to be successful as an industry forum—not only in foretelling the future, but in addressing it proactively, and even becoming a critical enabler of that future. Other forums are a great source of inspiration, including 3GPP, IETF, CEA, IEEE-SA, CableLabs, OASIS, and W3C. These forums have all been able, at times, to create the right specification at the right time for the right issues. TMF needs to consider adopting some of the best practices from these forums that have made them succeed. The TMF does not have the same kind of track record in creating interface specifications that reduce the cost, risk, and time of implementation. If it is to become a critical enabler of new businesses models and growth for service providers, it must learn quickly how to do so.
I’m hopeful that TMF will eventually begin creating, in earnest, interface standards, and drive these standards to industry adoption, while it adopts best practices from other successful industry forums. Specifications and even software implementations alone are meaningless unless the standards get adopted by suppliers and buying users of the systems.
I personally have, and will continue to, contribute within the forum to try to bring about these outcomes.
What are your thoughts about this subject? How can TM Forum continue to help shape the industry with standards that bring benefits to everyone in the industry?