Click on our Sponsors to help Support SunWorld

8 important issues to consider before building an intranet

What must you know about your intranet's infrastructure and staffing to be successful? These guidelines will help you through the morass of intranet planning. Plus Sun and Lockheed Martin tell how they constructed their massive intranets

By Kathryn Esplin
SunWorld
March  1997
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!
Abstract
Are you planning to install an intranet? Do you know what steps you'll need to take to get the process underway? If not, then this is just the ticket: eight key issues to consider before building your intranet. It includes the necessary questions you must decide for yourself and for your company -- many of which need answering even before you start installing hardware. (6,500 words, including two sidebars and extensive resources)


Mail this
article to
a friend

If you're an IT manager without an intranet in place, chances are your boss has already asked you if your company needs an intranet, and if so, how soon it can be built. You might even have a budget for evaluating intranets, or maybe you've been directed to build one, regardless of whether you think you even need one. Before you lay that first brick for your intranet, your organization must answer for itself these questions first.

For the purposes of this article, we'll assume that you've addressed the questions above and have a business plan, have an idea of what you plan to spend, know what you want to accomplish, know how interactive you want your intranet to be, and have a thorough understanding of your computing resources. We make these assumptions -- and big assumptions they are -- because the answers will differ from company to company. For example, the budget for a Fortune 500 company will be significantly different than that of a small medical practice with a dozen doctors and their associates. The ultimate aim might be the same -- more efficient collaborative computing and better use of technology -- but the scope will be different.

Before proceeding on, first a caveat. There are many different ways to plan for a project of this scope. As the automotive advertisers like to remind us, your mileage may vary. Your plan might differ based on your existing network infrastructure and how you answered the five questions above. As a result, you might be further along on your intranet planning, or you might be at the very beginning with no network in place.

One might argue that the planning process for building an intranet requires far more considerations than the eight covered below -- and they'd be right. However, we pose these issues separately because they are crucial to the planning process. Rather than thinking of these issues as part of intranet development, you might want to think of them as a prerequisite to developing the intranet.

Advertisements

What you need to know
Based on the givens above, here are eight key issues to consider when preparing to build an intranet:

According to The Delphi Consulting Group of Boston, 82 percent of companies are projected to have their desktops connected to an IP-based intranet by the year 2000. A recent study done by Framingham, MA, market research firm International Data Corp. for Netscape Communications profiled a day-in-the-life of several large corporations, highlighting the organizations before and after development of a corporate intranet with Netscape's Navigator browser. SunWorld obtained independent comments from two of these firms, illustrated in the sidebars on Sun's SunWeb and Lockheed Martin's intranet below.

Determining your infrastructure requirements
When we talk about the network infrastructure, we mean a TCP/IP protocol suite running on a local area network or used as a gateway to the Internet as the intranet's logical infrastructure. This article does not include a discussion of non-TCP/IP-based groupware (such as Lotus Notes) or of related software, as they are different products and pose different problems.

There also is the question of what kind of physical infrastructure you need for the intranet. This physical infrastructure probably will be made up of a combination of token-ring networks, 10 megabit-per-second (Mbps) Ethernet, 100-Mbps Ethernet, FDDI and ATM networks, associated hubs and routers, and T-1 and T-3 lines linked directly to the Internet or to an Internet service provider.

One question you may ask: "Is my infrastructure robust enough for the new requirements?" That depends. For most intranets, companies will need a minimum of a 100 Mpbs network with T-1 (1.544 Mbps) and T-3 (45 Mbps speed) lines to the Internet.

Some organizations might not have in place the TCP/IP stacks they will need for an Internet-linked intranet, says Ray Laracuentra, senior research analyst of Stamford, CT-based Gartner Group. Two-thirds of the file server market today are still running Novell Inc.'s IPX protocol, he says, and upgrading to TCP/IP stacks would probably run about $100 per seat. This price includes only the cost of the TCP/IP stack upgrade and does not include all other costs associated with building an intranet, like the expense of installing T-1 lines, buying and installing Web servers, desktop platform upgrades, the price of browser licenses on a per-seat basis, or the cost of associated HTML development tools for the Sun environment.

