Custom automation vs. commercial-off-the-shelf, or both?
How to automate is as important as when. Custom is not a four-letter word. Weigh the benefits of COTS and a custom solution, rather than restricting an automation project view to a COTS or custom solution. Don’t assume that custom solutions are bad. See graphics that illustrate.
Over the past decade, the system integration business has been pushed toward a “common everything” approach. Customers are searching for a one-size-fits-all solution that is easy: easy to buy, install, and maintain. Common-off-the-shelf or commercial-off-the-shelf (COTS) products have perpetuated the idea of one solution to meet all needs. COTS offers a one-line item purchase that promises to easily meet all the features a customer wants.
Unfortunately, this promise cannot be fulfilled by a “common everything” approach or by COTS alone. Except for simple system integration projects, this method is often not feasible and can lead to poor decision making for the sake of commonality. Typically, lack of understanding surrounding a successful system integration project is what leads to these decisions.
As a result, the word “custom” has developed a bad reputation in the industry. Customers steer away from anything custom for a variety of reasons—many of which are unfounded. This article examines these reasons, attempts to show that all system integration projects require some level of customization, and that custom products and efforts are a necessary option for success.
How did we get here?
Looking at the recent history of industrial automation, the current commonality trend can be viewed as a response to past market conditions. The 1980s and 1990s were filled with proprietary software and hardware that forced customers to make decisions with no recourse. Customers had to choose a particular platform and stick with it, because there was no interoperability between competitors. If the feature you wanted was not provided on the product line you chose, you were out of luck. And it was too expensive to change to a competitor’s product because the foundational infrastructure was already in place and was not compatible with a different platform.
These conditions led to a backlash from customers that changed how the industry would go to market. Customers required interoperability among competitors’ products. Product vendors established and adopted common, open protocols to support this effort. In the late 1990s, the development of OPC (object linking and embedding for process control) created a relatively inexpensive option to allow communication between or among proprietary systems.
Customers could now choose the right product for the job and be assured that the new product could communicate with the rest of the infrastructure as well as any prior investments. Unfortunately, this openness led to unwanted and unanticipated side effects.
First, customers could choose any product that met their needs. So they did. Now one facility may have a dozen or more product platforms that required support using different tools. This placed an unusually high burden on operations and maintenance departments.
The most successful system integration projects use both COTS and custom approaches to best fit the customer’s immediate needs and future requirements.
Second, anyone could write their own software to communicate with any process control product. So they did. Customers began to develop software internally or purchase software from unqualified developers that could not be supported or maintained.
Around 2005, the pendulum began to swing back in the other direction. Customers corrected these failings by staying with one platform that could be maintained by internal staff and only purchasing COTS products that worked on that platform. Customers began to do this regardless of whether the products could meet functional needs of the related applications. It was more important to maintain the “common everything” vision for sustainability.
On the next page, learn more about "custom" misconceptions and see two graphic examples
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
Fear can lead to poor decisions
These fallacies can drive a customer to make poor business decisions based on the fear of “custom” alone and allows customers to be lured into the promises made by COTS products. COTS-based projects fail for two primary reasons. First, the customer either does not understand the COTS product limitations or is willing to accept these limitations to adhere to the “common everything” vision. Customers often see success on their initial, relatively small deployment, but find it challenging to extend the system to other functional areas or facilities that have different needs.
A system integrator should assess the organization’s needs and provide the best solution based on those requirements, not based on what products they sell.
Second, the customer does not adequately plan for the maintenance and support required for the COTS product. Again, this issue is not readily visible on the first deployment. However, as the system grows and customized portions of the COTS product require modification and configuration management, customers begin to see issues with version control and support.
Leverage COTS and custom
The most successful system integration projects use both COTS and custom approaches to best fit the customer’s immediate needs and future requirements. For successful system integration, customers and their consultants must:
- Understand COTS and custom as viable and necessary options. Do not limit system integration projects to COTS without understanding the organization’s immediate and future needs. Be sure to recognize how any COTS deployment will be customized for these needs and the support requirements associated with all facets of the product. If the needs are unique, as most are, evaluate the merits of a custom solution.
- Decide what should be common and, conversely, what should be customizable. Every system should have a set of features that everyone gets and a set of expectations that every deployment should adhere to. Define these up front based on business requirements. Then, decide what features can be different between functional areas and facilities. Allow the standard features to support “custom” features that are needed in different areas.
- Find a technical advocate. When looking for a system integrator to assist, deploy, and program the solution, be sure to find a technical advocate and not a product vendor. A system integrator should assess the organization’s needs and provide the best solution based on those requirements, not based on what products they sell.
By seeing “custom” as a viable option instead of a feared word, customers can make better system integration decisions. Understanding custom as a tool and necessary part of a project, COTS or otherwise, a customer can weigh the benefits of a COTS and custom solution, rather than restricting their view to a COTS or custom solution.
– Corey A. Stefanczak is senior system architect at Leidos Engineering. His primary focus is helping clients unify automation infrastructure and information systems within large, distributed environments. Stefanczak uses 16 years of integration experience to help clients succeed by finding the right balance between COTS components and custom development. Edited by Mark T. Hoske, content manager CFE Media, Control Engineering, Plant Engineering, and Consulting-Specifying Engineer, email@example.com.
- Customization may be dismissed out of hand, when it can be the best solution.
- Just because it is commercial off the shelf (COTS) doesn’t mean it can be used without custom configuration.
- Do not limit system integration projects to COTS without understanding the organization’s immediate and future needs.
- If some customization is required to get 20% more output over the lifecycle of an automation system, wouldn’t that be worth the extra investment?