Why an Update to SAP Release Management?
In my original article I wrote that “Regardless of an up or down economy everyone wants to get the most value for their dollar; particularly in the IT space where costs continue to rise. There are always more projects to be done than a company can reasonably afford.” And I am sure we would all find that still holds true. Now that a few years have passed and we are all embracing business transformation, cloud computing, and IoT in general there have been a few developments that make release management even more practical and essential. As matter of fact the entire discipline of application lifecycle management (which Release Management is but one component) is now even more essential as a discipline in today’s Bi-Modal IT world. This update provides some practical advice on how to increase your effectiveness in release management delivery.
In my first article I pointed out that the goals of release management include:
• Planning the rollout of software
• Designing and implementing procedures for the distribution and installation of changes to IT systems
• Effectively communicating and managing customer expectations during the planning and rollout of new releases
• Controlling the distribution and installation of changes to IT systems
And that all still holds true. This update will talk about some additional goals of utilizing rapid deployment techniques, automation, and non-traditional project management methodologies along with tools to increase your RoI through release management.
Release Management as a cost reducer
For those who have been employing release management they have seen the benefits of three main objectives:
• Minimize the impact of changes to the productive landscape.
• Provide predictable timeframes for planning and execution.
• Effective communication and management of both successful launches and deployments that have issues.
Release management focuses on the protection of the live environment and its services through the use of formal procedures and checks. Traditionally that has meant a near waterfall, structured release layout with gates and checkpoints. But the goal is, and never has been, to create bottlenecks and unnecessary process for process’s sake.
In common terms Release Management is simply this:
Organizing a set of desired changes into one concise cohesive work package whose components can be developed together, moved to the quality test environment together, tested together, and then moved to production as one change (release). That is still the goal, but now with enhanced techniques and tools we can employ DevOps principles, Agile methodology, with a goal to deliver more technology sooner rather than later. Business demands to see results.
The Manufacturing Analogy – W.I.P.
Whenever I talk about Release Management I relate to it in terms of a simple manufacturing process. Orders or changes come in as separate pieces like materials coming into the front end of the process (such as a funnel). The changes (materials) are sorted out in some priority fashion and sent through the landscape from development to test and into production much like “Work In Process” phases of the manufacturing process. If one were to develop parts of a machine using metric measurements and another set of parts using American Standard measurements, the two sub-assemblies obviously would not come together in final assembly. It works the same way in integrated ERP systems. Unless certain components are developed and tested together as subassemblies you can have a problem when they become part of the complete solution.
Again, this all still holds true. However, due to the fast pace of change, applications and demands on business, the need to develop and move code through the landscape to production has a greater urgency. The days of a large 3-year SAP implementation where nothing goes to production for the first two years is over. It’s the obligation of release management to structure the release calendar in such a way as to align business and IT to a degree that will bring them to a consensus on developing solutions so concisely, that it will be successful in delivering smaller and more frequent moves to production.
The Solution to rapid yet effective release management
Moving to Release Management requires a paradigm shift throughout the organization. The Organizational Change Management accompanied with this shift should not be underestimated. Even though it requires a great deal of shepherding, and upper management support, it is worth the effort.
There are three key problems when managing individual changes in a complex ERP integrated environment: “code collisions”, incorrect prioritization, and improper utilization of resources. These require discipline at the grass roots level, and resolve at the executive level, to overcome. It’s easy to fall into old habits or mistake agile development as a free for all. Agile is not “cowboy coding”.
Code collisions can be a problem if you are managing individual changes with no release management strategy or in a complex DevOps or Agile shop. For example, let’s say I am managing independent changes and I introduce a change to the test environment on a Tuesday and test it and the change works. I then introduce a change to the test environment on Thursday and this change also works. However, the change I made on Thursday caused some failure to the change made on Tuesday. I would not realize this failure until it showed up in the production environment (i.e. a “Code Collision”). A Code Collision is an error which could cause system downtime or causes problems for the customer including potentially costing the customer money to untangle (locked tables causing automated jobs to stop in their tracks etc.). If I had instead, held the first change and then moved the two changes into test together, as in traditional release management style, I would have found the “code collision” and been able to correct it in the test environment. In rapid development and release scenarios the code is moved off quickly to production so you are managing one issue at a time.
The second issue caused by managing individual changes is improper prioritization. As changes come into the funnel they are prioritized. When individual changes are requested there is a tendency to work on what is perceived as most important rather than what may benefit the organization as a whole. To coin a few terms “the squeaky wheel gets the grease” and” whoever has the most money gets the service” (The Golden Rule). My personal favorite – “your lack of planning does not necessitate an emergency on my part”. I am sure we have all worked in environments where this is the perception of how work is prioritized and resources assigned. In order to resolve the above issue and employ rapid release processes, organizations will need to improve demand management as well as release management.
The third issue with managing individual changes is an improper allocation of resources. Many times a report request will come in from one division and a developer will be assigned to complete the coding. Another developer in another work area may be doing a very similar report with the same data. It is possible the two reports could have been assigned as one using different variants. Unless the developers are talking independently with each other, this waste of resources often goes undiscovered. Perhaps there is a better way to gain some synergies? There are strategies that can effectively link demand, release, and operations together for better organizational visibility.
Moving to Release Management requires a paradigm shift throughout the organization. The Organizational Change Management accompanied with this shift should not be underestimated and it is worth the effort.
What are the Benefits to Rapid Release Management?
Release Management done properly can create some obvious benefits and some that are subtler. The obvious advantage of working in a rapid release management strategy is moving changes together through the landscape. One can define specific work tasks and define a timeline that can be managed, thus reducing the cost of “wasted” time in organization and planning (i.e. developers randomly hopping from one fix to the next trying to accommodate shifting priorities). Once a release is set everyone knows the priorities. Only true emergencies can be moved into the release so there will be careful scrutiny.
The second most obvious benefit is that objects will be tested together in your quality environment. This testing reduces the risk of failures in production as described in my earlier example.
Another benefit is the reduced cost from less errors occurring in production. There will be less backing out code and correcting bad data, reprocessing orders and related work that I call “do-overs”.
Some benefits that are not so obvious can be the synergies obtained from the entire team viewing the system as a whole. Once you move to the release concept you will notice more dialogue around correctly prioritizing changes; performing additional testing; checking to see that infrastructure needs, storage space, and security questions are answered ahead of time instead of at the 11th hour. All of this dialogue leads to better performance from your delivery team. Results are seen more quickly and rewards are more timely.
An additional benefit is the added credibility you gain between the business and IT organizations. The IT group will deliver on time. The business is more engaged in the effort. Any potential “blame game” is minimized because responsibilities are shared. IT no longer just delivers to the business customer. IT and their business counterparts are transformational partners. The goal is for business to seek IT and work together to create solutions to business problems.
When individual changes are managed there are too many things that can come up and claim priority of an already existing change request. Changes that were promised are moved to the backburner and the business begins to say things like “We engage IT and request work and it ends up in a black hole and we don’t know where our changes are sitting.” Creating a formalized Rapid Release Management discipline means having better transparency. Everyone should be able to see where their changes are in the queue. Once you establish a release calendar and business and IT are performing rapidly together, questions diminish.
How Do I Get Further Assistance?
It’s important to approach moving from standard release management to a more agile technique with a holistic ALM approach in mind. It requires buy in from multiple stakeholders. It is best to construct a road map and tackle specific activities one at a time. Building relationships across the business areas and building bridges into the IT organization first, then building out your landscape and infrastructure to match how you plan on developing releases. The pace of changes only quickens. There are more changes coming into IT all the time. As stated earlier, you cannot underestimate the organizational change management needed to shift the paradigm and transform IT and business relationships.
In traditional release management implementations, I have seen a company’s first reaction is to resist the change because of a perception of increased overhead and time of delivery. New methods in release management support and enhance agile and DevOPs methodologies while reducing issues that are prevalent when managing individual changes and having no release strategy.
As stated in my original article, it is still better to work on what can be handled first. The simplest place to start is to go back to the three basics and make sure they are covered. Minimize impact of changes, provide predictable timeframes for delivery, and communicate effectively. How you organize releases depends largely on how you work the relationship between business and IT.
What Are the Pitfalls of a fresh Release Management Approach?
In moving to a Release Management discipline I am sure you noted some drawbacks. Once you overcame the initial resistance, you produced fewer errors in production. The business units became more satisfied with the IT organization, but the dynamics have shifted again.
Now the hazard is that you have people settled into a routine. IT believes you are now asking them to go back to something more chaotic. This is not the case. You are simply recommending a quicker more modular approach that launches more results.
As always priorities will shift based on the market, the season, or economic climate. Mergers and acquisitions will happen. People will move in and out of roles. Larger projects will threaten your ability to control the release timeline. There are answers for these objections and other objections you may think of that will probably be raised; ones that I haven’t already mentioned in this paper.
The correct answers to these objections are that the success is in the discipline and planning around the release. Even if it takes a little longer for planning changes to production, the actual development will be cheaper and faster. The business will be happier if they know what is going in and when it will get there. Business Units will be happier when there are less production problems due to code moves. Development teams will be happier when they know what is expected of them at any given time. (i.e. these items are in test, these items are in development and these items are coming up next). Test teams will be happier when they can adequately plan their work.
- ERP systems are too complex and integrated to move changes individually. However, business demands we move at a faster pace.
- Enhanced Rapid Release -Management requires effort in Organizational Change Management.
The basics still count in Release Management.
- The benefits of Rapid Release Management include
- Secure the pipeline
- Rearrange the funnel
- Enhance the process and architecture
- The benefits of Rapid Release Management include
- Lower costs per change
- Fewer production errors
- More comprehensive testing
- Better prioritization of work
- Better cohesion between business and IT