Five Intranet Management Problems You Can Solve With a Change Management System By David Rowley Remarks made around the office: "I updated that document yesterday, but it's not appearing on the Intranet. What happened?" "The new version's wrong! Did we back up the old one?" "Chris and I were editing the same file at the same time, but I finished first. His changes overwrote mine! "Who made that change?" "Only the Webmaster is allowed to change any files, so your changes might be implemented by Christmas." If you hear statements like these on a regular basis, you may be suffering from change out of control. Changes in files are necessary and beneficial, but they also have to be controlled. People in a development environment know all about this problem, and have devised a sound way of managing the volume of changes to software files. The discipline of managing, controlling, and automating changes in your files is called software change management. The Five Problems You only need to go as far as your Webmaster to learn all about the volume of change in a Web or Intranet environment. Just like their developer cousins, Webmasters struggle to manage the magnitude of change to a Web site. Now, with new integrated authoring and browsing tools like those available from Netscape Communications, making changes to a Web site is as easy as saving a file and pressing a "one-button publish." This technology opens the Web up to a whole new breed of content providers making changes to a site. Before the technology, changes had to go through the Webmaster because of the difficulty in executing the changes. Now, these new tools have empowered everyone to make their own changes. And consequently, new change problems have emerged. The following are some examples of common change problems affecting Intranet sites. 1. Your update didn't appear Even though you've made a change to a document, the old version remains on the Web. Until the new version appears, the time you spent updating it is wasted. If you can't find the new version, you will have to redo the work. This problem typically happens because two copies of the same file exist and the file you updated is not the file copied to the Web site. Say, you make a private copy "just in case." A commendable precaution but prone to problems. This private copy will often by-pass scripts and automated update tools. You may not notice that two long pathnames differ in a single component and you alter the wrong file. With two copies of a file, mistakes will happen. Or to put it another way, duplicate files diverge. You can solve this problem by controlling both how you change the original source document and how you make those changes available on your Intranet site. Some kind of approval or promotion mechanism is most useful. One of the first rules of change management states that you store each source file in only one place. 2. You can't restore an old version You need to examine an old version, but you can't. The backup has failed, or the changes were made during the time period between backups, or no backup exists for that directory. You usually discover this problem when you realize someone has made a mistake in the new version or released information before its time. For example, suppose you plan to change your internal purchasing system and, with it, the related forms on the Web site. If the new forms are incompatible with the old forms, then new page on the Web won't work with the old system. If you haven't put the new system in place yet, chaos will follow. Prevention is the best solution to this problem. One clear method of prevention requires having a backup methodology and an archive of all versions of the files on the Web server. Then, when a mistake does occur, the older version can quickly replace the mistaken version. This ideal archiving system is simple, automatic (or nearly so) and easy-to-use. 3. Multiple authors, multiple overwrites Two people opening the same file at the same time for editing creates an opportunity for file overwrites. In this situation, one person may save a file every minute while the other makes changes over a couple of hours before saving. Consequently, that file is a free-fire zone. As soon as the second person saves the file, all of the first person's changes disappear. Neither is careless, but a single save command has erased two hours of work. A change management system saves changes sequentially. It allows anyone to read a file at any time but controls the ability to save changes to that file. If you want to change the file, you must lock it first. This lock warns others that the file is being changed and prevents them from making changes. Then, when you finish changing the file, you unlock it making it available for someone else to lock, edit, and unlock. 4. You don't know who changed what or when When you discover a mistake in a document, you have no way of knowing who changed the file. With most systems you have difficulty determining who changed a file and when. Even if a file system records who last changed a file and at what time, that's usually all the information the system provides. This kind of system rarely keeps a history of all the changes or of the reasons for those changes. Since a proper change management system keeps a record of all the changes, it's easy to add who changed the files and when to the record. Ideally, you will enter a reason for the change like, "Fred added a new section to the whitepaper on change management." On an Intranet site, every object should have its own history. A single page may contain many different objects (graphical images, audio files, applets, etc.) each with its own history. For example, if your corporate logo changes, regular visitors to your home page will recognize the change. However, the change will actually take place in the image file not to the home page itself. A record of changes to the home page won't help track changes to the logo. 5. Your Webmaster does all the work Organizations solve the problem of managing change to a Web site by assigning the responsibility for change to their Webmaster. If an organization funnels all the work through a single person, the Webmaster, then it automatically assumes that he or she is accountable for the accuracy of the content. That funnel soon turns into a bottleneck, and the Webmaster who must do everything soon finds he or she has no time to do anything. A change management system approaches change in a more reasonable way. It evens out responsibility for change by enabling multiple, authorized people to make changes to Web content. Much of the work involved in putting files on a Web site is quite simple. It involves changing content, copying files, and confirming the links are correct. These kinds of changes users can make for themselves rather than requiring the Webmaster do it except for the possibility of mistakes. By protecting the files on your Web site against unwanted changes, a sound change management policy empowers users to make changes to documents in a structured, managed way. People can then work without the fear of losing data and the Webmaster can have a moment or two of peace of mind. The Concept of Change Management A change management system creates a "repository" recording all changes/revisions of a file so you can retrieve any one of the files later. But, change management systems frequently have a number of additional features as well. Some quite sophisticated. Of course, a change management system with all the bells and whistles is not for everyone. Some users require only a basic change management system for managing Web documents (such as a human resources or marketing professionals); others (such as the Webmaster or a team leader) require more advanced features. Basic features A change management system must provide seven functions: 1. Get a file from the repository in order to read or edit it; you can retrieve any specific copy of a file from the file's history 2. Lock the file so others can't change it while you edited 3. Put the file back into the archive 4. Unlock the archive so others can edit the file 5. Identify the different revisions with a number or a name 6. Provide an index or list of the changes made 7. Allow simultaneous changes Advanced features As already mentioned, some users find the basic features of version control are not enough for their needs. Typically, these people deal with the files rather than their content. They include team leaders, project managers and Web site managers. The problems faced by these more sophisticated users include: Finding differences: A user often needs to visualize the differences between any two versions of a file. Object re-use: Some components of the Web pages on a site are standard for the site (i.e., graphics and logos) and should be re-used as much as possible. Other parts are solutions to common problems and the program should re-use these as well. Can the software handle groups of files? Synchronizing groups of files: Files change at different rates; a team or project leader must ensure that a particular set of file revisions are kept together. Security: Large development projects require enhanced security. Some project maintenance actions should be restricted to qualified or approved users. Approving content: If the Intranet is used as a staging ground for documents that will later appear on the external Web site, there must be some way of distinguishing approved files and documents from those not approved, provisionally approved or under review. Team management: A Webmaster or a team leader cares about all the changes made to a group of files and all the files locked for editing at any one time. This person requires a "group-view" of the file system that differs from the narrowly-focused view of a single user. It's important to make sure that both the basic and advanced systems are compatible. For example, the two change management products produced by MKS for the LAN and the Web (MKS Source Integrity and the MKS Integrity Engine) use the same format for their file repository. A Policy for Change Begin with a sound policy when applying a change management system to Web development. Policy is the rationale behind tools and procedures, and without a sound one, the tools won't be nearly as helpful as they could be. When drawing up a policy, consider both the organizational structure and the logical structure of the Web site or sites: Are people organized into teams, departments or, perhaps, in a flat structure? How does that reflect the Web site? Are files under a version control of any sort? Are there both an Intranet and Internet site? If so, how do the content standards differ? Once you determine the site's structure and needs, consider the process by which documents get to the site --the approval; cycle. Different organizations have different procedures. The common history of a published piece of dynamic content is: New content is generated. This may mean modifying old content or creating new content. Content is approved. The person who created the content may be the only approving body, or there may be a formal review process. The Web page is tested. Again, this may be handled strictly by the person who created it, or there may be an official tester or testing body. The new content is made public. The order may occur in a slightly different sequence, but these four steps happen. Some may even happen more than once. If the content is not approved, new content must be generated again. You must also ask specific questions when formulating a policy that identifies responsibility at different stages in the process of documents getting to the site. 1. Who approves documents or file content? In order to streamline the use of new content on a Web site, there needs to be an approval process in place. The approval process will depend upon the nature of the content. For example, an art director may have approval over the use of images or logos, especially if they apply across the entire organization, and a development team leader may have to approve a new Java application. 2. Who will test the changed pages to ensure they are correct? How will the test be done? This is an important part of the approval and validation process. Web pages on the Internet represent an organization and mistakes do not reflect well even if they're relatively minor ones such as spelling errors or incorrect links. 3. Who has access? In other words, who can replace or write to the files? Even on an internal site it may be useful to establish a process for approval and access. On the external site, perhaps only the Webmaster may change files, or perhaps the Webmaster and team leaders. In most organizations, the person who places the file on the external server essentially approves it for publication. Conclusion The World Wide Web is almost synonymous with change. Essentially, every time you save a document you create a new version of a Web document or applet -- you make change. Mastering the Web depends upon managing that change properly. The ability to manage change depends, in turn, upon an effective version control system. Version control reduces lost information, eliminates confusion and duplication of effort creating bottlenecks, and keeps productivity up. The growth of the Intranet has brought in a new breed of content providers: people not interested in learning the technical details of version control. Therefore, version control must be made convenient, easy and invisible to them. The key lies in integrating version control tightly with the Web server. By allowing this new breed to maintain the revision history of their dynamic content with no extra effort, products such as MKS Integrity Engine lets them reap the benefits of version control without creating a need for technical education. Of course basic version control isn't enough for Webmasters or professional developers who develop complicated applications for the Web or organize large Web sites. These people require advanced version control to deal with internal and external servers, firewalls, multiple source files and approval cycles. Advanced version control is built upon a sound policy and understanding of the site's needs. It requires additional features such as extensive audit trails, access control, and organizational tools such as projects and sandbox directories. With a sound policy and the right tools, both the new breed of content providers and the old suppliers can manage change effortlessly and with integrity. MKS is a software company with more than ten years experience in managing change. MKS Source Integrity is one of the market's leading change management systems for developers. Now, Webmasters and Intranet developers trying to manage change and eliminate bottlenecks in their Web site development process can use Source Integrity. MKS also recently announced the release of MKS Integrity Engine, a basic version control system that integrates with leading Web servers. Integrity Engine, the version control system Netscape Communications chose to bundle with the Netscape Enterprise Server, is available for other Web server platforms. Unlike others in the version control market, MKS is the only company addressing the problems of managing change in both the client/server and Intranet development environments. About the author: David Rowley is Vice President of Business Development at Mortice Kern Systems Inc.

Use of this site is subject to certain Terms & Conditions. Copyright (c) 1996-1998 EarthWeb, Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited.