SAP Development Landscape Strategy

[Former Member]

Hello ABAP People,

I've been implementing SAP solutions since 1996 and this is the first question I have posted to SCN.

I'm hoping for a good experience!  Let me know if you think this question fits into a better area and which one if possible?

Recently I met with the Basis Team and we were trying to determine why we have seperate development clients for config, ABAP, & security.

Here is an exmaple of our development landscape

DEV 010 - Config only

DEV 020 - ABAP only + Unit Testing (config is SCC1 here)

DEV 030 - Security Development (config is SCC1 here)

What I would like to understand is the pros & cons to organizing the development landscape in this manner.

If we were to combine these 3 clients into 1 what problems may that cause?

I've seen replies to similar posts but never the reasons why this strategy is a good or bad.

Please do not respond to this post stating "This is an SAP best practice".

I would like to understand why.....

Also, what is the purpose of a golden config client?

Thanks in advance for anything that you can share with me on this subject.

Regards,

Ron Mattson

[Former Member]

Hello ABAP People,

I've been implementing SAP solutions since 1996 and this is the first question I have posted to SCN.

I'm hoping for a good experience!  Let me know if you think this question fits into a better area and which one if possible?

Recently I met with the Basis Team and we were trying to determine why we have seperate development clients for config, ABAP, & security.

Here is an exmaple of our development landscape

DEV 010 - Config only

DEV 020 - ABAP only + Unit Testing (config is SCC1 here)

DEV 030 - Security Development (config is SCC1 here)

What I would like to understand is the pros & cons to organizing the development landscape in this manner.

If we were to combine these 3 clients into 1 what problems may that cause?

I've seen replies to similar posts but never the reasons why this strategy is a good or bad.

Please do not respond to this post stating "This is an SAP best practice".

I would like to understand why.....

Also, what is the purpose of a golden config client?

Thanks in advance for anything that you can share with me on this subject.

Regards,

Ron Mattson

[Former Member]

Hi Ron,

As your first question it's a good one, I imagine many people apply a client landscape like the one you describe simply because that's what they always do.

The one benefit a config-only client gives you is a source for any new client that might be needed, your base config without data would be the best starting point for creating a new clean client.

Secondly by separating your config and unit test client you get a clear division between what is transportable config and what is manual, the SCC1 step between config and unit test clients enforcing that discipline.

That said, contrary to your example I typically see config and development performed in the golden client, with the unit test client completely locked down, but other than meaning the source of all transports is the same cleint I couldn't give you any tangible benefit for this.  I guess historically SAPscript development was better performed in a test client (SCC1 not originally being an option for these objects) and the example you give may be a hangover from that.

As to a separate security development I can't see any reason why they could not fit in to the existing Golden/Unit test pair.  I also sometimes see separate clients in development for data migration development.  Again, can't see why they can't work with everyone else in the one client.

More of a brain-dump I guess than a coherent answer, but I hope it gets the discussion rolling.

Regards,

Nick

[Jelena_Perfiljeva]

In my very first SAP implementation we had similar setup (development, config, unit testing) - I guess it might be "best practice" and, as Nick pointed out, "that's what they always do". After upgrading to ECC 6.0, however, we switched to just one DEV client and it was much better.

Currently I have to work again with the separate clients but finally got everyone to agree that at the earliest opportunity we will switch to one client. So far the only explanation I've heard for separate clients was "security", which makes no sense. Here are the main issues I see with separate clients:

- some items (e.g. VOFM routines) require development and cross-client configuration to be open in the same client;

- some configuration is client-independent, so there is really no clear-cut separation;

- SCC1 never happens consistently (especially if there is an urgent change) and is a huge pain in the back when testing SAPScripts.

The best setup in my opinion is with one DEV client and a Sandbox in a completely separate environment (with multiple clients sometimes one ends up being a "sandbox", which is not a good idea).

- with one client it's possible to do a system copy (supposed to be faster than client copy);

- no need for SCC1, configuration/code is always current;

- no confusion (especially for external consultants);

- less space.

This is just IMHO, of course. Requirements might be different for companies and teams of larger size.

[Ryan-Crosby]

Hi jelena.perfiljeva2,

