Managing Change in a Release Management Environment – Part II of IV (System Architecture)

[Former Member]

Last month we considered what Release Management was and why an organisation might consider it. This month we are going to discuss Release Management system architecture and several critical factors for success.

Release Management system architecture

When an organisation is considering a Release Management strategy it aught also consider how it might best organise its SAP environment or change process to facilitate the strategy. For example, an N+1 landscape to co-ordinate and manage releases outside of the day to day BAU (N) landscape might be considered. Also, perhaps an alternate change process for BAU changes vs. long term projects changes (Releases) if an N+1 landscape is not to be deployed.

In deciding whether or not to deploy an N+1 landscape a couple of key questions arise. These include:

• How many changes will each release contain (size of release)?
• What types of change will be included per release (impact of release)?
• How often releases are to be applied to production (release frequency)?
• How much and what types of change will make up the steady volume of BAU change?

Considerations	DEV – QAS – PRD (N)	DV1 – QA1 (N+1)
Size of releases	Low - Medium	Medium - High
Impact of releases	Low - Medium	Medium - High
Frequency of releases	Quarterly – Bi Annual	Fortnightly - Quarterly
Steady state BAU volume	Low - Medium	Medium - High

Table 1: Release strategy SAP landscape considerations

For example, an organisation implementing a high volume of new functionality that is closely related to existing functionality, whilst simultaneously processing a steady volume of BAU fixes and changes, should consider an N+1 strategy. Or, an organisation implementing a series of releases containing significant change that has high business impact, then an N+1 strategy should again be considered.

On the other hand, an organisation that retains much of its small – medium enhancement changes as part of the BAU stream, saving major enhancements for its quarterly Release may consider simply revising its processes and then managing releases through its standard BAU landscape.

Release Management success factors

The first of these is change definition.

Clearly define what an acceptable BAU change is and what a Release change is is. Any greyness in definition and the BAU list will grow and the Release list will shrink as users push needed changes to BAU. This over time will undermine the Release strategy.

The second of these is process.

Controlling the process through formalized steps to plan, schedule, and control and approve releases will ensure quality releases in tune with business requirements.

The final of these is managing parallel change.

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.