Developing an application is an iterative process. Developers constantly revise pieces of their application and periodically move these components to the test environment for feedback. At some point, user feedback must be solicited and the application must be stabilized. After an application is released for general use, problems must be fixed, tested, and incorporated into the production environment. This is the essence of change management, which is also sometimes referred to as configuration management or production control.

Organizations vary widely in how they approach change management. Some delegate much of the responsibility to developers while others establish separate organizations to maintain a higher degree of control. Typically, developers prefer to stay in their development tool environment to perform these duties while change management professionals prefer batch-oriented and API-based methods to move application components between environments. Developers may be required to implement a user-developed change management application in order to initiate changes after the application is moved to production. A combination of these approaches is often used in larger companies.

The examples that follow illustrate two different change management processes that might be found in a company. These sections describe product features and methodologies that can be utilized by companies to meet their change management objectives with Managed Reporting.

As shown in the following image, developers move application files between the development and test environments using their development tool. When the application is finished, a systems person copies the application from test to production using operating system utilities. There may only be a single test environment.

In this example, four WebFOCUS environments are established to increase the level of control over the process. Developers use the Explorer window in Managed Reporting Developer for Windows and Developer Studio to move application files from development to test. Developers then sign on to the Change Management Extract Utility when they are ready to move their changes to the user acceptance test environment. The Change Management Extract Utility allows the Developer to select the files to be moved and creates a change package on the Web platform. An administrator can subsequently insert the change package into an acceptance test using the Change Management Load Utility or (Java) Load Program named IBILoadRepos. Some organizations may choose to call the Load program from an automated process in to achieve better integration with their business processes.

As shown in the following image, when the application is deemed ready for release, the change management organization initiates a file system copy of the application to the production environment. Users begin using the application and the change management process shifts into an application maintenance support role. From this point forward, incremental updates to production are facilitated by administrators using the Change Management CM Load program.