I messaged Paul today on LinkedIn to get both of your impressions on this topic, and low and behold I found this post. To quote the great Han Solo... I find it to be a Hokey religious thing. In my prior experience, I had never come across it, but it keeps bobbing up to the surface now. We finished a second legacy -> S/4 migration last month, and each of the two SIs had proposed elaborate landscapes with many clients. I was baffled by the overkill of the supposed "best practice" and this incessant need to keep a "clean" copy of configuration and had never heard of SCC1 before (one developer (me) and two functional consultants outside of the SIs).

What am I to do with this configuration only client that contains no data - am I supposed to polish it or is it one of those scenarios where there is a glass case that reads "Only break in case of emergencies"? A couple of the reasons I have heard about why we should have one would consist of:

1. Can't undo configuration once test data has been created - Why am I creating configuration I don't want? Sounds like a case where a sandbox is more appropriate, and I would challenge anyone to create some configuration I cannot back out quite easily despite data existing (the one place I agree is the VC behemoth).
2. Need a clean copy of the configuration for reference - Yes, I have one of those too... it's called production where the business is running! And... if it were truly necessary it could be saved upon import into production into a separate client.

The only thing I see it managing to achieve is a whole bunch of additional administrative overhead for any deliverable. I need to login to this client to do my work, and then login to this other client to test my work? Maybe you could ensure I need to use the key fob to gain access into each system too...

Regards,

Ryan Crosby

[Jelena_Perfiljeva]

ryan.crosby2

A lot has changed in the last 10 years but not my opinion that multi-client DEV systems are nothing but the waste and nuisance.

There are now better options to manage large development teams with centralized ATC and all but it's a separate subjects. Developers never care for multiple clients anyways, in my experience.

You were wondering what configuration cannot be undone. There are some cases (turning on batch management comes to mind) where it's very difficult to undo configuration and you can't really not create any data because you'd want to confirm if it actually works as you expect. But to your point, this needs to be done in a proper Sandbox (i.e. a completely separate environment that you can just drop and re-create easily). Such Sandbox is also beneficial for the developers and is actually the best thing you can do for any team if you want to see innovation.

[Former Member]

Hi Ron,

(Dons ABAP Person disguise in order to meet the criteria to answer the question. )

The term "Gold Client" means different things to different folks. I'll try to explain the basic rationale and clear up the terminology as we go.

DEV 010 - Config only

               The #1 problem you want to avoid is ANYONE running transactions in this client to test ANYTHING. In theory, you should also have a sandbox client somewhere to play with different scenarios before you configure anything in your "config only" client. If you run transactions and then later decide that you don't like that configuration, you must go in and root out all of the transactional data before you can change the configuration. If you keep your configuration only client clean then if you do go down a blind alley, you can more easily change course. (Configurators often refer to the config only client as the "Gold client") It's not impossible to root out all of the transactional data, but it's darned hard and NO fun, so you get into big fights as to which team is responsible for cleaning up the mess. Best to avoid this by not giving anyone authorizations to run any transactions in this client (other than configuration)

               So clearly, no unit testing of ABAP in this client either because you have to have data, often lots of it and as previously mentioned that locks the config. Security can sometimes share this client if your security needs are relatively straightforward.

