The Business Case for Standards and How Management Will Cope An Interview with NMF

Anyone who follows the impact of the FCC's interconnection order on OSS knows there are serious difficulties, both concerning legacy system integration and management network interconnection. Technological complexity is part of the problem, but other facets such as obsolete corporate structures and underinformed management, especially within the RBOCs, are contributing just as much to the general lack of progress in the back office. At NMF's 20th Communications Management Forum and Expo, Billing World had the opportunity to discuss current OSS standards issues with two of the forum's directors, Elizabeth Adams and Keith Willetts.

Elizabeth Adams is managing director and COO of NMF. She has more than 25 years of experience working for telecommunications companies such as AT&T, where she managed switched services, including WATS/800, and served on the 1984 divestiture team. Adams expertise covers network operations, service management, business process re-engineering and systems integration. Keith Willetts is founder and president of NMF and a senior vice president with object-oriented software provider TCSI. Formerly with BT, Willetts is recognized as an authority on network and service management and has significantly influenced the development of many international standards. Adams and Willetts wrote The Lean Communications Provider; a book that addresses what service providers need to do internally to succeed in the new, competitive market. It covers topics such as service management, automation and process flow-through, systems integration, reducing operational costs and quality of service improvement.

Billing World: NMF is a facilitator for ideas to be shared throughout the industry. Still, enabling competition, improving network and management infrastructures will take more than developing standards. Issues enter into this that no group can handle, such as the psychological re-structuring within a carrier, or in other words getting people to change the way they look at their job and their company. What will it take to change the intangibles that are stalling the industry?

Willetts: I know a lot of people who really tune into [the psychological issues] and it's actually the biggest single barrier to change. The way the companies are organized doesn't fit É this idea of process flow-through. The problem is that you've got all of these hierarchical divisions in telcos, sort of a military style government, monopolies around the world, and the RBOCs don't look any different. Though they're private companies they're still pretty rigid. So process has to flow through three or four different organizations. Trying to get those three or four organizations to work together to come to a common view of what the problem is they're solving, to make common procurement decisions, is extremely difficult. It's all psychology, it's all in the heads of people who think, "Well, if I do this I'm out of a job. If I do this perhaps I lose some political power to this other group." There's always internal reasons for lack of progress...particularly in the RBOCs. I deal a lot with the RBOCs. They're fossilized managerially. They may have some very smart technology, they can take you to some wonderful data center and show you some whizzy new fiber technology, but managerially they're quite primitive.

Adams: There are a number of things that NMF actually has done to help with that problem. People were here [at NMF meetings] and they'd say, "How do I get the message to executives? They don't seem to be clued in. I understand [our problems and the standards] but they don't. "...Keith talked about process. With the emphasis that we've placed on process, in developing the service management business process, and now we're filling in the network management pieces of it, those kinds of things, I've seen when I talk with companies, tend to help based on some of these rigid cultural barriers between organizations. I do sense when I talk to folks at some of the NMF meetings that they are now much more likely to take a broader view. I think we've helped there. The other thing I think has been interesting, and it's still evolving, is that I think we've done quite a lot to break down the barriers between the telephony and IT parts of the company. Those used to be very separate, and when we started the SPIRIT initiative there was a vast separation in understanding. They (people on the IT side) didn't have a view. They kind of said, "We don't have anything to do with these management systems, we just want to do IT." I said, "You don't understand, the management systems are your clients. If you don't view it that way..." and they said, "No, we do general purpose things like billing," and I said, "that's a management system, that's part of management." "Oh, really!?!?" they said. So, we've come now after a couple of years where the IT people are much more tuned in, I think, to where they are with telephony. And certainly with the move away from pure telephony kinds of technologies and into more general purpose IT, the telephony folks are starting to break out and look around a little bit. I think those are some places where we've helped a bit, as much as you can. Beyond that you're absolutely right, there are cultural things...

