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.