Remarks made around the office:
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.
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.
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.
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.
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:
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.