Willetts: I think it is changing. I do honestly think that one of the only groups in the world that talks about it is here (NMF). Beth and I are invited regularly to meet with senior executives of telcos from here, to Brazil to the Far East. They do listen and they're very anxious to know what they need to do to change. Now, you do sometimes get a cap. You've got the activists buried in the organization. Even if the senior managers say "yup, buy into it" you still have to go through this sort of curvy middle management layer. But, all industries have to go through that. Take IBM, IBM was a classic case of that, and [IBM CEO Lou] Gerstner's made it, I don't want to say it's lean and mean yet, but it's getting leaner and meaner.

Billing World: What happens if standards aren't put in place? If industry- wide standards agreements can't be reached? And isn't there the risk that some standards may be obsolete by the time they are completed?

Adams: I guess my view is from a competitive perspective. This is the discussion we often have with senior executives because the first question people ask is, "Is it really a good thing for me to work this on a standard basis as opposed to doing my own thing?" And there are still companies who say, "It's my competitive edge to do things differently." [It's important to] understand where there is value and where there isn't value in having things different. I think one provider put it quite well at one point. She said, "We're negotiating agreements with companies all over the world and there are going to be issues of a business nature where we're going to have to take a stand and we're going to need to win." And she said, "I don't know É what those areas are yet, but for sure it's not around accepting our version of a trouble ticket. It's far healthier for us not to be seen as 'the heavy' with partners. It's better for us if we can say "rather than argue between going with your way or my way, let's go with one that's industry common.'" If you were to talk with a company like Unisource for example, the amount of time they spend just negotiating agreements for how to exchange some pretty rudimentary information is astronomical. So they desperately want to implement some of these [standards] quickly. The focus of all of [our] current work is on how quickly [it can be implemented]. Let's get the people in the room together who can actually do it.

Willetts: I think [there are] two drivers that make [implementing standards] such an overwhelmingly sensible thing to do. [In the partnerships in Europe], every one of those players are in and out of bed with each other. SBC's in this consortium in one country and in a different consortium in another country. It's like putting cream in coffee, it's all mushing down. RWE has been in every consortium in Germany so far, and if they said "the RWE way is this and you will all connect to us" it would have been impossible É because they are making networks out of other peoples" bits of networks, unless they've got some common processes and standards. And I know that RWE, as an example, does have an architecture that closely follows NMF. On the other hand, it's just plain simpler [to use the standards]. If you've got to take an integrated view of systems in order to get this process flow-through, and you're trying to connect many, many diverse things, [you'll need] a huge amount of custom software. Whereas if the things you're trying to integrate are themselves standardized it makes it easier. So there's some very big drivers as to why it should happen. Does [developing and implementing standards] take more time than their shelf-life? There is some truth to this. The standards making process comes out of the formal, very heavyweight process of getting national standards consolidated up to regional standards to global standards. And then making them usable is often a five- to 10-year process. CMIP [which took 10 years to nail down] is now being positioned as one of several protocols that are appropriate, where a few years back it may have been looked at as the standard for doing everything. We were hearing yesterday, for example, that for every one CMIP programmer you can find 10 CORBA programmers and 100 Java programmers. And what're you gonna do? You'll pay a lot more for those CMIP programmers. I think there is some benefit in moving more quickly because the industry isn't going to sit there and wait for you to get the standards done. I think the NMF has been, since its first inception, a very insistent, in-a-hurry type group. People look at the NMF and say it doesn't move fast enough, but boy, it's lean and mean compared to some others.

Adams: We used to do all our work in CMIP/GDMO, that's all we knew. So if you look at our existing solution sets, they're all CMIP/GDMO. (See box, page 23.) We never went through a structured process of writing the physical requirements of the interface, and then doing an information model. There was an information model, but it was characterized in GDMO. We changed that now. We kicked off a team a year ago and it has come amazingly fast to change our mindset so that we're really moving NMF into an object-oriented view of life. Among the documents approved [at this conference] was this information agreement with a protocol neutral information model...which gives us better flexibility in terms of the technology change. It's a much better "future proofing" kind of a thing to say "okay, over the years, perhaps CMIP may be less important in some of these areas and Java or CORBA will start driving down as they become more robust." So as long as we've got the information model capable of being interpreted in different languages, and the JIDM [joint inter-domain management], the CORBA-GDMO kind of agreement, then as long as we do things like making the object library available [we shouldn't run into any major problems].