In terms of how much physical bandwidth your company might need, the operative question is this: How do you plan to use your intranet? Online transaction-processing systems require considerable bandwidth, but forms- and text-based applications, such as displaying corporate policy manuals and telephone directories are not bandwidth hogs. Once an organization adds video, audio, multimedia, or online job posting for interactive responses, they will need more bandwidth, Laracuentra says.

However, much existing bandwidth that a company has is essentially free, since the network is already installed and paid for, and a company will add applications that take advantage of this existing bandwidth. The additional cost would apply only when companies need to add significant network legs, upgrade to T-1 lines, add more network segments, or upgrade the existing infrastructure from traditional 10-Mbps Ethernet to Fast Ethernet or FDDI.

"Probably the most important aspect of intranet development is that you need to consider upgrading your network infrastructure to support the intranet you are building," says Trent Waterhouse, Cabletron Systems Inc.'s program manager for LAN switching in Rochester, NH. "In most large corporations, critical applications are still based on mainframe technology, and legacy mainframe environments require less bandwidth than the client/server Internet environment," he adds. One of the most common mainframe environments is the IBM CICS and SAP mainframe environment, which soon will be ported to Sun's Java applet environment.

Cabletron is one of many vendors that offers network switching as a partial solution to increasing network bandwidth. Network switching dedicates bandwidth to every user on the network, which a shared-bandwidth network does not. When a company has new users or needs new ports, bandwidth is divided with the switch. It allows multiple, disparate networking technologies to be supported across the intranet in a way that shared-bandwidth networks, such as Ethernet, or even Fast Ethernet, simply cannot support. It is a bit like comparing the relative inefficiency of having a party line on your telephone system as compared to the more efficient private line.

Determining your Web server needs
The next step is to choose Web servers. There are a wide variety of hardware servers that can be used ranging from Compaq PCs running Windows NT to high-end Unix- or proprietary-based servers. Sun itself offers servers ranging from SPARCstations to Enterprise servers; it also offers the Netra, which Sun markets as being specially designed for this application.

Netra servers are essentially SPARCstations that have been tweaked to enable them to run over the Internet or within an intranet. The Netra family includes the Netra 5 server, which is an application-specific Internet/intranet-ready server; the Netra i 4000 and Netra i 5000 servers come bundled with a Netscape Communications' browser, an HTML interface, and specialized software that enables users to administer the network remotely and track security, and it also provides FTP capabilities. The Netra servers use Sun's NFS or run over TCP/IP, using the FTP capabilities provided to connect to the TCP/IP-based Internet. The Netra i 4000 and Netra i 5000 servers also include Netscape's Suite Spot software, as well as LiveWire, a third-party Web site management product bundled with Netra.

The Netra J adds Java support, which enables users to write Java applets for thin clients or network computers. Network computers are increasingly being regarded by IS managers as an inexpensive, effective way to put basic resources on the desktop without hammering a network, eating into IT's pocket, or giving users more computer than they really need. Sun itself is using 3,000 thin clients internally on its intranet. (For more information on Sun's intranet, see sidebar, "How SunWeb came to be: Sun's own story".)

On the software side other servers also are available, including public domain servers such as the Unix-based Apache from the National Center for Supercomputing at the University of Illinois at Champaign-Urbana, Microsoft Corp.'s Windows NT server used in conjunction with Microsoft's Internet Information Server; Amiga Web Server; Netscape's Enterprise servers; the National Center for Supercomputing Applications' HTTPd; and MIT's World Wide Web consortium's server, W3C, httpd. The httpd servers from NCSA and W3C are HyperText Transfer Protocol/Daemon type, hence, the "d" for Daemon, in this common server.

When selecting Web servers, consider the hardware and software platforms you want supported, what kind of performance you require, and how much support is available from the vendor. For Sun shops, consider the following from Carl Meske, Sun's Internet architect for the Netra business unit: "Most people will use the smallest machine they can use as a server," noting that the relative performance power a server has for Web and intranet deployment really depends on the content that will be put up on the intranet in the first place.

Intranet content could even be placed on a desktop unit, he says, unless the traffic becomes so heavy that that desktop machine is getting hammered, whereby the content could then be moved onto a dedicated Web server.

