In-Depth

Change management grows up and moves out

• By Philip E. Courtney
• June 4, 2001

It has been more than a decade since companies began to recognize the need for change management tools. Primarily MVS mainframe-focused back then, change management tools were implemented to help IT organizations get a better grip on application components such as source code, load modules, Job Control Language (JCL), copybooks and control cards. Requirements for functions such as source-to-load synchronization, versioning, reconciliation, component packaging, impact analysis, promotion/demotion and security transformed basic mainframe change management products from mere facilitators of component movement to software that became entrenched within the system development life cycle.

But distributed systems, multiple platforms and a slew of new technologies altered the way organizations looked at change management. Application components -- as well as the development, quality assurance (QA) and testing activities to build and support those components -- were no longer relegated to a single platform. Change management software needed to grow up and move out to encompass the expanding requirements of the enterprise.

"The challenge today is in synchronizing all of the integrated application components across multiple platforms," noted Jim Cavellier, project manager at AAA Michigan/Wisconsin. "These are components that work together in the production environment, and the change process needs to manage them as a group."

In addition to synchronization, "grown up" change management is required to meet many of the same mainframe requirements in the distributed world, while supporting existing processes for building and deploying application components.

While issues such as cross-platform synchronization and common, multiplatform processes have been raised by long-time users of change management products, these might be considered merely waves lapping the shore as the tsunami builds over the horizon. This is because many of the organizations that once disdained the use of change management tools have done an about-face in light of the pressures delivered by large-scale conversion projects such as Y2K and Euro. They began to ponder how they were going to manage all of those modifications across so many different platforms.

Today, through a variety of tools and a hodgepodge of homegrown automated and manual procedures, IT organizations have implemented the multiplatform change management disciplines that, for the most part, meet their needs.

Distributed changes

If production systems are the pavement, traditional mainframe tools geared toward change management of legacy systems reside on one side of the street, while tools for distributed systems live on the other side. Though some products have seen "trickle down" or "trickle across" extensions that have spread some support to other areas of the enterprise, bridges to connect the two sides are still in development, though not too far off in some cases.

Burlingame, Calif.-based Serena Software Inc., for example, is working to integrate its mainframe-based Change Man product with its newly acquired eChange product. This integration will enable users to centrally manage, monitor and deploy changes in MVS and distributed environments. And later this year, Computer Associates plans to deliver the first link between its CA-Endevor and recently acquired Platinum Technology CCC/Harvest products.

Despite the importance of the links, flexibility must be available to provide the level of control required by the organization, while supporting the fluid processes needed for a multiplatform environment. According to those responsible for performing and managing change, connections alone are not enough. What is needed is centralized management and control of all platforms. Equally important is a single interface that simplifies usage.

"Developers don't want to learn another product in order to perform the same tasks they're already performing on another platform," contends Larry Metzler, senior systems analyst at Proctor & Gamble Inc., Cincinnati. "Instead, the product should learn the processes that are employed within the company."

While Proctor & Gamble has long employed change management software for the mainframe, the firm implemented Computer Associates' CCC/Harvest a couple of years ago. The product was chosen to standardize the change process in the Unix environment and because the versioning tool delivered with the Unix operating system was only a portion of the technology needed to ensure application quality.

"Versioning is only part of the process," noted Metzler. "We needed to manage all of the auxiliary environments and to properly deploy components to the correct platforms." For example, at the most basic level, the procedures used by developers include the check-in of code so that they can perform modifications, the build process and a promotion to either a QA or test environment. "They'll promote to QA if it's a release or to the test environment if it's a fix," said Metzler.

One of the most important aspects of the process is the product's ability to create packages that contain all of the components related to a change, regardless of where those components may reside. CCC/Harvest, for example, contains an OpenMake function that can be automatically invoked during the build process. It moves all related components into the proper directories so that they can be included in the build process and deployed to the proper target environments. "It's smart enough to recognize the other pieces of the application and maintain control at the back-end of the process," said Metzler.

For a Boston-based financial management firm, the implementation of change management software and disciplines for the distributed environment followed on the heels of the launch of its Y2K project, as well as a tremendous leap in growth. "It used to be that verbal communications worked just fine," said Bob Hardway, production control supervisor. "But then our development staff was spread out to other offices as we continued to grow. We continually began to step on one another."

The implementation of Serena Software's eChange Man product helped the company gain control over its Y2K project, as well as traditional system development life-cycle activities.

With a mixed environment consisting of operating systems such as HP-UX, Sun Unix and Windows NT, "it was necessary for us to support our growth requirements while providing the ability to manage change," said Hardway. Some of the management functions included initiating control over access to production components, limiting concurrent access to code, and building the needed procedures for security and proper application deployment.

"Synchronization was also important to ensure all the right pieces were deployed on the correct servers," he added.

