|
May 3, 2006
Experimentation in PeopleSoft
Sometimes, at the beginning of a significant PeopleSoft
project, you may find that you don't know up-front
exactly how you will implement a requirement.
You might have been given a detailed functional
spec, but this should not specify the
technical implementation. (It might attempt to
do so, but its recommendations could be completely
inappropriate or even impossible. It can still
be a very useful document even if you need to
ignore the technical details it contains.)
Before diving headlong into construction, it
sometimes helps to do some experiments or
prototyping. This will probably
involve creating PeopleSoft objects. There is
a small problem here. You may find that you need to
backtrack and start over. There could be objects
created that you don't need in the end. If all
of this is done in the development environment,
that database can end up with many abandoned
objects. A full database compare will identify
these as customizations. This can complicate
upgrades and general maintenance.
One solution is a refresh from another
environment—maybe the next one in
the migration path (a testing environment).
This can help to keep the environments in sync.
However, if you are doing a lot of ongoing
development, a refresh may be disruptive.
You could save your projects as files and
reload them after the refresh. But what if you
have constructed some test data? That would be
more difficult to recover.
If for some reason a refresh is difficult to
do, it may make sense to have a "sandbox"
environment that you can use for your
experiments. This should not be a copy of
the demo database, but rather a copy of
the development environment. Create as many
objects as you wish. Once you have settled
on a good technical approach to the project,
you can start over in the development environment
or simply migrate objects. Be sure to run
a project compare first to avoid stepping on
other customization! Also, do not allow the sandbox to
turn into a second development environment!
All objects should be migrated to or recreated
in the actual development environment. They should
never be migrated directly to the testing
environment.
It's simply not possible in many cases to know
in advance exactly how a custom change should be implemented.
Being able to experiment and prototype first can
save headaches later.
Next week we'll consider the Waterfall method
of project management. From today's post, you
might be able to guess where that's going.
Until next time...
|
