\[Editor's Note: Do you have something to share with other readers who visit Windows NT Magazine online? We want to know about it. Write for Reader to Reader online, and you can tell others about your NT discoveries, comments, problems, solutions, and experiences. Email your contributions (300 to 700 words) to [email protected] along with your name and phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100. Reader to Reader submissions are the reader's opinion and do not necessarily represent the views of Windows NT Magazine.\]
Web browsers are a welcome tool for accessing information, to be sure. But imagine that you’ve been waiting for months to extract data from a host database. You can readily access the information with the software you have on your PC, but someone has decided that you should use a Web-browser interface to do so. Unfortunately, that same someone has done nothing to implement the browser interface, so you continue to wait, rekeying data and spending hours on a task that should take minutes.
Imagine further that you’re not alone. Hundreds of people in your enterprise are stuck in the same situation, all waiting for a browser interface. Sound crazy, or merely familiar? A friend recently told me of a case in which a company chose to conceal its capability to run extracts for 2 years because it wanted to implement a browser interface and it’s still not ready. The situation is reminiscent of the days of mainframes and terminals, when you had to enlist the help of a COBOL programmer to get a report.
Although today’s browsers are useful, they’re of greatest value when you’re supporting access to information by devices that you have little, if any, control over. The best example is the Internet. Because you want to accommodate everyone who connects to your information on the Internet, you can focus on a limited number of products people will use to access your site. Browsers fill the role nicely, even if you do have to worry about a few different brands and versions.
For intranets, however, you have other options that work just as well, if not better. The tools people use to access intranets typically provide little variability. In fact, many enterprises employ a standard desktop that effectively limits the options to one access tool or tools or that supports standard APIs such as ODBC. A common example is standardization on PCs with Windows NT and Microsoft Office. In environments where all users have a standard application suite, using a browser interface for an intranet adds little value; in fact, it can increase costs—sometimes considerably.
For example, once you create documents in Word, you typically maintain and store the originals in Word format. If everyone who needs to access the documents has Word, your files are immediately eligible for posting to an intranet. When users open the documents in Word, they’ll see all the information as you typed it, complete with color and graphics. A browser interface isn’t necessary. And, if you have collaboration products such as Lotus Notes or Microsoft Exchange for posting and routing information, the need for a browser is even less clear. Similarly, for databases with ODBC APIs, you can make the data available via Access.
You can argue that reliance on applications such as Office is more cumbersome because such applications require more training than a browser does. But if you don’t expect people to learn to use software, you should think twice about installing it in the first place. Furthermore, using the capabilities of a standard desktop suite offers additional flexibility to perform custom analyses and reports, thereby leveraging your investment in the applications. And, providing query and report templates as models rather than hiding them beneath Web-based queries can teach people to use capabilities of the software they might not otherwise discover.
It’s the proverbial choice between feeding people or teaching them to fish. Good anglers know how to employ a variety of rods, lures, and techniques to improve the odds of catching the fish they’re after. It’s likely that people angling for information will similarly benefit from having different paths to the sources open to them. Intranets provide powerful channels for communicating and turning information into useful knowledge.
To paraphrase a well-known saying, an intranet by any other name still is an intranet. It’s the APIs and the tools for actively linking files that are critical, not the interface per se. An interface comes in many guises. Browsers are certainly among the more alluring, but don’t rely on them if it means you’ll be delaying access to the data you need.
