If the customer has an older legacy system, and new business issues arise, such as Value Chain, B2B integration with business partners, or a need for enhanced management reporting, do you modify, live with it, or buy something else? Will "something else" bring its own set of problems?

Based on over 21 years’ experience of dealing with this, primarily working on Multivalue databases using some form of RAD (Rapid Application Development) front or another, I don’t have the usual trepidations that some might have on large fixed-field systems, where modifying is a major event. However, just because you CAN do it, is not a valid reason to "make spaghetti".

Modifications are written to get an application to perform differently from what the baseline product had intended. They may involve amending baseline code, or may involve adding code external to baseline. Modifications can include adding new fields to the existing database, utilizing "user-reserved" fields. Having the MV data dictionary simplifies this, but does require that the dictionary itself be well maintained.

Conventional wisdom is that modifications are to be avoided. Modifications may complicate vendor's support. Modifications mean that accepting vendor upgrades may be more difficult, in terms of time and cost. Modifications tend to make a system more error prone, and are seen to increase cost of ownership.

Since I make my living from consulting, which involves both maximizing customer/user value from what they already have, plus enabling what they need and don’t have, I have a different perspective. (Working with MultiValue and RAD fronts is another "plus").

a). Determine EXACTLY what the customer requirement is, and why they need it, for their business reasons. Sometimes what they need is a minor change, or addition, to what’s there – sometimes it’s additional code, or a separate module. Sometimes it’s just understanding what they have, after a key user has left.

b). I try to stay OUTSIDE the baseline code at all costs. I provide modules for Sales and Purchase Order History, but have constructed my own files for storage of information, and update those separately from baseline data entry, wherever possible, or through a File-Time call. All of my reporting comes from MY files, so it’s 100 percent custom, at that point. I am free to add my own fields to my own files, and not collide with a baseline upgrade. I can generate Excel, XML, whatever.

c). Make sure that a Development account exists for the programmer to work in, and a "Play" account, with a good set of representative data, for the users to test in. My environment (DataFlo) contains tools to move changes across to the LIVE environment(s), or to a Play environment, in an organized manner, and track the changes.

d). Documentation is the key. If you change a Program or Proc, you have to document the changes, and "border" the changed code with comments.

**Bgn Rev 0Z,06-01-2001,PBZOOM,PB: Added logic for PPV History

CALL MPO.Z201.CALL

**End Rev 0Z

There should be a section at the top of the record where changes are listed, with full comments, in the sequence made. I keep "custom" changes in a separate section, away from "baseline" changes that the vendor made, and can quickly tell "mine" from "theirs".

e). When upgrading, have room to store both the EXISTING and NEW baseline software, and a means to compare them. I am concerned with baseline software which was modified for the customer, not that which was untouched. If I see that the NEW baseline software record is identical to what is in the current record, any custom changes made will simply be brought forward.

If a policy consists of making changes as "external" as possible, ideally through 3^rd party add-ons, and documenting well, much of the pain of upgrades is nullified, and the customer can carry the modifications that they require.

The interesting problem is getting the customer to abandon modifications they no longer need, but that’s another column …..