Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Should I have a separate client for my developers?
It has been discussed endlessly and I never heard one argument that could convince me that a separate client would be required or beneficial at all. It is always the opposite way, that is, I have found several arguments that point to only one client for customizing AND developments.
Let's list some of those arguments that can be used to defeat separate clients ambitions:
Audit compliance and Traceability
When someone decides to use separate clients, it becomes complex to explain to auditors that “some changes come from one client” and “some changes come from a different client” and this generally leads to audit penalties
Change Control Management
Almost the same reason as for audit, change control management must control the origin of all changes and this leads to a higher complex scenario where changes may be created in different sources
When customer is using ChaRM it is mandatory to have only one client that is allowed to create transport requests (if someone brings in an alternative to bypass this, it is not considered a best practice!)
Administration complexity
Even when only the developers are to be maintained, it is an additional client to manage, control passwords, user locks, create and manage RFCs from Solution Manager to this new client and so on
Most of the developments are cross-client (see exception in the next bullet)
Once most objects are cross-client it makes no sense to create a separate client. If the objective is to avoid testing in the customizing client it must be prevented by authorization roles (don't forget that the same restriction should also apply to customizers!!)
Smartforms are client-specific and there is a development dependency upon customization that must be done in the SAME client where the smartform is developed
If Smartforms (and some other stuff) are to be developed then its configuration must be executed in the same client where it was developed (yes, Smartforms are client-specific!!) and this would lead to two clients providing customizing transport requests, bringing even more problems to the topics “audit”, “traceability” and “change control management”
So, based on the points highlighted above, every SAP NetWeaver consultant/developer should never agree with separate client for developments.
As a last comment, always keep in mind that once created and used such client could never be removed from the customer´s system in order to allow proper tracking of changes coming from that client.