Changeability

The principle of changeability defines the possibility to change the functionality of software components with as little as possible impact on other components and without having to change the architectural structure of the solution.

Software will change over time, and the anticipation of change drives many aspects of software construction; changes in the environments in which software operates also affect software in diverse ways.Afbeeldingsresultaat voor butterfly change

Change cases describe how the system might change in the future, and can be functional or nonfunctional. Examples of change cases to take into account are modified business processes, new technologies, integration with other systems, volumes of users.

Some practical aspects to assess changes against cases are potential benefits of the change, probablility of the change case becoming real, relative priorities.

If you address changeability in the software system being developed, you will need additional efforts to provide an extra degree of flexibility, extensibility, and scalability to support future change. The cost of the extra effort to construct more changeable software, or already anticipating future changes in the solution, must be weighed against the priorities, and the future cost the change to the software.

Applying principles for construction such as Abstraction, Encapsulation, Isolation, Layering and others will deliver software that is generally more robust to change.

Go fix it while it ain’t broken yet

Reg Harbeck wrote an excellent article in Destination z, Overcoming IBM Z Inertia, in which encourages IBM Z (mainframe) users to take action on modernizing their mainframe.

The path of action Harbeck describes is to assign new mainframers (RePro’s) with the task to find and document what the current mainframe solutions in place are expected to do, and to work with the organisation to see what needs to retired, replaced or contained.

In other words task a new generation with the mainframe portfolio renewal, and not leave this to the old generation, who are “surviving until they retire while rocking the boat as little as possible” (hard words from Harbeck but it is time to get people in action).

In additional to the general approach Harbeck describes I think it is important to assure senior management support on a level as high as possible. Doing so you prevent that the priority of this program is too easily watered down by day-to-day priorities and you assure perceived or real “impossibilities” and roadblocks are moved out of the way resolutely. So:

  • Make modernization a senior management priority. Separate it organizationally from task from the KSOR (Keep the Show On the Road) activities, to make sure modernization priorities compete as little as possible with KSOR activities.
  • Appoint a senior management and senior technical exec with a strong Z affiliation to mentor and support and guide the young team from a organisational and strategic perspective.
  • Have a forward thinking, strong and respected senior mainframe specialistĀ  support the team, with education and coaching (not to do it for them).

It will be an investment and, according to the “survivors” never be as efficient as before, but one very important thing it will be: fit for the future.

Close Menu