• United States

Speak the language of convergence

News Analysis
May 08, 20064 mins
ERP SystemsNetworkingVoIP

Butler University learned to keep an ear out for confusion over the terms and concepts used when groups collaborated on a VoIP deployment.

When Butler University recently migrated from an on-campus hosted Centrex phone service to a Cisco CallManager VoIP system, one of the first challenges it encountered was to get more than a dozen staffers from the voice, data and application groups speaking the same language.

The Indianapolis-based institution wanted to integrate its voice and data networks physically, meld several back-end applications – such as its PeopleSoft ERP system – and update its interactive voice-response system for self-service information-gathering.

The deployment took two years, from planning to completion in late 2005, and required a lengthy RFP process, an independent consultant to provide outside perspective and advice, and the gradual merging of four separate staffs: data and networking, telecom, facilities management and applications, says Scott Kincaid, CIO for Butler University.

The integration of the staffs was smooth, Kincaid says. But after a few meetings with everyone in the same room, Kincaid realized how high the barrier of technical language and jargon was going to be.

Say what?

“First, we started talking about MACs,” Kincaid says. “I thought it was a PC-vs.-Macintosh debate; the voice people are talking about moves, adds and changes; and, of course, for the data people, this was about the Machine Access Control addresses” on the IP phones and PCs on the network.

In addition to overlapping acronyms, concepts that are second nature to one group may mean something different to another. An instance of this was the idea of an extension.

“In the middle of our project, we kept using the word extension, and we found it was a meaningless term,” Kincaid says. To telecom staff, an extension was a logical endpoint that could ring in possibly multiple places. Data staff thought of an extension as a physical phone, not a programmable port or portable number that moved around. “Then you had the PeopleSoft/ERP team members, who thought we were talking about data fields in a software product,” he says.

Another concept that needed to be defined clearly as the project got underway was the word directory, Kincaid says. To the data group “this is all about Active Directory and [Lightweight Directory Access Protocol],” he says.

For the voice technicians, directories were lists of phone extensions. To the programmers, these were the file structure and hierarchy of the servers and systems on which the ERP software and applications were running. The trickiest part about all of this, Kincaid adds, was that eventually all these concepts would have to come together: Cisco CallManager runs Active Directory, which includes phone extensions and dial-plan data, and is stored on Microsoft Windows 2003 servers in a directory hierarchy.

Besides separate definitions of terms, Kincaid says he found the groups differed in their approaches to and philosophies about maintaining and managing a network, because of habits and tendencies built up over the years related to the technical cultures of each group.

“Most voice people I work with seem to come from a mainframe background, and they have that kind of mentality. There’s a centralized mind-set to it; there aren’t that many of them, first of all,” Kincaid says. “They like documentation. And there are only so many things you can do on a PBX. They’re used to a very stable environment.” Above all, he adds, “They tend to have this belief that end users have a God-given right to [a] dial tone, and you have to respect that.”

As he worked with data people, he found their approach was more distributed and decentralized. “The data people were comfortable and used to pulling different pieces together. But they’re not used to having someone come into their network without them being in the loop.”

Using an outside consultant was key in helping the converged IT staff at Butler understand their communication differences and various philosophical approaches.

“It was important for us to have an independent consultant, not to make the decisions or to lead the project, but to guide us and help keep a level base line,” Kincaid says. In meetings, the presence of an outside voice helped encourage the members of each IT faction to clearly describe what they were talking about in the larger context of the project.

Above all, a group of users – university staff and faculty – had the biggest jargon-cutting role in the combined IT organization. They were not afraid to raise their hand in meetings and question what the IT staff were talking about, Kincaid says.

“We got into all of these discussions about QoS and data packets and security; none of that mattered to the user. What mattered to the user was the phone conversation. The call center being there. Having availability to information. Having them involved was probably the most important step we took.”