| To Patch or Not? | KEVIN RESCHENBERG
03-21-2005 |
Do you keep up with all of the service packs/bundles/updates/fixes/patches issued
by PeopleSoft (now Oracle)? You may be thinking, "Well, of course!
That's required!" At the same time, though, others are thinking,
"Well, of course not! It would be a full-time job!" And for still others,
the standard procedure is "x", but they often do "y"...
Most people probably think that the decision of whether or not
to apply all patches is an easy, clear-cut one. I'm not so sure.
Yes, keeping your system up to date confers clear advantages: better
support, fewer bugs, and the opportunity to take advantage of
everyone else's testing. (And I would never recommend against
it—it's hard to justify that position, besides the fact of it
being very politically incorrect.) But it also requires a large time
commitment. Also, as you know if you do keep up to date, a
patch can easily "break" something that was previously working.
Most customers want to test the patches before moving them to
production, and this means additional time and the need for
coordination of processing schedules and any customization that
is currently in progress.
What's the alternative? Some customers successfully follow the
opposite approach: Never patch unless a bug is found (or a Payroll tax
update is needed). Yes, I know
that's heresy (and as mentioned earlier, I'm staying neutral
on this), but it has worked.
Once the system is stable and working as needed, these installations
can enjoy relative peace and quiet. The risk, of course, is that
they may not know about lurking bugs.
The obvious way to catch important bugs is to monitor the
documentation on the available patches, and then apply the ones
that are needed. This might be proposed by the functional team.
It can lead to a very bad situation, though, if the users want
to pick and choose patches. Many patches require prerequisites
to be applied. If the users are allowed to say "yes" to one
patch but "no" to its prerequisite...well, let's not even go there.
For teams that monitor the available patches, the rule should be
that if a particular patch is needed, then the prerequisites
must be accepted also (if they are really required).
I said that some companies have successfully run their systems
without applying all patches. What about Payroll tax updates?
These are important, of course, but many of them consist mainly
of setup table updates that can be done easily. A big risk
with not keeping up with patches is that someday you may need one,
only to find yourself faced with a large tree of prerequisites upon
prerequisites. At that point, you have four choices: Try to track
down and apply all the prerequisites; evaluate the patch carefully
to extract what is really needed, along with what is really required
as a prerequisite, and apply only those pieces; do an upgrade to the current
release or service pack; or write a custom fix.
Either way, don't let anyone tell you that one method is obviously risky and
the other is not. Either method entails risk. Not keeping up with
patches exposes you to bugs. Applying them, on the other hand,
presents its own risks: Something that was working will break; you don't
apply the patches correctly; your existing customization breaks; partial
customization is migrated along with the patches; or the time
taken in finding, applying, testing and migrating the patches could
have been put to better use.
You may be thinking that it's safer in general to keep up with the patches.
In that case, how can you evaluate and schedule them—or should you,
in fact, do any evaluation or scheduling at all? I'll describe one
experience next week.
|
