Throughout the 1950s and 1960s, innumerable films and television shows depicted a future in which everything, from getting dressed and making dinner to giving Fido a bath, was automated. While they appeared outlandish in their day, many of those dream s have come to fruition -- witness the microwave oven, cellular phone, and laptop computer. The advent of client/server computing has done its share of miracles, particularly in the area of human resources -- you can now screen, interview, hire, discipli ne, and terminate employees without sharpening one single pencil.

Human Resource Management Systems, or HRMSs as they are called, are becoming increasingly popular tools for HR managers in every kind of organization, from the Department of Veterans Affairs, popular clothing retailer J. Crew, and Burger King to the C anadian federal government. From an employee standpoint, HRMSs still have a disadvantage: the information remains in the hands of HR staff and not easily in the hands of the people. Xerox Corp. (Stamford, Conn.) has set out to change this with its Xerox PeopleNet system. The application puts basic HR information and applications at the hands of all users with a networked PC.

Xerox PeopleNet was conceived in conjunction with Xerox CEO Paul Allaire's future vision for where the company needs to be in order to be competitive in the year 2000 -- Xerox calls it Xerox 2000. The project was designed to help facilitate a paradigm shift in Xerox's human resource arena. The idea for an automated HR program for employees supported Allaire's vision for an empowered, productive, accountable, and satisfied workforce. For it to be successful, the paradigm shift depended on the use of t echnology (in this case client/server architecture and GUIs) to make traditional HR information and tasks (such as general compensation, wage and salary administration, and so on) available to managers and employees at the time of need.

A key word here is technology. Xerox's infrastructure at that time was based on Xerox's own proprietary workstations and networking hardware. Xerox had already made several attempts in the old mainframe environment to make basic HR information availab le to employees, but the mainframe technologies just weren't user-friendly enough for the typical manager/employee skillset. At the same time that the Xerox PeopleNet project was getting underway, the Xerox infrastructure was changing from strictly propr ietary, homogeneous hardware to more industry-standard workstations such as IBM-compatible PCs. This factor presented more possibilities but also more challenges to the Xerox PeopleNet development team.

The small team dedicated to the project was never more than 20 people at any one time. The project was sponsored by Anne Mulcahy, vice-president of Corporate Human Resources, in partnership with Xerox's GP&IM, or Global Process and Information Managem ent Group, headed by GP&IM Vice President Patricia Wallington. The project manager was Thomas Stone, the development manager was Karen Mihara, and the primary system architect was Jim Johnson, a consultant with Tridec Development Corp. in Rochester, New York. Bob DeRoller was the deployment manager and also the unofficial customer relations manager. Today, Thomas Stone, Bob DeRoller, and Karen Mihara still maintain these roles as work continues on the application.

In the Beginning

Research for the project began in 1993. At this time, developers studied what was the right thing to do, what was the niche for the project, what were other companies doing, and so on. In June of 1993, they decided on the overall concept of Xerox Peop leNet as a tool to put HR management more in the hands of managers and employees. Xerox already had a well-established legacy system of general employee and personnel database systems, which the company didn't wish to touch. Most of the vendor solutions that the team evaluated at first were designed for use by human resource managers rather than the typical employee or manager. It was thus decided that the Xerox PeopleNet project would go off in a totally new direction.

Because Xerox was changing its hardware infrastructure, the project team had to begin by prototyping technologies. At the time the project was started, client/server technology was still very new, and nobody had completed an application like this on s uch a large scale (approximately 20,000 users across the country) within Xerox. The development team worked with GP&IM on setting the basic application/system standards for a technical framework (selecting Oracle/Unix database servers, ODBC, PC clients, and so on), and used prototyping to test different development approaches and to design the overall GUI. Because Xerox decided to outsource its infrastructure support to EDS (Falls Church, Va.), which owns and maintains the current infrastructure and man ages the workstations, the Xerox PeopleNet team had to coordinate its plans with EDS as well as several other different partners. This meant that they couldn't define their own standard and enforce it on everyone else. Instead, everything they chose unde rwent strict compatibility testing to ensure that it coexisted well with other Xerox applications and standard configurations. Consequently, a large part of the rest of 1993 was spent investigating and testing technologies.

From January to June of 1994, Johnson and several developers and consultants worked on the application prototype, deciding on the GUI, the basic metaphors that would be used, and pulling together the technologies for a pilot for the prototype. From th e pilot, the team got the go-ahead and the funding to pursue a production version of the application, which was launched to the domestic personal computer community in January 1995. The first version contained read-only, simple applications because, as t he company migrated from proprietary hardware to new hardware, the developers needed to understand the Xerox infrastructure before doing a major roll-out of the functionality. Sample applications included personal employee data, the HR policy manual, emp loyee salary data, and fund balances. The Xerox team also designed the screens and queries to limit how much data came to the client at any one time, to minimize network traffic. The next phase provided simple functions such as letting employees change t heir name, home address, and phone number. Also, the team focused heavily on making the primary architecture as stable and set as possible so that they could spend the next year enhancing the application's functionality.

