Telecom analyst Alan Quayle recently polled CIOs during research into business transformation, and discussed the results on his blog (http://www.alanquayle.com/blog/2011/02/its-time-telcos-made-some-chan.html). Alan made a surprising discovery: “In a market study I performed last year on business transformation, to my surprise, few operators conform to the TMF specifications, most have no intention. Even BT, the founder of TMF, does not consider its architecture TMF-compliant.'”
The problem with standards advanced by TMF, according to Quayle's research, are significant.
“All Telcos deliver the same services: voice, video and data to pre- and post-paid customers,” writes Quayle. “Commonality should be high, yet TMF has failed to deliver...Frameworx is seen as a repackaging of existing specifications, its perceived as marketing spin, not progress on specifications created in some cases 10 years ago and based on nearly 30 year old ideas created at BT and AT&T.”
This point has not gone unnoticed in the vendor community.
In a post on the official Amdocs blog, Tal Givoly wrote:
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.”
The Role of Standards in the Future
Essentially, as it relates to the OSS and BSS software, the problem remains that many vendor solutions are closed—that separate vendor systems cannot interact with each other without some heavy mediation software or custom code. High-level compliance to regulatory, protocol, and security requirements is not really the concern, because there are financial incentives that prompt vendors and carriers to stay at the forefront of, say SIP for VoIP, or a fiber standard like OC-192.
As Alan Quayle explained to me, “The biggest issue is for operators to get their data out of vendors solutions that try to lock them in, so that needs to be spec’d, at least at a basic level, and let’s face it, a call is a call whether it’s happening in Outer Mongolia or downtown Chicago.”
In an article for business management on the official British Telecom Blog, BT writes: “Don’t feel like you are tied to any of your suppliers. If they no longer meet your needs, or fail to give you the value you deserve, they are no help to your business or your bottom line.”
This will become increasingly important as carriers, like BT, seek to establish IP interoperability offerings to create and market communications systems that extend across multiple network domains. A white paper BT released at the end of September outlines this strategy:
Services like high-definition (HD) voice calling and video calling can deliver much-needed revenues for fixed and mobile network operators, ISPs, and over-the-top content and application providers. But they are available only in islands: there is little interworking between different providers’ services, and it is limited between managed networks and over-the-top internet applications. If service providers can enable interworking, the potential extra service revenue may be as much as £3.5 billion globally by the end of 2015, and more beyond.
Widespread adoption of open interoperability standards could drive a revolution in the industry. We could very well see a commercialized communications operating system, or CommOS, evolve from this concept in the decades to come. (For further discussion on this topic, check out this article).
In the general IT space, there is a considerable development in this direction, led by SODs like the IT Infrastructure Library (ITIL) and The Open Group Architecture Framework (TOGAF). Who is positioned to lead this charge for the OSS/BSS marketplace? Certainly the ITSMF and the DMTF are doing valuable work in this area. But probably the best candidate for driving this change, as Amdocs noted, is the TMForum itself, although it would have to undertake a considerable business transformation of its own to become an enabler of the CommOS revolution.
