This topic was actually suggested by my friend Paco. I think there's a constant state of tension between application people and infrastructure people. With Sarbanes-Oxley, I guess that there's now tension with security people too.



I've usually seen the security issue dealt with by designating one of the test environments as a "security" environment where security is finalized and unit tested. I don't normally think of security (at least in PS) as a technical responsibility. PeopleSoft's rigid Page>Component>Menu structure allows security to be safely dealt with later in the cycle by non-developers.



I've seen time and time again where restrictions in the development environment has significantly lengthened development times causing key milestones to be missed with very little benefit in terms of accountability or control.

Derek

To follow up with what Brent said, the whole process can slow down if you start to limit your developer in development. I usually suggest the security be built and tested in a testing environment. Though many projects I've been on didn't have a testing database on day one, seldom does security need to be nailed down at the begining of a project. Some of the security can't even be addressed until your developers have "built" the new pages (customization slope ahead...but we live for it).



The more you allow your developer to experiment in DEV, the more knowledgable they can be. I would step out on a limb and say that most of PeopleTools is learned thru experimenting with the product. We don't limit young drivers to just the backroads until they're 21 (I hope this is a wise analogy).



Best of luck.

David Vandiver

Consulting at the University of Houston

Thank you both for your comments/responses.



David,

That is exactly the point I am trying to make to our infrastructure team. I hope they listen!



Thanks again

Derek