Implementation was slow, mostly due to the fact that it coincided with the company's switching to a PC environment. At some points, nobody could tell who had a PC and where they were located. Roll-out started in the few hundreds, and it took several m onths to get kicked off. Between January 1995 and January 1996, however, the team had already hit the 10,000 mark in terms of software installs. The ultimate goal is to install the application on 30,000 PCs across the country. As for use, at the end of D ecember 1995, Xerox PeopleNet was at a little over 2500 logins per week, and that number is steadily growing. There were at least two subsequent version releases through the course of 1995, each one adding more functionality until the end of 1995, at whi ch point developers were in production on transaction-processing applications. Figure 1 shows Xerox PeopleNet's main menu screen with eight file drawers. Each drawer contains folders with additional information specific to that loc ation. Use is anticipated to grow as more applications are added to the program.

The Basic Architecture

The application's success on such a large-scale user base depended primarily on its use of an ODBC driver. Xerox PeopleNet runs an OpenLink Software Enterprise Edition ODBC driver against Oracle7 database servers with Sparc Server 1000 server hardware . As of January 1996, there were three production servers, with a fourth one in the works. The client side was developed in Visual Basic with a local Microsoft Access database. Instead of talking directly to ODBC, developers programmed to Microsoft's Dat a Access Objects (DAO), a higher-level interface to the database. The developers liked this solution because of the tight integration between Microsoft's Visual Basic and Access. Intersolv's PVCS Version Manager is used to keep track of the Visual Basic source code. BMC's Patrol software monitors the production database servers to ensure maximum system uptime.

Why ODBC?

Developers were set almost from the beginning on ODBC rather than native drivers. They spent a moment considering vendors that had proprietary APIs that they could use. For example, TechGnosis' SequeLink (now owned by Intersolv Inc. [Rockville, Md.] a nd renamed Intersolv DataDirect SequeLink) would let them use ODBC or the product's own proprietary interface, and it even had support for Visual Basic (as did Oracle and others). But their desire for a flexible tool that didn't lock them into any specif ic database or middleware won out. ODBC offered them the biggest safety net and ensured that what they built wouldn't have to be thrown out in three years -- ODBC is supported by every client application and every database, in one way or another.

The team evaluated several ODBC drivers before deciding on OpenLink. They looked at Intersolv's DataDirect ODBC Pack, Oracle's (Redwood Shores, Calif.) ODBC Driver, Microsoft's (Redmond, Wash.) ODBC Desktop Database Driver, Intersolv DataDirect SequeL ink, and Cross Access Corp's (Oakbrook Terrace, Ill.) CrossAccess Data Delivery System.

Why OpenLink?

It goes without saying that performance was of primary importance -- and OpenLink's performance was solid and fast or, as Johnson says, "It had a simplistic elegance to it." Another crucial factor was installation, because there was such a high user b ase. The product had to be easy to install and it had to work with automated installation without too much tweaking. Another eliminating factor dealt with finances: with an estimated 20,000 to 30,000 users, even the most nominal per-seat charge could be debilitating. So it had to be a server-based product with a concurrent user license.

They needed an ODBC driver that would support stored procedures and binary large objects (BLOBs). A lot of products that the team evaluated either didn't work well with stored procedures and BLOBs or had limitations on the size of the objects they cou ld handle. Also, they found that many of the ODBC drivers seemed geared towards doing standard decision support-type queries, working with text and numbers only and not doing stored procedures and BLOBs.

They also needed a driver that would support both TCP/IP and Novell's IPX/SPX. Developers found that several of the ODBC drivers tested (or the middleware on which they ran) seemed to be more focused on TCP/IP, or if they did support Novell, the ODBC drivers ran quite a bit slower. With OpenLink they got very good performance on both protocols.

With the enormous size of the install base, the ODBC driver had to add very little network traffic, because it would be multiplied by at least 10,000 users. They found that OpenLink had less overhead on the network than other ODBC drivers they tested.

The developers liked the fact that OpenLink was designed such that both the communications layer and the ODBC layer are contained within the driver. At the time, Intersolv's DataDirect SequeLink was the only other product with this architecture. Havin g both layers on one driver eliminated middleware layers and simplified the client side considerably. It also meant that they only went through one vendor -- in this case OpenLink -- if any problems were to arise. Working with only one vendor also kept t hings more cost-effective.

OpenLink also proved the most willing to adapt its product to exactly what the Xerox PeopleNet team needed. In particular, OpenLink expanded its existing BLOB support to BLOBs in excess of 64K. Also, OpenLink was originally written to the Winsock stan dard, because both Windows NT and Windows 95 support SPX/IPX via Winsock, but because Xerox was going to use Windows 3.11 for quite some time, OpenLink implemented support for SPX/IPX under Windows 3.11. OpenLink also added support for encryption, anothe r thing Xerox PeopleNet needed. Johnson explains, "We didn't want somebody to be able to sit there with a line monitor and watch all this very sensitive data going across. And at the time, OpenLink was the only one that could do that for us." OpenLink al so had several other security features built into the driver, including a Rule Book, which has several parameters you can set to control who has access to the data and to the server.

