In the last six installments of this series, I've looked in depth at a number of functional areas by which to evaluate BI suites. In this final column, I address architectural considerations and wrap up with a context to help you determine the best BI tool for your company.
Continuing the car-buying analogy I've used throughout this series, discussions about BI architecture are similar for many people to hearing car dealers tout overhead cam versus inline-6. Customers want to shout, "Skip the techno babble, just tell me the benefits!" Is it fast, does it scale, and most important, does it work within my current infrastructure?
There are many aspects of a BI architecture that will never come across in a vendor demo, such as:
- Whether it's client/server or Web-based
- The OLAP approach used (MOLAP, ROLAP, or DOLAP)
- How easily the BI tools can be customized or embedded within other applications
- How common is the framework (metadata, security, and infrastructure) that the suite uses across the different tools, such as query, reporting, OLAP, dashboards, or analytic applications?
- Whether services can be distributed across multiple servers and platforms.
Just as you may have to open the hood of a car or take it for a test drive to see some of the engine differences, so too will architectural differences in the BI suites become apparent only when you install, deploy, or customize the products.
As BI has moved to the Web and to enterprisewide deployments, many BI tools today have a serviceoriented architecture (SOA). An SOA allows different BI services to perform specialized tasks and, when necessary, to be distributed across multiple servers. As an example, let's look at three possible BI services: query, presentation, and scheduling. (See Figure 1.) Keep in mind that each BI tool may have more (or fewer) specialized services that may handle tasks such as logins, prompt generation, request routing, and so on. (For more on prompt generation, see Part 1: Query, in Resources.)
FIGURE 1 Service-oriented architecture for BI tools: BI application servers can run on either a Web server or a dedicated application server.
In Figure 1, the query engine is responsible for querying the data source, possibly a data warehouse or MOLAP cube. After the query completes, the presentation component must convert the query results into meaningful reports, perhaps with charts and crosstabs, and potentially in different file formats such as HTML or PDF. If a user schedules a query (see Part 3: Information Delivery), the scheduling service continuously monitors when it's time for the scheduled request to become active and passes it over to the query service. How the query, presentation, and scheduling components communicate is where standards such as COM, CORBA, and Web services protocols come into play. Alternatively, a BI vendor may use proprietary approaches to handle these communications. COM and CORBA are older methods of supporting an SOA; Web services standards are gaining both acceptance and capabilities. (See "Web Services: It's About Connections," Intelligent Enterprise, Oct. 10, 2003.)