Making a browser choice
You will need a browser for each desktop; site licenses are available from the major vendors, enabling a gracious upgrade for the number of total users on your intranet two years down the road. With Netscape's Navigator and Communicator browsers weighing in at approximately 85 percent of the marketshare, many users have found this to be a good bet. However, Microsoft's Internet Explorer, NCSA's Mosaic, and Lynx, a character-based browser from the University of Kansas, are also available.

Not all browsers implement all elements of the HTTP protocol and HTML. You will want to inquire about how the browsers implement graphics, support style sheets, and so on, when deciding what kind of content you'll provide and how you will display it.

How will you use your intranet?
Your company executives, department heads, and staff will decide how the corporate intranet will be used. However, as the systems administrator, it is your job to implement these decisions. Part of the value an IS manager or systems administrator can add is to recommend to management which end-user intranet applications make sense today based on the functionality and technical aspects of the application and which ones you will want to expand toward in the future.

For example, you obviously wouldn't want to implement an application now that has a Year 2000 problem; you'd replace it with a different application or make the fix before you go through the trouble of loading the program onto the intranet. Sun's Meske says that a careful examination of how you will use the intranet and what kind of content you intend to put onto it is very important. At the top of Meske's list of priorities is determining what functions you want to distribute, how you deploy Web servers in your company, and how you deploy proxy servers to minimize the impact on the network. Wise use of intranet servers, Meske adds, will minimize "sneaker net," resulting from foot traffic incurred when the intranet is overloaded.

Common uses of corporate intranets include numerous human resource applications (such as policy and benefit manuals, OSHA documentation, staff directories, and online job postings), collaborative computing applications, multimedia, as well as applications linked to sales and marketing applications (like success stories), engineering and design departments, and customer service, among many others. At Sun, Meske says, virtually every corporate function is available to Sun's 19,000 intranet users. These Sun intranet users take advantage of such applications as human resources data, Sun's internal library, sales and marketing, accounts payable, career services, corporate security, education, corporate affairs, and so on.

Determining the application development software you need
After you select servers and browsers and decide what types of applications you plan to run, you will want to consider Web server interface tools. Some of these tools include:

Many HTML authoring tools use, or are part of, a text editor that can be used to write HTML code. In fact, HTML editors are not a requirement and often are an added and unnecessary expense. For example, at SunWorld, all HTML coding and programming is done in either textedit or vi.

Weeding through the pros and cons for your firewall
When it comes to protecting your intranet from the outside world, your attention turns to your firewall. Security is such a significant issue, we need to divide it into two sections: determining the type of firewall you'll need and how to build it. Not every intranet is vulnerable -- only those with Internet connections. However, most companies that have internal networks use the same infrastructure for both the internal network and the link to the outside world. That's why firewalls can mean the difference between having confidential data and setting yourself up as a cracker's play thing and the IS manager's worst nightmare.

The firewall you select is the key element by which all users will gain or be denied access to information on your intranet. Though the primary purpose of the firewall is to block the public from accessing your intranet, the firewall may also be used as a one-way service for your employees to go from the intranet directly to the Internet.

Two types of firewall design are commonly used: network level and application level. The firewall functions as a traffic router sitting between the Internet and the intranet. When routing is implemented at the IP level (the Internet Protocol level), the firewall is known as a network-level firewall. This network-level firewall functions like a simple router in that it directs packets without necessarily knowing where they came from. The key disadvantage of network-level firewalls is that they are essentially traffic routers and require a good IP address block to ensure security.

On the other hand, application-level firewalls that run proxy servers can be used for traffic auditing and traffic logging tasks. These offer far greater security because they control access much better. Their key disadvantage is that they are neither as fast nor as transparent to users as network-level firewalls.

The following table provides a breakdown of representative firewall vendors, along with a description of their products. This list is not meant to be a complete buyers guide of all firewall vendors, but it can help in understanding availability and pricing.

Selected Firewall Vendors
Company Product Platform Layer Price
CheckPoint Software Technologies Inc.
http://www.checkpoint.com/partners/index.html 		CheckPoint Firewall Solaris, Windows NT, HP-UX Network layer $4,990 for up to 50 nodes
Digital Equipment Corp.
http://www.altavista.software.digital.com 		AltaVista Firewall BSDI and Digital Unix Application layer $3,995 to $14,995
Raptor Systems Inc.
http://www.raptor.com 		Raptor Eagle Firewall Solaris, Windows NT, HP-UX Application layer $6,500 for up to 100 nodes
Secure Computing Corp.: Sidewinder
http://www.securecomputing.com/sidewinder/sw30web.html
Secure Computing Corp.: Borderware http://www.securecomputing.com/borderware/contents.html 		Sidewinder Security Server Borderware Solaris, BSDI Application layer $7,000 to $25,000 $4,000 to $14,000
Trusted Information Systems
http://www.tis.com/docs/products/gauntlet/index.html 		Gauntlet Intranet Firewall Solaris, BSDI, Windows NT, HP-UX Application layer $7,500

