|
The details on BI vendor evaluation are covered with in the tool domain. In that section, we have given a generic approach to Execution-MiH Vendor-Tool evaluation (which is equally applicable to any IT OLTP as well BI initiative). This page will provide an additional set of thoughts specific to the context of Business Intelligence. You should refer to the Vendor Evaluation before going through this page (as this is an appendix to that section)
BI initiative is different from an OLTP initiative-
You can refer Data Warehouse BI initiative has unique challenges, for details. Here are the key differences in-brief between a BI and OLTP system:
- The business requirements of BI are generic: BI is not created to generate specific reports.
- The BR of BI are fast-changing: As information needs change rapidly, the BI platform has to be flexible and extensible.
- User load projections are loose - Unlike an OLTP system designed for a range of transactions, a BI platform can have sudden fluctuations of load, depending upon the kind of queries, and not only on the number of users.
- Variety of front-end applications: You can place large variety of reporting, modeling, data mining tools over a information platform like a Data Warehouse+ OLAP. Each of these new tools can place a quantum jump on the load factor.
- Business knowledge required: Data modeling for an OLTP is simpler due to the specific requirements. As the business requirements in BI are relatively loose, one needs to have more business perspective.
Consideration for IT vendors related to Business Intelligence:
An OLTP vendor has to bring in quantum mind-set change to enable a good delivery and management. There are many Vendors who have grown in life, through successful OLTP+IT-focused businesses. As these Vendors establish their BI practices, they have a risk of applying the same OLTP DNA, which can be detrimental. Following are the mind-set and skill changes, which a Vendor has to bring in (and you may like to check, when you evaluate a Vendor):
- Bring in business domain expertise and business oriented thinking. It is needed to translate not only for the current business requirements into the BI models and design, but also to make it flexible for possible changes and additions for the future.
- BI project management: A BI initiative project management requires different skills and approach. We will be having more details on this subject in the future. As an example you can refer Data Warehouse testing is different.
- Manage derived data: Typically, the OLTP systems, do not have derived attributes OR derived measures. The derived components are created via data transformation (For example Age Band is a derived attribute from the date of birth attribute of the customer). A vendor, when modeling has to go beyond the data in the source systems, and model the derived information as well.
- Managing access and retrievals: A good part of the production OLTP systems include operations and processing, which includes data entry on a specific transaction. In BI, most of the operations are access and retrieval operations. This places a demand on the vendor to re-look at the cache management, aggregation management (pre-calculated summarization) and cube management (multi-cube vs. single cube)..
- Storage space is typically not a big issue for transactional systems, as the growth is organic. In BI, Handling Data Explosion (when we store permutations and combinations of data mostly containing blank fields, as in real life all permutations and combinations will not happen- For example all stores will not sell all possible products..) can lead to large demands of data storage. A vendor has to develop capabilities to manage the BI data storage effectively.
|
