Packaged software simplifies upgrades and maintenance because of its singularity. Support and adoption also are simplified because the single system is well known. Customization of software, by definition, is the modification of packaged software to meet individual requirements. Various valid enterprise requirements lead to customization of packaged software. In general, the benefits as well as shortcomings, of available customization techniques are poorly understood and improperly lumped together into an all-encompassing perception that all customizations inhibit evolvability.
Maintenance, or evolution, is the longest and most expensive phase of the application lifecycle. Once released, software has to be corrected and updated. Evolvability is the key metric used to judge an applications ability to incorporate updates and new revisions of packaged software while maintaining required customizations throughout the application lifecycle. This post defines three levels of software customization and their impact on application evolvability.
The Three Levels of Software Customization
An application may be defined as the combination of packaged software and customizations required to support an end user in performing user specific tasks efficiently.
Individualization
The first level of customization, known as Individualization, is commonly referred to as “customization through configuration”. Important aspects of corporate-identity such as the corporate logo and corporate color scheme should reflect a corporate design. Packaged software should provide different options to different user groups. Reports should reflect company identity and reflect information necessary to support an organizations processes, workflow and individuality.
This first level of customization almost always take place for enterprise applications and tends to be a non-controversial practice. Properly executed, Individualization is well understood and requires a fairly low degree of effort to implement and maintain over the application’s evolvable lifespan.
Key metrics for Individualization are the number of properties, options and configuration settings changed from the packaged software installation baseline.
Tailoring
The second level of customization is Tailoring and represents a stable middle ground for the applications continued evolvability. Packaged software comes with built-in assumptions and procedures about organizations’ business processes. These assumptions and procedures seldom match exactly with those of the implementing organization’s existing processes. Therefore, most implementation projects involve some degree of software tailoring so that the software will fit current organizational processes. Tailoring may involve module selection, table configuration, or the addition of encapsulated new user functions.
In Module Selection, companies choose to implement one or more modules of a software application. In this case, customization is achieved through the company’s module selection. A Key metric for module selection is the number of implemented modules versus the total number of modules available.
Table Configuration, another tailoring technique allows an enterprise to eliminate features that are not pertinent to a give task and tailor necessary features to better suite the given task such as selecting more appropriate application defaults, or by using task-specific vocabulary in the application. A key metric for Table Configuration is the number of fields configured in each application table.
Tailoring by using Encapsulated User Functions may be broken into five categories: external input types, external output types, logical internal types, external interface types and external inquiry types.
All of these second level tailoring customization techniques utilize software “open points” built into the applications framework. Software open points, popularly known as application programming interfaces (APIs), permit changing a software system by exposing internal components in an explicit and malleable way for deployment of new or missing functions to users. Properly using these open points to extend or enhance packaged software’s built-in behaviors adds the requirement for proper development and test environments and a higher degree of skill usually provided by the system integrator.
The degree to which second level customizations can easily be maintained over the application’s evolvable lifespan largely depends on the resiliency of the exposed APIs. In mature packaged software, APIs tend to be relentlessly maintained, making tailored customizations predictable during future software package/customization deployment cycles. A metric measuring the number and frequency of change to established APIs will provide insight into the stability and resiliency of the applications open points.
Core Code Changes and New Custom Software Modules
The third level of customization involves Core Code Changes and New Custom Software Module additions to packaged software. This level of customization brings with it the complexities of true software development, integration and testing during each revision/upgrade cycle. Customizations at this level frequently undermine the confidence in the packaged software’s integrity and the overall application’s evolvability.
The number and frequency of these third level changes should be carefully tracked. A high number of these changes indicates that the packaged software may not be suitable for an application. Additionally, adoption effort is an important metric with this level of customization since there is no baseline training or documentation upon which to rely.
A healthy evolvability metric for an application with third level customizations would be a downward trend in the number of third level customizations needed as newly available package software modules become available in future package/customization deployment cycles.
Conclusion
Evolvability should be an intrinsic metric in an application’s design, initial implementation and maintenance since healthy enterprise applications evolve over time. Each customization to packaged software can be categorized and measured. Properly implemented first and second level customizations provide an acceptable level of evolvability for an application. Third level customizations, while initially necessary, typically impact evolvability and should trend downward over the lifespan of a project while first and second level customization may trend upward to accommodate the configuration and tailoring of these new replacement modules.
–Charles Angione
