SAP Change Release Management: Part 2 - Keeping Emergency and Routine Changes Flowing on Lanes 1 and 2

[Former Member]

With SAP IT support cycles mixing software stacks and suppliers, IT needs tighter control, traceability and production stability. In a multilane strategy, it’s crucial to keep change transports in their proper “lanes” or a systematic approach can degenerate into chaos. For an overview of four-lane Continuous Delivery, scan part one of last month’s post.

Control over lane assignments is especially crucial for the first two lanes in four-lane delivery strategies. The first two lanes are where assignment problems will first come to light.

Lane 1 – Emergency changes

These have the highest priority, moving on the fastest promotion track.

• An emergency change may require changes to an object making its way toward production in a slower lane, perhaps as a business-requested enhancement or as part of a monthly release cycle. This will result in a later collision. You’ll have to keep track of everything moving through the other lanes to prevent such collisions. That would be impossible with manual methods – change automation and enforcement can help keep changes intact when later changes are applied.
• Business users may purposefully label any change as an emergency, hoping to accelerate delivery. This undermines the entire strategy, yet business users must be able to apply the Emergency label when it is in fact justified.

The answer is to provide special IT-level review for any emergency change request and give IT reviewers a way to disapprove the label or reassign changes into the proper lane.

Lane 2 – Weekly support releases

Routine changes and minor enhancements move through weekly or biweekly, but your users may call bigger changes “routine” simply for expediency. Again, careful review and authorization to swap changes into different categories will prevent problems.

Both IT and business users may be reluctant to label a change “Emergency” if they fear they don’t fully understand an error’s potential to cause damage and consider “Routine” safer than “Emergency.” Careful review can keep changes flowing appropriately.

Also, the possibility of objects require changing now that are currently being changed in the other slower lanes need to be managed as outlined above.

Lane 1 and Lane 2 - Management

To avoid mistaken lane assignments and future collisions, carefully manage challenges that can amplify problems. For example:

• Keep parallel development visible and under automatic review
• Review changes for potential overwrites and keep the process visible
• Always review and reassign Emergency Changes if appropriate
• Keep the entire IT team as well as any business-side requester aware of incidents caused by incorrect lane assignment, so everyone learns
• Feedback - Invite both IT and business-side feedback

You probably noticed that stake-holders from developers to business-side requesters should all be invited into the process. The better your buy-in, the fewer problems you’ll have with users misunderstanding or misusing the four-lane strategy.

Next month I’ll look at the “slower” Lanes 3 and 4, where “big projects” are born. They have much in common with the faster lanes, but the challenges of keeping them organized are different.