How to bullet proof your firewall
Okay. So you know the basic differences in firewall. Now what? The three most important issues in firewall protection are security, security, and security. Accurately establishing identification and authorization privileges is paramount, says Michael Zboray, vice president of network security at the Gartner Group. With today's increased user mobility,"there is no easy way to understand who is using which IP address and what the rights of that user are," he says.

Until recently, IP networks were static, meaning that each desktop user was matched with a specific TCP/IP address. Anytime a person moved his or her desktop location, it required that their address move to a different subnet. But now, users can get a permanent IP address that moves with them, regardless of whether they dial in from a remote location or physically move their computer to a different subnet. Users have rights to various network resources, including data and peripherals, based not only on who they are (their identification based on the IP address), but also on their function within the organization, Zboray says.

Another recent change is the adoption of the Dynamic Host Control Protocol (DHCP), a protocol that dynamically sets IP addresses each time a user logs in. The benefit to this approach is that it reduces the number of IP addresses a given server requires. If you assume that only a certain percentage of your users will be logged on at a given moment, then you can set IP addresses dynamically, eliminating the need to set each user's IP address individually, and thereby reducing support costs.

So, how do you select a firewall that's savvy enough to deal with both dynamic and static IP addressing? Generally speaking, the firewall needs to be able to perform numerous auditing and logging tasks at the application layer rather than at the network layer. Some points you might want to remember in bullet-proofing your firewall include:

If you want to connect your FTP server to the firewall, either use a proxy server or restrict incoming connections to specific port ranges. If you only want to download FTP files, you may wish to use the Web interface for access. A list of books on how to build a secure firewall can be found in the Resources section below.

The changing role of the Webmasters
With increased intranet development, many analysts believe that the role of the traditional Webmaster will be cleaved into smaller roles, often one per department. The chief Webmaster might oversee all functions of the Web connection, including technical functions, while departmental Webmasters would oversee content development and HTML tooling for that particular department's needs. The changing Webmaster role means that traditional network monitoring and security checking, network deployment, and such is still done by an IT administrator, whereas HTML authoring, content brokering, displaying content, and maintaining content on Web pages within the intranet itself is being managed by the many departments contributing to the intranet.

Why is this an important step to building an intranet? Without understanding the proper role of the Webmaster, it will be difficult to know if the Webmaster is performing the appropriate duties required by the job. Just as you need to know what you expect from your firewall to know if it's meeting expectations, the various Webmasters' roles need to be well defined to assure that the data that needs to be made available to your users is, in fact, being made available.

Here too, planning is the key. In some organizations, the Webmaster's role is strictly technical -- keep the servers up and running. In others, the Webmaster has content responsibility as well. By defining the role of the Webmaster and the ancillary staff, it will be possible to assure that updates to the CGI and Perl scripts are made, content gets pushed, and the Internet connections remain live.

The day-to-day management of the intranet is relatively easy to qualify, in some respects, but difficult to quantify. The traditional role of having an overall network manager who uses network monitoring software to avoid network overuse and to perform audit trails is still a key feature of day-to-day network management of an intranet. But this network manager might just as well be the Webmaster or a member of the Webmaster's staff as a member of the IT staff.

However, even with a large intranet, one or more technical IT Webmasters will also delegate numerous Web management tasks to individual departments responsible for putting up content on the intranet. This way, the IT department can perform the actual network monitoring tasks it needs to maintain network performance without being bogged down by numerous other tasks, such as maintaining content found on the intranet.

The individual departments that author such content, like human resources, sales and marketing, engineering, and accounting would assign one or more individuals whose responsibility would be creating and maintaining that content. Maintaining intranet content also includes such tasks as ensuring that documents are password-protected, up-to-date, and are also easily usable by those who need it. A list of books on how to build an intranet can be found in the Resources section.

