Do I need ChaRM to use Retrofit?
…or: Can I use Retrofit as a stand-alone component?
by: Hannes Kerber, SAP Active Global Support, ALM RIG EMEA
The clear answer to this question is:
No! It is not required to implement Change Request Management in SAP Solution Manager to make use of Retrofit.
Very often we receive this question internally from other colleagues and even more from our customers. This is why I want to use this Blog-Post to provide a clear insight on how the Retrofit Functionality of SAP Solution Manager 7.1 can be used and what the prerequisites are.
First of all I would like to mention that the question is very common and is very natural. Especially when running a complex system landscape, customers perform an upgrade or following the new strategy of “Two Value Releases per Year” as well as running a constant dual phased landscape to manage large projects, rollouts or their releases, Retrofit sooner or later is a topic on their table. Some customers call it Double Maintenance and also Dual Landscape Synchronization. In this post I will refer to it as Retrofit – this combines first of all the process and secondly the tool inside SAP Solution Manager.
So, if I clearly say “No”, ChaRM is not required to make use of Retrofit, how does this fit to the whole Change Control Story and what are the prerequisites?
If we take a look at the famous “Change Control Pyramide” this gives us the first indication of how retrofit fits into the whole Change Control Management portfolio inside SAP Solution Manager:
The retrofit is part of the whole Change Control Management Concept in the SAP Solution Manager and can be used
– As an own component and tool
– integrated with the different Change Control Tools.
Of course the retrofit relies on using the Change and Transport System (CTS and TMS) for transport management, but by just looking at the picture it becomes clear, that the retrofit does not require ChaRM or QGM to be set up and used to the full extent. As the retrofit is a tool inside SAP Solution Manager, of course and very naturally, certain requirements and prerequisites need to be fulfilled to use it properly. But definitely I highly customized and impactful Change Approval process or Quality Gate Management Process with 4-Eye-principle and SoD do not form part of these prerequisites. The only requirement is to have activated a central infrastructure in Solution Manager to manage transports. With this infrastructure you are already in a position to make use of the retrofit capabilities. Additionally the Cross System Object Lock needs to be turned on for the target retrofit system to feature conflict detection in retrofit and that’s it.
To further support this we can take a look at the various retrofit scenarios and use cases from different angles (views in the following picture). We can and should
discuss the retrofit and how the process behind the tool is really implemented and “lived” at every customer from these 3 angles as they can influence majorly how the retrofit is performed, by whom it is performed, at what point in time and by which team. These 3 angles/perspectives are:
Of course we want to clearly focus on the usage view, which means how the retrofit can be used from a tool and integration use case perspective. This can be influenced by “where the customer is coming from” or where the customer currently is, in terms of the implementation of change control tools.
The retrofit tool therefore needs to be embedded into current change control procedures and processes. If this would require to implement an entirely new tool and process:
This can require a lot of change impact at the customer…
…when e.g. currently only using standard STMS
…for possibly a lot of developers, consultants, configurators
…for the whole Change- and Release Management Process
…for the technical transport management process
Therefore, if customers only require the possibility of support in the retrofit process
…tool support should be possible and available
…the Retrofit provides this tool support
…the developers, consultants and configurators should not need to change their way of working
…the Change-, Release- and Transport Management process should be affected as less as possible
Thus, the Retrofit needs to be made available without putting in place any major changes to the daily operational change, release and build management processes.
Of course it is possible to use the Retrofit in a highly integrated Change Request Management scenario, but even with a few enhancements it is practically possible to enable a kind of use case to continue working through SE09 and Co. and still use all capabilities of the retrofit (please get in touch with the experts at SAP to discuss further details of this scenario). The infrastructure just needs to be prepared in SAP Solution Manager and be available as foundation for the retrofit.
Now the natural question is: Do I lose anything or do I block my way forward when considering implementing ChaRM at a later stage?
And also here the clear answer is “No”. The components of the Change Control Pyramide are all aligned and use the same foundation and building blocks. As described before also a tight integration into the whole governance process, release management process and also build management process is possible, when lateron deciding to implement these capabilities inside SAP Solution Manager.
As a last chapter to be covered in this blog post I would like to raise the question:
“What is really the effort to implement retrofit?”
Of course and as always no clear numbers can be given for the full implementation as it highly depends on the landscape, customer organization, transport volume, specific requirements, training, size of the development community…
But: For the pure technical implementation and making the tool available and ready to be used only a few days are really required (depending on preparation, authorizations etc.) and can the effort really can be brought down to 2 to 4 days.