To Patch or Not?
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.
Until next time...
 Email: kevin@sparkpath.com
|