Billing World: If all goes well, how long does it take to get the standards in place? Have the FCC's deadlines helped or hurt this process?

Willetts: Some of that is already [done] of course: Electronic Bonding is already in place. Some RBOCs are going faster than others about opening up their interfaces. I think in the short term [the FCC act has] caused complete mayhem. It has paralyzed decision-making in the RBOCs from an operations system standpoint. I know that from a supplier point of view, you can't find anybody who can make a decision because their company is about to be acquired by another RBOC, or they're merging with another RBOC and the systems policy is on hold. ...there's also some evidence to say that the RBOCs believe, a bit like we were hearing about Germany, that if you just drag your feet and slow it down that this competition stuff will go away somehow. And certainly the FCC put very unrealistic time scales on these interconnect agreements. They gave three months or six months to do a job that realistically would take two years, even if you're going from "here's your marching orders" to getting it up and running and working. But the reality of life is that I think some players at least would rather the standards didn't harden up in their area because they think that's then a good reason to say to the FCC, "Well, we'd love to have done it but the standards weren't there."

The reality is that most of the standards are there, or pretty much there. They're either there through the work of the NMF or through North American standards bodies like the OBF. I would say the cycle time given an industry that wanted to do it, say from being told to do it to having things up and running in a pretty standard way is a couple of years period. What the FCC's view is I don't know. Why the FCC gave them such a silly, short window...

Billing World: What was that short deadline a result of? Was it intended to put pressure on carriers to get the ball rolling or was it just a matter of ignorance?

Willetts: It may have been to put the fear of God in them (RBOCs). It may have been just sheer ignorance itself.

Adams: Although, having said that, the short-term solutions are pretty much meeting that deadline, so I'm not sure whether if it were six months or one year that it would have been much better than the short term. They probably would have just waited a little longer to [open their interfaces]. They've obviously found ways to do it, they're clumsy, but to at least meet the letter of the law for competition purposes, [the Jan. 1 deadline] wasn't too unreasonable, at least at a gross level, to get that started. I think the real issue for the providers is "no, we can't stay with this [interim OSS interface]," but now that they've got it in place there's probably more of a sense of urgency to move toward something they can live with before the violence starts and they get killed.

Billing World: What about the suggestion that vendors may be hesitant to move to the standards because they want to protect their products and product differentiation?

Willetts: That's been an old nutshell since the beginning. I've heard management trot it out year after year after year and it just simply doesn't wash. You're being told by this vendor that, "Well, we're not standard but we've got this wonderful kind of thing." All the vendors do is complicate the life of the RBOC or the operator and therefore the operator has to say, "Well, it's got to be an overwhelmingly good deal to get me to swallow all this proprietary stuff because I've got to figure out how to integrate it." ... I'm predicting that we'll now start to see major players, the large Japanese, European, as well as North American equipment vendors, lose big contracts because they didn't have the right kind of standards support. And that hurts big time. They go running back to mother and say "we've got to rethink this."

Billing World: What about vendors who claim to be TMN compliant but really aren't?

