…or: What do I need to think about?
by: Hannes Kerber, SAP Active Global Support, ALM RIG EMEA
As promissed in the last blog post I want to try to cover some more strategic aspects around retrofit and how to use it and what processes to put in place around the tool. To do so, I want to tackle the below questions:
- Who is responsible for the execution of the retrofit?
- What does this mean for my tool setup?
- What is the right time to perform retrofit? Are there different strategies?
- Do specific guidelines exist?
- What are generic rules I can apply to my synchronization process?
- What impact does retrofit have on my release landscape?
- Is testing impacted?
- Is cutover to BAU/Maintenance/Production Support affected?
- How can I setup a governance and reporting process around retrofit?
Let's begin with responsibility:
1. Who is responsible for the execution of the retrofit?
There exist some best practice recommendations which are widely used in customer scenarios, but as usual there are always some very specific requirements or circumstances which prevent those best practices from being implement.
The most obvious (and probably in terms of knowledge and acting in conflict situations most clear) approach would be that the developer of a change (or transport) is also responsible of retrofitting this change/transport to the project/release landscape. This gives the advantage of having someone take care of the task who as actually provided a bugfix or smaller enhancement to business and the currently productively used IT solution. So in case of any conflict situations, issues or estimation the developer is the most knowledgable person of the change which has been performed.
To enforce this, the retrofit activities can be integrated into the whole build and change management process and with a small condition on change level a change can not be completed before the retrofit has actually been performed (or the necessary indicators have been set).
The second most common approach is a dedicated retrofit team taking over the tasks of retrofit and performing it on a regular basis. This has he advantage that the developers can focus on the task of bringing improvements, continuity and new innovations to business. Additionally those teams become more knowledgeable over time and develop a certain routine by performing retrofits more often and on a regular basis. Also any governance around this process is easier to achieve and the community to contact is much smaller. Nevertheless, in conflict situations the developers need to be contacted anyway to solve critical situations or assist with technical details and testing/verification of a replicated change.
2. What does this mean for my tool setup?
The above mentioned approaches have an impact on the tool setup and how retrofit is started, executed and integrated into the change process. For the first approach (developer performs the retrofit) it is advisable to include a retrofit task into the overall build and change management process. For example an action is available for any kind of change to start the retrofit tool directly from a change document in ChaRM to access a filtered retrofit list to execute the change directly. This avoids the hassle of having a huge list of transports available, having different ways of accessing the retrofit and spending time on searching the right transports and lateron documenting this in the change.
The second approach (central team) though requires the exact opposite. A clearly structured overall retrofit list to have access to all transports. This can be managed by accessing the tool centrally from the maintenance tasklist or through an own transaction (which can be easily created - wait for the next blog post). With this the dedicated team can work through the list of last weeks changes easily and discuss any problems, conflicts or dependencies.
3. What is the right time to perform retrofit? Are there different strategies?
I have a clear opinion on this. The sooner, the better. But let's take one step back - what is actually the first possible time to perform a retrofit, meaning from what point in time on, is the data available that actions can be executed?
Whenever an original transport request is released (not a ToC) the retrofit data for this transport is created. This includes all information and is only created at this particular point in time. That means, e.g. for a Normal Change in ChaRM, when a change is successfully tested and ready for production it can be retroffited - and it should be! As all functional testing cycles should usually be covered with Transport of Copies (Test Transports) only the finally released transport request appears on the retrofit list and is therefore ready for retrofit.
I know that many customer only perform the retrofit when a transport request really reaches the productive environment. But why not before?
Let's look at 2 cases:
1. Urgent Change - There is no transport of copies, but if really used as urgent change the transport won't take two long to get to production, even if there are multiple cycles. Here it is just fine to perform retrofit for all transports after a successful test and almost deployment to production. In the end, if really used as urgent change, the urgent change won't have that many cycles as the scope is very limited, the bug to fix very clear and the amount of change to be performed very small.
2. Normal Change - The transport might take some time to go to production. But why not retrofit? It is clear that it will go to the production environment and in the end only once the change is tested successfully the transport will be released and therefore be ready for retrofit. So it will go anyway - so perform the retrofit right away.
But as a summary: It always depends on the change process which is implemented and the implications certain technical actions and activities have and what a transport request release means in the context of a change. That is why it needs to be looked at individually and cannot be generalized. But just as a way to think about it: if a change is successfully tested, the transport request is released - what prevents it from going to production (there are always cases...but think about the change process setup?
4. Do specific guidelines exist?
I tried to give some guidelines above and also (for the real execution) in my last blog post. I would suggest to take a look at this to have an indication of what is important: What do I want to retrofit, what is the technical situation (conflicts, dependencies?), how can I do it?
5. What are generic rules I can apply to my synchronization process?
Retrofit is important for landscape consistency.
Retrofit should be performed as soon as possible.
Conflicts should be handled with care.
It is not just copy and paste.
That's it :-)
6. What impact does retrofit have on my release landscape?
- Is testing impacted?
- Is cutover to BAU/Maintenance/Production Support affected?
There are 2 important rules to take care about when considering this question.
When looking at testing one thing is important: No new changes should be introduced to my test system, test scope and my project/release I am currently testing. That means no new developments should happend are at least not be put in scope of my project or released to my test environment. Changes can be introduced in 2 ways. The first is new change in my project/release - the other is change in maintenance and thus via retrofit. Of course, emergency changes always need to be handled (maintenance and business continuity priority). But those are limited and have a small scope and only occurr rarely. But smaller enhancements handled in maintenance need to be freezed at a certain point in time as they change test scope and thus impact my tests and my test results! Therefore during the last testing phase (at least) a freeze should also be established in maintenance.
The second important rule: Before cutover to BAU/Maintenance/Production support all retrofits need to be completed! Without ensuring this, it might become impossible to assess the impact a project/release Go Live might have and what inconsistencies might be cause, as not all changes have been incorporated to the release and some might be completely lost. That means: Retrofit Queue empty before cutover!
7. How can I setup a governance and reporting process around retrofit?
Someone needs to feel responsible! In the end both organizations, maintenance and release/project organization, should feel equally responsible for retrofit activities being performed regularly, with care and consistently. The project/release organization of course does not want to experience "unwanted surprises" during cutover and final testing, the maintenance organization does not want to fix bugs twice. That is why both organizations have a high interest in retrofit and therefore should ideally jointly take care of the whole process. It also helps if a regular synchronization statistic is presented to management and any involved stakeholders.
For some customers it has proven to be extremely valuable of putting in place a "Retrofit Guard". This is a dedicated person performing regular reporting, spot checks and the complete governance, as for example based on the above outlined rules, around the whole process of retrofitting, the status, outstanding issues and acting as a SPOC in this area.
I hope that these aspects can give some input, thougts or ideas to you...feedback and additional questions are very welcome!
Next time is helper time. I will provide a little insight to helpful reports, own customized transactiosn or helpful BADI Implementations which are regularly used.
Cheers...
. All the landscape verification related settings are moved to LMDB itself. I am taking an example of ECC server , where you can see the LVSM properties in LMDB screen.
