Executive Summary

Today almost every business of every size will be using a commercial off-the-shelf (COTS) product in one of their business processes. But Cots products are not necessarily appropriate for every system.

In this blog we provide some information to help guide decisions about when commercial off-the-shelf (COTS) products are an appropriate solution—and when they are not. When purchasing a COTS based system purchasers have high expectation in terms of value and the effort required to successfully deliver that value. This makes it difficult to make the necessary decisions.

Here we describe seven “rules of thumb”— thought points to challenge our readers when considering solution options and whether a commercial off-the-shelf software product(COTS) might be suitable. With each “rule” we provide a brief summary to help you in following the Rule.

These seven rules are:

• Rule 1: Find the ways in which COTS products can help you.
• Rule 2: Determine the regulatory, statutory, and policy constraints on your system to decide whether they make the use of COTS products infeasible.
• Rule 3: Establish whether your system is subject to extreme performance requirements (e.g., security, safety, real-time) and whether they exceed the capabilities of the COTS products.
• Rule 4: Decide whether the requirements and users’ business processes are flexible enough to accommodate COTS products.
• Rule 5: Determine your ability to leverage the marketplace.
• Rule 6: If you are developing your COTS-based system by evolving an existing architecture, examine that architecture for its resiliency and its ability to keep on evolving.
• Rule 7: Generate a gross cost/benefit analysis.

While these seven “rules” are a great start they do not provide the whole answer, considering partnerships, the drive to standardisation with suppliers/customers can add additional dynamics to the thought process.

Myths of using commercial off-the-shelf software product (COTS)

• COTS products will save money.
  Don’t just think about the cost of the software or the terms of payment (perhaps on a monthly basis), consider your teams effort in configuring, loading data and using the system on a daily basis. If the product enforces a strict process that adds extra time to every activity then those savings could soon vanish.
• Because it’s COTS, we don’t have to test it.
  Ensuring the software meets your businesses needs, you understand how it works and more importantly you trust any output (reports, client emails etc) is critical prior to launching. Whether a system for generating invoices through to managing your inventory – you need to be sure the system does what it say’s on the tin and you are happy with it.
• Because it’s COTS, we don’t need to worry about any architecture or engineering.
  This isn’t always the case – some COTS products are installed on site and others are cloud based. Either way you need to consider the criticality to your business of accessing these solutions – what if they aren’t available for an hour, a day or a week? All too often COTS products don’t work in isolation and required integration (either manual or automated) to other systems – what if those change?
• Because it’s COTS, there will be nothing to maintain.
  You are putting your trust into the 3rd party to maintain the solution as you would need to operate your business, what if there are a lot of customers and the change request process is slow (or non-existent due to other customers not seeing the same value in the change you do). Ultimately the COTS system will rely on your company’s data – whether master data telling the system how to operate through to transactional data which is about your services/products, customers, suppliers etc – ensuring you can access your data anytime should a supplier fail is worth thinking about.

Rule 1: Find the ways in which COTS products can help you.

The first step is to find all the reasons that a COTS-based systems approach is right for your system – here we are looking for cases where the ready made solution fit’s your organisation. The easiest way to map a commercial off-the-shelf product(COTS) is to find those small/repetitive tasks which can easily be replaced by a COTS product. If a product already exists and is a perfect match there will be little reason to recreate. For example few organizations would consider developing their own operating systems, databases, or word processing software.

Allowing Cots Products to perform the functions they do best enables you to concentrate on what you know best—the features and functionality that make your system unique and cannot be bought in the commercial market (hopefully differentiating yourself from your competitors and adding business value).

Another reason to use COTS products might be that the technology needed is too advanced and specialized for the organization to undertake development. The organization may not have the expertise to reinvent, much less improve upon, an existing product that has the advantage of being user-tested. Even if you had the expertise to reinvent existing technologies, you probably don’t have the time.

Rule 2: Determine the regulatory, statutory, and policy constraints on your system to decide whether they make the use of COTS products infeasible.

Where your business has to confirm to industry or legal frameworks, practices, data formats might determine whether to use a COTS product. A good example is the need in the UK to Make Tax Digital – here a pre-described format is required to be sent to the government for various filings. Making use of a COTS product to manage the submission would be a sensible approach depending on the volume of data and benefits of the COTS system – as such there would be a tipping point where the value on integrating into custom software would outweigh the COTS benefits.

Rule 3: Establish whether your system is subject to extreme performance requirements (e.g., security, safety, real-time) and whether they exceed the capabilities of the COTS products.

When choosing a COTS product you are agreeing to the performance and stability metrics provided by the supplier. For non-critical uses the past performance can be used as an indicator, does the software work quickly enough, can it handle sufficient users, what are the Service Level Agreements for when there is a critical issue? If you have a business critical solution then perhaps a COTS product might not be suitable – having a specific solution with support tailored for your business ensures you not only have insurable support but well thought through recovery processes.

Rule 4: Decide whether the requirements and users’ business processes are flexible enough to accommodate COTS products.

Benefits of using a COTS product are that the business processes are usually fixed with little flexibility, this is great if you don’t have the business experience to suggest anything different and want to ensure your team remain on track. Should your business need the flexibility to differentiate from your competitors (otherwise where is your differentiator?) with regards to the process then a COTS product might not be suitable. After all changing your business working practices to fit into a COTS product might not be the best approach – this would demand a high level of change management to run alongside the implementation project and potentially introduce business process performance issues/additional costs.

Rule 5: Determine your ability to leverage the marketplace.

Here you need to understand what is available and at what price. Potentially combining COTS products to deliver the functions you need or combining COTS with bespoke software to deliver the best of both worlds. A trusted IT adviser can often advise on what options are available, how those can be combined and look at total cost of ownership (TCO).

Rule 6: If you are developing your COTS-based system by evolving an existing architecture, examine that architecture for its resiliency and its ability to keep on evolving.

Here you need to consider how well the COTS product will replace an existing process, system or integrate into existing systems/processes. Does the COTS product offer integration points that match your existing software estate, does the COTS product introduce a weak link into your software landscape (or conversely introduces a stronger element)? The key is to consider the business and whether the COTS product fits into the overall view.

Rule 7: Generate a gross cost/benefit analysis.

Back to the numbers – here you look at all of the costs related to the COTS product and whether there are benefits in implementing. Costs should include but not be limited to:
• Initial software cost and ongoing running costs
• Internal project team costs – time spent choosing, configuring, training and managing the ongoing contract (consider retraining as new versions are released on a regular basis)
• Change management costs – costs to load data, validate, communicate the new system to users, update support desks etc
• Exit costs – costs to obtain your data at the end of the contract

To COTS or not to COTS

We hope the above has given you a small insight into some of the considerations when weighing up whether to choose a COTS product, bespoke software or hybrid. Matter of Software act as trusted advisers to our clients ensuring that they receive the best solution to meet their needs, our team can configure COTS products, integrate to them or deliver a hybrid solution to suit.
Why not start today with a free, no-obligation discussion to see if you are getting the best value from the software in your organisation – contact us.

The post 7 Rules when choosing a commercial off-the-shelf software product(COTS) appeared first on Matter of Software.