Guide to the TechWeb Network

Intelligent Enterprise

Better Insight for Business Decisions

Intelligent Enterprise - Better Insight for Business Decisions
search Intelligent Enterprise
Advanced Search
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

Continued from Page 1

I'll admit with embarrassment that I've designed and implemented a data warehouse only to find out later that the client really needed an ODS. The client asked me for a data warehouse — even insisted upon it. But the client didn't need a data warehouse. I've learned from this lesson, and now during a project's initiation and analysis phases, I attempt to avoid BI-specific language completely.

Avoiding BI-specific terminology in these phases is actually easier than you may think. Business users are confused by BI terms not just because some of the definitions are blurry but the terms are usually new to them as well. If our BI language is new to them, the simple solution is to talk in their native tongue. While this approach may not seem as elegant, it's more efficient.

In talking with clients about their BI needs, I've discovered that many even have trouble with the term business intelligence. They want to adopt this term because it sounds like an admirable goal, but, truth be told, they still tend to think of BI primarily in terms of reports or, perhaps, analysis. By using the client's own terminology (leaving the BI terminology and architectural discussions within IT and the project's design phase where it belongs), you can eliminate confusion.

Without BI terms potentially predefining the architecture, the business drivers become the unbiased single-source of input for defining the BI architecture. At a high level, four key business drivers will push the overall system architecture: reporting types, data source scope, time variance requirements, and enterprise BI vision.

These terms may lack flair, but they overcome their superficial mediocrity by being ubiquitously familiar.

Reporting types. The types of reporting can be broken down into three categories along with the typical questions they answer:

  • Operational reporting. How is the business doing right now? Based on operational metrics, where is the organization doing well? Where should the focus be today?
  • Tactical reporting. Over a given reporting time period, how did the business perform? Which goals were met for that time period and which weren't?
  • Strategic analysis. How is the organization performing in the long run? What is the correlation, if any, between a given performance measurement and other external or internal factors?

Scope of data. Does the required data come from one department or across the enterprise? Do other departments define the calculations for a given metric or are they your own?







IE Weekly Newsletter
Subscribe to the newsletter
    Email Address







techweb
Online Communities TechWebInformationWeekLight ReadingIntelligent EnterprisebMightyNetwork ComputingDark ReadingDigital LibraryWall Street & Technology
Byte & SwitchNo JitterInternet EvolutionLight Reading's Cable Digital NewsContentinopleUnStrungBank Systems & TechnologyAdvanced TradingInsurance & Technology
Face-to-Face Events
InteropWeb 2.0 ExpoWeb 2.0 SummitVoiceConBlack HatCSISoftwareEntrprise 2.0 ConferenceGTEC
Mobile Business Expo
InformationWeek 500 ConferenceBuy Side Trading XchangeBuy Side Trading SummitBank Executive SummitInsurance Executive SummitTelcoTVEthernet ExpoOptical Expo
Magazines  
InformationWeekWall Street & TechnologyInsurance & TechnologyBank Systems & TechnologyAdvanced TradingMSDNTechNetSmart EnterpriseThe Architecture JournalDatabase Magazine
 
Research & Analyst Services  
Heavy ReadingInformationWeek ReportsInformationWeek Analytics