| Fear of Customization | KEVIN RESCHENBERG
07-18-2014 |
Over the years I've noticed that we PeopleSoft developers sometimes act out of what appears to be an irrational fear of changing things.
We were taught by PeopleSoft (or those who went before) to use the "vanilla" system and its components as much as possible.
So we try to use existing objects for new purposes and avoid changing any delivered objects. Although it's a good goal, in practice it can lead to
some not-so-good results.
Here's a simple example. The other day I was designing a new table and adding fields to it. Naturally, I scanned the list of existing
fields to use. This one has a good, relevant name but is the wrong type. This one has too many decimal positions. Here is one that fits but
has a misleading name. After several minutes of this I snapped out of it. Not only was this a big waste of time, but it probably would have
ended up as a compromise—a field that only sort of fits, but not really.
So I just created a new custom field with the correct characteristics and an appropriate name.
Was that wasteful? Do we really want another object in the database? Well, consider that HRMS/HCM 9.1 has approximately
82,000 delivered field objects used 466,000 times
in tables and views. One more probably won't hurt.
Similarly, we might be tempted to reuse an existing delivered field on a table when we think the field isn't being used. But just about every
field is used in some way, and it takes time to track down all the references and ensure that they would never be triggered. And a future
upgrade could change the way the field is used, conflicting with the new (custom) use of the field. In most cases it is just better to add
a new field. (Or create a new sibling table—but be sure that it is kept in sync with the other table at all times.) Be very careful, however,
if you want to add a field to one of the very few payroll tables that are maintained by the COBOL programs. That can require a lot of extra
work and is best avoided.
One of the objections to customization is that it makes upgrades more difficult. That is true, but especially if your changes are of the
"bolt-on" type, where you are creating something new, an upgrade generally won't touch them. And changes that overlap with delivered objects can
be managed effectively if we just use the analysis tools available, migrate from clean projects, and test.
One of the strengths of the PeopleSoft system is that it allows a great deal of customization. Rather than limp along with a system that does not
meet the users' needs, why not take advantage of it?
|
