Mars, Venus, and a Successful Business Intelligence (BI) Architecture

by Rick Sherman, Athena IT Solutions

When it comes to 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 requires more than just a silver-bullet product.

A successful BI architecture has four parts:
1. Information Architecture
2. Data Architecture
3. Technical Architecture
4. Product Architecture

1. 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.

2. 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.

3. Technical Architecture
The technical architecture defines the technology of the products and infrastructure. Technologies include relational databases, OLAP, BI, ETL (extract, transform and load), EAI (enterprise application interfaces), EII (enterprise information interfaces), 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.

4. 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, timeframe 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.

© 2003 Athena IT Solutions

This article may be reprinted freely online, as long as the entire article, copyright, and the following resource block are included:

Rick Sherman is the founder of Athena IT Solutions, a consulting firm that offers data warehouse assessments, full-scale implementation, research, and education. Rick is a published author in technical publications and a speaker at industry conferences and events. He can be reached at rsherman@athena-solutions.com