Expand +



Nathan Williams' TechEd Wrapup on SAP Solution Manager

End of maintenance, cCTS, Solution Documentation the big SolMan topics in Vegas

by Nathan Williams and Kristine Erickson

November 5, 2013

Nathan Williams, a Solution Manager expert and consultant, and author of the SAP PRESS book IT Service Management for SAP Solution Manager, recently answered a few of our questions to wrap up SAP TechEd. He covered a range of topics, including end of maintenance, the new cCTS offering, Retrofit, and Solution Documentation in our conversation. Read on...


Q. Great to have seen you in Vegas, Nathan! 

It was great to finally meet you, Kristine! In addition to the educational content and first-look at new innovations, my favorite part of TechEd is connecting with colleagues face to face.

Q. I know you participated in a Monday panel at SAP TechEd on SAP Solution Manager. What do you want to highlight from that discussion? What were customers talking about during that panel?

That’s right. Michael Pytel of NIMBL and I were invited by SAP as trusted partners to discuss our experiences with Solution Documentation in the field. This all-day ASUG pre-conference track was centered on the Two Values Releases per Year proposition introduced from SAP earlier this year. Throughout the day, SAP delivered a series of lectures, demonstrations, and lab previews of Solution Manager functionality.

All of the content delivered supported the fact that Two Value Releases Per Year can be a reality for any size organization. Just what is this concept? Simply put, if key Solution Manager scenarios are strategically enabled IT will be better equipped to deliver releases every six months, bringing tangible value to the business.

Since the inception of SAP Solution Manager (over a decade ago) the roadmap has continued to focus on breaking down SAP application specific silos and driving towards a business process oriented way of implementing and supporting solution landscapes. Today, that driver is still in place and it all starts with centrally establishing your system landscape, business processes and interrelated components within a single tool; SAP Solution Manager.

Right before the lunch break, the speakers divided the room (of approximately 80 attendees) into six groups. Each presenter, including Michael and I, facilitated interactive discussions specific to Solution Documentation. The objective of this exercise was to determine how existing SAP customers are currently documenting their business processes.

The questions we asked included the following: Are you using Solution Manager? Are you using third party toolsets? To what extend is your solution documented? What challenges have you faced when deploying Solution Manager as the central repository for critical solution landscape details?

After the lunch break each presenter provided a summary to the entire room, detailing the findings from the group they lead. We found a moderate blend of customers who have their full solution documented to some customers who were just starting down the path of a documentation roadmap. The biggest challenge we noted? The fact that they were unable to locate resources with the experience to drive a solution documentation strategy to fruition with SAP Solution Manager.

Q. Any updates from SAP in those Monday sessions that you really are focused on now?

Throughout 2013, the majority of my consulting engagements have been related to change control and release management (i.e. the project charters did not call out Solution Documentation as a specific scope item). While I did mention that Solution Documentation was foundational to the aforementioned white paper, there are numerous other Solution Manager components that are instrumental when striving towards a strategy to enable business transformation via two major releases a year. 

With that being said, the areas that I am really focused right now that were addressed by Monday’s sessions include the areas of Release Management and managing a dual track landscape for supporting maintenance and implementation projects in parallel. These processes are critical for organizations that require the delivery of regular software updates (via major or minor releases) while simultaneously providing a secure and stable production environment for end users. Monday’s sessions discussed best practices for Release Management as well as provided recommendations for how to architect an N, N+1 landscape to support parallel development activities and reduce conflict / risk associated with change activities.

Monday’s sessions reinforced the power of Solution Manager (as well as my efforts in the field!) in that the infrastructure provides the functionality needed to support best practices for Release Management and dual landscape maintenance. While ChaRM and Quality Gate Management are the technical infrastructure that deliver the functionality, it all starts with a Release Management strategy based on leading practices.

In my engagements N, N+1 is a hot topic and a very common scenario for SAP customers that run development initiatives (innovation) and operation support (maintenance) in parallel. SAP Solution Manager’s Retrofit functionality provides automated tools to synchronize your maintenance and innovation activities. Retrofit is a component of Change Control Management that provides a highly automated way to run parallel projects and aid with the management of conflicts across development objects. Retrofit supports a flexible release management strategy while preventing potential downgrades that are likely to occur in your production system.

Need to control changes across an N, N+1 architecture but not ready for the control ChaRM offers? Not a problem! ChaRM is not required in order to leverage the automated tools available with Retrofit. Retrofit can be deployed in your environment independent of the control, workflow, and approvals provided by the front-end ChaRM application. While Retrofit is a component of SAP Solution Manager’s Change Control Management suite (and also highly integrated with ChaRM), you do not need to implement ChaRM as a pre-requisite to take advantage of its synchronization capabilities.

Q. Before heading to TechEd, you mentioned in your blog that cCTS would be covered. What is cCTS and what did customers learn about it there?

For now, I’ll cover this in broad strokes, as it is a major change in the underlying infrastructure that controls the movement of transports across managed environments (and readers should look for a separate blog / article specifically dedicated to it!).

