Custom automation vs. commercial-off-the-shelf, or both?
Misconceptions of custom
These industry events have led to today’s common-focused approach. However, it is not well understood why “common” is different than “custom” or even what those terms mean. Misconceptions about COTS and custom follow.
FALSE: COTS means not custom. This is probably one of the biggest fallacies of system integration. Customers believe that by purchasing a COTS product, there is no custom work that needs to be performed. This is rarely true, even for simple projects.
There are no COTS products that work purely “out of the box” without any customization. Vendors often use the word “configure” instead of “customize” to alleviate the fear associated with customization. Regardless, this is still a custom activity performed specifically for a customer. In simple cases, the customization work may include modifying product parameters. For more complex uses, the process is typically much more elaborate. This may involve writing scripts for supervisory control and data acquisition software, developing logic for a programmable logic controller, or writing custom communication components to bridge systems.
The customization of COTS products is clearly required based on the offerings of the product vendors. Almost every major COTS product vendor maintains a system integration group whose sole purpose is to customize the product to meet integration requirements.
FALSE: COTS means standard and supportable. Almost all customers can recall an instance where a motivated employee produced “custom” software that provided immense value, but could not be maintained or upgraded without the original programmer. This leads to the inevitable operational collapse when the programmer is unavailable and cannot be reached to support the software.
Fear of this type of situation often drives customers to COTS products with the belief that the product itself will provide standardization and supportability. Unfortunately, this is not true; COTS products are highly customizable and can lead to the same issue described.
A simple example of this is Microsoft Word—one of the most widely used COTS products. Without input from a user, it does nothing. A user must customize its output to produce any document of value. Examples 1 and 2 are the same text.
The first example illustrates a standard format for documentation. The second shows a document written without standards. What portion of Word prohibits a user from producing either of these documents? Absolutely none. This shows that a COTS product like Microsoft Word cannot actually provide standardization or supportability.
In fact, standardization and supportability are much more a function of processes and procedures rather than the product on which the development is performed. The use of a standard template, specified guideline document training, and a review process actually produces standard and supportable output—not the COTS product itself.
An organization needs the proper processes and procedures to support any system integration effort. This applies to custom developed software applications and COTS products equally.
FALSE: Custom means proprietary. The only word that customers fear more than the C-word is the P-word: proprietary. And “custom” and “proprietary” are often assumed to be inextricably linked. In the past, this may have been true because the ability to provide custom solutions using open and standard communication was difficult. But since the adoption of open protocols and OPC, it is rare to find a custom solution that is built on a proprietary foundation.
The key is to ensure nonproprietary products are the same for custom software and for COTS products. And customers must make certain that this is part of their requirements, whether procuring development or purchasing a product.
Proprietary systems are feared primarily because a customer can be locked into a specific product without the ability to switch to a competitor. In the past, this was a technology-related constraint. Today, contracts play a crucial role in restricting a customer’s capability to change platforms or augment a system. In most cases, it is more difficult to understand these aspects of a COTS product than for custom-built solutions. A customer must evaluate licensing and support contracts to ensure that a COTS product does not prohibit the extension of the system or platform.
On the last page, see how fear influences decisions and how to leverage COTS and custom