The Unfinished Business of Business Intelligence Part 4
Anticipating success: making the BI platform capacity keep pace with demand
Failure is the biggest fear of any applications team or architect charged with deploying an Enterprise BI system; the second biggest fear is success. A well thought-out selection and deployment of a BI system leads to increasing acceptance of the tool and growth in demand, the rate of which sometimes surprises even the most experienced architects and managers.
The three most important considerations of BI platform scalability are:
- Whether or not the tool is intrinsically designed to scale to handle the ultimate projected workload. Several of the more narrowly focused BI tools – e.g. tools directed to a specific industry or type of analysis – are not intrinsically scalable, rather they are intended for department or team use. Department-oriented BI platforms must be scaled through proliferation with the hope of implementing uniform standards of content organization and security; often this scenario entails some degree of duplication of content across multiple installations of the tool.
- How to leverage a scalable BI platform in the corporation’s infrastructure. The larger, broader-based BI platforms are designed to scale vertically (adding instances of platform components on a single host) and horizontally (adding more hosts with BI platform components). The decision of which (or both) scaling approaches to use requires the participation of most of the areas of expertise discussed earlier, as well as a good understanding of the BI platform’s internal operation.
- It is critical to obtain a clear, written description of how the BI platform vendor licenses the product at both the immediate scale and at possible future scales; nuances of scaling and virtualization are critical inputs to license agreements.
The facts of Life: the software will break, and at the worst possible time
Every major software product occasionally malfunctions; what distinguishes BI platforms from many other types of application is the potential for failure or degradation caused by developers or users. Anticipate such problems, with these points in mind:
- Insist that the ability to open service requests be part of the product evaluation process in order to gauge the vendor’s support capabilities.
- Once a product has been selected, organize your support team’s approaches to the initial diagnosis of problems and the collection and packaging of supporting data in order to reduce the time spent with the first tier of vendor support.
- Identify the connection points in the BI platform for both standard and custom enterprise monitoring tools; the major BI platforms support connecting to well-known monitoring products, and they have published monitoring APIs for developing custom tools.
- Prioritize your team’s efforts in “instrumenting” the BI platform: the first priority is to know that a problem exists as quickly as possible; pro-active support of the end-users is critical. The second priority is to leverage the BI platform and external tools to identify the cause of the problem as quickly as possible.
- Use 24×7 monitoring at verbose logging levels, employing techniques such as advanced log rollover management and RAM-based file systems to ensure that data is captured when the problem occurs, rather than turning on detailed logging afterwards and then hoping to reproduce the problem.
The highlights that are used in this series are derived from years of real-world experience working with customers and my colleagues here at CTI, in the hope that readers can use these points to build a road map for their BI deployments.