Custom automation vs. commercial-off-the-shelf, or both?

08/21/2013


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.

Microsoft Word is one of the most widely used commercial off the shelf COTS products, yet a user must customize its output to produce any document of value. Examples 1 and 2 are the same text, though they differ greatly. Example 1 uses a standard template

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.

Example 2 is a Microsoft Word document [commercial-off-the-shelf (COTS) software] that shows the need for a standard template, specified guideline document training, and a review process to produce standard and supportable output. Courtesy: SAIC

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



No comments
Consulting-Specifying Engineer's Product of the Year (POY) contest is the premier award for new products in the HVAC, fire, electrical, and...
Consulting-Specifying Engineer magazine is dedicated to encouraging and recognizing the most talented young individuals...
The MEP Giants program lists the top mechanical, electrical, plumbing, and fire protection engineering firms in the United States.
2014 Product of the Year finalists: Vote now; Boiler systems; Indirect cooling; Integrating lighting, HVAC
High-performance buildings; Building envelope and integration; Electrical, HVAC system integration; Smoke control systems; Using BAS for M&V
Pressure piping systems: Designing with ASME; Lab ventilation; Lighting controls; Reduce energy use with VFDs
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.

Protecting standby generators for mission critical facilities; Selecting energy-efficient transformers; Integrating power monitoring systems; Mitigating harmonics in electrical systems
Commissioning electrical systems in mission critical facilities; Anticipating the Smart Grid; Mitigating arc flash hazards in medium-voltage switchgear; Comparing generator sizing software
Integrating BAS, electrical systems; Electrical system flexibility; Hospital electrical distribution; Electrical system grounding
As brand protection manager for Eaton’s Electrical Sector, Tom Grace oversees counterfeit awareness...
Amara Rozgus is chief editor and content manager of Consulting-Specifier Engineer magazine.
IEEE power industry experts bring their combined experience in the electrical power industry...
Michael Heinsdorf, P.E., LEED AP, CDT is an Engineering Specification Writer at ARCOM MasterSpec.