And then there's training
The popularity of the World Wide Web and the ease with which users can put up their own content on a server and mark it up using HTML has made training users, department managers, and corporate executives in how to write, mark-up, and manage content easier than it was just a few years ago. Back then "tech" Internet protocols were the only options for data transfer, data retrieval, and management. All those are virtually unnecessary now for the everyday user. So, basic training for intranet deployment is easier than ever before.

Gone are the days when users needed to rely solely on the MIS director for setup, training, and problem solving. Users are already skilled in Web access; many are being trained in Web page design; and some are rapidly progressing to a point in which they need only initial training in their department's intranet applications and interim follow-up sessions. They do need to be assured, however, that they will be able to find technical trouble-shooters easily if they experience difficulties.


Click on our Sponsors to help Support SunWorld

Resources

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free! 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-03-1997/swol-03-intranet.html
Last modified:

SidebarBack to story

How SunWeb came to be: Sun's own story

Way back in the stone age of Web development, 1993, Sun Microsystems' began to develop what would become its commercial Web site and then, a few months later, its own intranet. Unlike 1997, which boasts a number of platforms and software tools for creating intranets, the early days of the World Wide Web boasted only a handful of Web sites and almost no utility software. Carl Meske was one of the system administrators at Sun's engineering facility at the time; numerous technical people were beginning to take a look at Mosaic, the first Web browser. Mosaic had just been developed at the National Center for Supercomputing Applications at the University of Illinois-Urbana Champaign and Meske, along with countless others, found this new technology unbelievably "cool." Sun began to use it within its engineering community.

By 1994, Sun had built its commercial Web site, and that Web site encouraged rapid proliferation of Web servers within Sun's engineering community. Developers devised their own "construction" kit consisting of numerous templates. These templates contained information such as how to build documents, how to design user interfaces, and how to implement procedures and technology on the intranet. This proved to be another case of a company developing tools for sale after building them for their own purposes.

Sun took a copy of its original Web site to the 1994 Winter Olympics in Norway, which resulted in a significant amount of publicity for the Olympics and for Sun. Meske notes, however, both Sun and the Olympic site had underestimated the popular response for this Web site, and the network was soon overloaded, resulting in a necessary and immediate upgrade of the network infrastructure.

However, Meske and others who were responsible for developing Sun's Web site also noticed the fruits of their efforts. The utilities that were being generated for HTML file conversion were significant steps. "We started building Web servers that would support translation of digital content," he says. "Our goal was to publish information to our own employees that we already had published internally throughout the corporation.

"It did not take much to translate this internal content into HTML, and so we developed `www.SunWeb.ebay,' our intranet. Hassan Schroeder was the Webmaster, I was the technical manager, and Judy Lindberg was the program manager," Meske says.

"We went to the content providers, (the internal departments that would provide the content for the intranet), with whom you need to work closely because you are trusting them to be the gatekeepers of the information they have. We would funnel in information from the content brokers through the staging Web servers (the public Web servers), and then we set up the network infrastructure. After that, we created templates and logos that each Sun operating company would be able to use in developing their portion of the intranet. We wanted to design a common look-and-feel and have the same established policies and procedures throughout for SunWeb," Meske adds.

"We kept track of the requirements that we wanted to verify; for example, we wanted to be certain that the actual server machine on which the content was being placed for distribution was owned by the correct person; we needed to also be certain that this content broker would verify that the content was not confidential information," Meske says.

"We set up templates and created a home page, like a product document, such as how one would go about publishing information on the intranet. With the use of HTML utilities such as MIF (Maker Interchange Format), among other utilities, as well as with filters and file conversion tools, the content was translated into HTML in a quick process that otherwise would have been laborious," Meske recalls.

"We moved all the content that we now had to the staging server that was specific to the individual Sun Microsystems' operating companies. We then moved all of this to the master staging server, and then moved it to the overall server, which resides at the firewall level," Meske says. By this time, he says, it was early 1994, and the explosion of Web servers among the engineering community was beginning to spread to all other departments within Sun.

