Electronic Software Distribution: A Long Shot

By Rikki Kirzner


[Chart]: Electronic Software Distribution
Before trying to distribute software across a heterogeneous client/server environment, get out the aspirin and caffeine and pack your overnight bags. This isn't going to work easily.
It's the middle of the night, and you're staring at a cryptic error message flashing across the screen. The message advises you for the umpteenth time that the automatic installation of your new software application is not going well. The software simply won't load on all the machines on your company's network.

Sound familiar? It should. It's a situation that happens all too frequently. And no one willingly discusses it. After all, you have convinced your boss to invest in the latest network and systems management software. You have purchased a new electronic software distribution (ESD) package. The application's installation instructions clearly say it can be distributed automatically across the network. So, like your colleagues in other companies, you begin the process of automatically distributing the data or applications across the network. But nothing happens according to the book.

The reasons for this hassle are as complex as the conditions inherent in your environment. In diverse client/server systems, one size doesn't fit all. Before purchasing any software product you want to distribute throughout the organization, consider the possible complications. The following questions point to some common stumbling blocks.

Are all the client PCs and server systems from the same manufacturer, with the same configurations and running the same versions of system software? Is there enough memory on all the computers? Are all the conditions necessary for successful installation present on all your systems? Is some "private" software package installed on a PC somewhere that, because of memory or address constraints, could produce a conflict when you try to download software? Do some functions of the installation process still need manual intervention? Are your troubleshooting tools adequate for tracking what is actually happening during the distribution process? Even some experienced network and system administrators don't know the answers to these questions before they begin.

The New Model

Of course, there are pressing reasons why remote software delivery has to work. In restructuring to reduce overhead and labor costs, many companies are resorting to decentralization. Together with mergers and expansions due to business growth, more and more corporate resources are being deployed to remote sites. Many of these sites don't have the technical staff available at the central computing location. Since users at these sites must be able to run the same files and versions of applications as the rest of the company, IS managers are struggling with the ongoing challenge of trying to keep all software current and to deliver new releases and updates to each desktop in timely fashion. Remote sites must also be able to access the same data and documents as the rest of the company, and remote users often require the same level of support as the central IS site.

Additionally, networks represent a melange of computing capabilities. Unfortunately, as a result of the differences in power and complexity of the systems residing on these networks, the most common method for updating or loading software is still manual. The cost in time and labor is excessive.

The administrator must install part or all of the software individually on each machine. Most personal computers still require software to be loaded from diskettes; some of the larger programs take up 20 or more diskettes, each of which must be manually loaded and removed. The process can take minutes to hours to complete, depending on the software and the system. Sometimes, conflicts may result in having to make hardware or operating system changes or upgrades before the software can be loaded. So as part of their downsizing strategies, many companies are looking at ESD as a potential solution.

However, when considering ESD software the IS manager has other concerns besides the targeted systems. In addition to simply downloading software, IS must be aware of rules of operation in effect throughout each division. These business rules may differ even between departments. And although many company managers are reluctant to admit it, some personnel feel they have "fiefdoms" to protect. For instance, it may be important that different LAN and network administrators be able to control what, where and how the software is to be installed. Department heads may be working on a project that can't be interrupted to load, test and reconfigure older systems when a new version of software is needed. In those situations, the upgrade should be delayed or avoided. And in all cases the administrator or IS manager must be able to verify that installation was completed successfully and the package is functional.

Looking for Good ESD

A good electronic software distribution product must be able to handle all these complex tasks in delivering software and data to all client and server systems dispersed on a network, while verifying that the software was installed successfully and is ready to run. It should be able to de-install problematic software and restore older versions if a problem occurs. A good ESD program also will help IS keep track of the versions of software and data that are currently installed. ESD programs should be able to distribute software to as few as one or two computers or as many as thousands of systems at various geographical locations. The product should be robust enough to handle thousands of PCs and flexible enough to let remote sites delay the software distribution when a new installation might generate problems.

Do such programs exist? Yes and no. Scores of products are now available to support electronic delivery of software. But these products are, for the most part, not as robust as they ought to be for distributed client/server environments. Moreover, the more robust the product, the more complicated it is to install and run. To complicate matters further, many of today's client/server applications consist of unique, individual components. Often the client and individual server components are different. And many organizations support multiple client and server platforms.

