Access control issues are entirely different on the viewer or client side of the web model. Here we start with the idea that there is no control at all, other than the fact that the access is read-only. In other words, anyone on the network can hit the web site and extract the contents, but no one can edit or change the contents at the site. That's for starters.
Beginning with this open model of universal read-only user access, we then have other levels of access control:
Read-write access to selected materials. The authors or developers of the web site can selectively provide users with both read access and write access to certain materials. For instance, the authors might include interactive forms that can insert or update records in a database at the author's site. Though rarer, its not hard to imagine that future server-side applications will be used to pass edited documents back and forth from authors on the server side to collaborators on the client side. IP address filtering. The authors or developers of a web site can selectively allow or deny access from specified IP addresses. Most likely, this would be used to limit access to certain audiences, such as people in the same department or work group, or to certain classes of users such as dealers or sales reps. User authentication. If desired, web authors and developers can take their sites all the way back to the old login model where everyone who accesses the site must have a user ID and password. Naturally, this increases the administrative burden considerably, since each user ID and password must be set up individually at the web server.
Though access issues may seem a somewhat arcane subject, they are really at the core of the entire management issue. Though the web comes with certain access controls built in by default (read-write on author/server side, read-only on user/client side), much of the creative work in developing web systems revolves around how access is manipulated to provide different kinds of services and functionality.
One of the key moments in computing history was probably the day-sometime back in the 1970s or early 1980s-when they changed the name of most corporate computer departments from "data processing" (or DP) to "information systems" (or IS). This change recognized that computers could be used to deliver something more than just raw data in the form of mind-deadening numbers; instead they could be used to provide people with useful information.
The job of computer departments, then, was to capture information, process it, and present it to users in an automated way. And they've done an admirable job, considering what they've had to work with. Back in the days of data processing, the computer room was like a scene out of Dr. Frankenstein's lab. The old CRT displays were covered with gibberish. Today your very own "personal" computer is more likely to greet you with a smile, a catchy tune, or even visions of flying toasters romping in outer space.
But the job of automating information systems is far from complete. Even today, with all their growth and technical sophistication, corporate information systems only handle about 20 percent of the total information available in the enterprise. The other 80 percent falls under the category of miscellaneous. Information systems are great at handling all the mission-critical data, including customer information and accounting records, but not all the other stuff, such as reports, memos, catalogs, specifications, manuals, budgets, project schedules-you name it.
Nowadays, these various bits of information are prepared on computers, of course. But then they often get transferred straight into the old information system: the copier, mail room, and filing cabinet systems that handle tons of paper every day. Normally, you can't see these documents online unless you're the one who authored them. Or if they are online, they're online in an inaccessible way: in certain people's in-boxes, on certain network file servers that can only be accessed by certain groups at certain times, locked in PC WinHelp systems, and so forth. There hasn't been a way to take all of this information and catalog it the same way you can catalog information in a database. Raw information is a messy business that doesn't easily submit to neat solutions the way raw data does.
The problem of automating the other 80 percent of corporate information, therefore, has been partly due to a lack of suitable technology. That's no longer true with the web. First, people put their information online using web publishing tools, conferencing tools, and messaging tools-instead of going onto paper with the old desktop publishing tools. Then a search engine comes behind and makes it all accessible enterprise-wide within seconds.
The feat you accomplish is a little like what might have happened if you had deliberately set out to bring online the other 80 percent of data that remains untouched by the corporate IS function. But instead of years of dogged efforts by squadrons of bleary-eyed IS people and contract programmers, it all happens automatically within seconds.
Of course, the fact that it happens magically on search engines like Lycos doesn't mean it will happen magically on your Intranet. It won't happen until the web is fully populated with information from all segments of your organization. So the trick will be how to get the ball rolling, how to gain wide acceptance of web technology in your organization, and how to be "smart" in your use of the technology so that everyone remains productive during the transition.
Probably the best way to manage an Intranet may be to have an internal vanguard team that functions as consultants and advisors to the rest of the organization on web technology. It may be that your company already has such a group that has charged ahead with its own internal web site and that is full of people who already salivate over the technology. If not, it's likely that such a team might be assembled from the ranks of IS, network services, or other groups that have an IT orientation. Or you may want to pick individuals from various disciplines, such as technical communications, marketing communications, database services, corporate communications, and IS.
The responsibilities of an internal vanguard team could be quite diverse, but would probably include:
An internal consulting group set up to perform these tasks can help promote organization goals without creating a centralized bureaucracy. At first it may be that such a group exists independently of IS, since in many cases an Intranet is considered a foreign concern to IS. It may be that someday this evolves into a department that actually swallows the IS function completely.
Another area where management can make a difference in the development of an Intranet is by promoting standards for development, design, and production of the new systems. There are basically two ways your company can deal with an internal web: (1) Everybody reinvent the wheel everyday and do things in the hardest possible way, or (2) everybody benefit from a set of standards, guidelines and tools that will help people work smart and be as productive as possible. Admittedly, these are two opposite extremes of the spectrum. There are gray areas in the middle, somewhere. But it pays to examine both the worst case and the best case to make a point.
Let's look at the worst case first. Assume that everyone is on their own without any standards, guidelines, or training to help them. First, everyone will have to go off and learn about web technology on their own. They'll have to read books like this one (actually, not a bad idea) or do about a year's worth of thinking and study on the subject before they realize how web-based communications can benefit the entire organization. Then they'll have to find it in their heart to put the organization's best interests ahead of their own lethargy, and start using the web. Not too likely, right?
Now let's look at how a well-designed set of standards, templates, guidelines, tools, and workflows can help an organization. The workflow is built around a set of templates and the way that information is deposited into them and then makes its way from the author's desk to the web.
The templates would contain a set of style tags (also called a style sheet) that everyone should use to format their documents: Heading 1 for major headings, Heading 2 for subheadings, Bullet for bullets, Body for body text, and so on. To use the style tags, just point at the paragraph you're typing and select the correct tag from the style menu. It's a little disorienting the first few times, but you get used to it. You can distribute the templates as hyperlinked directly from a web page, and include online instructions on how to use them or a full-fledged online style guide.
It's easier to distribute the workload in such a way that everyone cooperates in maintaining a publishing standard. This helps us avoid the retraining that would be involved in a move to new tools, or the rework and doubling of effort required if we have to reformat everything that everyone writes. Style sheets are not hard to use: in fact, they will make everyone more productive even if you aren't doing web publishing.
For each set of templates, there will be a set of map files and a tool like HTML Transit, WebMaker, or Cyberleaf that can suck the documents right out of their source directories and turn them into published web documents on the fly. The important thing is that the templates and the map files be designed to work together by someone who understands style sheets, HTML conversions, the tools involved, and the formatting requirements of the web.
Once all the elements in a template-based workflow are set up and meshed properly, the conversion process is so easy that a single administrative assistant (or webmaster) could easily handle all the conversions required by a workgroup-or even a set of workgroups-without seriously breaking stride.
Styles sheets are destined to become an important part of the corporate Intranet, as future browsers and Internet tools begin incorporating the style sheet standards developed as part of the HTML 3.2 specification (see http://w3.org/). Microsoft Internet Explorer 3.0 was the first browser to recognize these new cascading style sheets, and Netscape 4.0 (Communicator) also came online with its own style sheet features. If you want to enforce look-and-feel standards enterprise-wide, there may be no better way to do it.
Letting people take the technology and run with it is one thing. But if you're going to create a truly company-wide Intranet, you're going to need participation from everyone. That means not only identifying mission-critical applications and creating teams to develop them, but getting everyone to use the Intranet as a standard conduit for their own critical information.
One of your greatest challenges in doing this will be helping people understand the benefits of the new communications model. Just because you find this technology powerful and productive, you shouldn't assume everyone will share your feelings automatically. To get everyone working on the same channel, it's going to be necessary to achieve buy-in from both the executive level and the grunt level. To bring benefits to the entire enterprise, the web must achieve a certain level of saturation within the organization.
Preliminary reports back from the front say that it's not easy to impress rank-and-file employees in the benefits of this technology unless several things happen:
Upper management makes it clear that it supports the effort, and that it considers company-wide Intranet to be an important strategic tool of the organization. The web contains a critical mass of important applications that people need in their daily work and that are essential time-savers. That means not just documents but crucial up-to-the-minute data, like the profit-and-loss statements Chevron maintains for each team (see Chapter 4). Rank-and-file employees get the tools and training they need to make web publishing easy-and even fun.
Never underestimate the enthusiasm of empowered employees. In places where employees have been given the right tools, the right models, the right emphasis on benefits, and the right training the Intranet has achieved critical mass and taken off. In some places, the Intranet is so popular that other problems arise: the problems of keeping people from doing too much with it and using it for inappropriate purposes, such as putting up pictures of their children and dogs.
In places where employees don't get the proper tools and training, where management imprimatur is absent, or where the web is still in an experimental or stripped-down stage, the task will be harder. People may applaud the new technologies, then turn around and go right back to doing things the old way.
There's also something be said for a laissez-faire attitude. After all, you shouldn't have to force people to use web publishing tools, any more than you have to force them to use desktop publishing. People already use desktop publishing as a matter of convenience, to help rapidly develop the standard written communications required in every job. They should use web publishing the same way, but also for its added benefit of allowing document distribution without the hassle of printing and distributing paper documents. When people see the benefits of the Intranet fairly presented-that it can speed up their communications and take the drudgery out of distribution-it should be sufficient incentive for them to get involved.