Managing Change in a Release Management Environment – Part II of IV (System Architecture)
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.
This blog well reflects the N+1 decision process. One additional success factor for my clients has been the retrofit process. As Solman is not always available, a manual process must be defined to bring BAU and Release changes down to the project landscape after they migrate to production.
Hi Kathleen.
Thanks for your comment. This is critical. I heard quite recently of one large organisation that typically overwrites up to 10% of their BAU changes every time a release is pushed into production.
A clear example of poor process. However, it also points out the need to capture every BAU change for retrofit as the first part of the process.
The second part is the retrofit process itself. I heard of another organisation that was spending up to 600 developer days per release rekeying each and every BAU change into into the N+1 stream. Automatically reapplying these is much faster, and more accurate although not always possible due to conflicts. It is also another example of poor process as possibly many of these BAU changes should be defined as Release changes to reduce the BAU volume.
Something I don't believe SolMan does but is very handy is a pre-import conflict check. If there is no conflict then an auto import can go a head, if there is , then a rekey is rerquired.
Thanks again for your comment.
Best regards, Rick