Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
Valdecir
Product and Topic Expert
Product and Topic Expert


Every now and then we face the discussion:

 

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.

1 Comment