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.
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.
4 comments:
Not to get picky, but COTS packages have been around for decades. Originally, there was a definite choice to be made between customizing the package or trying to change your business to do what the package did.
However, packages have come a long way. It started with something simple as user-defined tables, to today where many packages are highly configurable. My example would be my experience with HRM products from Kronos; if you can define your business requirements as processes, data and rules, then Kronos consultants can configure their system to do what you want. No programming needed, and virtually no requirements that went un-met. Not your father's package, as the saying goes.
Agree with you David.
Many of the packages specially in ERP space have matured a lot and as you said as long as the requirements are defined in terms Process, Data and Rules..things are not that complicated.
But not all COTS products have matured.. take for example the ECM space..products like MOSS, Interwoven, Documentum, Fitlnet etc. are still evolving and the business use these products for various purpose.. from building an enterprise intranet portal to building a collaborative drug dev. system. In such scenarios the challenges are different and it is rare to find a BA with both product and business specialty ..the intent is to address such situations.. which I myself have faced while working as Business analyst.
Thanks a lot for your comments. I learned that if we still focus on Data, process and rules this can be easier..
I would like to share some of my experiences with COTS projects:
1. It may be difficult for a BA to map to-be processes if he/she is not familiar with COTS product.
2. Most COTS projects involve process re-engineering and change management. Often, the business can not agree on changes business processes. A BA has to face the following challenges:
a) Business may not be ready for a change.
b) Reluctance to sign-off processes due to the politics around increased / decreased workload of individuals / depts. as a result of process changes etc...
3. It can be challenging to proove how a COTS solution met business requirements. Often the requirements are high-level one-liners that are open for interpretation. It can be a difficult task to derive test cases from such one-liners.
4. What to test - Requirements or to-be business processes?
Thanks for your comment Maulik. Certainly these are the challenges faced by the BAs.
Keep visiting.
Post a Comment