Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search

View all Portals

Scheduled Events

White Paper Library
Research Papers

View Job Listings
Post a job


DM Review Home
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

Buyer's Guide
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

About Us
Press Releases
Advertising/Media Kit
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

BI Briefs:
Mars, Venus and a Successful Business Intelligence Architecture

online columnist Rick Sherman     Column published in DMReview.com
June 26, 2003
  By Rick Sherman

When it comes to business intelligence (BI) architecture, business users are from Mars, and IT people are from Venus. Each approaches a BI project from a totally different viewpoint. As an IT person, you often need to educate your business users to make sure they understand that a successful BI architecture is more than just a silver-bullet product.

A successful BI architecture has four parts ( as shown in Figure 1):

  1. Information Architecture
  2. Data Architecture
  3. Technical Architecture
  4. Product Architecture

Figure 1: Business Intelligence Architecture

Information Architecture

The information architecture defines what business application systems you need to access, report, and analyze information to enable business decision making. It includes business intelligence systems and business analytics applications used for reporting and analysis. This is the only part that is truly visible to the business users, so it's often the only part they care about. From their viewpoint, the other components are just infrastructure that doesn't concern them.

Data Architecture

The data architecture defines the data, source systems and framework for transforming data into useful information. It begins with the sources (information provider) and ends with the business user (information consumer). It includes defining information requirements; determining the source of data; defining business rules and transformations; and, moving, storing, formatting and enabling access to the data. Transformations are used to create dimensions, i.e., create common product, customer and employee reference data; reformat data between source systems to enable common processing; handle data quality issues; and prepare data content, context and structure for reporting and analysis. With an enterprise scope, this is the most difficult portion of the architecture. It's usually underestimated in project planning, underappreciated in scope discussions and is where shortcuts are most often taken. The latter is the most damaging because it results in the creation of information silos with different numbers that confuse business decision making.

Technical Architecture

The technical architecture defines the technology of the products and infrastructure. Technologies include relational databases, OLAP, BI, extract, transform and load (ETL), enterprise application interfaces (EAI), enterprise information interfaces (EII), networks, operating systems and the interfaces/protocols/APIs in the layers within and in between them.

It's a big mistake to confuse the technical architecture with the products themselves. This can happen when you associate products with specific technologies. It's important to remember that products may incorporate many technologies, especially with vendors extending their product lines and supporting an alphabet soup list of technologies. Resist the urge to evaluate products immediately. Determine what your information and data needs are and then select the technology that will support them. Two areas where this is most important are in BI and data acquisition. In BI there is a variety of potential technologies and approaches that support different types of business users. Too often a one-size-fits-all approach is used that results in an underused architecture-based solution or creates BI anarchy, where business users start purchasing many BI tools hoping to pick the "perfect" product. In the data acquisition area ETL, EAI/Web services and EII are often viewed as competing solutions rather than the more pragmatic view that they can be complementary elements in an overall robust architecture.

Product Architecture

The product architecture includes the actual products used. Don't rush to select products before you define the other components of this architecture. Companies that issue product RFPs before examining their information, data and technology needs end up with an architecture determined by the vendor. You then conform your architecture, project, resources, time frame and budget within their product framework. Unfortunately, vendors very often underestimate your data requirements and issues. It's in their interest to get you deployed with their products as soon as possible. If problems result or numbers don't align, they can always blame the source systems and other applications. This is where you see the gulf between business users (Mars) and IT (Venus). Business users will go off on their own and purchase products based on a great looking demo and PowerPoint presentation. "Architecture...we don't need no stinkin' architecture!" This throws IT's four-part architecture framework totally out of whack.

Why is it Important to Differentiate and Plan for all Four Architectures?

You need to determine what you need before you design, plan, build and deploy business solutions. When redeveloping architectures, don't rush to buy products. Start with your information requirements, then data, then technology and finally select products. Realize there is no silver bullet when it comes to products and technology. You need a mix of different types for a comprehensive, robust, expandable solution. The toughest component is always data, and the most likely area where you will be tempted to take shortcuts.

How Do You Get Started?

When implementing architectures: Plan globally, act locally. First, determine what you need for business solutions addressing business pains. Second, develop the overall architecture. Third, develop an overall program plan with iterative projects moving towards your architecture. Finally, do it!

Always couple your projects with business solutions developed jointly with business and IT participation. Your CFO and CIO need to sponsor the architecture program with other business executives sponsoring the specific business solutions from each project.

Regardless of what planet you're from, you need to establish an architectural framework for your BI projects. Creating a framework and plan increases the likelihood of long-term success.


For more information on related topics visit the following related portals...
DW Administration, Mgmt., Performance and DW Basics.

Rick Sherman has more than 18 years of business intelligence and data warehousing experience, having worked on more than 50 implementations as an independent consultant and as a director/practice leader at a big five firm. He founded Athena IT Solutions, a Boston-based business intelligence consulting firm and is a published author and industry speaker. He can be reached at rsherman@athena-solutions.com or (617) 835-0546.

Solutions Marketplace
Provided by IndustryBrains

Manage Data Center from Virtually Anywhere!
Learn how SecureLinx remote IT management products can quickly and easily give you the ability to securely manage data center equipment (servers, switches, routers, telecom equipment) from anywhere, at any time... even if the network is down.

Data Mining: Levels I, II & III
Learn how experts build and deploy predictive models by attending The Modeling Agency's vendor-neutral courses. Leverage valuable information hidden within your data through predictive analytics. Click through to view upcoming events.

Design Databases with ER/Studio: Free Trial
ER/Studio delivers next-generation data modeling. Multiple, distinct physical models based on a single logical model give you the tools you need to manage complex database environments and critical metadata in an intuitive user interface.

Data Validation Tools: FREE Trial
Protect against fraud, waste and excess marketing costs by cleaning your customer database of inaccurate, incomplete or undeliverable addresses. Add on phone check, name parsing and geo-coding as needed. FREE trial of Data Quality dev tools here.

Live Web Cast - Maximizing Revenue, CRM & CDI
FREE, LIVE & Interactive web cast on customer data integration (CDI), customer intelligence management, integrated revenue management (IRM) & more. Hosted by Aberdeen & Nimaya. Register and receive a free whitepaper and chance to win an iPod Nano!

Click here to advertise in this space

E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2006 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.