January 31, 2007

PeopleSoft Environment Usage

Over the last two weeks I've outlined some ways of setting up your PeopleSoft environments (databases) to enable development and support. I've discussed having multiple testing environments at one step on the migration path vs. multiple testing steps on the migration path. Two common configurations are the three-step path (DEV - TST - PRD) and the four-step path (DEV - TST - UAT - PRD). Which is better?

As with so many things, it just depends. However, a major consideration involves your data access policy. If developers are restricted from seeing production data (or at least restricted from changing production objects), then I'd recommend at least four steps on the migration path. Here's why.

If developers cannot see production data, then obviously they are not allowed to migrate objects to production. Another group will do this. It might be DBAs or some separate production control group. Now, suppose that we have a three-step setup (DEV - TST - PRD). Developers migrate from DEV to TST, and the production control people migrate from TST to PRD. That won't work. First, the production control people have only one chance to practice the migration—and it's on the production migration. That is very risky. Second, the modification cannot be tested on "real" data, since TST would need to be "scrambled" to allow developers access to it. (Never restrict developers from trying out their changes in TST!) It's just a mess, so let's look at the four-step variation instead.

Consider the roles of four groups of people: Developers, testers, end users, and the production control group. In a four-step (DEV - TST - UAT - PRD) configuration, each group has access to environments as shown below:

Group	Environments
Developers	DEV, TST
Testers	TST, UAT (and sometimes PRD)
End Users	UAT, PRD
Production Control	TST, UAT, PRD

In this setup, we'll assume that DEV and TST contain "scrambled" data and UAT and PRD contain "real" data. Developers make their changes in DEV, test them, and then migrate them to TST. They do another quick test in TST to ensure that the migration was complete and accurate. The testers (functional team or QA group) check out the changes in TST and then request migration to UAT. The production control group migrates the objects to UAT using instructions provided by the developers. The testers do another quick test in UAT to ensure that the migration was complete. The end users then look at the change in UAT. (The quality of testing at this point tends to vary wildly across companies, departments and individuals. The value to be derived here is mostly in the areas of "acceptance"—does the change reflect the users' requirements?—and training of the end users.) If all goes well, the production control group migrates the objects from UAT to PRD, doing exactly the same steps they performed the first time (TST to UAT). Note that production control does not ask for the instructions again; the same instructions as before are used. If for some reason there is a separate step for the production migration, the developers must inform production control in advance. In almost all cases, this migration should be the same as before.

Using this structure, everyone has adequate opportunities to test both the actual change and the migration procedure. Both must be accurate, of course, but the migration test is often neglected and this results in unpleasant surprises in production. Of course, you could have other steps along the way. But I recommend at least these four steps where data access is an issue or where developers do not migrate their own changes to production.

Until next time...