There are some fairly significant enhancements to ChaRM (SAP Change Request Management) that have been made available in SPS10 (released in the last quarter of 2013), including:
Enhanced Approval functionality
Assigning a nominated approver now works as you would expect i.e. only the person assigned (or a delegate thereof) can sign off their approval step. No longer is it simply enough to have the correct authorisation object. In addition we now have the possibility of approval substitution / delegation and can create approval groups to reflect Change Management teams or Change Advisory Boards.
Status Overview Graphic
This new assignment block provides an optional graphical representation of the status values and a basic transition sequence for the change record. This will be particularly helpful to the less frequent user who is often not sure what the next step in the process will be.
Building upon the enhancements provided by the Status Driven Import, we now have even more flexibility and are able to choose which changes will be imported at the point of import, rather than having to perform an import for all the changes of a given release / project.
All of the above are useful for the everyday operation of the system and very welcome enhancements to an already comprehensive change management tool. Yet the flexibility that the new ‘central Change and Transport System’ (cCTS) affords is worthy of an in depth exploration all on its own.
This insight provides an overview of the core changes that cCTS encompasses, providing an explanation of the real world implications based upon our own experience of implementing ChaRM in multiple customer landscapes. Read on to find out more about the most important update to ChaRM since the release of SAP Solution Manager 7.1!
The new central Change and Transport System (cCTS) Infrastructure
Our insight begins with the explanation of two new concepts that are fundamental to the new cCTS infrastructure:
In simple terms a Transport Collection is a container for one or more transports that belong to a change. The key word here is ‘change’. Previously transports were grouped by the CTS Project associated with the development systems IMG project; this could not be changed once a transport had been released i.e. once a change had reached the successfully tested status as part of a project (at which point the transport is released), it was forever-more committed to that project.
With this new entity, one or more transports belong to a Transport Collection, which is linked to a change. This is a very important separation, which is key to providing much of the new flexibility.
The Transport Collection can span multiple systems. For example, a single change request might involve a change to a BW query, a change to a corresponding extractor running in the ECC system and a change to the Portal system (running CTS+); all of which require their own transport(s) in their respective development systems.
The Transport Collection allows all transports to be grouped together, such that when the change is ready to be moved to the respective test system(s), all of the transports for the given change are contained within the same container and will be promoted together.
Seemingly simple enough, but as you will see from the below, the implications and benefits of this step-change in infrastructure are much more impressive.
Transport System Cluster
This new entity enables different product systems (e.g. SAP ECC, BW, PI) that share the same role (e.g. Development, Test, Production) to be grouped together under a single SID. In this example, a customer landscape containing ECC, BW and Portal has all of the development systems grouped together into a Development Cluster (CDV), the test systems into a Test Cluster (CQA), and the production systems into a Production Cluster (CPR).This concept allows for a truly synchronised import to take place for a given change – all transports in a transport collection (see above) are imported to their relevant systems of the cluster i.e. we should think of the Transport Collection moving between Clusters rather than individual transports between individual systems.
Benefits of cCTS for ChaRM
The cCTS infrastructure enhancement alone is a fundamental change to the way ChaRM is allowed to behave. This will help to bring many new benefits, click on the below to find out more:
The immediately obvious benefit is a true synchronised deployment of transports across systems. No longer are you reliant on all the production import steps being carried out via the ChaRM Task List for each production system. The import takes place for the Transport Collection and cCTS takes care of the rest.
This is a significant enhancement and one which our customers have requested for some time.
We have often seen client implementation projects where during the final test cycles a new fault will be uncovered in a pre-production or regression test system. After assessment of the fault and confirmation that the change and its corresponding transports do not have dependencies on other aspects of the release, the typical project team response is to remove that particular change from the deployment. After all, they have a deadline to meet and cannot always afford the time necessary to fix and retest all faults. The project is then faced with a dilemma on how to proceed:
- Delay the Go-Live of the entire project until the fix is in place and tested
- Go-Live with the broken code / configuration and fix during the post go-live support phase
- Use Status Driven Import (if configured in advance), to import only those changes that have passed all test cycles and leave the entire failed change behind
In all such cases the failing transports are still associated with implementation project due to the CTS Project identifier. Simply reassigning the incorrect change or the few failing transports to another project was not possible.
Of course, there were good reasons for this approach; in a truly integrated system it is important to consider that objects across transports can be interrelated and have dependencies, therefore if one transport is left behind/reassigned then you could potentially compromise other aspects of the project. Yet in the real world these examples do occur; a development / configuration team can provide the necessary expertise to determine if the transport(s) can be removed from the current change without impact on the remainder of the project.
This latest enhancement now allows us the choice of reassigning the failing transports to a different change and project, perhaps a delta release of functionality or a bug fix project to follow after the initial go-live. This additional flexibility is very welcome and will help to answer a previous pain-point that many of our clients have experienced.
However, as Voltaire (or was it Spiderman’s Uncle?!) states: “With great power, comes great responsibility…”. Reassigning released transports should not become the normal mode of operation! This functionality should be used with great care and only after due consideration of the impacts of the transport reassignment have been fully understood…
Another pain point, typically experienced by implementation projects using ChaRM or QGM, was the inability to take 3rd party transports under the control of the change tool. Occasionally, this issue could be resolved by applying the 3rd party transports to your development system and then repackaging the objects into a newly created request, but this was not without issue (consideration needed to be given to the Development Packages used, additionally this action could invalidate your warranty with your supplier).
The new cCTS infrastructure allows these 3rd party transports to be simply attached to an existing change in their released state. ChaRM / QGM is then just used to propagate the change across the landscape via the Transport Collection. This brings us much closer to one having a single tool and process for managing all changes across our landscape.
It should be pointed out that there is one notable limitation to the new cCTS infrastructure. In order to make use of cCTS in your projects it must be the case that all of the systems / logical components added to your ChaRM or QGM project must have the same number of system roles. As an example, if your ECC system had Development, QA, Pre-Production and Production system roles (hence a requirement for four Transport System Containers) then so should all the other systems that are attached to your project. It would not be possible to incorporate a system into the project that was missing, say Pre-Production. Hopefully this limitation will be resolved in a future update.
A final point on the cCTS infrastructure before bringing this insight to a close, is to note that it is not mandatory to use cCTS and that you can choose to enable it on a project by project basis. If you still wish to retain the previous CTS infrastructure for certain projects (for example where you require more rigid controls) then this is still possible.
All in all, SAP have done a great job in improving the flexibility and addressing the key customer pain points of ChaRM. Having the ability to reassign already released transports, coupled with the additional benefits that the new cCTS infrastructure brings are enough to justify an upgrade to SPS10 without even mentioning all the other areas of functionality that have been improved!
For a look at some of the additional benefits SPS10 has brought to Solution Manager, not just in the area of ChaRM, be sure to check out our post ‘What’s new in SAP Solution Manager SPS10?’.