THE APPLICATION PACKAGE DILEMMA
Classic Decision Making and Implications
There are classic rules of thumb used in buy/build decisions. Buy in situations of parity. Build for competi-tive advantage/differentiation. In a buy scenario, you willingly cede control of the end product (functionality, architecture, technology) for the promise of a lower price tag, ease of implementation, and quicker time to market. If you are disciplined, in that you actually do cede control of functionality, architecture and technology, in other words, no modifications, then the buy scenario usually pays off.
Unfortunately, in the depths of implementation design, long after contracts are signed, and initial payments are made, even the most disciplined initiatives run across something (terminology, business rules, business proc-ess, functionality) that they either can’t live with, or without. As a result, a modification list is created.
In a best case scenario, the modification can be handled via a configuration setting. In a middle-of-the-road scenario, the modification requires an extension point into another (new or existing) application or data structure. In the worst case scenario, the modification requires a change to underlying application code and/or data struc-tures. Often, the software vendor/implementer is employed to change the underlying code and data structures, or to provide an extension point mechanism. Depending on time and skills, either the vendor/implementer or project team builds the actual extension applications and data structures.
In the short term, application package modifications increase a project’s implementation price and lengthen the schedule. However, if a modification list is managed well, the overall project cost and schedule can still be more attractive than a build-from-scratch model.
Of course, there are also long-term implications of customization. Sometimes, a customization (by vendor or project team) is done in a manner that causes your installation to fall off (or behind) the vendor’s upgrade path. Other times, your customization is such a great feature that the vendor folds it into the package. This bodes well for your upgrade path, and (unfortunately) for competitors using the same package. Lastly, in a scenario we are seeing frequently in consulting engagements, simple application package extensions have evolved into hardwired ecosystems of complementary applications, data stores, and reporting environments. Typically these ecosystems have explicit knowledge of (and dependencies on) the application package’s data structure, code, and business rules.
1
Print this article
Email this article
Talk Back!
Write to Editor
