COTS or CRHMS? Understanding Full Stack of a Core Enterprise Software.

Commercial Off-the-shelf Software, or COTS, seems as, although expensive, a way to avoid risks and challenges associated with development of core enterprise software. At the same time it appears that some of the most bizarre IT failures, those that make it into newspapers due to ridiculous losses, are related to COTS.

The secret is, those were CRHMS rather than COTS solutions. However as the term CRHMS hasn't been known until this article, they were seen as COTS and unjustifiably trusted as such. 

CRHMS (pronounced /?kre?ms/) stands for Commercial Rather Heavily Modified System. As far as the reputation goes, CRHMS should be at the top of your list of anti-patterns - massive costs, costs blow-outs, ridiculously expensive support and therefore a real obstacle to business agility. There is no need to suffer all that, as CRHMS can be easily distinguished from COTS if you understand the full stack of a software system. 

When people hear "full stack" they usually think about DBMS, an Application Server, User Interface and other technical details - however those do not make a successful product. Before you write the first line of code in a system that should pay salaries or social benefits, deliver cargo to retailers, collect custom duties or bus fare, you secure some business expertise. 

Such business expertise makes the top layer of every core enterprise application. UI, internal workflows, database schema - all flows from the understanding of the business, which become embedded in every part of the solution.

If you agree with that vision, you are in the COTS territory. When the way the system does things is different from your existing practices, you should be prepared to change your practices. If you do that because you trust the vendor's expertise that is followed without modifications by many similar enterprises, you are fine. If you agree to change your practices grudgingly, for the sake of saving customisation costs, you are also fine, at least from IT perspective. However if your requirements are quite different and you need to engage several of several dozen of Business Analysts to capture your requirements and pass them to the vendor, you are in the CRHMS territory.

It is no secret that 90% of testing is done by end-users in production. It doesn't matter if the salesperson swears that their COTS solution can do what you need it to do. If it is off the beaten track, it hasn't been tested in such configuration. Nobody knows how well it would work, or whether it would work at all.

You are effectively buying developers of unknown expertise with massive libraries they are not necessarily familiar with. The rates will be per COTS customisation standards, the documentation of the solution internals would be per COTS customisation standards, the sophistication of your development processes would be by COTS customisation standards, yet the volume of work would be comparable with full-on development.

It has been drilled into us that the customer should talk, and the vendor should listen. That is what creates CRHMS - customer says what they need, and a sales person promises to deliver that. In reality it should be the other way around - the vendor should describe what kind of business can be naturally supported by their platform, and the customer should decide whether they want to be that kind of business. If "yes", take it off-the shelf, install and use. 

And "customer" in that case should include the stakeholders. If you are implementing a payroll system in an enterprise with unionised workforce, you cannot implement any change to the existing arrangement without the Unions. If you are implementing a welfare system, there would be political implications of following the practices assumed by a COTS solution, so their should be a channel set up from the beginning to suggest such changes.

Or you can run a CRHMS implementation project. We all know how well they turn out.