Change Control Automation and the Path to SAP DevOps

[Former Member]

I recently came across the eBook, "Digital Transformation and the CIO: A point of view prepared by IBM and SAP" which, among other things, highlights the need for SAP IT organizations to develop systems, processes and methodologies to deliver continuous innovation for the business.

In discussing the opportunities and challenges for CIOs, IBM and SAP highlighted the areas that CIOs have articulated as their priorities. One of these priorities is around agility and delivering continuous innovation for the business. However, with only 17% of IT support organizations having adopted any kind of agile software development methodology and just 15% having adopted a DevOps approach there is some ground to be covered yet.

So how do SAP IT teams and their CIOs get there, particularly as far as the enterprise core systems of record are concerned?

The Path to SAP DevOps

The technical path to SAP DevOps is relatively simple, particularly if based on effective use of a change control automation platform.

So, assuming change control automation is in place, here is the path to SAP DevOps we have observed SAP IT teams have been traveling.

1. Develop a multi-speed approach to managing SAP change


2. Introduce agile development methodologies


3. Graduate to a DevOps approach

1. Multi-speed approach

There is an unavoidable difference between the rate at which the digital systems of engagement can change and the rate at which the SAP systems of record can change and so dual-speed approach is necessary. But this doesn’t mean that all SAP change needs to be slow, or that governance and control should result in sluggish delivery of system of record changes.

Through a multi-track approach SAP IT teams can significantly speed up enterprise change without compromising governance or control, or quality.

The approach is quite simple.

Divide the work into types of change by potential impact and run each type down its own delivery and approval track. Low impact being the faster tracks with fewer approvals and minimal testing and higher impact the slower tracks.

2. Agile development methodologies

Whether the work is divided into sprints, stories or releases, methods of delivering smaller pieces of quality built software, fully tested and ready for deployment, are required. Smaller pieces of functionality will have lower overall impact, require less rigorous testing and can be delivered faster.

This builds on the multi-track release methodology.

As far as possible, work is developed to minimize impact so it can be run down the faster, low impact tracks and only the unavoidable, high impact changes being run down the slower, more controlled tracks.

3. SAP DevOps

Shifting left things like QA, Impact assessment, testing to be in process enabling developers to understand the impact of their developments earlier enables more change to be developed at lowest impact thereby increasing the volume of faster track changes.

This approach requires the use of a range of intelligent ALM tools (SAP native or third party) that automate DevOps activities like code review, impact assessment, unit and regression testing and so on.

As these are introduced into the development cycle and then linked via an automated change control workflow platform, like Rev-Trac, observable DevOps and its benefits result.

Automation as the Platform

For SAP IT support organizations using Rev-Trac as their agile/DevOps platform, good governance and control and rapid development are not mutually exclusive. Not only are the tasks and process required for good SAP change management automated, but also the controls needed to enforce a multi-track approach without burdening the team. The workflow platform needed to link together the DevOps activities so they become as ‘in-process’ as other development activities is also in place as the program matures.