Business intelligence solution architecture
Although there are a very large number of business intelligence tools on the market, they broadly fall within just a few functional categories. The Figure below represents each category as a component of the generic business intelligence solution architecture. Most common business intelligence problems are solved with a combination of these components all doing what they do best. This is the most effective way to build a BI application, playing each tool to its strengths. We can waste time and resources if we ask a single tool to play outside of its core competency.
When you first see all the components in the generic BI solution architecture (below), your first response might be why do I need all this stuff? At first, it seems like a lot of moving parts. However, just like more familiar home-office software, each tool has a distinct purpose that is not easy to replicate using other components. By example, although it is possible to write a letter in a spreadsheet application, there are many good reasons why it is better to use a word processing application.
Business intelligence components
The Figure has two main segments. On the left is the data storage architecture. This typically includes three tiers: primary data sources, a data warehouse, and analytical databases. On the right of the figure are the end user tools. We can use an existing application as the interface for BI information – ideal for supporting a business process – or use specialist query tools, reports, dashboards, and spreadsheets.
Generic business intelligence solution architecture
The diagram illustrates two important features of the generic BI solution architecture.
- The BI user interaction tools can legitimately interact with data from any layer in the data architecture
- A mature BI technology capability will support a variety of end user tools
The second point may surprise some readers who would imagine that consolidating BI tools should be a driving force of a technology strategy. Consolidation is desirable for the DW, ETL, and (to a lesser extent) analytical databases. The user community for these development tools is relatively homogeneous – power users and technology professionals. In contrast, the preferred style of interaction for end user tools is much more subjective with different user groups favouring different tools.
One BI tool or many?
The solution architecture diagram covers the broad categories of user interaction. Within each category, you will find many distinct products that provide the functionality in different ways. As a starting point, you should aim to provide a tool for each of these categories. As new user groups and requirements come on board, you should be open to incorporating new tools. Justifications for expanding the end user toolset are that the new tool:
- is particularly well suited to supporting a business process or user group
- does not simply replicate a subset of functionality provided by an existing tool
- can be justified in terms of upfront cost and ongoing maintenance versus expected benefit
Many user-facing tools in the BI space are quite inexpensive or come free with other software and are easy to implement on a single desktop PC. In this instance, the threshold for justification should be quite low if a business user feels that it will support their process better than existing tools. Where a new tool is expensive and requires its own server infrastructure and dedicated support, we would expect a more rigorous approval process.
In the article links below we look at each of the components of the generic business intelligence solution architecture in more detail.