At the beginning of the month, my family took a trip to the Kennedy Space Center. Seeing the amazing accomplishments of the space program was inspiring! Can someone find me a PeopleSoft project that takes us to the moon?
The museum pointed out that in the age of mass production, the space industry had to perfect custom built, unique parts to accomplish a precision goal. In one of the most hostile environments, they had a high standard of safety and did not sacrifice lives for accomplishments. My PeopleSoft projects may not be anything close to a hostile work environment, but I hope hope that some of the precision, excellence, and quality rubs off on me.
One of the many things that stood out to me was the Go/No Go Card and the Flight Checklist. Everything was planned down to the minute detail and a check list was followed and practiced. Anything that we want to be repeated successfully and accurately could follow their example, but in our world, a migration could probably benefit the most. If you want to get your development into production with no mistakes, you’ll follow a checklist. Here some thoughts just to trigger some analysis of your own migration practices.
The astronauts didn’t just plan and show up. They ran through the list and practiced each step. When something didn’t work or they found a better way, the list was changed and tweaked. They even practiced failures and problems so they knew what to do when something went wrong.
In the PeopleSoft world, we should never move from our development environment directly to our production environment. A test environment should exist to give us the practice of migrating the code and changes before doing it in real life. Remember that when your users test in your Test or UAT environment, they are not only testing the new product that you just developed, but they are also testing the migration process.
Consider your refresh ability. If something goes wrong in the migration, can you refresh and start over? If you have a culture in which environments are static, it impairs your ability to test the migration. Automating the refresh can help minimize the time and effort to refresh. Tracking efforts in progress can also help so you know what is in progress and don’t have to fight a refresh with fear of loosing something.
Follow the Plan
I’ve been told that a migration technician goes through three phases. First, he clings to the check list and directions because he is unsure and is afraid he’ll miss a step. As his experience and practice grows, he confidently coasts through the migration without a glance at the list. Finally, as hard experience continues, he diligently looks at the list and instructions because he is confident that if he doesn’t watch the list, his haste will cause him to miss something critical.
The astronauts had practiced so much they could probably do it in their sleep. Still they followed a list as a team. If we want the same precision in our PeopleSoft migrations, we’ll make and follow a list.
Space is tough to practice. It’s hard to find a place with no atmosphere or no gravity for practicing. Still they gave it their best shot. We saw videos of them practicing underwater, out in the desert, in simulators, and in g-force machines.
Also in PeopleSoft, we can’t exactly replicate our production environment. For example, we don’t want real emails leaving the system and some vendors may not have a test interface we can use. Like the astronauts, we should still give thought to replicating as best we can.
Again, refreshing the data often can help. Testing with 3-year old data is not the same as testing with month-old data. Simulations can also help. For example, you don’t want to send real emails from the system, but if you can setup something where all emails get redirected from the system to a test account, you can still test to make sure the emails get sent like they are supposed to.
One of the biggest bonuses of the space program is number of new technologies created to meet the challenge. NASA can boast of smartphone cameras, infrared ear thermometers, and water purification systems that were invented because of their efforts.
In the PeopleSoft world, necessity is just as much the mother of invention. A smart team will develop tools to that help with migrations. For example, you could write a tool to make sure objects aren’t left out of projects and that development standards are followed. If you find yourself constantly writing custom DMS scripts to migration configuration data, why not write a simple interface between systems?
PeopleSoft may not demand the same life-critical accuracy as the space projects, but our users still expect precision. Migration skills can always be tuned and enhanced. Hopefully, something was said that will encourage you to take the next step.