Quick Poll - Isolating Security from Production

Bob_Duben

Bob_Duben

Well Known Member
Hi List!

I just wanted to do a quick pole of how many of you have separated your security to isolate Production from the other environments?
In other words setting up two sets of the security tables and reassigning the OCMs to keep development and test separate from Production.

Then as a second question, did you also separate out the DataDictionaries and UDCs as well? :cool:
 
I would be interested in the result. I work with many clients and can only tell you what I have seen, what I have seen work and what I recommend: yes, definitely separate Security in Prod from Dev/CRP/PY type environments. It saves a lot of pain but I understand that this isn't quick and simple. It's benefit comes from large multi-site implementations with staggered Go-Lives.

Data Dictionary should be split for the same reason but this is less critical and I haven't seen this done as often. I would probably recommend it.

UDC's are mostly treated as just another Business Table rather than a Control Table and mirror Business Data locations. I haven't seen any strong reason for this to be done any other way but would be happy to be enlighted. Control Tables are normally sliced up between the Path Codes in a variety of ways - I don't know what is right or wrong but most are based upon old JDE advice which seems OK....
 
Thanks Mark for answering the Poll.
Due to Roles and handling all environments within the roles rather than user accounts we have experienced crossovers and want to purify this.
I thought others may have separated the security tables to protect PROD from the other environments and remove the possibility of "accidental" access. I do realize this does increase the work of the Security Administrator.

I'm still researching the why or why not we should consider separating the other components.

Bob
 
While separating Prod security does make sense from an internal control viewpoint, our reason for doing so in our 8.10 implementation was much more pragmatic. Testing of security changes is very difficult when security is system wide. Unless done very carefully, production can be adversely impacted. However, separate tables do have some disadvantages with maintainence and troubleshooting being the primary ones.
 
Back
Top