Finally, as odd as it may sound, they needed a product that was actually shipping. Johnson declined to name the company, but he did confess that one company they talked to didn't even really have anything yet. "They were practically ready to sell it t o us, and all of a sudden we realized that they didn't seem to actually have the product yet."

Other Challenges

Once having decided on the OpenLink ODBC driver, the developers were still faced with a number of challenges. As mentioned previously, Xerox was moving from a homogeneous, proprietary infrastructure to a completely heterogeneous PC arena, and the infr astructure was still very uncertain. Says Johnson, "The fact that we didn't have a homogeneous workstation population forced us to go into a phased roll-out approach, which was kind of good news and bad news, learning what the systems were like. With suc h a sheer number of users, you run into every imaginable PC configuration, with all kinds of different hardware and software."

Another challenge was simply in physically getting the software out to 20,000 to 30,000 users. The developers considered all sorts of delivery strategies and came up with several options: They ship it out to local system administrators, they put it on CDs and floppy disks, they put it on the internal Web for employees to download themselves, and some Xerox organizations are looking at electronic software distribution so they automatically deploy the software. Once the software is installed, it automa tically upgrades itself with PeopleNet's built-in version control system. They can thus monitor from the servers the versions of the clients that are running when someone logs in, and pass them new versions of software as needed. Johnson explains "The id ea was that we wanted to install a workstation once and never have to go back to it. Or ideally the end-user would install it him or herself. We didn't, when we have a new release, want to have to go back to 10,000 PCs and have them reinstalled. The soft ware just keeps updating itself every time it logs in."

None of the drivers that the developers tested offered a built-in tool to automatically handle a large distributed environment such as the one at Xerox, so the developers were forced to write their own load-balancing program. This program spread users across the servers depending on server load and geographical location, and allows them to bring down a server without impacting the system's users. The OpenLink driver worked well with the load-balancing problem, because it permitted the switching of se rver connections while a client was connected to a server

The only major problems encountered with the application thus far have been at specific sites that may have local network problems. If the site has a node that has a very slow WAN link, there might be problems running the application. However, as long as there is enough bandwidth at each site, the application runs fine because the Xerox PeopleNet network traffic is minimal.

Pass or Fail?

Overall, the program has been quite a success. Part of what attributed to this success, says Mihara, was the fact that the group was so small. "A lot of times when people tackle enterprise-wide applications," she explains, "they tackle it in the old m ainframe mentality. Here's this huge project, and it's the size of the Pacific Ocean, and we're going to scope it that big -- and they put a huge development team on it, and in the course of that, the vision changes several times, and it's hard to keep a ll of them coordinated."

In contrast to what Mihara calls the "mainframe mentality," the Xerox PeopleNet project followed a very phased development approach of prototyping, testing, testing again, and then rolling out, again and again. This was part of why they chose Visual B asic as the client development tool, because of its ability to facilitate prototyping. This phased development approach was mostly due to two factors: the group was testing new technology, and it had to gain the confidence of the company's different divi sions to ensure its success.

Future Directions

Now that the primary architecture is well established, the development team can now focus its efforts in 1996 on new transactions, such as employee promotions, cardless time reporting, changing salaries, changing 401K contributions, transferring emplo yees, and online training course registration. While hiring and terminating employees is on the list, Mihara isn't sure that the business is ready for that. "We know that we want to move that responsibility over, and in this company it currently resides with the manager anyway, but we're not sure we can sort through all that paper to make that happen." How much has all this cost? The project has been in development for two years, and Mihara estimates that the cost has totaled approximately two million d ollars -- a low sum considering that the project was the first of its kind, size, and scope within Xerox.

No Regrets

Xerox PeopleNet developers were hard pressed to come up with anything that they would change, could they go back and do it again. Johnson praises the fact that they began by building a strong, core infrastructure and keeping the functionality light un til they had proven the concept. "In the background," he adds, "we were building a foundation for something much bigger than what people saw. So once we got over the hurdle of the infrastructure, all of a sudden the application just took off. We add func tionality very rapidly now."

If the project were to begin today, the developers agree that they would probably choose some new tools, simply because new technology is available. But based on what was available to them when they began the project, the developers wouldn't change a thing -- a rare statement to hear these days.

At Xerox, employees can now effortlessly access information from their workstations that used to be guarded in somebody else's file cabinets. And from anywhere, you can do your banking, buy a used car, rent an apartment, make new friends, and order a pizza from the comfort and convenience of your very own computer. While the inability to reason, think, and feel still separates computers from humans, projects like Xerox PeopleNet clearly demonstrate that we are heading toward a world in which the powe r of action is only a mouse-click away.

Figure 1.

The Xerox PeopleNet applications are organized in a main folder as shown here. Each file drawer contains folders with additional information specific to that location.