Six Basic Interrogatives – Part 1, 6BI Overview

This article is the first of a three part series that introduces a method for analyzing the data sources for a business intelligence solution in a framework that classifies the data entities into six (6) basic categories, sometimes called business object classes, but that I call the “Six Basic Interrogatives” or “6BI”, a term taken from journalism. Obviously a play on the common abbreviation for business intelligence, BI, as well. It is based on the familiar Zachman Framework for Enterprise Architecture, and thus acts as a bridge between the disciplines of Business Intelligence and Enterprise Architecture, EA. These categories are the aspects (vertical columns) of the Zachman Framework; “Who”, “What”, “Where”, “When”, “Why”, and “How”.

The article was first published in January 2004 on Datawarehouse.com, a website that no longer exists, under the title “Six Basic Interrogatives – Part 1, 6BI Overview”. The article owes much not only to John Zachman, but also Dan Tasker and Len Silverston, from whom much inspiration was gained and hopefully refined in the process.

Six Basic Interrogatives – Part 1

One of the most difficult and yet most critical activities to get right when embarking on a new Business Intelligence / Data Warehousing (BI/DW) project is organizing and presenting the data requirements in such a way that they make sense to the persons responsible for designing and building the database that will support the decision support application. Two aspects of this activity make it very important.

First, when a significant amount of analytical ad hoc reporting is required, the database cannot be tuned to enhance the performance of any specific query. In ad hoc environments all the details of all queries are not known in advance (if they were it would not be ad hoc and probably of limited analytical value). Second, the people who design and build the database may not have personally participated in the often intense and sometimes contentious requirements gathering and analysis process. These two skill sets (business requirements analysis and database design) are often found in persons with different learning styles, experiences and motivation, so are quite frequently done by different individuals.

The required business performance measurements need to be identified, agreed upon and the algorithm for each defined. The available data sources that support these measurements must also be identified. Ideally the activity to identify candidate data sources will be performed in parallel with that of identifying business performance measurements. Once both of these “identifying” activities have reached an agreed upon state of completeness we then need to match the performance measurements to the data sources. That is, we need to know what are the data elements which, when combined algorithmically, produce the required performance measurements. We need to answer these questions:

Who produces the data we are going to use to measure performance?
What task, item or service is producing the measurable performance?
Where does the activity used to measure performance take place?
When and for how long is the performance of the task, item or service measured?
Why do we believe the data we are using actually measure performance?
How are the data values that measure performance produced?

These questions, or others very similar to them, form what I call the “Six Basic Interrogatives” or 6BI approach to database design for business intelligence. I use this term, borrowed from journalism, to describe a framework for thinking about what needs to go into the database to support decision making and ad hoc reporting. Which is, after all, what needs to come out of a data warehouse or decision support application for it to be useful. In other words we need to know all the factors that influence the data we use to measure performance.

To answer these questions, the structures within a business intelligence database must be designed to hold information about certain categories of business objects. These categories include:

Parties (Persons and Organizations) who produce the data we are going to use to measure performance.
Products (Goods and Services) that are represented by the data used to measure performance.
Locations (and Means of Communication) that facilitate the Goods and Services represented by the data used to measure performance.
Points in Time when the data is produced that is used to measure performance, and Durations over which the performance measures are produced.
Initiatives and Programs designed and executed to influence the data used to measure performance.
Contracts, Exchanges and Actions that represent the activities (participated in by the Parties) that produce the data used to measure performance.

These business object categories then provide the starting point for classifying the dimensions of a data warehouse database design. The design needs to allow enough flexibility to support ad hoc reporting by focusing on the basic questions that all decision support data structures need to support. However, good dimensional design also needs to address the unique decision making environment of the specific enterprise for which it is being built.

The next challenge, of course, is determining the actual measurements of performance themselves. These make up the facts or measures in the fact table that the dimensions describe. These are the data elements that, when combined algorithmically, produce the required performance measurements.

The 6BI design framework provides an approach for organizing and understanding the context of business intelligence and provides a way of classifying legacy data and meta data so that it makes sense and can be built upon. It can not and should not be followed slavishly and there are quite often data structures which simply cannot be easily classified. However, if a place to get started with your database design is what you need it can provide a platform to build upon.

In future articles I plan to discuss each of the 6BI business object categories in more detail, what you look for to identify how to classify data elements and examples from my own work experience. As the database administrator (DBA) function evolves from solely a technical expertise to more of a partner with business domain experts we will all need to quickly and effectively transform business requirements into working software solutions.

Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: