Linux as the Network client:

It does work...

The global players in software and hardware have discovered Linux and are hurriedly announcing support for it and the porting of their applications to Linux. However, the emphasis is mostly on Linux as a network OS. What happened to Linux on the client?

As if Linux still had to prove itself as a full fledged network OS. A myth persists in IT decision making circles, that Linux, even though excellent as a network OS, was not as useful as a client OS in corporate IT settings. While corporations are setting up substantial networks under Linux, realizing significant performance and uptime improvements in the process, they continue to use MS Windows based solutions as office applications for end users. During a consulting project for a midsize firm we had an opportunity to prove that Linux on the client does work. To do so, we had to clear several hurdles, some of which became apparent only during the course of the project.

Gaining Management Support

Possibly the biggest hurdle was to obtain management approval for testing Linux on the desktop. Leaving behind the Linux-fan's infatuation with the technology and confronting the realities of corporate decision making, we quickly realized that the technology advantage alone would not sway management. To obtain top management's blessing, we had to stress benefits such as lower purchase price and cost of ownership and substantiate expectations of operational savings and productivity increases. In this specific case, we also needed to assure management that there would be no problems with data-exchange. Management's fear of disrupting operations due to data-file incompatibilities outweighed its reluctance to pay for MS Windows and MS Office licenses. Any Linux implementation had to maintain compatibility with the world at large.

Preparation

To ensure success, we had to prepare the project on several levels. We were not setting out to simply revamp and expand the customer's internal network. We were going beyond that, to port complex work processes to a new client OS platform.

In the first stage, we established a "wish list". For that process, management and IT staff would express their wishes for functionality, maximum cost and time-to-implementation. Interestingly, the final result would not turn out to closely match the firm's original wish-list.

With a partial port from Windows to Linux approved, we next had to isolate the affected work processes from the overall work flow and analyze them. In the process, we also evaluated which software was required for achieving each task. As a byproduct of our analysis, we were able to significantly optimize these business processes and markedly reduce the number of software programs used in these tasks as well. Thus we achieved considerable savings for the firm beyond the expected payoff of the network restructuring.

The business process analysis also gave us an opportunity to learn about the IT wishes of the end users. These did not mirror the "wish list" we had gathered from management and IT staff. Not only did the end users contribute useful ideas for streamlining software usage and optimizing work processes, they also provided valuable suggestions for solving security problems of the network infrastructure currently in use.

The results of the business process analysis were compiled into a blueprint of the firm's future IT environment. In it we defined which programs under Linux would be used to accomplish which tasks and which data formats would be adopted for data-exchange internally and externally. We adopted open data formats only. For example, for the formatting of text files we would not choose a proprietary file format such as MS Word but recommended RTF instead. We selected Applix Office as the corporate desktop office solution, an Oracle data warehouse as the database solution, Samba for file servers and Apache for Intranet-servers and Web-servers.

Porting

With the corporate standards defined, we tackled the actual porting of the client desktops to Linux. Since many end users were not really computer literate, we needed a Client solution with a GUI. We chose KDE because we deemed it more advanced in its development than GNOME and we liked its stability and capability.

As an initial porting step, we moved one single department to Linux as a "beta-test". To prevent disruption to the business, we chose a department that had volunteered for this assignment. Thus, we encountered less resistance-to-change from fearful employees and increased the chances for success. The experience from this "beta-test" came in handy during actual deployment phase, enabling us to efficiently port business processes to Linux clients across the other departments.

The biggest transition problem was getting the users to cope with some idiosyncrasies of the new GUI and applications. Consider, for example, the diverging usage of the middle mouse button (where available) in KDE and Windows. Some users needed up to three months to get used to their new desktops. Consequently the corporate help-desk incurred considerable support overhead in the initial stages of the port. As a result of Linux' superior stability, the added support overhead eventually dropped back to normal levels. One year later, support overhead ran about 10% lower per client than had been projected.

Conclusion

After using Linux in several different server configurations as well as on the network clients, management reported the following findings:

Significant savings had been achieved due to reduced license fees for OS and applications. Downtime for systems classified as mission-critical was negligible, resulting in substantially higher productivity as well as markedly lower support requirements.

Management criticised that, due to the lack of in-house expertise, the new infrastructure required support from third parties to be added.

In summary, management noted that the transition to Linux had gone smoothly and had yielded substantial savings both short and longer term.