Central Change and Transport System (cCTS) was introduced with SP10 of Solution Manager (released at the end of October, 2013). cCTS introduces a more flexible, adaptive, and innovative way to address changes that arise across innovation and maintenance projects. The objective of cCTS is to deliver an enhanced infrastructure that can support project innovation as well as complex IT landscapes to speed up the process in which changes are deployed (when necessary).

First, customers were briefed in detail regarding the objective I described above. The speakers led an in-depth discussion covering the growing challenges associated with change and release planning (due to complex landscapes and the interconnected business processes in which they support). Changing market conditions, organizational challenges, and issues with change management were among the list of drivers for enhancing the existing CTS platform. Customers also learned about the progressive history of this platform and how it has matured to date. Traditional CTS, available for ABAP systems, was introduced several years ago. This technology provided the ability to model systems with different roles (i.e. development, test, etc.) and transport changes across the various systems. Later, Enhanced Change and Transport System (CTS+) was deployed to accomplish the same objectives however supporting non-ABAP systems.

With the Central Change and Transport System (cCTS), new concepts are introduced to support the challenges facing IT and the business today regarding change control.

Specifically, customers learned about the concept of “The System”. The System provides the ability to model transport system clusters. A cluster contains “The Systems” that should be included / bundled when being transported into follow-on systems. For example, one system identification number (SID) will unite various systems within the same role! Development ECC, Development BI, and Development PI (for example) could be represented as a cluster.

 Another new term, Transport Collection, brings all of the transport requests of The Systems within the Cluster and drives the import. Transport routes are defined between the clusters, which facilitate the import path of the Transport Collection.

In addition to the concept Clusters and Transport Collection, cCTS also provides capabilities that support the need for more flexibility. Decouple and assigning transports from one change document to another (even when the transport is released) is now an option. Worried that there is too much flexibility? Downgrade Protection delivers checks to ensure that conflicts are not introduced to your production environment.

Q. cCTS sounds like a significant enhancement and shift from the fundamental CTS and CTS+. What does the adoption strategy look like for customers who are currently using ChaRM with the existing infrastructure?

For customers who already have ChaRM projects running, the good news is that they can let them run their course aligned to the existing infrastructure and current plans. The rule of thumb is that old (existing) projects continue with the legacy infrastructure.

The recommendation from SAP is to try out cCTS on a new project (the traditional infrastructure and new infrastructure can be run in parallel!). It may be a good idea to try out cCTS for one project, or a series of non-complex projects.

Q. From a high-level, what are some of the setup and configuration activities that administrators and stakeholders need to be aware of when developing a roadmap to adopt cCTS?

First and foremost, it is important to know that system landscapes that have been maintained in TMS can remain as is. Also, there is no need to maintain logical component setup.

Here is a glimpse of the high-level activities needed in order to deploy cCTS (i.e. these are very high-level activities but should give you an idea of the initial effort required for setup).

  1. A new UI is delivered (the cCTS config UI) where you perform the following activities
    Create the clusters and assign systems to the clusters
    Distribute plug-ins to managed systems
    Maintain necessary TMS parameters
  2. Update your STMS configuration
    Create domain links
    Create transport routes for the clusters
    Maintain TMS parameters and import targets
  3. Maintain Project Administration data
    Define the projects that will use cCTS
    b. Choose the appropriate cluster and assign the different roles to the systems

Q. What about end of maintenance for release 7.0 - any discussion of this?

Absolutely. This is an important milestone in the product roadmap. Not surprisingly, a large percentage of the customers I talked to during Monday’s TechEd session have not taken direct action on the fact that mainstream maintenance for 7.0 is quickly coming to an end. 

In my opinion, the messaging regarding the sunsetting of 7.0 maintenance has been received loud and clear for years. Yes, years!

Remember, SAP Solution Manager 7.1 was released in August of 2011. Immediately, SAP initiated recommendations around transitioning (whether via upgrade or new install) to 7.1. With those recommendations came the discussion of mainstream 7.0 maintenance coming to a close in late 2013.

However, there still remains a significant number of SAP customers that are still running SAP Solution Manager 7.0. Believe it or not, I even ran into a couple customers at TechEd that were still on 4.0 (I won’t name names).  Needless to say, as trusted partners, enthusiasts, customers, etc. we must continue socializing what the end of 2013 means to customers who have not yet transitioned to 7.1.

What does this mean specifically? Simply put, no new updates or patches will be released for the legacy version.

In my opinion, the motivation for upgrading to Solution Manager 7.1 should not be driven by the fact that maintenance is coming to an end for 7.1. Rather, customers should consider this as an opportunity to re-visit a Solution Manager strategy, outline a roadmap, and determine how they can adopt Solution Manager to bring innovation into their organization.

Still not convinced? You may want to check out Matthias Melich’s article Top 5 Reasons You Should Upgrade from SAP Solution Manager 7.0 to 7.1.

Q. Thanks, Nathan! Looking forward to more updates in the months to come.



An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!