Adams: We have what we call a component set for a TMN basic management platform for that very reason. Because we have computing suppliers coming out and saying they've got a TMN platform, but some of them did nothing more than contain a CMIP protocol, which is pretty useless. That's where I think organizations like NMF have to set the hurdle and say we've got to be precise about [specific aspects of TMN]. One of the things I've been harping on in the industry is that the service providers aren't very helpful in this matter and I think it's just out of ignorance, to be honest with you. One operator was asking me, "Is it possible to over-commit to TMN?" And my response is, well, if you think about the [TMN architecture], no it's not. Just embrace that thing, understand it, think about your own processes, do whatever you can to start thinking about how your information flows...The standards themselves are another story. There's been a tendency on the part of service providers over the years to say to their supplier, "I want you to be TMN compliant," which of course isn't defined, and so the supplier comes back and says, "Which of these hundreds of TMN recommendations are you really interested in?" "All of them," they say. What I tell the service providers is, first of all, these standards are only useful as a means interoperating, which means that your systems have got to implement them as well as the suppliers". If you don't, you get no value. That thing may be TMN compliant or it may not and you'll never know it. The supplier understands that when you ask them to be compliant to everything you're telling them flat out, "I have no intention of doing anything to take advantage of them. I'm just requesting standards because it's the safe route," and that's dumb, it's just not good business. We're on a campaign to educate service providers to say "don't ask for TMN compliance, you're doing yourself a real disservice, ask for a solution set." That's specific, that's a certain subset of standards that's very well defined so that you will not get hoodwinked by the supplier. But frankly, the suppliers if they have this, some of them have been delighted to comply. And for them it's a saving. Instead of having to go insult the customer by saying, "You don't know what you're talking about," [many suppliers will say instead] "Okay, we'll be 'TMN compliant', because they'll never know anyway." [Solution sets] give the industry something that's much more specific to shoot at.

Willetts: At one end of the spectrum, some members told us, "Yeah, sure we're TMN compliant," when they really haven't got very much at all, they've got a thin slice. And the other end of the spectrum, which is the safe, vault and braces service operators asking for every one of literally hundreds of component standards that make up TMN. In some ways É as we stretch TMN to cover more than just network management, we go into service management, and invite in other protocols like CORBA and Java, we run the danger of making that problem worse. Because if you've got two or three technologies in the TMN mix vendors can say, "Sure we're TMN compliant," because we've made the box bigger and they've got this little, small part. And you do again invite the service operators to do this nonsensical thing, and ask for everything that could possibly be in TMN, as opposed to saying that for this job we'll use this part of TMN. I think it makes a roadmap of our work over the next several years; if we open the aperture of TMN, we have to do more and more of this solution setting to make it real, otherwise you just get the two ends of the spectrum.

Adams: The same company that was asking about overcommitting to TMN, I'm sure, [was] expecting me to just say, "Go for it, support it all the way." And when I didn't, their faces kind of fell. But I said, "If you cannot build a business case for every standard you ask for, you shouldn't be asking for it because you don't need it. If you don't know what the value is you're going to get out of it, don't ask for it, you're just wasting your time, you're wasting your supplier's time, you're going to pay for it, and it's meaningless." And I think we'll need to keep pushing on that, to keep making it relevant to business applications, relevant to something that can be developed into a business case.

Billing World: Is there a certain amount of education that goes into learning how to build business cases for specific standards?

Adams: There sure is.

Willetts: [Yes, for example look at] Newbridge; they're a company that has taken the opposite view to this and say okay, to make us stand out we're going to be very good at this management thing. They've got a TMN interface package where they've shown interoperability with other vendors. In my company, TCSI, I'm out there selling software layers above the equipment, and it's actually quite a pleasure to come across a company that's got Newbridge because I know it will be easy to integrate because they stick very cleanly to the standards. Another vendor is much messier. It takes forever to unpick what they've done, even if they're "TMN compliant." Most of the menu is still proprietary and it's just horrendously difficult to integrate these systems. Either we do it on behalf of the service provider or the service provider does it themselves. It can take a long, long time. Whereas, at our Barcelona meeting, Newbridge was there and they'd implemented a solution set, and they found out the guys a few booths away had implemented it, and I don't think it was planned, they said, "We'll try it out." They flung a cable across the top, plugged it in and it worked. That's something that from personal experience can be nine months of integration, including testing and so on. So there are some vendors around who are actually turning [the standards] into commercial advantage.

