• MSSQL Server
• Analysis Services (MSAS)
• Data Mining
• Reporting Services

Enterprise Business Intelligence

• Cognos
• Business Objects
• Crystal Analysis & Reports
• ProClarity
• MicroStrategy

Multi-Layered Business Intelligence Solutions ...

       Require Multi-Layered Architects

 An important consideration, when designing a Business Intelligence system within any environment, is “where to put the intelligence” among the various “layers” within the system.  I have stated many times in the past, in both articles and presentations, that “multi-layered reporting solutions require multi-layered architects;” Nowhere is this more true than within the design and implementation of the Microsoft integrated business intelligence solution.  A “typical” implementation for me includes the following:

• MSSQL Server:  An RDBMS layer, consisting usually of both relational / OLTP data sources and warehouse(s) / mart(s);

• Analysis Services:  The OLAP layer, consisting of multiple OLAP cubes;

• Reporting Services:  The Reporting layer, within which both relational and OLAP reports are authored, managed and delivered.

In the search for a qualified BI Architect, particularly in what is becoming the common backdrop of an integrated solution combining end-to-end relational, OLAP and reporting strata, corporate decision-makers need to rely upon architects that understand all the layers.  The practice of seeking a “reporting guru,”  “OLAP Architect,”  or “Data Warehouse Designer” to meet a specific need often leads to a suboptimal solution, because the “stratum specialist” often builds functionality into the level he / she knows, and not necessarily in the level that best serves the integrated mechanism. 

Add the inherent inability of the placement industry (for organizations that cannot or will not do their own research), to grasp even the requirements of the discrete layers, and the odds of a successful outcome become small, indeed.

Many of my articles give examples of considerations of this sort, just a few of which include:

• Housing functions and calculations at the MSSQL Server (or any other enterprise-level RDBMS) database layer (be it relational, star-schema, or other), which are leveraged in the cubes or reporting system;

• Building structures within the Analysis Services OLAP layer to provide picklist, conditional formatting and other support to the reporting layer of the system;

• Building virtually anything we need in the way of calculated fields, parameterization support, conditional formatting, and more at the reporting layer.  This can be seductively easy within the flexible vacuum of the Reporting Services design environment, but can often be the worst place to house the associated structures from an optimization perspective.

Regardless of whether you implement the entire solution using in-house talent or seek skill / other resource augmentation from consultants, seek a multi-dimensional perspective in the planning and design stages of your implementation, at a minimum.  Much of the time, money and aggravation that are the natural issue of a haphazard approach is unwarranted, and can haunt the enterprise for a long time. Relying upon application specialized “gurus” (or, even worse, placement organizations that purport to “pre-qualify” them) can be a career-limiting move, indeed ...