| Change Control and PeopleSoft Development |
|
| Wednesday, 05 April 2006 | |||||
|
If your company is big enough to afford PeopleSoft, chances are it's big enough to worry about IT audits -- whether they are Sarbanes-Oxley related or your company just likes to maintain a high level of quality in their development processes. Here are some common aspects of PeopleSoft development Change Control processes that I have encountered: Separation of Duties While it would be convenient, developers can't migrate their own projects. I normally find developers who write the code, and a DBA or PeopleSoft Administrator who migrates the changes upon request. PeopleSoft security is set up in such a way that developers can't migrate, or make any code changes outside of a development and/or sandbox environment. Tracking Changes Auditors often pick a project out of development, and want to see how it progressed from development, through testing, and finally to Production. Or they'll pick a modified object in Production and want to see the entire documentation trail as to how it made it there. Either way, good documentation is essential. Documentation starts with the original user request. Usually enhancement requests or break/fix can be tied back to an issues database, help desk application, or other central repository. Depending on the complexity, functional and technical documents might be prepared and approved. At some point, a PeopleSoft project is created with a specific naming convention and this project is tied back to the original user request. Then the developer makes his changes and places all of the objects in the project. I've often seen this project name made part of custom SQR and Crystal filenames to make them easier to track. When the developer is done with unit testing in the development environment (which itself may involve a unit test document), some type of migration request is prepared and sent to the PS Administrator or DBA. At a minimum the migration request will contain the source and target environments, the project name, and filenames of all batch and flat file objects. After making sure everything is in order, the admin does the migration and notes on the migration request who moved the project and when it was moved. Once the project is tested, there is usually some type of user acceptance that indicates from the business end user that the change fixes the problem. Also in this phase I've seen test plans and sign-offs from other interested parties. Finally the time comes for the move to production. This certainly involves another migration request, and usually involves some type of Production System change notification document to notify interested parties. Usually production change notifications require some sort of review by a controlling board who will always ask what it does, who approved it, what's the risk, and what's the rollback plan. Once everything is approved, the admin actually moves the project to production and updates all relevant documentation. The Devil is in the Details Sounds pretty straightforward, right? Well, it can be. But your process needs to be very clear and everyone must understand them. And the best processes allow for flexibility when timelines are tight or a quick fix is critical. Unfortunately, PeopleSoft doesn't manage change control very well. You can work around this by using a product like Quest Stat. If you'd rather not spend the money, you'll need to 1) Convince your auditor that PeopleSoft doesn't do change control but that's OK; or 2) export your projects to flat files and (optionally) check them into a VSS solution. The trick to convincing your auditors that change control is unnecessary is to have another environment where you can migrate previous versions backwards. For instance, if you mess something up in Development it's Ok because you can pull it from test. Or if a change messes up test, you can pull it from Production. It generally works well enough until the change goes into Production. Then you end up talking about database restores or pulling unmodified code from a reporting or staging instance. Exporting projects to a flat file and optionally using a source control system seems like it would work, but to tell the truth I've never gone this route. If you have I'd like to hear from you. It doesn't seem like a natural fit for either the developer or the migrator, although the auditor would probably love it. I understand that PeopleSoft used this approach with some success. Conclusion Tracking changes like this is probably my least favorite part of the job. But that's why I wanted to post about it. Maybe if we work together we can come up with some best practices that won't add too much overhead to the development process, but still insure the quality that our stakeholders expect.
|
|||||
| Last Updated ( Wednesday, 05 April 2006 ) | |||||
| Next > |
|---|