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:
16.2.1 StoreCompany change management policiesStoreCompany 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.
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.
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 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 policiesLinux, 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.
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.
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. |