Introduction

You might think you’re fully in control of your change and release process for SAP. After all, who’s going to admit to promoting changes to Production otherwise? Let’s just say that after twenty years of working with SAP I’ve seen – and maybe even been involved in – some less than textbook practices. Or perhaps you’re really not sure, because ‘the basis guys do all that stuff’. Either way, in this blog I’m going to highlight a few scenarios that commonly occur in organizations that don’t have full control. Hopefully this will help to clarify where your business stands and whether you are unknowingly taking unnecessary risks which – in a worst-case scenario – could lead to significant outages in your Production systems. 

There’s a good chance you’ll find it’s hard to come by the information needed to answer the questions I’m going to pose. I’d argue that situation tells its own story though – one that may indicate you are not where you need or want to be in terms of true governance and control.

I’m not going to cover the obvious “core” elements of a robust change and release process, like automated checks, workflow, notifications, approvals and integration with other tools. After all, those things should really be taken as read (and if that’s not the case in your organization I’d say you’ve already answered the title question!). Instead I’m going to focus on some common edge cases encountered by our customers before they implement ActiveControl, Basis Technologies’ DevOps automation software . In part one of the blog I’ll look at Development-related scenarios and in part two, Production-related ones. 

Ensuring the Integrity of your Development Systems

A well-managed Development system is the foundation of a robust, secure, high-quality application development lifecycle. But a typical SAP Development system is shared by many team members – perhaps hundreds of people in a large organization – and it’s fair to say that they are often lacking a bit of Tender Loving Care. During my career I’ve noted three watch-out areas – though no doubt there are many more – that can undermine the best attempts to build a solid ALM foundation. 

1. Unreleased customizing transports more than a few days old

Unlike with workbench objects, there is no lock mechanism for changes in configuration objects. Only the key is recorded in the Transport Request (changes are not). When the transport is released, a snapshot of the fields belonging to the key is written into transport files. Only at this point is the change “locked in”.

That means it’s easy, when releasing a customizing request which has been open for a while, for something unexpected or untested to be locked into the transport. This can lead to promotion of unintended changes to Production without the knowledge of the change owner/developer, which in turn can cause Production outages. It’s tough enough to triage and fix any kind of outage, but things get even more difficult when the people who own the change are unaware of what may have been included! 

What questions should I be able to answer?

• Can you see how many unreleased changes are in your Development system today, and how old they are (1 week, 1 month, 6 months, etc)?
• Who owns those changes (functional area, partner company, and so on)?
• How can you measure progress as you reduce the number of older, unreleased changes?
• Are developers warned of a potential conflict when they change configuration that is also being changed by others?

How can ActiveControl help?

• Reporting – available in just a couple of clicks – enables any team member to understand what work is in progress and where activities may have been left unfinished. This information, which would otherwise have to be collated from spreadsheets (if a record was even kept), can be used to drive a process that limits the amount of work-in-progress configuration and the associated risk of an incorrect change being moved to QA.
• Auto notification enhances such a process by providing automated notifications which warn the change owner and/or developer that something has been left open for a defined period. If no action is taken within that time, an escalation email to project managers or system owners can be automatically triggered.
• Alert when a developer is changing a customizing object/key that there is an open change and potential conflict.

2. Using the Development system like a Sandbox

A Sandbox system should be used when exploring a solution, trying out new ideas, or activating business functions and add-ons that might be non-reversible. Many organizations have them. Typically they’re a bit Wild West, but that’s fine. In fact it’s kind of the point. The problem comes when – as in all too many places – the Dev system serves as both a shared Development environment and the ‘Sandbox in the playground’. 

If people are making unauthorized changes (ie. those without an approved change request) in the Development system – as they often would in a Sandbox environment – then you’re running the risk that the system could need to be restored, that development activities are disrupted or that unintended changes are being developed without necessary oversight. 

What questions should I be able to answer?

• Do you have a policy for using a permanent or temporary Sandbox?
• Can you tell whether people are making changes in the Dev system which have not been authorised?

How Active Control can help?

• Authorised Work only – Based on configuration, you can ensure that transports can only be created in the Development system if linked to an approved work trigger (a change request, an incident, etc)
• Flexible Transport Path Management – it is very easy to add systems to, and remove them from, transport paths in ActiveControl so there’s minimal overhead if you want to set up or retire temporary experimental systems. The tool can automatically identify missing transports to ensure each system is “up to date” based on where it sits in the path.

3. Appropriate handling of critical objects

In SAP landscapes of every size, from the largest to the smallest, there are a number of objects that are critical to correct operation (factory calendars, sensitive tables, reports which run as background jobs in Production, critical billing interfaces and SAP OSS notes, to name but a few examples). 

They might be custom objects, they might not, but regardless, more scrutiny and care needs to be taken whenever they’re touched because they come with a higher risk than anything else. Break a critical object and the consequences can be severe. But I’ve seen many organizations ‘flying blind’ without a way to distinguish the high risk changes from everything else that moves through their landscape.

What questions should I be able to answer?

• Do you have the critical objects for your solution documented? 
• How do you know whether a transport contains one of these objects? 
• Do you have an “enhanced” process which is enforced for transports which contain these objects? 

How Active Control can help?

• Risk Guard highlights any transports that contain objects identified as a critical or risky. For example, company code changes, planned changes or changes to number ranges. You can automatically flag high risk objects and enforce specific approvals based on their risk level.
• Impacted batch jobs analyzer – Identifies which scheduled batch jobs may be impacted by the objects being delivered in SAP transports. Provides the ability to easily avoid deployment of changes into Production when critical batch jobs are scheduled to run. Enforce the splitting and segregation of transports to avoid mixing certain object types.

Those are my big three ‘gotchas’ for managing change at the very start of the process in your Development systems. Hopefully you found some food for thought. If so, and you would like more details about how ActiveControl can help to answer the questions I’ve posed and create a more solid foundation for your entire ALM process, why not request a demo?

As I mentioned earlier though, this isn’t the end of the story. No matter how much time and effort it might save if you clean up the start of your change and release process, your Production systems are the ones that really matter. So come back soon for part two of this blog where I’ll look at some important considerations that are more closely related to live systems and how changes are deployed there.