Getting Started Newsletters Store

Hi, Guest

Log On Join Us

Search the Community

Products

Services & Support

About SCN

Downloads

Industries

Training & Education

Partnership

Developer Center

Activity

Lines of Business

University Alliances

Events & Webinars

Innovation

Browse

More blog posts in

Communications

Actions

SAP Solution Manager

Actions

SAP Solution Manager

Login to follow, like, comment, share and

bookmark content.

Strategic Aspects of Retrofit

Login

Posted by Hannes Kerber in SAP Solution Manager on Aug 18, 2013 11:00:59 PM

Register

Previous
Next
Share

Like

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?
postpost
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:

Filter Blog

1. Who is responsible for the execution of the retrofit?

By author:
---

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.

By date:
--By tag:
alm application_lifecycle_management
business_process_analytics
business_process_improvement charm

sap_solution_manager
sapmentor solman solman_71 solution_manager
solution_manager7.1 solution_manager_7.1

solution_manager_71 solutionmanager
solutionmanager71

Recent Posts
We Launch New Book "SAP Solution Manager for SAP
S/4HANA" at SAPPHIRE NOW
Big News About SAP Solution Manager: Announcing
Focused Solutions
System Decommissioning : Guided Procedure (Ad-hoc
and Planned)
Quick Tip - Note Search help in SOLMAN_SETUP in
Solution Manager 7.1 SP14
SAP Activate integration with Solution Manager 7.2
How to install a Diagnostics Agent with SWPM 1.0
SP10 (archive based installation)
External service desk coupling SAP Solution Manager
7.1 - OTRS
Solution Manager 7.2 - Installation and Configuration V - Managed System Config - ABAP System
converted by Web2PDFConvert.com

3. What is the right time to perform retrofit? Are there different strategies?

Job SM:EXEC SERVICES does not process the EWA

session on a future date

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.

SAP Solution Manager 7.2 ALM Best Practices

Incoming Links
Recently Featured Content on SAP Solution
Manager
Change Control Management
Comment on 'Retrofit: How to perform retrofit
from an End-User perspective'
New Post on Strategic Aspects of Retrofit...

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
converted by Web2PDFConvert.com

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...

3271 Views
Products: sap_solution_manager Tags: charm, solman, ', retrofit, solutionmanager, solutionmanager7.1, solutionmanager71,
changecontrol, service_and_support

Average User Rating

(5 ratings)
Share

Like

5 Comments
Shehryar Khan Oct 3, 2013 3:08 PM

Hi Hannes,
Thanks for the insightful blogs on the topic of Change Management through Solution Manager.
We are currently finalizing our dual track strategy and as part of it, I wanted to address application
specific change management guidelines especially for applications like BW/BPC. You mentioned
here that there are certain limitations for BW and customers need to contact SAP for more
information. Is there a specific person/team we need to approach?
I have created a thread

here and it would be great if you can please comment on it.

Thanks and regards,

Shehryar
Like (0)
Binil Jose Oct 24, 2013 8:01 AM

Hi Hannes,
Good blog on Retrofit functionality. Can this also be extended during the upgrade project, where we
need dual development in two different versions of SAP ( say ECC 5.0 and ECC 6.0).
Thanks and Regards,
Binil
Like (0)
Raufman Brasse Apr 4, 2014 4:44 PM

Can the retrofit tool be used to sync changes between two landscapes?
For example, we have ERP in one landscape (DEV, QAS & PRD). We also have HCM running in a
separate landscape with its own DEV, QAS & PRD systems. There are some changes that need to
be synchronized between these two landscapes. Can retrofit help us with that?
Thanks,
Roy
Like (0)
Billy Warring Oct 2, 2014 2:36 PM (in response to Raufman Brasse)

I believe retrofit is intended to work as a 1 for 1 technology, so ERP to ERP not ERP to HCM.
Like (0)
Billy Warring Oct 2, 2014 2:37 PM

Excellent info Hannes!

Like (0)

Site Index

Contact Us

SAP Help Portal

converted by Web2PDFConvert.com

Privacy

Terms of Use

Legal Disclosure

Copyright

Follow SCN

converted by Web2PDFConvert.com