Martin Creaner, Chief Technology Officer, TeleManagement Forum

Service providers and independent software vendors have long used the TeleManagement Forum's enhanced Telecom Operations Map (eTOM) and Shared Information Data (SID) model, along with other tools, to design their back office infrastructures and solutions. But always on a quest for better tools, the forum's Service Provider Leadership Council urged to TMF to develop something to help them grapple with realities, not just ideals.

So one year ago, TMF members AT&T, BT, Colt Telecommunications, EDS, Metasolv, Oracle, QinetiQ, Sprint-Nextel, SunTec, TDC, TeliaSonera, and Tribold launched the Telecom Applications Map. Two weeks ago, TMF released Version 2. Martin Creaner, chief technology officer for the TeleManagement Forum, talked to Telephony's Tim McElligott about the project's progress--and threw in a teaser about the forum's Prosspero project.

Why the need for another design document--another map?

First, a little history. We have the eTOM, which describes all the processes, all the activities that happen within the service provider environment. And we have the SID, which describes all the information that exists inside that environment. Theoretically, you could extend the processes and the information to describe anything that goes on inside a service provider environment.

Now service providers are saying all this is well and good, but in fact they have real systems, and when they look at the boxes in the e-TOM and the systems in their own environment, they can't do a one-to-one mapping partly because some systems are involved in multiple processes. So what they really wanted was a map of the systems that actually exist in their environment as a companion framework to the eTOM framework. That's why the TAM was developed. It represents the real applications and systems inside the environment and helps them rationalize what that have. The idea came directly out of the Service Provider Leadership Council.

What's new with the TAM since the project launch?

Version 1 of the TAM was produced a year ago as a very high-level, but useful guide to the systems that sit inside the service provider environment. Version 2, which came out two weeks ago, is a much more vigorous description. One carrier doing a lot of acquisitions lately told me last week they have been trying to rationalize all their systems and said they used the eTOM to do that. I asked them why they hadn't used the TAM and they said the TAM is exactly what they were looking for, but it was only on Version 1 and was quite lightweight. Now that Version 2 is out, they said it looks like it's just the beast they need. It's much more rigorous and comprehensive.

TAM Version 2 will be a huge hit across the industry, particularly with service providers, but also with vendors. They have traditionally gone to market with a basic offering and said next year the product will be bigger and the year after will do more things. That isn't necessarily what service providers are looking for. More and more they are looking for products that focus on a specific need--scratch a specific itch. They don't want to buy a huge product where they'll have to turn off 80% of the functionality. Now they can use the TAM to tell the vendor to restructure their product for individual needs.

How is the TAM being used today?

Over the last couple of years, service providers have become cleverer and have used the eTOM with their procurement process and in building their RFPs. Now they are using the TAM to help build those RFPs. The TAM has a huge amount of boilerplate text describing what things do. They then add their own requirements, and that becomes the basis of the RFP document.

Right now the TAM is used mostly to rationalize systems such as fulfillment, assurance, billing and traditional back office capability. But a lot of my discussions over these last months have been around the huge importance of a service delivery platform (SDP) and framework. Service providers are asking why TAM doesn't talk about digital rights management boxes and content repurposing boxes--and they are right. So we kicked off an activity to clearly define the different aspects of service delivery platforms. Companies like Oracle, AT&T, Accenture, HP, Telcordia and BT are involved with coming to an agreed definition of what a Service Delivery Framework looks like, then agreeing on how to extend that to the TAM in order to adequately describe it.

What will you have ready by TeleManagement World in Dallas?

Today everyone has about 20 different pictures of what an SDP is. By TMW we hope to have that reduced down to a few commonly shared views of what an SDP is. Then we'll translate that to a more rigorous definition, but that will take a little time. Our goal is to have Version 3 in the February or March time frame.

Where does one map end and another begin?

The maps all address different aspects of the same problem. You can't structure them entirely differently. Individually they'd all make sense, but when you tried to use them together everything would fall apart. It's like the English language: The eTOM describes al the verbs, all the action, like authorizing a credit card or activating a customer. The SID only talks about information--in other words nouns, the types of things that get handed off. The TAM talks about things, too, but a much bigger aggregation of things, the real systems. So the TAM is structured in exactly the same way as the SID but with different domains.

Will it be proposed as a standard?

It's going to get there. eTOM took five or six years before we turned it into an ITU standard. It is certainly not ready for that yet. Probably another year or two of development before it's as mature as the eTOM.

What's new with Prosspero?

It has really matured over the last couple of months. The whole idea behind Prosspero is to identify interfaces that are ready for mass-market adoption and then make them much easier to implement and destroy all the barriers to implementation. Since Nice [in May], we have clearly developed the whole process and identified the first few interfaces and built all the implementation stuff, which we'll launch as Dallas. There will be a trouble ticketing interface, inventory and maybe fault management as well. We're also trying to line everyone else in the industry around this and get service providers to consistently ask for Prosspero interfaces and get the suppliers to be ready to support it.

But the big area for Prosspero in 2007 is fleshing out other areas like SDPs. Interfaces are only beginning to form in that area, but service providers are saying they would like Prosspero interfaces right from the start in the area of SDP.