Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

May 13, 2003

The Lexicon of BI

Business drivers, not business intelligence terminology, should determine your solution's architecture

by Joseph Luedtke

I'm a business intelligence architect. Last year, I was a data warehouse consultant. A few years prior to that, I worked in decision support. In these various roles, I've implemented data warehouses, data marts, and operational data stores (ODS) in all their various flavors of federated, dimensional, and as components of the customer information factory. Even with years of experience in the field, I've found it challenging to understand the practical applications and fundamental architectural differences implied by these terms and how they alter data warehouse life-cycle methodology.

This lexicon is confusing; the definitions of these terms blur as they overlap one another in functionality and architecture. I have no intention of attempting to define them here; you could take Data Warehousing 101 and still not be sure that a data warehouse wasn't really an ODS.

Instead of defining these terms, I'm advocating that you don't even try — or at least not right away. After observing someone from my client's IT department continually correct the project sponsor on his use of the term "data warehouse," I knew we were taking the wrong approach. "We're building a data mart, not a data warehouse" was the mantra. Although technically true, it had no bearing on our discussion of the sponsor's business needs and drivers for the project.

Stumbling On The Words

Too often, data warehouse practitioners get hung up on the lexicon. Attempting to educate your users on these terms not only causes confusion but also may have the side effect of defining a solution's architecture prior to completing requirements gathering and the requisite analysis. In the BI world, I've had many clients tell me they "need a data warehouse" or "need a data mart." Outside of BI, however, clients have never told me they need a "transactional database" or a "relational database in third normal form." Business users typically describe system needs in terms of their function — a CRM, ERP, or order entry system. Then why do we ask our BI users to understand the underlying architecture-defining IT lexicon when naming their system?

This confusion of terms wastes energy. It can distract business clients from their day-to-day work and the project tasks of setting objectives and gathering requirements. The definition and use of these terms should be kept behind IT closed doors.

(But even confined within IT, these discussions can sometimes cause problems: In addition to being confusing, these terms can incite passionate opinions. I once witnessed a few months of successive meetings, emails, and hallway discussions on whether what was being built was truly an ODS. Eventually, when a clear decision couldn't be made, someone suggested a new term of "operational reporting mart." The new term seemed to defuse the controversy, and now that term has permanently stuck.)

What Was Said vs. What Was Meant

The real risk with a BI lexicon, however, is implementing an architecture that's called for in name but not supported by the underlying business requirements. Once a term such as data warehouse becomes pervasive in project discussions, you run the risk that the IT staff will adopt that term as an architectural requirement. Blind obedience can cause BI practitioners to follow the assumed architectures that go hand-in-hand with the terms and other lingo but don't necessarily align with the client's needs.