16.2 Change management

Companies that intend to survive in today's rapidly changing world must constantly adapt to these changes. It is important to remember that unregulated change can be just as disastrous as a reluctance or refusal to undergo change. Controlled change is a change toward a well-defined destination, with a clear idea of the cost and risks involved. In a Linux-onthe-mainframe environment with numerous Linux images and possibly traditional operating systems all on one machine, there are both challenges and opportunities for change management. In this section, we describe in some detail our hypothetical companies' change management strategies to represent the diverse successful approaches to change management in real-world Linux-on-the-mainframe environments.

Our StoreCompany example (see 16.2.1, "StoreCompany change management policies") shows how Linux images can be used to isolate risks in a mainframe environment. Risk isolation provides the opportunity for rapid deployment of new applications and projects. This does not mean that all Linux projects depend on rapid change for value. You obviously do not need to apply the same change management policy to all of your Linux images, especially those images associated with high risk.

We use the examples of ISPCompany and StoreCompany to illustrate which policies can govern change in different environments. We will see that both companies apply the most conservative rules and restraints to changing assets that are associated with the greatest overall risk, while applying less stringent rules to assets that are not associated with great risk.

The reasons for making changes fall into three broad categories, which are often covered by separate policies:

  • Some changes introduce new functions. These changes can open up new opportunities for your business.

  • Some changes fix or prevent problems. These changes are also referred to as maintenance.

  • Security patches, because of their sensitivity, are usually treated as a third category. (See 8.6, "Keeping up to date on security issues," for sources of information on current security issues.)

    After a security patch has been applied to an image, you have to verify that your image is still hardened to the extent that you intended. 8.3, "Before opening the doors: hardening," addresses this issue and also includes a brief discussion of security patch policies.

16.2.1 StoreCompany change management policies

StoreCompany is using Linux as an opportunity to rethink its conservative change management policies. StoreCompany's aim is to facilitate fast deployment of new applications where this opens up significant business opportunities.

StoreCompany has a set of change management policies that is typical for mainframe shops. These policies have served well by keeping individual system outages to an absolute minimum in their sysplex environment.

Existing StoreCompany change management policies

  • There are no planned sysplex-wide IPLs. No more than one production z/OS image is ever changed at a time.

  • All changes follow the IT division's production change management rules:

    - The proposal goes to the change management review board for initial approval and scheduling.

    - An interim review is held when the impact is assessed, and the schedules are built.

    - A final review follows after stress test results are completed, including the entire install and back-out process validation tests.

    - The change is scheduled for the next change window, which minimizes the risk of interacting with other changes going in at the same time.

  • After three months of successful execution on one image, the change is eligible to be moved to the other z/OS images in the sysplex.

  • The change management review board meets once a month.

These change management policies have also impeded the speed at which new concepts can mature into changed operations. To overcome this obstacle, StoreCompany is experimenting with a set of Linux images that it provides to the business manager in charge of exploring new opportunities. At the same time, StoreCompany introduces a set of policies that permits fast deployment of Linux-based projects.

New StoreCompany change management policies for Linux projects

  • The base IT organization makes weekly backups, but the team members can install changes and boot their own Linux images on whatever schedule they need provided that any such outages do not create a negative customer impression of the overall e-business.

  • New workloads should not require changes to the z/OS images or procedures unless absolutely necessary. All such changes will have to be scheduled and must follow the IT division's production change management rules.

  • When a Linux image project has proven successful and is to be owned by the IT Division's production control, normal change management rules will be followed.

The last of the new StoreCompany policies constitutes a concession toward the established ways. The policy limits the fast path to only the experimental phase of a project. StoreCompany intends to review this policy when the approach of isolating new applications and processing in Linux images has proven successful. A policy that permanently opens the fast path for Linux images would provide a space for projects that are not only quickly deployable, but also can be rapidly adapted to a changing market when the need arises.

In contrast to a z/OS image that is designed to efficiently run multiple applications concurrently, a Linux image typically runs a single application. This limits to an extent the scope of failures that might occur. However, more constraints are needed to contain the potential damage that a malfunctioning Linux application could do. StoreCompany makes the applicability of the new policies conditional on the following constraints:

  • The Linux image must not own corporate data.

  • No two Linux-based functions may run in the same Linux image.

  • IBM WebSphere Application Server must be used as the basic programming model. Where possible, functions running on z/OS are exploited by Linux.

