What works and why

IT experts offer their advice on top technologies including VoIP, patching, WAN services, SOA, security and more.

VoIP: Ask questions upfront

By Tim Greene and Phil Hochmuth

Unforeseen VoIP glitches range from who gets the fancy phones to how you track phone use by department so you can bill them for what they use.

The phone project manager should have veto power over who requires more than a standard handset, or department heads will start dishing out the more expensive, feature-rich models to people who really don’t need them. “They want the phones with more buttons,” says Roger Fahnestock, IT director for Kane County government in Illinois.

IP call servers log calls, but don’t translate them into calls by department or flag the calls that cross the public phone network and incur toll charges. Customers should plan to buy software that converts the logs into readable bills if they hope to charge departments.

Businesses need to figure out how costs will be divided for VoIP, because it raises all sorts of questions. If a department gets one more employee, does it pay for the phone? If all the ports on that department’s switch are full, who pays for another switch? If the IT department pays, what is a good way to plan for such unexpected costs?

Businesses must figure out how long they want the phones to work when the power fails. A one-unit battery backup may support a group of phones for 20 minutes, but it may require extended-run battery modules to keep phones up for three hours. That means planning for the cost of the backups and also figuring out whether there’s enough space in the wiring closet to house them. In some cases, a back-up generator may be a better option.

Vendors have 911 schemes that link corporate IP phones to physical locations so ambulances can find the person who made a call for help, but these systems must interface with carrier 911 networks. Expect to dedicate time to make that interface work properly, because it is far from standard.

Departments left to set up their own interactive voice-response systems may come back to IT for help because they don’t have a good sense of how to set them up. For example, one user cited a department that created 10 options for callers to choose, forced them to listen to all 10 before they could punch a number, and had no option to bump out to an operator. As a result, everybody was hanging up in frustration before they made a selection. Then the department head complained that the phones weren’t working because there were no inbound calls.

If VoIP is intended to minimize the number of phone lines, businesses should plan to install a fax server to get rid of analog fax lines. And if modems are necessary, plan to keep analog lines to support them or be prepared to suffer with temperamental analog-to-digital modem-conversion gear.

Patching: First, it’s not impossible

By John Fontana

“Patch, patch, patch, test, test, test, test,” says Tim Rice, a network systems analyst in the department of medicine at Duke University in Durham, N.C. Those two steps, repeated in multiples year in and year out, more than any others are the keys to patching systems from any vendor. Rice doesn’t apologize for the apparent simplicity, because he knows the task is anything but.

What most IT managers say is that it takes a process to save a village.

David Giambruno agrees with that. His tip? “Fail fast.”

For Giambruno, director of strategic infrastructure and security for Pitney Bowes in Stamford, Conn., that means he knows where his pain points are in the network and he has documented why and how they may fail. “Fix the pain points last. Find out what is problematic, and once you do that, you will find you have a large area that is probably pretty easy to patch and [is] pretty vanilla. You get comfortable, and you can do those areas quickly.”

As for the pain points? “You are going to have to ask for forgiveness initially,” Giambruno says. But eventually, you document why certain systems are not patched or protected in other ways, such as with firewalls, because of aging applications, configurations, hardware or department heads with their own issues. Documenting those anomalies lets you answer intelligently the inevitable C-level question: “Why weren’t those systems patched?”

Giambruno says if you can’t answer that question, “you are the sacrificial lamb at that point.”

Duke’s Rice also has tips for keeping client upgrades as easy as possible. “Keep the hardware consistent. Windows XP is making that a lot easier,” he says. “We build an image, put all of our software on that image, do a system prep and drop the image on the hardware. At most, we run a repair.”

For Bruce Alcock, IT architect for Integris Health in Oklahoma City, Okla., one of the keys to client upgrades is preparation. His organization has forced end users to put their key files on network shares. “Everything is already on the network, so we’ve found this is not only beneficial for client upgrades, but if a user’s PC goes out, they lose whatever is on the local drive. Forcing them to the network solves lots of problems.”

WAN services: Maintaining flexibility is key

By Jim Duffy

WAN services experts recommend working flexibility into your contracts: Technology changes fast, as do prices, so they advise you to structure contracts that keep options open.

Coast Capital Savings of Vancouver, the second-largest credit union in Canada, has WAN contracts that run three to five years. Three years ago, the company intermeshed 58 offices with fiber services running VoIP to 2,000 phones.

