| Migration Instructions | KEVIN RESCHENBERG
02-07-2007 |
Today's post continues the overview of PeopleSoft environment usage and migrations.
I probably have another week or so to go on this topic and then will finally wrap it up. (Promise!)
But before getting into today's item...I just noticed that it's been three
years now since I starting writing these weekly rants and ramblings. Some readers have sent good comments and even
compliments, and these are much appreciated. Part of the reason for starting this
series was selfish—I wanted to build a sort of library of information and opinion that
I could pull from when clients asked common questions, and that has happened.
But I hope these have occasionally been useful to you as well.
In last week's discussion of three-step vs. four-(or more)-step migration paths,
I mentioned the role of a separate production control group (or DBAs, or whoever
handles UAT and production migrations). This is a common setup. In many cases,
this separate group works with systems other than PeopleSoft. Direction needs
to be given. There is probably a form to fill out. Here is where you can have a
process that helps to ensure accurate, smooth migrations, or a process that
practically guarantees problems.
First, why do we need a separate production control group at all? The previous
post gave one common reason: The need to protect "real" data. There are others. But one reason
commonly given is that this separate group acts as "another set of eyes" to
check development and/or migrations. This is a good idea in theory, but it works
only if the production control people actually know what PeopleSoft development
is all about. In many cases they don't or can't, especially when they handle
multiple systems. Even when they are experienced developers, do they really review
objects, or do they just mechanically follow the steps?
In any case, as I said, there is probably a form to fill out. The less experienced
production control groups will probably demand a highly detailed document.
This will list the steps to be followed, but it might also include lists of
objects and what to do with each. It could even require screen shots of steps
to be taken. Or, taken to an extreme, it could require code listings and screen
shots of objects.
Now, documentation is (usually) good. But remember that every time one document
or object is translated into another document or object, errors can be introduced.
For example, Application Designer projects contain (most of) the objects to be
migrated and/or deleted. If this list must then be transferred to a separate document
and these two sources must then be kept in sync, there will be errors at some point for obvious reasons.
More documentation is not always better. Sometimes having more documentation introduces
more risk. The trick is to determine what types of documentation will be useful.
If the production control group must be led step-by-step through normal migrations,
is any real value being provided? Might it be better to move this function back
into the PeopleSoft development group, possibly assigned to one or two senior
developers or managers? Even if the responsibility is not transferred, I would
suggest that you encourage the production control people to use the tools available
(such as App Designer or Stat). They should also be aware of your standard
procedures and require specific directions only when there are deviations from those standards.
For example, if you normally do not migrate menus, then everyone should know this.
The production control group should not migrate menus unless given
specific instructions to do so. It should not be necessary to state "remember not to migrate
the menu" in the migration document. The production control group should know what
it means to "migrate a project" and should be able to perform this for normal
projects without detailed instructions.
Another example of a standard concerns whether the developer or the migrator is
responsible for setting the "upgrade" flags. Is the migrator expected to run the
compare report to set the flags, or does the migrator simply use the flags
as they exist? Or is the migrator expected to rerun the compare and then report
back on any inconsistencies with the way the flags were previously set?
Work this out in advance.
Of course, there are always special instructions for certain projects. If your
environment is informal enough and your processes smooth enough to support this,
you can just put these instructions in the comments box of the project itself.
That's close to the source and will be helpful to other developers who look
at your project later.
|
