Wednesday, October 25, 2006

How to choose a Commercial Off The Shelf (COTS) Product

Here are some guidelines in choosing a product for integration in an application or product or selecting a product for an independent implementation. The following key factors must be considered when evaluating such Commercial Off The Shelf (COTS) products in the order in which it has been listed (the most important considerations are higher up on the list):

1 Fit-for-purpose

This evaluation is to ensure fitness for purpose. Make a list of all the must-have requirements and nice-to-have requirements in a table format and check the product for coverage of all these requirements and features. Some of the common features that all products must have include a good management instrumentation support, good alerting facilities, good health monitoring support etc.

2 Technology Risks

Carefully evaluate the product for various technology risks. Some of these could be in the following areas:
- Product built in an older technology – Check whether the product has been built in an older/obsolete technology.
- Product built in the latest technology – Check whether the product has been built in the very latest technology. Technology typically evolves through a couple of versions before stabilizing. Consider for instance the advances made by Java from JDK 1.0 to JDK 1.5. If a company had built a product in JDK 1.0 when it was just released, today the product would be missing some of the enhancements and advances made by the latest version of the JDK.
- Product built in an obscure technology – Check whether the product has been build using an obscure technology such as PERL where resources are hard to find.
- Lack of standards-based support – This is related to the Integration section mentioned earlier. A product with minimal or no standards-based API support is a big risk.

3 Scalability and Performance

Evaluate the product for scalability considerations (how many users, how many object calls etc. can the product support? Also, how well does the product perform when additional load is applied on it in terms of no. of users, amount of data to be processed etc.

4 Product Strength

This parameter is to evaluate how well the product is doing in general. A product that isn’t doing well is probably not a good candidate for evaluation or purchase. Some of the ways in which this can be evaluated are:
- No. of implementations done – This indicates the various scenarios that the product would have factored in in its feature list and hence would be resilient to most feature and requirement requests
- No. of good reviews received – This can be gauged by the no. of independent industry journals, whitepapers, websites, blogs etc where the product has received a favorable rating or review.
- No. of forums available – Check the no. of forums available for discussing issues with the product. Few or none is not a good indication.
- Quality of documentation – Read through the product data sheets, technical documentation, user guides, deployment guides to determine the quality of documentation.

5 Company Strength

This parameter is to evaluate the strength of the company making the product. Some of the ways in which this parameter can be evaluated are:

- No. of years in business –This indicates the stability of the company and the success of the product. It is important that a product being purchased have a financially sound pedigree to ensure adequate support and new versions that will be required as and when there are technology-advances in the area in which the product was built.
- Worldwide presence – This indicates the financial health of the company and availability of a wide support network. It also indicates location sensitiveness built in to the product which is very important for language/culture support.
- Clientele list – A clientele list that has quite a few Fortune 1000 companies will indicate that that product is well adopted and accepted in the community. Since larger companies typically have a very good due diligence process, this is a good indication of the product’s viability. Especially, see if there is a client that is mentioned in a similar industry. For instance, if the product is being evaluated for a bank, look for other competitor banks in the clientele list.
- Evaluation Support – This is one of the most important factors for choosing a product. When evaluating a product, verify the responsiveness, appropriateness of answers, willingness to help etc. from the support team of the product to get a good indication of how support will be post purchase.

6 Product Costs

This parameter is to evaluate how much will the product cost - obvious and hidden. Some of the ways in which this can be evaluated are:
- License Costs – Carefully evaluate the license costs for the product. Is it per-CPU, per-client access, per-machine etc. This would be the biggest contributor to the overall cost of the product.
- Implementation Costs – Ask about how much it would cost for implementation of the product. A lot of products do require the product company’s personnel to perform the implementation and their costs would be in addition to the license costs.
- Training Costs – Most proprietary products require extensive training for using, developing and administration. Check what the training costs are for these and how many people would require this training.
- Hardware Costs – Ask about what kind of hardware is required to run the product and find the cost of the hardware.

7 Integration Considerations

Almost every product will require to be integrated with other software products or applications. A product being purchased off-the-shelf must be evaluated for integration issues. Some of the ways in which this can be evaluated are:
- Integration Interfaces available – Ask about the APIs available especially for J2EE, .NET and web services. Ensure that all major web service standards are largely implemented.
- SDKs available – Ask about any Software Development Kits that will allow the company buying the product to enhance the product by itself.

8 Availability of Resources

Availability of resources for the following is a key consideration when deciding a product
- Availability of Administrators – Products such as Oracle 10g, Business Objects Data Integrator etc. require slightly specialized skills to manage in a production environment.
- Availability of Developers – Ensure the product has good APIs that support J2EE, .NET and web services. A product without this support will require specialized developer skills and the cost of such resources is higher than a J2EE/. NET resource.

No comments:

Post a Comment