At the time, the company negotiated “partial QoS” for this network. Had the company known that its telephone company would roll out MPLS-based services, it would have grandfathered in tighter QoS guarantees based on MPLS .

“Three years ago I didn’t know much about MPLS,” says Luis Henriques, senior network engineer for Coast Capital Savings. “Right now, we’re running over a partial QoS network that’s working 99% of the time, but we do still have 1% worth of problems. You’re signing for such a long time, and it’s hard to know what new technologies are going to come out there.”

Procurement consultants concur.

“If you say, I’m going to do nothing – I’m going to keep the network I have and just get a lower price – that used to be a good strategy in the short term, but it won’t work in the long term,” says David Rohde, a senior analyst at TechCaliber. “You’ve got to make some sort of decision about your technology migration now.”

Henriques also recommends working the best WAN prices into your contract, whether that price is available when you negotiate the contract or a few years down the road when you need those circuits.

“Today, a 10M bit/sec link costs you $1,000, but you don’t actually need any today. In three years, it only costs $200, but according to your contract you’re bound to buying it for $1,000,” he explains. “You’ll want a clause in there to say you’ll be guaranteed the best price at the time.”

Users should also grandfather service-level agreements into any new circuits they add during the life of the contract.

“When we signed our contract we had 45 branches,” Henriques says. “Since then, we’ve grown and added quite a few more. Fortunately, in that contract was a statement that said that any new links will adhere to the technical agreements in the contract, and they will expire at the same time in the contract. You want all your links to expire, as far as the contract is concerned, at the same time. Otherwise, it’s harder to manage and harder to negotiate a new contract when things are expiring at different times.”

Lastly, if any hardware is needed, Henriques suggests negotiating new equipment purchases with your WAN service provider. They’ve already bought a bunch of gear for their own networks and have wrung the best prices out of the vendor, he says.

“We took the opportunity to put in that contract that we would have a very low cost – a wholesale price plus a percentage, which is much better than we were able to get from any other networking vendor,” Henriques says. “We saved thousands of dollars with that.”

SOA: Here’s the real skinny

By Ann Bednarz

Creating a service-oriented architecture is like dieting: As much as it’s tempting to shell out money for the latest promising gimmick, the reality is that reaching the goal requires a significant lifestyle change.

“Weight loss is a very much like SOA in that it’s a discipline,” says Ron Schmelzer, a senior analyst at research firm ZapThink. “It’s more important to change the behavior, if you want to change the outcome, than it is to buy something new.”

An SOA is a platform for building modular, reusable application components that can be called and combined without the integration pains of past development efforts. Pursuing an SOA approach promises to make new and existing IT assets more flexible – and therefore more easily tapped for use in different, innovative ways.

But like the latest diet fad, the SOA approach is vulnerable to backlash from unfulfilled expectations. For example, reuse of services is a key element of an SOA, but it can be very difficult to achieve if teams are unwilling to share applications, says David Chappell, principal of research and consulting firm Chappell & Associates.

Companies can try exerting pressure from top management, or implementing a charge-back policy whereby internal customers pay the internal service suppliers, or selling the idea of reuse, because it’s best for the company as a whole – but none of these approaches is easy, Chappell says. “I’ve talked to organizations whose SOA efforts stopped dead because they couldn’t deal with this problem.”

Another roadblock to SOA adoption is the tendency for companies to gravitate to familiar technologies.

A lot of people are pinning their hopes on the emerging category of enterprise service bus (ESB ) products, many of which are little more than old-school messaging brokers with new labels, Schmelzer says. Adding more of the same, familiar infrastructure products just continues the cycle of technology rip-and-replace, he says.

“People are really overestimating the ability for these ESB products to deliver a service-oriented architecture for them.” On the other hand, the importance of tools that support a change in development behavior – such as process-modeling tools, metadata management and registry products – are underestimated, Schmelzer says.

Equally important to the success of SOA is understanding when it’s appropriate. Zeroing in on a specific business need can help companies make decisions about how much of their existing applications to service-enable, says Theo Beack, chief SOA architect at Software AG. In many cases, exposing 20% or 30% of the functionality of an existing legacy application as a Web service can yield the most benefit. “That’s where the sweet spot lies,” Beack says.

