Business Analysis in COTS Environment- Part 2

Understanding COTS Products

Use of commercial off the self product is gaining popularity, specially where the Business needs matches those of one or more commercial IT market place segments like ECM, Collaboration, Enterprise Search, SCM, HRM, CRM, Business Intelligence etc. These components offer a promise of rapid delivery to end users, few organization can afford resources and time to replicate the market tested capabilities for these products.

For a Business Analyst, working in a COTS environment is different from a typical custom solution development projects primarily because the components are preexisting and are not designed to meet specific business needs. For BA it becomes important not only to know what the business needs are but to also understand the functionality of the COTS product how it is likely to change over the period of time. This understanding is vital as it help in doing a 'to-be' mapping of the business process and define more useful business and system requirements.

So how are these COTS products different? What are the key characteristics of these products and as Business Analyst what should I must know about COTS system in general? The SEI has identified following attributes of the COTS products and components:

• The marketplace, not one system’s needs, drives COTS component development and evolution.
• COTS components and the marketplace undergo frequent, almost continuous change.
• Frequency and context of COTS component releases are determined at the discretion of the vendor.
• COTS components are built based on unique architectural assumptions and are not constructed using a universal or consistent architectural paradigm.
• There is at best limited visibility into COTS component internals and behavior.
• COTS component assumptions about end-user processes may not match those of a specific organization.
• "Vendor” is not a new name for subcontractor. Different relationships are required to have insight and to influence component changes.
• COTS components often have unsuspected dependencies on other COTS components.

I have been working with COTS products ever since i started working as Business Analyst. I feel that it is must to understand the above mentioned features of an of the shelf product. It is not possible to know all the functionalities of a COTS product for a Business Analyst but the basic realization that these components are market driven and may not satisfy some of the project requirement prepared the BA for negotiation with business and IT.

References: EPIC: An Overview [ A must read]

Coming up:

• BA in a familiar COTS environment i.e. when you know the product.
• BA in unfamiliar COTS environement i.e. when you have no idea about the product's capabilities.

Business Analysis in COTS Environment- Part 1

Summarizing the Process:

1. Ideally, the business process re-engineering(BPR) should happen and the business should be made aware of what the COTS tool can offer and changes that may be required in their current way of doing the business.

2. Ideally, the Business Analyst should be fully aware of the capabilities and functionalities of the COTS tool and help business identify the functionalities that the tool can offer.

3. Ideally, Agile methodologies should be adopted to built COTS based system to enable system development adapt as per business needs.

4. Ideally, the OOB features should be implemented with phased and with incremental releases.

5. Ideally 80-20 principle should be followed. 80% features coming OOB and 20% through custom development.

But system development is rarely Ideal. Often a COTS tools are chosen because some smart sales guy managed to influence the CIO or the manager in charge and now it has become a company standard. As a BA you were not involved early in the process and have little experience with the COTS tool and the dead line is too aggressive, now what do we do. We will get to that later. But there are some things to keep in mind:

1. There will always be a mismatch in business needs and what COTS can offer. It is good to know both.

2. There will be a constant negotiation between development teams and the business on what should be done OOB and how much custom code should be written, facilitate these discussions.

3. Ultimately both will have to mid somewhere in middle, a little between of custom code, a little bit of requirement changes and a lots of OOB.

... Stay tuned for more.