Setting up a central ATC-system – Part 1: Setting the stage

We are getting ever closer to setting up a central ATC-system so I thought it might be of interest to start a little blog series detailing the various steps as we actually walk through the process helpfully outlined in Olga Dolinskaja‘s blog post series. At the moment I don’t yet know how many posts this will turn into or when the next part will get published. I’ll just play that by ear.

Starting position

We have a pretty complex SAP environment but for now will concentrate on our two main ERP development systems which feed two “lines”: one for the headquarter and a second for all the subsidiaries around the globe. We also have a central dev-system which feeds into the two main development lines. This is mainly used for SAP- and dictionary objects to keep these in-sync across the two main landscapes. ABAP-code in Z-objects is only maintained in some rare cases in this central system.

Development for the headquarter system (DEV-HQ) is mostly done by internal and external developers located in Germany, with some exceptions being large-scale projects where development gets done by contracted consultants. Development for the worldwide systems (DEV-WW) is in parts also done by our team of internal and external developers, but some countries either also have their own small teams or look for contractors to especially get legal requirements implemented.

Since end of November 2017 we are on NW 7.50 EHP8 with HANA-DB and had our Z-code updated by Smartshift to meet the HANA-requirements. Thus far, I have ATC enabled with HANA-checks in both the DEV-HQ and DEV-WW system and it also kicks in during transport release, but doesn’t prevent it. So, we obviously currently run the risk of non-HANA-ready code creeping back into our Z-code. As we want to prevent this we were given the green light to set up a central ATC-system based on NW 7.52 with all the capabilities that brings with it, like the option to work with a baseline and do the checks already on task-release.

Current activities

As I’m writing this, the system is getting set up, so I haven’t yet been able to actually see it. Once it has technically been set up, our basis team will prepare it for our usage and then it’ll be my turn to do the ATC-customizing.

I’m using this time to get the word out to our developers, starting with the ones working from our headquarters in Winnenden. This is not really the first time they’ll hear about ATC as information about what it is and how we use it has been available in our development guidelines for quite some time leading up to the migration to the HANA DB. There’s also mention of the fact that we’ll eventually switch to preventing transport release from the DEV-systems as soon as that is feasible. So, they’ve already had some “fair warning” that this is coming!

My current plan is to activate the central ATC-checks for DEV-HQ first, see how that goes, and then add DEV-WW in a second step. So, I invited our local developers to a short informational session to show them what’s coming and why. These took about 2 hours to prepare and 1 hour each to hold. I offered two sessions to accommodate the different days in a week some of them are available either in the office or via web-conference.

Next steps

Sometime in June I hope to get my hands on the central system to do the customizing. This will not just involve the one-off settings but also deciding which messages should get which priority with only a few of them designated as “1” or “2” in order to not have too many findings potentially preventing a transport release. As an aside, I’d very much like to have an option in customizing to only have prio “1” messages prevent a release and not also prio “2” as there are just way too many messages which currently fall into one of these two categories.

Once we have the settings defined, we’ll create our very first baseline for all the Z-code currently in the DEV-HQ system. We’ll also have to give setting up the exemption process some thought as the standard option where the developer picks one of the designated approvers will not quite work in our case. We’ll need to find a possibiity to have the notification go out to a group of potential approvers and to also have the process kick in a lot more often than the default setting of once per day. But all of this will most likely be material enough for a second part in this blog series – so please stay tuned till then!

Cheers

Baerbel

Here are the links to the other parts of the series for easy reference:

Part 2: Preparing the systems

Part 3: Tweaking the settings to our liking

Part 4: The final stretch

Part 5: Keeping an eye on things (January 2019)

Part 6 – accumulated FAQs (March 2021)

For the overall journey, please see the long, long winding road edition.