Skip to Content

Last blog we discussed system architecture (N+1) as an important consideration in managing change in a Release Management environment and introduced several corresponding and important critical N+1 architecture success factors. In this blog we are going to drill down a little into each of the critical success factors. These being, change definition, process and managing parallel change.

  

Change definition

  

In part I we introduced a basic list of change types. In order to have an effective release strategy, a defining of the types of change to be managed by the release needs consideration. For example, the definitions should allow for important fixes and low impact changes to continue to trickle through the BAU landscape without undermining the overall strategy. If Gartner’s five different types of change are considered, the following could become a basic change definition table with delivery paths and team responsibilities allocated.

                                                                                                                                                                                                                                                                                                                

Change type Delivery path Team responsible
Large business enhancements Release (N+1) Projects
Small business enhancements Release (N+1) Projects
SAP support packs Release (N+1) Support
Non-urgent problem resolutions Release (N+1) Support
 
Urgent problem resolutions BAU Support
Emergency fixes BAU Support

  

Table 1: Change type definition table

  

  In order to prevent non-urgent problem resolutions or portions of small enhancements sneaking into PRD via the BAU path, approval policy can be designed to prevent this from occurring. One of the side effects of introducing a release strategy into an existing IT change team is for process workarounds to come into play (for example, a sharp increase in the number of emergency fixes is often noticed).

         

Process

         

An appropriate and enforceable approval process will prevent workarounds and ensure the release strategy is adhered to by business and IT. Each step of the process requires an appropriate level approval before progressing (for example, the change requester ought not be authorized to define the change as BAU fix).

                                                                                                                                           

Status Description
CR defined Change request is defined as a particular change type i.e. emergency fix
CR approved Change request is approved for inclusion in a release or as a BAU fix
CR allocated to release or BAU BAU path or N+1 release path

Table 2: Basic change approval process through to allocation

         

However, a process is more than approvals. A good process will, for example, include management of the various statuses each change within the release will pass through, manage potential conflicts within the release and govern management of the individual transports containing the changes.

         

Managing parallel change (conflict)

         

An important function of a process is to assist the IT development team manage the release changes technically. For example, simultaneous change within BAU and the release can result in overwriting of BAU change when the release is delivered to Production. Such errors can be very difficult to track down and can reflect badly on the quality of the release.

         

Additionally, careful control over changes within the release, i.e. order of migration of configuration and development into the test and production systems, is critical to minimize or prevent conflicts between the different changes within the release.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply