ALM Coffee Party V – Dual Landscape Part 5
Practice
Post-cutover
One function is still missing. This completes the “dual landscape” master: as soon as we have set our project major release live, we have to synchronize the maintenance landscape, i.e. all changes that the major release has set productive must be distributed to the maintenance landscape immediately.
It is a good idea to use the nice FB standalone extension “Cutover Checks and Post-Cutover Activities“, which is also described in this blog. You pack the productive transports from the project, which hopefully contain all retrofitted maintenance corrections, into ToCs, which are then imported into the upstream systems (QA and development) of the maintenance landscape. The original system of the workbench objects is changed to the maintenance development system so that future corrections are not regarded as “repairs” under the control of the Modification Assistant.
It is advisable to study the cutover checks offered intensively at least one week before the release goes live. They are partly congruent with the checks of the very useful transaction /SDF/TRCHECK.
The upgrade case
A system upgrade is a special case in which a higher version of the respective SAP application is introduced.
For obvious reasons, it is not possible to simply distribute the productively set transports to the maintenance landscape. It also takes too long to carry out the same upgrade according to all the rules of the art in the maintenance landscape in order to cancel it before the productive system, which is already on the new SAP release status. There is a risk of inconsistencies here; it is enough for an SAP note to receive a new version.
As an exception, I recommend synchronizing the maintenance environment using a database copy from the production system, and certainly also the maintenance development system, although Note 2259615 “ChaRM/QGM: Correct Procedure of Refreshing a System Managed by a SAP Solution Manager System” advises against it, because overwriting the maintenance development system is controllable (Good idea for a future coffee party). The original system of the Workbench objects must also be changed. We are happy to help here.
While the maintenance landscape is synchronized via a database copy, the project landscape must exceptionally take over urgently needed error corrections. Perfectionists will create new, short-lived cycles for this brief phase, in which the retrofit direction is reversed. Pragmatists, on the other hand, will simply prioritize the necessary corrections and only implement the really urgent ones, documenting them in a simple list so that they can be added to the maintenance landscape once the system copy has been successfully completed.
Operations
Post-cutover synchronization ensures that the maintenance development system has the same versions as the production system. This means that we can carry out all bug fixes to the release as usual via the maintenance environment immediately after the release goes live.
This also has the advantage that the normal incident process (“Detect to Correct”) continues to be used here: From go-live, the “normal” users will stumble across undiscovered errors, not the project team. This had had its chance during the integration and regression tests.
It should not be concealed that this third variant represents an organizational challenge, because from a project perspective, variant 2 with a hypercare phase and fix pace is more obvious, you stay among yourself and can approach the handover to the maintenance team with peace of mind.
But here, too, the advantages of the dual landscape are evident. Let’s not kid ourselves. The non-technical (cutover, go-live) but functional handover of the project output to the maintenance team (operational documentation, training of the maintenance team) tends to fall by the wayside: the project budget has been used up, the project team is falling apart, everyone already has new, very important tasks in new projects, a desperate project manager is still trying to dry up the handover, but the longer the hypercare phase lasts, the more difficult this becomes.
About a second peculiarity of the Fix-Pace process, in which actually only Error are to be corrected via FB Urgent Correction (UC, S1HF), namely that these UCs are often misused by developers to quickly (and without regression tests!!!) add functions that have not been completed after the release go-live instead of moving them to the next release in accordance with the rules, I would like to spread the cloak of silence1.
In the recommended variant 3, on the other hand, you are forced from the outset to organize the handover to the maintenance team before the technical go-live. This forces communication between the two silos (oops, now I’ve said it…), and the necessary collaboration between the two teams in the days after go-live increases the quality of maintenance.
Conclusion
The dual landscape with retrofit and post-cutover as the master of change management: I hadn’t promised too much.
Yes, it is a feat of strength! But this featis worth it, because the result is deeper collaboration between the teams, resulting in higher software quality, lower maintenance costs and ultimately fewer losses due to expensive errors in the production system.
This feat is worth it!
If you missed the previous part, you can read this one here.
