Defining Change Management Requirements: Issues and Strategies By Stephen M. Brown Stephen M. Brown is an independent consultant and industry spokesperson regarding automated software management strategies. He has over 17 years of experience with vendor software development and support. Now more than ever, the eyes of management are focused directly on IS, and with good reason. As the keeper of software assets, IS holds the key to critical corporate and customer services -- services that affect productivity and profitability in a very big way. For this reason, issues relating to software reliability, availability and auditability are quickly moving to the forefront. This scenario wouldn't concern IS professionals if software applications didn't change. But they do change, and frequently. Every week, hundreds of environmental and applications changes are made to strategically support new business requirements. Key IS personnel work diligently to develop effective methods for controlling and managing the ever-growing, ever-changing software inventory. Unfortunately, things will get more complicated and overwhelming as we add CASE tools, distributed development and the prospect of cooperative processing to the picture. The good news is that it is possible to develop strategies for controlling and managing all the change processes involved in developing, maintaining and distributing software applications. But how do you develop a change management strategy that is flexible enough to fit your needs, both present and future? Meeting Today's Requirements In addition to meeting site requirements that are unique to particular environments such as MVS, DB2, CSP and PC, there are a number of specific change management requirements that apply to the management of software objects, software processes and software resources. Managing Software Objects Being able to find what you need, and being able to verify and identify what you've found are two critical requirements of software object management. Versions, Variations and Configurations. One of the initial challenges in managing source code involves tracking versions of software objects through time and space. Changes to software objects over time are well understood as versions. However, the concept of space or location changes -- traditionally associated with the movement of software through the development life cycle -- has taken on a new dimension with the emergence of concurrent development and distributed execution. These practices dramatically increase the number of legitimate places that software objects can be located and modified independently. Emergency fixes that supersede ongoing program enhancements, and the special exception changes made to code as it is transported to satellite divisions are examples of business requirements that give rise to program variations; variations that can cause serious problems in ongoing maintenance. Add to this scenario the fact that programs rarely function in isolation; they have complex relationships with a multitude of other objects that are also evolving, though not always along identical paths. The need to accurately identify and track these program-component interdependencies or configurations is also an important requirement in developing change management strategies. Inventory Classification. Inventory management provides a critical mechanism for mapping and tracking the flow of software objects along their unique, though not necessarily linear, life cycle paths. Ideally, inventory and data base disciplines a re combined so that an object's physical location can be separated from its logical identification(s). This allows a single software object to own multiple names, statuses or attributes -- without spawning unnecessary physical copies. See Figure 1. The need to overlay your physical inventory with a logical classification and control structure typically arises when your DP staff can no longer readily and accurately locate the "right" edition of program code. A formal inventory structure is also needed if access control or change accountability is becoming an organizational issue due to audit requirements. Non-Source-Based Development Environments. When examining your requirements for inventory control systems, keep in mind the special needs and limitations of non-source-based development environments. Their emphasis on modularity and reusability result in a greater volume of discrete components with extremely complex relationships and dependencies. Maintenance and enhancement procedures can be very risky without accurate and up-to-date configuration and impact analysis data. The frequent limitation is that these non-source-based systems typically employ proprietary data structures and are thus closed to the tools and disciplines that you use on your conventional software inventory. If your CASE product does not offer sufficient change management within its closed environment, it needs to support import/export facilities or an Application Programming Interface (API) that permits a viable means of interfacing to an external change management system. Managing Software Processes A common issue in corporate MIS shops is improving the integrity and availability of critical software applications. In the area of change management, this translates into better control of the processes that cause software objects to change status, content or location. Sometimes this is expressed as the goal of enforcing corporate standards; more often the motive arises from the need to reduce ambiguity and error in the transformation of objects from source to executable, or from phase to phase within the life cycle. If your operations demand that software objects be handled with greater consistency and auditability, then automated process management should be high on your requirements list. Defining Actions and Processes. All automated applications support the traditional add-modify-delete actions. But does your software management environment support the use of English language verbs to manipulate versions, variations and configurations? Can your staff generate outputs, retrieve current or past editions, or migrate logical groupings up (promotion) or down (back-off) the normal life cycle path? Can they perform those functions consistently and without extensive knowledge of your environment's technical quirks or political sensitivities? If you seek improvements and operational efficiencies in these areas, then consider using a software control mechanism that gives staff a logical view of their tasks while automating the underlying mechanics. Regardless of the physical implementation of this control layer, it must satisfy two key functional objectives: first, it should simplify and standardize staff operations; and second, it must work in conjunction with the inventory management structures mentioned earlier. Detecting, Tracking and Reporting on Change Events and Activities. When an automated change management methodology combines an automated process control mechanism with a logical inventory structure, it provides a powerful and reliable means of detecting, tracking and reporting on change events and activities. This information enables you to identify who changed what, when and why, fulfilling your requirements regarding project coordination and problem resolution. Supporting Past, Present and Future Software Iterations Since the development and movement of software is a dynamic process, your process language should provide support for all software iterations -- past, present and future. o Past: Problem resolution strategies, occasionally even legal requirements, may require the ability to re-create a program, or entire application system, exactly as it existed at some prior point in time. Configuration data and the supporting retrieval commands make this possible. o Present: As parallel development practices increase, the automated management of concurrent changes becomes an important requirement for coordinating staff activities. Consider the importance of signout/checkout functions, as well as flagging of unintentional regression. o Future: Ensuring the future integrity of current systems is one of the many purposes of impact analysis. Pending changes can also have a disastrous ripple effects if subtle component dependencies are not detected prior to production implementation. This requirement alone has often justified extensive software management disciplines for mission-critical applications. For this reason, impact analysis should be a standard feature of the inventory's configuration data. Managing Software Releases and Packages Process control must also support group level operations -- the ability to select and operate upon packages representing an inventory cross-section. Packaging provides a "forest over the trees" method of scheduling, coordinating and managing change activities with the big picture perspective so necessary for companies that make hundreds of discrete code changes weekly. Package processing is most often needed to deliver or release software bundles across organizational or life cycle boundaries, but it is also becoming a popular technique for localized project control. In general, all processes used to manipulate individual software objects are also required for package execution. Managing System and Staff Resources A comprehensive and controlled set of software actions operating against a well classified inventory structure sets the stage for the final aspect of software management: the coordinated and effective use of limited machine and staff resources. Machine/System Resources. The need to conserve DASD was a prime motivation for the initial development of library management ystems over 20 years ago. Today, hardware is rarely the bottleneck or gating resource to corporate objectives. Yet even with the additional storage of an inventory data base, it is still likely that change management will produce moderate DASD savings considering the compression and delta-deck technologies employed by most commercial implementations. But do not expect any savings in CPU. CPU cycles, perhaps the cheapest data processing resource, is the commodity expended to achieve improved system quality and staff productivity. Staff Resources. The final and perhaps most important requirement of a software management strategy is to both control and increase staff performance. This subtle balance is achieved by applying flexible automation technologies that protect software assets from unintended or unauthorized change while boosting staff effectiveness through improved coordination and communication. The key is to implement rule-based control structures that enforce corporate policies and risk objectives by specifying the conditions (time, status, attribute, etc.) under which certain process commands can be issued by classes of predefined individuals against specific portions of the software inventory. The explicit authorization of a formal security system is readily implemented through these structures. Other mechanisms such as approvals, signout/checkout and notification can be added in accordance with your company's need for staff management. Keep in mind that since technical personnel tend to resist controls, you will need to identify your requirements cautiously. And for each constraint you automate, you may want to provide an equal or greater number of productivity enhancements. Anticipating Tomorrow's Requirements The emerging development strategies involving client-server architectures, distributed development and work station connectivity will challenge change management disciplines by increasing the quantity of inventory items and locations. Peer-to-peer architectures and platform interoperability will qualitatively challenge your control mechanisms by requiring multinodal inventory control points with the attendant synchronization problems. Understanding and addressing your current requirements will help set the proper foundation for addressing these expanded needs tomorrow. Preparing the Way for Future Architectures. Change management will be one of the big winners of the vendor move to open architectures. With SAA, AD/Cycle, and SystemView, IBM is setting strategies that will ultimately result in greater compatibility among the data objects and communication mechanisms of the independent software vendor community. Progress on non-IBM standards such as DEC's EMA, OSI, OSF/1 and others are adding momentum to this trend. Your best preparation from a change management perspective is to begin classifying your inventory objects and standardizing your transformation processes now. Conclusions Although the list of specific change management requirements is long, there are three important observations that can be made from the start. First, automated technologies are an absolute must. Manual or semiautomated methods are time-consuming and prone to error, rending them infeasible by most IS standards. Traditional library management systems, while a step in the right direction, are extremely limited in their ability to manage the software inventory logically and to provide additional software management functionality. Second, stick to the basics when initially selecting and implementing your strategy. In defining your requirements today, do not be tempted to "chase the rainbow." By focusing on basic automations that coordinate your staff as they perform disciplined operations upon a life cycle inventory structure, your company will meet its most critical software management goals without being distracted by the unique constraints of any particular development technology. Third, adopt a software management strategy that is positioned to carry you forward into the future. By anticipating the explosive growth in software management complexities that will come from the industry trends toward distributed operations and decentralized development, you can ensure that your current strategies will have the greatest resiliency and longevity. /* Was this article of value to you? If so, please let us know by circling Reader Service No. 00.