New England Research Institutes (NERI), based in Watertown, MA, performs epidemiological research that influences health policies in the United States. Brandon Savage, network system analyst, says that, when the company began evaluating ESD products two years ago he found only two products worthy of consideration: Software Update and Distribution System (SUDS) from Frye Computer Systems (since acquired by Seagate EMS of Scotts Valley, CA) and Bindview NCS, a local-area network inventory program from Lan Support Group of Houston. He eliminated Bindview as too large and too complicated to use. "It had a lot of capability and could produce a variety of reports and status information," Savage recalls. "But you had to buy everything at once, and we didn't need many of the components at the time. The product also wasn't intuitive; it required too much training to use the tool effectively, and it was expensive compared to the alternative."

SUDS is an automated software distribution system for local- and wide-area networks. It can update and modify network, server and client files of any type. NERI chose it because it can inventory LAN directories in an enterprise. Eventually, the company began using SUDS to update software on its Novell NetWare servers and DOS and Windows PCs.

The biggest hurdles Savage faced when trying to get the product up and running were its complex installation and insufficient documentation. However, once the product was running, Savage says, "It was easy to use and offered central management services."

More than Dreams Needed

It appears that up to now the solutions don't meet the demand for comprehensiveness. Says Paul Cubbage, director of client/server tools for Dataquest in San Jose, CA, "Much of the industry has adopted a Field of Dreams philosophy about electronic software distribution--build it and they will come." The result of this philosophy is that the products that are developed manage to solve only immediate problems. Slight consideration is given to how to distribute software across other types of computers that might be part of most heterogeneous environments.

"There's little understanding of the real issues involved, so there are few fully integrated or full-function products," says Cubbage. "If the product is not developed by system or network management vendors, there is also little consideration for how the product can fit within the predominant system management frameworks. In addition, since the infrastructure of corporations is changing so fast, it is hard for the automated tools to keep up with the changes made to products and corporate rules."

This is the predicament in which Savage found himself when his environment changed to Windows 3.1. He found that Microsoft has made so many changes to the new Windows products that it is too hard to find them all to program his ESD tool. "As a result, SUDS often fails because we didn't know something was changed," he says. "It is our responsibility to program all the changes into the software distribution product and program it to handle the upgrades and changes. That is too difficult."

As a result of this added burden, Savage is evaluating another product, LAN Escort from Landovation of Minneapolis. "We need something that can automate the process further," he says.

LAN Escort is a centralized Windows management solution that lets you set up default desktops and environments for both groups and individuals. According to Savage, "All the interfaces are the same for DOS and Windows, which is important because we have both operating systems installed here." LAN Escort is the type of product that "finds all the things that need to be changed and automatically handles the upgrades and changes," he says.

Savage's concerns are echoed among other IS managers evaluating ESD products. And there's no clear solution in sight. He hasn't identified a product that will be able to handle operating systems such as WIndows NT and Unix as easily as the PC ones he has worked with. The company doesn't think Microsoft's System Management Software is mature enough to install and hasn't evaluated its software distribution capability.

The Burden of Choice

Good point solutions are coming onto the market, but they can't handle client/server environments well. There are packages for Windows- or NetWare-based products, but they can't recognize Unix or proprietary systems that may also be on the network. And Unix-based solutions have a rough time with Windows PCs because the configurations and setup are completely different.

Gary Smith, system administrator for the Vancouver Stock Exchange in Vancouver, BC, Canada, required a product that could handle his heterogeneous, distributed environment, which includes several Unix servers from HP and IBM, Windows PCs and IBM MVS servers; some applications run between the exchange's Vancouver and Toronto sites. Evaluating products that could handle 150 PCs, Unix servers and an Oracle database, he looked at several, among them HP OpenView and Legent's Distribulink. Legent's products were priced according to functions required. For instance, the staging function Smith needed was an option. Smith says he rejected Legent's solution because there was no consistent GUI and the product did not stand out above others. OpenView didn't provide staging at the time of Smith's evaluation.

(Staging is distribution of software in which the software is sent from a host computer or a central location to a more distributed server at another location from where it will eventually be delivered to remote systems.)

Smith chose Xfer from Platinum Technology of Oakbrook Terrace, IL. Xfer can function as a stand-alone client/server application or be used in conjunction with network management packages such as SunSoft's SunConnect and SunNetManager, IBM's NetView/6000 and HP OpenView. Xfer offers centralized control of software and file distribution.

