Just What, Precisely, is COTS?
Understanding different interpretations can help in evaluating options
COTS, it sounds like such a simple acronym, but what does it really mean? While there are indeed a number of definitions in the context of laboratory informatics, there is a common consensus that COTS stands for commercial off-the-shelf and, generally, is used in reference to software. The specific type of software is irrelevant, it applies whether you are talking about operating systems, word processors, laboratory information management systems (LIMS), laboratory information systems (LIS), electronic laboratory notebooks (ELN), scientific data management systems (SDMS), or any of the other software tools we might use.
Unfortunately, beyond this simple definition, things get rather murky, and we start to lose consensus. Don’t believe me? Check out the technical paper “Definition and Classification of COTS: a proposal.”1 The popular concept, at least with users, is that COTS refers to software that is used as-is. However, there is frequently significant room for interpretation, and this article explores a number of varying definitions of the term.
If you first decide on the definition you want to use for COTS, you can then use that for comparison with the way that others are using the term. For example, while you will find plenty of people willing to argue the merits of building versus buying a laboratory informatics system, most will at least concede that building their own system from scratch does not constitute a COTS product. However, you still have the ongoing debate regarding configurable versus customizable systems. If you look carefully, though, you may soon discover that the build-versus-buy dichotomy is not as clear as you thought either.
|Moving in the direction of the “Flexibility” arrow toward customizable, the flexibility of the system increases, i.e.) a customizable system is more flexible than a configurable system. Because you are altering the program code, you can make a customizable system do anything you want, where you can only select the options in a configurable system that the programmers gave you. Ideally, it will do everything you need but, in principle, the customizable system can give you more options.|
Over the years, I’ve seen instances where people have abandoned home-built systems for commercial ones, in part so that they would not have to maintain the internal development expertise to support them, and so that they could readily upgrade to newer technology. However, they then, between their own IT group and the vendor, customized the system so much that even the vendor couldn’t figure out how to upgrade it to the newest version of their software. This left them in the unenviable position of having the worst of both worlds. They had to maintain the customizations, but they did not have access to the systems core engine to alter its functionality, whether to correct a bug or to enhance its functionality, nor did they have a clean upgrade path to upgraded versions.
The take-home lesson being that, just because a system might be sold as COTS software, you need to take a close look at how it is actually engineered and be very careful how you customize it to ensure you maintain your upgrade path. If you don’t, you might, in effect, end up with a home-built system for which you are either responsible or will pay considerably more in consulting fees to have the original vendor maintain.
Snafus like this are one reason that I tend to prefer configurable systems over customizable ones. Yes, in principle a configurable system is more restrictive in functionality than a customizable one. Emotionally, that can be a weighty factor. However, when assessing systems, it is more important to evaluate options based on what you need to do and are likely to do, as opposed to all of the possible things you could do. I’ve seen plenty of examples where a system has been customized a particular way at a customer’s request and, unfortunately, they only later realized all of the new problems their customization created.
Another factor to consider here, which is frequently overlooked even by professionals who should know better, is that purchasing a new system provides you with both the excuse to reevaluate your current processes and the opportunity to re-engineer them to eliminate steps that are either no longer needed or, occasionally, were never needed to begin with (part of the “we’ve always done it that way, I don’t know why” syndrome). With the flexibility found in configurable systems today, if it can’t be configured to handle your process, perhaps that should be taken as a hint that it is worth taking a closer look at your process and why you are doing it that way.
To be fair though, with the diversity of businesses and organizations out there, I’m sure that valid instances can be found where they must do something that an unmodified off-the-shelf package can’t handle. So, what then? Is your only choice to go with a customizable system? Depending on what your needs are, it is possible that going with a customizable COTS package, assuming that the description isn’t a complete oxymoron, might be your most expedient option, but it is no longer the only one.
Application program interfaces
As representatives from several LIMS companies pointed out in a question and answer session that appeared in Scientific Computing earlier this year,2 there is now a third option which provides the benefits of both customizable and configurable systems. These are basically configurable systems that add one or more application program interfaces (API),3 allowing them to communicate with external programs. Like a moderate in politics, this approach provides them with many more options than groups that have been polarized to the extreme right or left. Any special functions, whether it is to handle data collection, display or processing, can then communicate to the main system through these interfaces. As long as the interfaces are not altered when migrating to a new version of the system (which is likely a contract issue), you can continue to use your custom code with the upgraded system, eliminating many of the classic upgrade problems.
There are many options regarding the approach taken for the API, and there is no reason that a specific system can’t support a number of them. With regard to Web-based systems, the chosen technology might be for a SOAP or RESTful interface.4 For systems employing more of a classic client-server architecture, you might use more of a component object model (COM) interface.5 However, when venturing into this area, there are ancillary issues you must consider as well. First, you must make sure you get past all of the hand waving and obtain a clear understanding of what interfaces are available and what their capabilities are. Second, enabling and using these interfaces opens you to a variety of data integrity and validation issues that you must carefully address.
Adding functionality by taking advantage of a systems API means that you are now relying on code outside of the vendor’s system, so they have no control over what it can do. If this code opens a backdoor into the system or its functionality is not carefully designed, it can play havoc with the data integrity of your system and, at the very least, can bring the wrath of multiple regulatory agencies down upon you. In addition, it opens your system to a range of attacks. Since an API does not intrinsically know who’s talking to it, it must be carefully designed to authenticate any communication handshakes, otherwise you’ve broken the audit trail chain and can no longer certify who did what in the system. This handshake validation is a critical API feature you need to check on when making a purchasing selection.
Dealing with these issues can result in significantly more stringent selection, development and validation requirements than with a straight configurable system, or even more than some customizable systems. However, when dealt with responsibly, the addition of a flexible API to a COTS application can significantly expand its flexibility while still allowing for straightforward system validation and upgrading.
In summary, these systems can be differentiated in terms of cost of validation. Non-COTS, custom-built systems, whether coded internally or externally, generally have the highest validation cost. However, some customizable systems, even though sold as COTS, can be so extensively customized that they are indistinguishable in terms of the validation cost. Configurable systems generally have the lowest validation cost, but can potentially be too confining in terms of functionality. Providing a middle ground are configurable systems that allow for the addition of custom functionality via a flexible API, without modification of their base code, where only the custom code outside the API requires extensive validation.
1. Morisio, M. & Torchiano, M. “Definition and classification of COTS: a proposal.” COTS-Based Software Systems First International Conference, ICCBSS 2002 Orlando, FL, USA, February 4–6, 2002 Proceedings 2255/2002, 165-175 (2002).
2. Joyce, J. et al. “Industry Insights: Examining the Risks, Benefits and Trade-offs of Today’s LIMS.” Scientific Computing, 15-23 Jan./Feb. 2010.
3. Application programming interface. en.wikipedia.org/wiki/Application_programming_interface
4. Neal, M. “Enabling Remote Access.” Scientific Computing, 14-15, Sept./Oct. 2010.
5. Component Object Model. en.wikipedia.org/wiki/Component_Object_Model
John Joyce is a laboratory informatics specialist based in Richmond, VA. He may be reached at editor@ScientificComputing.com.