Using a Windows Explorer-like interface, the eChange Man product provides developers with a view of the servers and directories they are authorized to access. Through impact analysis capabilities it displays relationships between various application components, as well as versioning, comparison and merging functionality to show or blend differences between multiple versions of source code.

Linking mainframe and distributed changes

"Developers can see all the relationships and can search for variables throughout an application," said Hardway. "The product uses the information to automatically build a work list that contains all of the files needed in a change. It also automatically deploys the components to the correct servers."

Change management takes on an entirely new light for those companies responsible for maintaining applications in both mainframe and distributed environments. In most instances, these organizations have long employed mainframe-based change management software and discipline; however, it is not always possible to implement identical solutions for the differing environments.

"We standardized our change process for the MVS environment and tried to roll out the same procedures for the distributed environment," said Terry Von Bank, assistant vice president for change and configuration management at M&I Data Services, Milwaukee. "We found it was necessary to rebuild those procedures to meet the needs of the Unix and NT environments."

"While the disciplines may be similar, the needs of the mainframe and the distributed environment are different," said J. Jeffrey Broderick, senior systems analyst at Illinois Power in Decatur.

From a technology perspective, volume represents the major difference between mainframe-based change management and that of the distributed environment. The distributed environment simply has more components, files, objects, DLLs and so on going to more places and platforms when compared to the mainframe environment.

There also exists a cultural difference between developers of mainframe and distributed applications -- especially when it comes to the Web, where content has traditionally been driven by marketing. Change management must be able to encompass all related components regardless of point of origin, platform or language. But that technology does not yet exist today.

To help facilitate change management processes for a diverse environment, Illinois Power has assembled a collection of change management, procedural tools, automated notification and some homegrown programs.

While the mainframe environment has long been managed by Serena Software's Change Man product, change management in the distributed environment comprises tools such as Source Integrity from Waterloo, Ontario-based Mortice Kern Systems (MKS) Inc., SureSync from Alameda, Calif.-based Software Pursuits Inc., and Lotus Notes from Cambridge, Mass.-based Lotus Development Corp., a unit of IBM.

Running on a central server, MKS' Source Integrity is used for component check out and change control. Upon return to production, the source is placed into a centralized location where it is "picked off" by Software Pursuits' SureSync product and distributed to the proper servers using a target list created by developers using Lotus Notes.

"Lots of internal development was performed to build an automated process," said Illinois Power's Broderick. "But we'll need to improve the system as we continue to grow. Seamless integration and a centralized interface to all change management activities will be crucial."

Seamless integration in change management is the goal for virtually all companies with large-scale computing environments. This includes a centralized location to manage all application components regardless of platform. "The ultimate vision is to place the entire production environment under the single point of change management control," said Cavellier at AAA Michigan/Wisconsin. Most of his apps integrate across a number of two- and three-tier architectures.

The company employs CA-Endevor for mainframe change management, and PVCS from Mountain View, Calif.-based Merant for the distributed environment; but sitting on top of change management activities is Merant's PVCS Dimensions, which assists in process management.

"[PVCS] Dimensions links the different development environments and helps us better manage the process," said Cavellier. For example, a typical PVCS Dimensions package could include Endevor packages, PeopleSoft Project Ids and associated documentation. And while packages are reviewed for approval and simplify monitoring of the change process, "it doesn't do the work for you. It makes you think," emphasizes Cavellier.

Similarly, M&I Data Services has placed some controls over its change management process using Impact from Naples, Fla.-based Allen Systems Group and CA's Process Engineer. "We use the [Process Engineer] tool to help automate our software development methodology," said M&I Data Services' Von Bank. "It drives the processes needed to deliver quality systems.

"As for the Impact product," she said, "it is used to describe the functional changes as requested by users and customers."

Sitting on top of CA-Endevor and CCC/Harvest, Impact includes change information such as migration dates, types of components, impacted users and business reasons for the change. "Nothing is automated, but it provides a method for documenting changes made with the change management systems," said Von Bank.

Impact analysis

Although centralizing change management activities for all platforms will provide the benefits of single access, single control and a reduced learning curve, another important function that must be expanded across platforms is impact analysis.

While virtually all change management tools today provide some sort of interactive or subsumed impact analysis functionality, all of those functions are limited to the platforms on which the tools operate. For example, while a tool that performs change management in a distributed environment can easily and automatically reveal the relationships between a C++ program and files, the capability does not exist to determine if the C++ program and files are related to a mainframe copybook.

"We have a large number of applications that have related components on a variety of platforms," said Von Bank. "While we can perform an impact analysis to determine the relationships between a PowerBuilder application and some Visual C++ components, there is no way, with our change management tools, where we can automatically reach across to determine the impact on a mainframe app."

Although traditionally outside the realm of change management, enterprise-wide impact analysis is fast becoming a requirement for companies like M&I Data Services, Illinois Power and others.