"It is very simple to build a page, create your content, put it on a Sun machine, and boom, that machine becomes a Web server," Meske says. In order for all of this to work in a rapidly growing environment, the intranet team held weekly meetings with people within Sun, to ensure that growth would be managed. Some of those included in regular meetings on how to manage the growth of the SunWeb intranet were the Sun librarian, the many content developers within virtually each Sun department and operating company, and numerous network specialists to ensure that the infrastructure requirements were being met.

This entire procedure, Meske says, differed radically from the approach used in the not-so-distant past. Previously, there was a large flow of data back and forth among Sun employees using e-mail, NFS, or FTP. Departments that were sending information regularly were candidates for internal Web sites, Meske says. Using the construction kit that Meske and others created, Web sites within the company rapidly increased from 500 to 2000 within just a few months in 1994, thereby placing unrealistically heavy demand on the existing bandwidth during peak usage.

As a result, procedures were established to help regulate intranet growth. "We came up with a business plan, and we had to decide who would support the intranet and what impact it would have on the network. Since no such management tools existed at this time (1994), we had to deploy proxy servers to perform audit trails on every packet going out to prevent excessive browsing on company time during peak usage, such as at the end of the quarter," Meske adds.

"Every packet that went out to the Internet through the firewall was monitored to determine if it originated from corporate, engineering, human resources, or wherever. Guidelines were established concerning fair use of the intranet so that if a particular domain included 100 HTTP connections, people would not overuse it during peak periods. We let people know that we were monitoring their usage of the intranet, especially at the end of the quarter, otherwise the network would be hammered when we were trying to conduct quarterly financial business while employees browsed."

Software, such as the CERN and NCSA httpd servers, were modified to go through the firewall via proxy servers, according to Meske. These proxy servers not only increased security, but also saved time for users and improved performance within the organization. This approach worked because the proxy server would check to see if the information requested was available inside the firewall or if the proxy server had to go outside of the firewall to retrieve it. In that case, the proxy server would cache the retrieved information so that next time a client requested it, retrieving it would be faster.

The SunWeb intranet now includes functions from virtually every department and connects approximately 19,000 users.

SidebarBack to story


SidebarBack to story

Lockheed Martin takes "the long view"

With two mergers in as many years, Lockheed Martin leveraged its existing technology to create a worldwide intranet of 190,000 employees. Lockheed Martin, one of the world's dominant aerospace companies, evolved its intranet over a two-year period.

In 1993, Lockheed had 90,000 employees, but by 1995, Lockheed had acquired Martin-Marietta and became Lockheed Martin, totaling 190,000 employees worldwide. Lockheed Martin now has 80 business units and 250 locations in the United States. With a 200,000-user site license from Netscape for Navigator, the company now has this browser installed on each desktop within the company. The first use that Lockheed designed for the intranet was to describe the firm's policies and procedures manual.

"In the beginning," says Katy Finneran, manager of media and events for Lockheed Martin's Enterprise Information Systems in Lanham, MD, "there was a lot of conversion from the mainframes to HTML, but by 1995 this conversion was complete. At that time, the firm began looking toward intranet development. According to the Netscape study, in three years' time, Lockheed will show an ROI rate of 1,500 percent on its original intranet investment. As far as cost goes, the employees' access to information is so fast with search engines at their desk, that time savings is a real savings, because employees can find information quickly and do not need to use more costly resources," she says. (The study she's referring to was commissioned by Netscape and produced by International Data Corp.)

"By speeding up access, we saved a lot of money. It is much easier to teach people how to access the mainframe database by using information published on the intranet. Once that application was up and running, people were accustomed to accessing the intranet, and they expanded their knowledge to other uses, such as the human resources department's corporate-wide job posting application," Finneran adds.

Using this intranet application, the human resources department can post job information online so that employees can search by job title, location, or business unit. Once the employee gets a result, they submit a response for that job opening and then they can check on the status of the opening directly within the HR department," she explains.

Other intranet uses for Lockheed Martin units include collaborative work environments within engineering departments, a litigation-tracking system, and a facilities management system, such as one designed for Lockheed's Orlando, FL site. "The entire facility might be scheduled to turn its lights off at 7 p.m., but if you are working, you can go to a Web site and key in a code number for the room you are in, and that code will turn on the lights where you are," Finneran says.

SidebarBack to story

About the author
Kathryn Esplin is a technology writer based in Belmont, MA. Reach Kathryn at kathryn.esplin@sunworld.com.