More on COTS vs custom software

Lausanne Flon Copyright 2002-2008 A. Barake

It has been my experience that integration and associated maintenance of commercial off-the-shelf software (COTS) is an expensive and difficult process due to a few factors:

• The "normal" upgrade cycle for vendors is often strategic and is driven by internal rather than external compatibility – upgrades also tend to break interfaces regardless of intent, it just does not help that the intent to play well with others is often at odds with large company policies (i.e. marketing strategy), especially when their suite of products covers many functional domains
• Integration requires glue, and glue can either be COTS or home grown. For COTS, see above objection, and add cost. Home grown defeats the argument of using COTS in the first place Q.E.D.

Now, if we look at home-grown software, we have a few things to consider:

• Maintenance is dependent on knowledge, but unless you are writing in APL  (and even then), the pool of developers with expertise usually exists; reading code and fixing it is what they are hired for and have some training in.
• Developers in my experience much prefer to work on code where the source is available than integrate stuff using configuration and proprietary tools where the options are limited and the dependency on documentation and vendor support is limiting
• Code is now pretty much commoditized except in specialized areas (telephony switching, military stuff, embedded stuff) and even then… there are only a handful of approaches that people use to write and maintain code and most good developers can immerse themselves in a code base within days of weeks and make it their own.
• Renewal is key, and owning a system and renewing it by adding features is easier with home grown that has few integration points with COTS than with disparate COTS on different version cycles with glue in between.

The standards efforts are a sort of socialist (Stalinist really) approach to trying to control the ecological process described above, but is thwarted by vendor power struggles and the usual embrace and extend strategies, coupled with purchasing power in the hands of non-detail oriented people (i.e. not tecchies).

UNIX and other open system approaches have and are trying to tackle the problem through factoring out of common functional requirements into modular technical modules and protocols, and have had some success in advancing the state of the art – the Internet and its associated protocols and services are a direct result. The OSI stack is a manifestation of this approach and has become a pattern of understanding outside that world.

One approach is to layer the commercial stuff and isolate it from other commercial stuff through standard gateway mechanisms, off the shelf if you like, and these include queues, UNIX gateways and subsystems that use HTTP, SMTP and LDAP, xDBC as well as XML protocols where practical and where translation mechanisms are easy to obtain (message brokers, AJAX, browsers, SAML…) At another level we should be writing our own application code to use these underlying systems and the glue should be at the application level – i.e. SOA – services are COTS with standardized interfaces, applications are not.