Smith liked the "robustness of the product," but he encountered a problem when he installed Xfer. "It was hard to distribute software to the PCs," he says. He credits Platinum's technical support for help in getting the product up and running. "However, minor problems still crop up occasionally with our PCs," he adds.

Smith says that, although he hasn't installed the latest release, Platinum has added features that the Vancouver Stock Exchange requires, such as automatically bringing Windows PCs up and rebooting them after the software is loaded. He still longs for additional features, such as an easier interface to his PCs and an easier way to change files on PCs. "When we go out to the PCs, we have to go through Unix shell scripts," Smith says. "Changes to the PCs are made on the Unix systems and sent back to the PC."

Choices are limited, because few if any ESD solutions can do everything. Even those that can perform a variety of complex operations cannot handle every task equally well. For instance, there are LAN-based solutions that can track PC software distribution to each desktop but can't manage WAN or distributed heterogeneous environments. There are heterogeneous environment solutions that can't handle all PCs in all locations. There are good software distribution packages that can't scale beyond a few hundred systems. Other products can't provide enough feedback when something goes wrong.

The Human Factor

Software distribution has the power to affect many IT users of various types, and IS departments must account for this. For example, within large, diversified companies there is always debate about the merits of software that can replace manual labor. Some LAN administrators fear to move to new automated distribution tools. "There is nervousness on the part of many LAN administrators to adopt automated solutions, because people believe that these products could help eliminate their jobs," says Cubbage.

There is also ongoing discussion about the merits of authoritarian versus decentralized approaches to software distribution. The choice should depend on the conditions in the environment. Installation of a new version of software may adversely impact the operation of a remote division. Incompatibility of a new release can--and often does--wreak havoc on older legacy systems when backward compatibility isn't designed into the new version. New versions of software may render old applications and data unreadable. This could bring a business to a virtual standstill until the application upgrades and data conversions are done. In those cases individual departments should decide what they want to install and when to perform that installation.

This is where the product's ability to do staging is crucial. It is often the procedure of choice for environments in which loading new software or upgrades must be at the discretion of the local administrator.

As always, users want to be able to choose best-of-breed solutions. They want products to be independent of the network and operating systems. They want to be able to select the best solution without getting locked into a proprietary approach that will prevent them from moving to a better solution when it becomes available. Such unregulated environments may be suited for the end user, but they create headaches for the administrator responsible for installing or upgrading new software on the network.

Power users in a company are likely to customize their workstation configuration to accommodate their own requirements. This can derail an unsophisticated ESD download if, for instance, the software expects a critical file to be in a specific location and it isn't there. The frustrated power user may also pay a visit to the local computer superstore and buy and install a needed application. The consequences of such action can range from nil to disastrous, depending on how much of a drag on network resources the additional software produces.

Words to the Wary

If all these considerations make you long for the days when you could buy all the software you needed from a local retailer and install it yourself on just one system, take heart. There are things you can do to simplify the process of selecting and distributing the right software for all computers in your environment.

To find the right ESD product to balance your company's and users' needs, start by setting down a list of policies and procedures for how the network and its administration should be controlled. If you don't know what environments you are going to have to support, it will be impossible to find an ESD package that can meet all your expectations.

Next, assess your upgrade and download requirements. If you spend more time and money upgrading Windows applications or if the majority of your systems are PCs, you might opt for an ESD package that is more efficient at handling PCs than one that is fine-tuned to loading software on Unix systems.

Even the best preparations will be met by unexpected results, so consider the debugging tools and level of error detection your product of choice provides. You'll also want the product to clearly communicate any error that interrupts the process. Cryptic or common error codes across multiple conditions will lead to hours of extra time spent trying to debug a problem that might be as simple as a scripting error.

As not every site will be ready to receive software at the same time, be sure to include scheduling capability on your checklist. In the case of Novell's NetWare Navigator, for example, that entails different schedule programs for the different kinds of systems in the network.

If your company develops its own internal software or needs to distribute data to different systems, be sure that the ESD product can distribute it as easily as packaged applications.

Also make sure that your ESD application can function in the same manner on a WAN as it does on a LAN. If you are using a WAN, the ESD package should be able to schedule software transfer at a time when the links are less expensive or when traffic is less congested. And the software should support mobile users as easily as remote networked users.

Finally, don't be surprised if you are unable to obtain every feature you need in the package you are considering. Ultimately, until this market matures, you may have to settle for most of what you need rather than wait for the perfect product to appear at your door.

Rikki Kirzner is a free-lance writer based in Silicon Valley.