Columns

Avoid these 5 Host Integration Mistakes

IT managers share the lessons learned from host-integration deployment.

• By Joseph McKendrick
• 07/01/2002

In many respects, the past decade could be called the "Big-Box" era—when big-box stores and big-box cars came to dominate our landscape. The computer industry went the other way—to very small boxes. Unfortunately, in the process, many companies ripped up their big boxes in expensive (and sometimes disastrous) attempts to migrate systems and applications to smaller boxes. Throwing out the host certainly ranks as one of the classic mistakes in host integration.

Lately, however, mainframe and server consolidation have come into vogue, along with impressive advances in host-integration technologies. Big boxes are back. In recent years I've spoken with numerous IT managers about how they successfully integrated—rather than ripped and replaced—their big boxes with small boxes. Here are some lessons they've learned in the course of their host-integration deployments.

Mistake #1: Not keeping end users involved in the process.
Upper management is usually blissfully oblivious to the hows and whys of host integration. However, your end users care a lot about how the eventual interface will look, feel and act.

Get them involved as early as possible. "We got a lot of feedback during our pilot, and incorporated a lot of suggestions into the final design," said one IT director. For an internal deployment, the best approach is to form a user group with representatives of key departments.

Keep members of the group informed on any planned upgrades or changes. For external customers—be they business partners or consumers—you may need to enlist the help of your marketing or sales departments. It's also helpful to conduct usability studies, and even hold customer focus groups.

Mistake #2: Overlooking or underestimating IT talent.
Countless books, seminars and articles talk about the disconnection between IT and end users in projects. Such disconnection also takes place between IT development teams. For example, many companies will hire intranet or portal developers separately from the datacenter staff. "Quite frankly, my newer developers really don't understand or know anything about the mainframe," lamented one CIO. This CIO actively promoted partnerships between mainframe and Java developers to "cross-pollinate" the two skill sets.

Some IT managers find that it makes more sense to provide re-training where necessary, rather than hiring out. "Maybe it's the fact that I've got a little bit of gray hair, but Java just seems like another new fad," remarked one IT director. "If you have people who are good and flexible, you can write anything."

This lesson extends to interactions with outside vendors as well. "After a while, all vendors look the same," said another IT manager. "You have to look under the covers at the kind of people that these companies are going to be able to deliver. You're going to rely on them in many ways to deploy these apps."

"We need to concentrate less on the latest new niche technologies and more on communication."

Mistake #3: Getting too hung up on the "latest and greatest" technologies.
For technical folks, it's pretty exciting—the main reward to the job outside of money—to experiment with new technologies. But resources are limited, especially if you have a small IT staff. A related challenge is translating new technology approaches to business users. "I think we do ourselves a disservice when people don't understand what we're talking about," remarked one CIO. "We need to concentrate less on the latest new niche technologies and more on communication."

Mistake #4: Assuming one approach will fit all.
There are more ways to Webify a back-end system than there is room in the pages of Enterprise Systems. If one approach doesn't fill the bill, there's probably another that will.

Even if your host integration package seems to have many nice features, it may not work on all of your applications. You may even have to do additional programming directly in the host application. "When we prototyped our Web-to-host interface, each tab had a different set of command-key sequences, depending on the screen. It was a real nightmare," said one IT director. "We had to re-write the underlying application to a hub-and-spoke approach, so you could get from anywhere to anywhere."

Mistake #5: Overdoing it with the interface.
A good rule of thumb is that if the interface is for internal employees, minimal is best; if the interface is public facing, then dress it up. Many 3270, 5250, and terminal screens work fine for heads-down, tab- and function-key keyboard pounding. Why wrestle with a complicated application-integration scheme when mere screen scraping may do the job? Pretty pictures may only slow things down.

The IT director at one major medical school, for example, had to be able to provide an interface to an audience of students and faculty across five continents. He urged end users in many parts of the world to go to cyber cafés, rather than struggle with dial-up access through notebooks. In cases like this, the less complicated the interface, the better.