The first constraint ensures that applications on the Linux image do not endanger the integrity of corporate data. The second constraint isolates functions and applications within a Linux image and thus eliminates the risk of a failing function or application damaging an unrelated capability.

The last constraint is not a means of risk isolation; instead, it demands adherence to the corporate object-oriented data model. It saves costs by ensuring that existing skill is applied and that successful projects can later be integrated into the production environment without the overhead of a complex port. See B.3, "Programming model and middleware platform."

The combination of Linux technology, constraints, and policies provides a safe arena for experimentation. StoreCompany envisions benefits beyond this isolated experiment. Establishing a group that generates revenue by bypassing the old established policies puts these old policies into question, but it does not overthrow them. After all, the old policies have proven useful for a long time. It does, however, open up the discussion of where the established policies are helpful and where they do not further the business, but endanger it by preventing useful and profitable changes. With Linux, you can introduce an advocate for change that brings new ideas into an IT organization with established ways.

16.2.2 ISPCompany change management policies

Linux, per se, does not require change management policies that are conducive to rapid and frequent change. Change is not an end in itself and still only belongs where the expected benefits outweigh the associated risks. ISPCompany has a well-established ISP business section that operates satisfactorily and currently sees no advantage in making changes to the services it offers. The main concerns of the ISP section are to maintain availability for its customers and to continue generating revenue. Consequently, the ISP section follows a conservative change management scheme that allows fast changes only where inaction might endanger the availability of its services.

ISPCompany change management policies for the ISP section

  • Security exposure fixes that impact the delivery of mail service will be applied as soon as they are verified. If possible, the fix should be applied within 24 hours of being released.

  • Changes to introduce new function in the system that are to be featured in marketing or save us costs in providing the service (for example, changes to improve availability) follow the normal review cycle and become candidates during the quarterly update window.

  • Everything else will be considered if there is an unused time slot in the quarterly change window.

As shown in this example, Linux can be used in a tightly controlled environment. Of course, ISPCompany cannot expect Linux to deliver benefits from fast deployment if it applies policies that impede change. Here, it uses Linux not as an agent for change, but as a low-cost and stable operating system that is suited to the task at hand.

In ISPCompany's outsourcing section, the readiness to change means a competitive advantage because it enables ISPCompany to offer new technologies and functions faster to its clients. ISPCompany maintains a small number of golden Linux images that it replicates when clients request a standard Linux image. While changes to a golden image affect a large number of clients, changes applied to a custom-made image have a narrow scope, usually only a single client. The damage that could result from a harmful change to a golden image is so widespread that ISPCompany applies stringent controls to any changes.

Tight controls that involve lengthy procedures are neither possible nor necessary for the customized images offered to clients with special requirements. Lengthy change procedures would nullify the flexibility that is the essence of this business opportunity. The small scope of the change makes assessing the likelihood of problems and the associated potential losses easier than it is for the golden images. Here, the rules can be more relaxed.

ISPCompany change management policies for the outsourcing section

  • Controlling our costs in providing "standard" service is crucial. Limit the number of golden copies for the "standard" systems to five.

  • Excluding the category of changes for security exposures, a golden image's code libraries and parameter settings will be changed only once a year, in the summer.

  • Other changes to golden images must be reviewed by the change board and systems fully load tested for at least a month before being cut over to production.

  • For those clients with special system contracts, all changes will be managed according to the terms specified in the contract, including at a minimum, final sign-off by both the client and our client satisfaction team.

For the golden images, ISPCompany strikes a balance between the benefits and the risks that are implied in a change. The custom-made images and the contexts to which they are applied by clients are too diverse for a generic benefit/risk assessment. Instead, the policy stipulates that an agreement on how to handle change must be part of the contract with the client. A risk assessment is then conducted for each individual case.

Linux can be managed to be rigid or flexible. ISPCompany applies Linux to a full spectrum of risk scenarios and corresponding change management. The same IT staff that handles the fast deployment end of the spectrum also handles the tightly controlled images. Whatever the software risks, the mainframe adds improved availability and makes the overall risk of outages lower and easier to assess.



Linux on the Mainframe
Linux on the Mainframe
ISBN: 0131014153
EAN: 2147483647
Year: 2005
Pages: 199

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net