Let’s recall for a moment, after we purchased and Installed Microsoft Office, how many of us will consider customise the Microsoft Word, or Powerpoint application to follow our way of working? Or imagine that every user tries to customize the Microsoft Office interface and make it looks unique by developing new add-in using self-invented API or object library.
I can hear you screaming out loud. “Noooo, that’s ridiculous!”
“Why do you want to do that?” You continue asking.
“You can make use of Microsoft word and Microsoft Powerpoint out of the box after installation, why bother to change it? Besides, if you customized it, my life will turn upside down if all my colleagues’ Microsoft application looks different from each other. Worst when Microsoft rollout new release (which they will), the self invented add-in will become unsupported or I wouldn’t able to upgrade to the latest version and enjoying all the new features of Microsoft because too much add-in were customized.” I can hear you continue to lecture me.
Ok. ok. I hear you loud and clear and it does makes a lot of sense. But to my amazement, we are doing exactly the opposite when comes to implementing GIS project. We still tend to customize every application to make it only uniquely ours, regardless the risk that one day the developer that developed the application might no longer with us. Or the tendency to reinvent the wheel by committing precious resources to do R&D or continue maintaining the aging apps.
We have too many experiences that heavily customized GIS systems cannot be easily scaled or extended because there is inadequate documentation to perform transfer of technology, or the technology is no longer supported; or the resources that has the specific programming skill sets are no longer available.
The following excerpts are extracted from a great whitepaper published by Esri titled “Taking a COTS-based approach to implementing enterprise GIS“. I encourage you to download and read the full text.
For those of you that would like to read only the executive summary of the white paper, I have extracted the following short paragraph for your reading pleasure.
The fundamental premise of a COTS approach is to exploit all the power and functionality the commercial software has to offer, minimizing custom development.
Implementing the COTS approach requires fresh thinking, leadership, and agility. This can be challenging in environments where there is a history of procurements to build custom systems. One key difference is that the COTS approach is predicated on a focus on business goals instead of a list of detailed feature functions. This allows the organization to select the COTS solution that best meets business goals and to implement the COTS solution rapidly with the grain for best results.
This approach asks users to consider new business processes. COTS solutions provide new workflow capabilities based on industry best practices, which are often better than legacy business processes. Traditional systems procurements often fall into the trap of re-creating old workflows out of new software, usually because people and organizations resist change. It takes leadership, communication, and follow-through to overcome the tendency to stick with the familiar (and usually less efficient) legacy workflows.
An additional trap that users must avoid is the temptation to customize rather than configure. Even when a system has been proclaimed a COTS implementation, the best intentions of many people often push systems toward customization. The trade-offs of custom development must be kept in mind during the decision-making process to avoid moving a COTS-based system into a custom or component-based implementation. Many heavily customized COTS systems cannot be easily scaled or extended because there is inadequate design documentation; the technology on which it is based is no longer supported; resources with needed skill sets are no longer available; or the COTS, as opposed to custom, modules are not clearly delineated, creating dependencies between components that minimize the potential for reuse.