Adams: And Newbridge is doing quite well as a result. If there's ever a good business story to be made, they're it on the equipment side because I think they've proven that standards can be a very profitable route to go.

Willetts: It's classic though, you take IBM. IBM was the one who for years said, "Well, international standards are very well but..." and you've got other companies coming around the side of them that played the standards card. They played the open card and I think that's what Newbridge is doing to the big giants like Siemens and so on.

Billing World: And that puts a lot of pressure on them...?

Adams: Well it does, and it was interesting that Siemens just announced at...an NMF press review, unbeknownst to any of us, [that] they had just implemented our switch interconnection management solution set. We didn't know they were working on it, but they announced it and we said, "Holy smokes, this is great" because they're the vendor that you look back and think, "I think it'll be a while before they do anything." And quietly and unobtrusively they just implemented [our solution set].

Willetts: Siemens has taken on TMN with a religious fervor, mainly because Deutsche Telekom is requiring it. There's some interesting cultural things going on. The Japanese market is wall-to-wall TMN because if NTT says that's how it [goes] then they're going to do it. The German market, RWE for example, Deutsche Telekom, Siemens, because they're quite a conformist society [they adhere to standards as well]. America, it's all over the map: "I've got to do what you tell me, hell, no."

Adams: We're cowboys.

Willetts: So it does go culturally. As business becomes more international we'll see the mushing down of this [resistance to the standards].

NMF is a nonprofit organization made up of members from the global service providing, equipment manufacturing and software development industry segments. Divided into three major work programs-Service Management, Network Management and Platforms and Technology-the NMF is responsible for defining the ITU's Telecommunication Management Network (TMN) standards guidelines. These standards are critical to the development of competition and the successful modernization of carrier management networks.

The goal of TMN is to provide specific guidelines by which a telecommunications provider may create a standardized, automated management network to more effectively and economically manage, maintain, provision and expand its service providing network. TMN is also intended to provide a standardized method for OSS interconnection and for linking separate carriers' management networks or TMNs.

CMIP: Common Management Information Protocol. CMIP is a sophisticated, OSI-standard protocol used for transmitting network management information in a manager-agent paradigm, within a carrier or across corporate boundaries from one management network to another. Originally, CMIP was the protocol of choice for TMN, but NMF has stepped back from it to allow other protocols, such as Java and CORBA, to be considered as well.

CORBA: Common Object Request Broker Architecture. Developed by the OMG (Object Management Group), CORBA allows applications to communicate regardless of location or developer. It is designed especially to facilitate communication among applications in a heterogeneous environment. CORBA was introduced in 1991 with a defined Interface Definition Language (IDL) and APIs that enable client/server object interaction within a specific implementation of an ORB. The ORB is the middleware that passes and translates objects between heterogeneous systems.

GDMO: Guidelines for the Definition of Managed Objects. GDMO is the standard for object definition in a CMIP-specific, TMN-standard system.

Java: Java is a relatively new language with many potential uses. Java is being considered for network management purposes because it is hardware-independent and can run on basically any system. It also provides a relatively simple and inexpensive development environment and can be used to enable interoperability in a heterogeneous computing environment.

JIDM: Joint Interdomain Manager. JIDM is an NMF solution set that defines the algorithms for automatically translating between CMIP or SNMP (GDMO) and CORBA.

Solution Sets: The NMF develops solution sets to provide specifications for implementing specific aspects of TMN directed at solving a particular business problem. Solution sets are essentially instruction manuals for developing specific TMN systems. A carrier, or someone looking to purchase TMN-compliant equipment or software, could also use a solution set as a defined set of specifications for a supplier.

SPIRIT: Service Provider's Integrated Requirements for Information Technology. NMF continues to develop SPIRIT, a set of software components that provides a standardized, high performance client/server platform designed specifically for telecommunications providers using existing technology. This initiative was undertaken to start a move away from proprietary, telecommunications specific systems toward standard systems that can allow a provider to mix and match and more easily expand its IT infrastructure.