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

Continued from Page 2

The task of identifying the data elements for the BI project is where understanding and agreeing upon the definitions of the terminology becomes critical. However, the definitions that you need to agree on aren't the BI terminology, but the business terminology.

When defining the BI system's data requirements, gaining a thorough understanding of the data's attributes (I'm biting my tongue here to prevent "facts" and "dimensions" from slipping out) and definitions is a necessity. Terms such as net revenue and income may seem simple enough to define and ultimately derive, but their definitions have potentially far reaching implications on the data attributes required by the BI system and ultimately the data sources required to obtain these attributes. Additional data sources increase scope, raise ownership and support issues, and may help define whether the scope of the BI system is departmental or enterprisewide in nature.

Time variance. Do only the current values matter, or are changes over time important? For example, if sales were $1.1 million at the close of the month, but a week later are recalculated to $1.2 million, does the system need to know that the business once thought the month close was $1.1 million at a specific point in time? What if sales for Jane's northeastern sales region totaled $4.5 million for the year, but Jane didn't get the promotion to regional sales rep until October — would it matter if the report appeared to credit Jane for the entire year's worth of sales?

As a student of BI, I find it easier to refer to this driver as the design for the time dimension or the problem of slowly changing dimensions. But again, here lies the trap. In the requirements gathering phase, referring to subject areas as dimensions implies you plan on implementing a dimensional database model. Is that the predefined architecture regardless of the business need?

Enterprise BI vision. Rome wasn't built in a day, and neither are enterprise visions. Most are funded incrementally through projects. A company may have a stated vision for the development of an enterprise data warehouse, but it will more than likely evolve over time, project by project. Projects fill specific tactical needs, but often are challenged to assume a strategic role and work toward the enterprise vision.

Your project may only need a divided highway with a top speed of 55mph to get from point A to point B in sufficient time, but a four lane superhighway with express lanes may fulfill the enterprise vision. Unless the department funding the project has a tremendous budget surplus, this disconnect can rarely be reconciled completely. But it can — with effort — be managed.

The act of managing to an enterprise vision, while serving tactical needs and budgets of the project, is more of an art form than a methodology. A few key points need to be considered:

Share the vision. Achieving any enterprise vision requires good vigilance. Make sure that the keepers of the vision know where they want to go and have worked diligently to gain the buy-in and support from those departments and projects with tactical needs.
Find a medium. Stovepipes and enterprise systems aren't two points lying side-by-side, but the opposite ends of a rather lengthy continuum. There is a medium. It may not be a happy medium that immediately satisfies both sides, but compromises can be made to position a departmental effort for future enterprise integration without overtly affecting the current project's cost and timeline.
Plan for incremental growth. The architectural plan for an enterprise system must support incremental growth. Numerous approaches can help achieve this goal — albeit with limited success. Creating a flexible architecture that responds well to changes and additions is difficult and has a high degree of risk. Sound advice is to pick an industry-accepted architecture that seems to be the best fit for your organization and then test it against change. Before completing design, test its flexibility. Go through the exercise of adding a new subject area or a large number of new attributes. See how pliable the design you came up with actually is. These flexibility tests can then be integrated into future projects as well.

The Lingua Franca

You may find it difficult to stay away from the BI lexicon, but by focusing instead on these business drivers you'll be able to efficiently gather all the architecture-defining requirements for the project. At the same time, using terms the business clients will understand will facilitate more efficient communication and bring greater clarity when gathering the business requirements for the project. Only once the requirements have determined the system design will you then know whether you have an ODS, data warehouse, data mart, or a combination of the three.

Rate This Article

Comments:

Optional e-mail address:

Then all you'll have to do is determine if the information needs to be presented in a business activity monitoring system, corporate dashboard, balanced scorecard, or executive information system. But that's another problem.

Joseph Luedtke [jluedtke@reveregroup.com] is the principal of Advanced Technology Solutions for The Revere Group. He has 15 years of IT industry experience, including more than five years in consulting. He joined The Revere Group in 1998 and currently leads its business intelligence practice area for the Milwaukee office.