Nothing inherently wrong with COTS provided the decision is fully informed. It has some inherent limitations:
1. A COTS product was developed to meet some else's requirement, and you may never get to see the detailed requirement it was developed to meet.
2. You don't own the design of a COTS product, so if they modify it you have to accept the changes if you want any more spares
3. A COTS product was developed to align with someone else's operating and support procedures - if you do bay maintenance and they didn't you either have to adopt their procedures or pay for the extra development of bay test equipment, procedures, spares etc
4. If you choose a COTS product you must take it as-is. If it falls short of your requirement you just accept the shortfall because it's a mature product at the wrong end of the product lifecycle and any changes will be hideously expensive, especially once you've requalified the changes. "Modified COTS" is also known as "Suicide Acquisition"
5. A COTS product is already fully mature at the start of *your* design/integration process, so it will start to see obsolescence problems sooner than a developmental item.
6. A COTS product will require a *custom* integration, and all the integration will ahve to be done on your side of the interface (hardware AND software)
7. Always remember that choosing COTS is a design solution - not a system requirement. It's depressing how many times a project starts saying "we need to use a COTS solution" when they cannot possibly know that at that stage of the project.
If all the above issues and risks can be identified, quantified and managed then COTS approach may well be a viable solution.
PDR