I’ve worked specifically in SAP change management for more years than I care to mention, and one thing I’ve heard repeatedly is the need for a reliable method of checking inter-object dependencies between transports.
It can be difficult keeping SAP landscapes consistent. For example, as Quality Assurance environments are refreshed, over time systems can begin to get out of sync. The number of DEV system transports existing only in the development system, unlikely to ever be moved to Production, grows.
It goes without saying that unplanned SAP production outages are costly. That’s why many SAP customers spend large amounts on ensuring high availability and redundancy. Eliminating single points of failure ensure continuous up time. But those infrastructures, no matter where they exist are still subject to accidental production downtime. Whether on premise or in the cloud, SAP systems are still at risk from poorly managed SAP change activities.
Just back from another SAPPHIRE NOW & ASUG Annual Conference and my head is filled with all the latest buzzwords. We heard much about “Digital Transformation”, “Cloud” (Public, Private and Hybrid), “Leonardo”, “DevOps”, “Agile Development” and of course “S/4 HANA”. I was a little surprised to hear so much of the “A.I.” term being widely used.
Just like servicing a car, or painting a house, Rev-Trac will require occasional upkeep to ensure ongoing brilliant performance. Due to the nature of fast moving businesses with requirements changing priority, experiencing delay or sometimes being cancelled altogether, the modern SAP shop leveraging Agile and CICD techniques will eventually find abandoned transports remaining in their non-production systems.
Today, it’s quite common to see SAP environments consisting of three or four SAP applications running a two or three track system architecture (N, N+1, N+2) with additional integration testing and preproduction systems included. However, over recent months there has been a growing question among SAP IT organizations around the multi-tier strategy and looking at ways to go back to a single-track, flat architecture. Perhaps this is due to the high costs of standing up additional SAP instances, retrofit and system synchronization challenges or simply a reaction to the overwhelming complexity.
For many years SAP organization’s have struggled with parallel object sequencing, overwrites and downgrades. Particularly parallel objects across multiple development tracks, such as an N and N+1 architecture for separate Support and Project development. Naturally, a fully-fledged change control automation software will automate the retrofit or reapplication process between Support and Project tracks, while identifying and providing options for when retrofit conflicts do arise. However, there is normally a large amount of investigation required to discover the technical impact of retrofit conflicts when deciding an appropriate course of action.
Over the past month I’ve spent some time with a few of our Melbourne based customers. One customer ran me through the methods they were using to perform reapplications of BAU changes to a project track. The customer was benefiting from the Rev-Trac’s OOPS Overwrite Foreign reports, which identifies any changes in the project track, about to be overwritten by BAU support changes.
Last week, I visited a customer in Kuala Lumpur, Malaysia, to assist with the Rev-Trac configuration for the addition of a parallel project development track to their existing SAP support development track. During the setup, we had some interesting debates about methods for reapplying their support changes to the project track systems.