It’s also important to understand that not every new application should be built in a service-oriented style. It takes more effort to design, create and secure a service-oriented application than a traditional multitier application, and not all applications are likely to repay the expense, Chappell says. “An application that’s meant to be used only by a relatively small group in an organization might not be worth the expense of being built in a service-oriented fashion,” he says.

Key to avoiding wasted resources is having the right people behind an SOA effort. A lot of good developers make lousy architects, Schmelzer says. Companies today are hiring architects that are measured against business goals – such as how quickly a service will return value to the business – not traditional development goals.

“If we can get it right, the emergence of the architect class will be a pretty significant transformation for the IT industry.”

Security: Think people first

By Ellen Messmer

Managing security is as much about managing people as it is software and hardware, say those who do it for a living.

Kirk Drake, vice president of IT at the NIH Federal Credit Union in Rockville, Md., says one of his favorite management tactics is touching base every day with the IT staff in charge of network and applications.

“I figure out the things that absolutely shouldn’t go wrong, from routers to financial things such as dividend postings and check files, and accept no compromise,” Drake says. “I send out periodic reminders and check to make sure that things get done.”

This approach is intended to get ahead of problems through regular contact with the dozen IT staff members that support the back-end applications and the online banking used by the 45,000 credit-union customers.

“I look at log reports and ask questions,” Drake says, noting constant dialog with staff has been crucial in deploying newer technologies, such as data-leakage prevention to stop unauthorized transmission of sensitive customer information.

Jack Mackenzie, principal information security engineer at mortgage insurance company Radian Group in Philadelphia, says the tip he’d offer first also has to do with helping people be more effective in their jobs. Radian Group has five security specialists interacting with an IT staff totaling 140.

In the past, IT staff would tend to describe problems they’d encountered, depositing them at his doorstep, waiting for him to discover something that might resolve them. But that method didn’t lead to successful resolution very quickly, he says.

Mackenzie now lives by the adage that “I never take others’ problems and make them my own. I’ll steer them toward solving it.” He says he helps staff with analysis, answers questions and suggests security approaches, but makes it clear he expects those directly in charge will execute any necessary changes. And he checks to see that it happens.

He says this approach encourages IT staff to more directly confront security concerns, and “problem-solve and bring the solution back.”

E-mail archiving: Better safe than sorry

By Deni Connor

While many organizations implement e-mail archiving for regulatory compliance or evidentiary discovery purposes, Paul Veeneman, chief technology engineer for Hawkins Chemical in Minneapolis, had an entirely different reason: He wanted to protect one of his company’s most business-critical applications: its Microsoft Exchange database.

Veeneman had been protecting his Exchange 5.5 server with daily, weekly and monthly full backups. While he had backups of Exchange that he kept for a year, from time to time he might lose e-mail between backups.

“We wanted to look at scenarios that could cause potential harm to the users or business unit if data was lost,” he says. “E-mail is one of the most important applications to our organization and we wanted to move it to an archival platform.”

The company also wanted to be able to archive more than a year’s data.

“Being publicly traded, we wanted to do due diligence to our shareholders and ensure that our data is archived or backed up in the best fashion,” Veeneman says. “Although we don’t have the same requirements as a company with a trading desk, and we aren’t burdened with finding the irrefutable truth for litigation, being able to recover e-mail has come in handy when someone lost a message.”

Veeneman chose Intradyn’s ComplianceVault, an e-mail archiving and recovery appliance. ComplianceVault connects to the Ethernet network and is bundled with Sony AIT tape drives, where e-mail data is archived. A rules-based engine allows Veeneman to decide when e-mail is migrated and archived and how it can be recovered.

Veeneman says being compliant wasn’t completely a matter of out of sight, out of mind.

“With Sarbanes-Oxley, we are definitely being held to a higher standard in protecting the data and making sure the data is available even if the user or system loses data,” Veeneman says.

He says setting up e-mail archiving also involves determining which users have the ability to recover messages. In Hawkins’ case, Veeneman chose a limited set of individuals.

“We don’t give end users the ability to get in and retrieve their own data – that creates a Pandora’s Box,” Veeneman says. “What we have done is gone through a secure hierarchy of two to three users who can access e-mail – IT, human resources and two for the desktop IT group.”

“There’s a potential for malicious activity, and giving human resources access protects us from that,” he says.