Deciding to Customize

You could write a book--and many have--on the proper way of executing a customization project, and we do not intend to discuss in detail the process of managing a customization.

Nevertheless, we have heard of some sites performing modifications of production databases while they are in use on a server. We have seen other sites go through a lengthy series of customization changes only to realize that the features they desire closely resemble the standard Archibus domains.

Sometimes customization is as simple as changing the Field Headings to reflect the terminology used in your organization or adding a column or calculation for data you need to track. Often it will involve both data and functionality.

With a product such as Archibus that offers that capability to do just about anything you want, there is often a temptation to declare that the stock product doesn't fit the organization's needs so customization will be needed. This is an easy trap in which to be caught if you don't take the time to think about your processes and how you could alter them to fit the way the stock product works. It requires that you analyze the driving requirements rather than just looking at how you accomplish a particular task today. No stock offering will exactly duplicate your processes, but if you perform a gap analysis between your system and the stock system, you may be surprised to find that a slight modification to the stock product will serve your needs.

Performing a formal needs analysis and documenting your findings ensures that everyone understands the current reality and the goals of the customization. Often, issues concerning the priority of different goals will become clear, and effort spent on secondary or minor features can be avoided.

Another consideration in launching a customization effort is the impact that it may have on your ability to implement future upgrades to the Archibus product. While every effort is made to provide backward compatibility, a time may come when a new version of Archibus would interfere with your customized implementation. At that point you would need to decide if the cost of making your customization work with the new version of Archibus is worth the benefit of doing the upgrade. Ultimately you could end up in a situation where your base Archibus system is too far behind to be supported. In any case, all customizations increase the complexity of upgrading to new versions of the product and you should be prepared to deal with that consequent cost/risk.

In terms of changes to the structure of the database, you need to have a solid business case for changing stock field attributes that affect the physical database like data type, or field size. These types of changes can have unintended negative consequences. The addition of tables or columns, or changing attributes that don't affect the physical database (e.g. Field Heading), are less of a concern.

In any case, all customizations increase the complexity of upgrading to new versions of the product and you should be prepared to deal with that consequent cost/risk.