DEV 020 - ABAP only + Unit Testing (config is SCC1 here)

          So if you can't run transactions in the config only client, then where do you run them? In the unit test client! How do you get the configuration from the configuration only client to the unit test client? SCC1! (Ding, ding ding ding! Correct answer! If you answered, by closing the configuration transport and importing it into the test client, BOOOOOO, you FAIL! The latter strategy creates a complete nightmare of extraneous transports, typically accompanied by massive sequencing problems.)  SCC1 allows configuration folks to control the timing of their unit testing. Config -- SCC1 -- Test  -- rinse, repeat until it works, THEN release transport. Ideally you should only have 1 transport per unit of configuration work (yah, I know, suuuuure, but this method keeps it to a minimum).

          What about ABAP? In some cases ABAP and configuration Unit Testing can share gracefully, but at sites where ABAPers are doing significant conversions, at times the conversion programs can create large volumes of bogus, disruptive data, which annoys the fire out of the config team, who then demands that the basis team wipe out the unit test and refresh it with only the released config from the configuration client (again the "gold client". Occasionally folks will demand a config only refresh in the QA system which is why sneaky basis folks often keep a secret (GOLD) client which no one but the basis folks can access. That client only recieves transports from the dev system and is untouched by meddling, pesky, friendly, well intentioned configurator/ABAP hands.  This secret client is often called the "GOLD CLIENT" by the basis team which causes big fights with the configurators who like to call their configuration only client the "Gold client". *sigh* can't we all just get along.

          In other cases, ABAP gets a separate client from the configurators' Unit Test client in order to avoid clashing over "bad" data. The flip side is that when they are separate, the configurators whine, complain, wheedle, respectfully request that he ABAP team use the conversion programs to create data useful data in the Unit Test client. Again, this causes friction. There are tools that can be used to move subsets of data from production back down into any client, but into the Unit Test client, in particular. SAP's tool is called TDMS (Test Data Migration Server, if I recall correctly, but everyone just says TDMS). There's a popular 3rd party product called.... wait for it.... GOLD CLIENT! Tada! Third usage of the term!

DEV 030 - Security Development (config is SCC1 here)

     So why would you want a separate Security Development Client? One, because security folks are all handsome/beautiful geniuses with awesome senses of humor who in no way would ever mess with anyone's security profile if said person every implied anything negative about them... right security folks?  Right ?.... *nervous laugh*  Aaannnywho.. (slips the security team a large pizza)

     Seriously, most likely this comes about when you are running HR security which is tied in to the HR org structure. It's been a while since I've dealt with this, but I vaguely remember the HR org management folks needing a separate dev client and the security folks colocating there in order to test different HR security schemes.

     In less extreme circumstances, Security could peacefully coexist with either the Unit Test and/or ABAP client.

In my experience, I wouldn't recommend less than three clients: sandbox, config only, and unit test. ABAP and security, if they can play well with others, can cuddle up with unit test, but should generally stay away from the config only client to avoid data mistakes.

And that... dear ABAP people (whips off disguise to reveal.... BASIS GUY! *gasp!*) is why we can have up to 5 or even more clients in the Development system based on the requirements. (Bet you saw through my disguise when it took me 1000 words to say "it depends".)

Now slide me TWO large pizzas and I'll explain why the "Transport of Copies" functionality should be your BEST friend! (Hint... you can run multiple tests in QA and not release your "true" transport until you have a functioning unit of work. ONE transport instead of having to track the 15 you normally create doing iterative testing in QA! Every ABAPer I've got over the "but that's not how we do it" objection to try it has LOVED it. Win/win for basis and ABAP. See! We *can* all get along!

Hope this helps!

Best regards,

  --Tom

[Jelena_Perfiljeva]

Tom, thanks so much for the post! I tried very hard not to laugh out loud (open office, you know).

Certainly we can have multiple clients (hypothetically 1000 I guess - 000 to 999), but it doesn't mean that we must have them. Your example is a great illustration of what might be required for a larger organization. But the same thing is an overkill for, say, our SAP team of 4 (four) and no HR (in SAP). So probably the decision regarding clients should be based mainly on the individual needs of the specific organization.

[Former Member]

Jelena,

I'm so glad you enjoyed it! I was going for humor, but since I'm home with a fever, I'm just happy that it came across as lucid. You are exactly right. I do tend to err on the side of having more clients rather that fewer, but that's definitely due to average size of the systems/customers I've dealt with over the years. At a small shop such as you described, one client is probably just the ticket.

Grats on the SCNer of the Month, by the way! That's how I found this post. I'm just happy I could help out on this one!

Grats again!

Best regards,

  --Tom

[Akshay_G]

Greetings Tom,

As always like before, I thoroughly enjoyed your such a Candid yet empowering insight.

At my Organization's, we have more than dozen of them in Development System since inception.

Literally like a client for everything, A client for Virsa (SOX), Client for Authorizations, Sandbox Client, Client for Prototype, Spattered Clients for HR, SRM, XI Development, Client for TDMS, Golden Client, Then again a copy of Golden Client, Also a client of Production Customizing.

I felt like lost for a while in SCC4, but your insight enlightens me.

Glad to know the essentials.

Very nice post

Regards,

Akshay.

[Former Member]

What is SAP's recommendation on the number of clients ?

Do we have any SAP document (OSS Note) on latest client strategy which we can refer to ?

- sid

[Former Member]

Thank-you for the responses.

Regards,

Ron Mattson