Petya Petrova - Fotolia

Manage Learn to apply best practices and optimize your operations.

Why a BI environment needs a solid architecture framework

In a book excerpt, consultant Rick Sherman explains why taking a siloed approach to creating a BI architecture framework can lead to problems for organizations.

This is an excerpt from Chapter 4, "Architecture Framework," from Rick Sherman's book Business Intelligence Guidebook: From Data Integration to Analytics. Sherman is the founder of BI and data management consultancy Athena IT Solutions, an adjunct faculty member at Northeastern University's Graduate School of Engineering, and a frequent contributor to industry publications, events and webinars.

In the chapter, Sherman provides insight as to how the BI environment in many organizations has been waylaid by the siloed approach to IT and application development. He also explains the benefits of a comprehensive and well-planned BI architecture strategy, and lists the four architectural layers of a BI framework.

BI environments and houses have something in common. When you plan to build a house, you start with its purpose: a place to live, a place to work, a place to raise kids, a place to grow old, etc. Knowing that, you put together a wish list on the architectural style, size and types of rooms. Then you hire an architect to design the house and create a detailed blueprint.

Business Intelligence Guidebook: From Data Integration to Analytics

The architect gives you feedback on how the various rooms can fit together, what the building codes are, and how to fit in the infrastructure such as wiring and plumbing. Most importantly, the architect advises you on what is really possible or practical given your location, house size, wishes, budget and timetable. In addition, she offers ideas for things you had not thought of.

What happens if you skip the architect and go straight to a builder? The house may not meet building codes, the flow of the rooms will be awkward and the style will not be as attractive. The process will take longer as the builder tries to figure out what you want. Meanwhile, you do not really know what you want until you see it, and then you probably do not like what you see. And you certainly do not like paying for all this extra time.

Successful enterprise BI solutions with enduring business value are not completed in a 'one and done' project, but rather evolve over time.

Like the unfortunate house without blueprints, many enterprises today have a BI environment that did not have the benefit of an architecture framework. It is a hodgepodge of the following pieces:

  • Many application-specific reporting environments in addition to an enterprise BI environment. Business people are forced to switch between these environments based on what they are trying to analyze.
  • Various databases created for BI outside the application environments (above) that were created at different times, by different teams for different purposes. These databases might be referred to as data warehouses (DW), data marts, operational data stores, repositories, online analytical processing cubes or by some internal acronym.
  • Several different BI tools, associated with either the application-specific reporting environments or the enterprise BI solution. It is not unusual to see the enterprise BI environment supporting several BI tools because different BI tools were designated as the enterprise standard at different times. And once a BI tool becomes a standard, it is likely to become entrenched in an enterprise for a long time, even if a new BI tool has been selected as the new or latest standard.
  • A data integration tool selected as the enterprise standard for loading the DW, yet people use a lot of manually created custom SQL code or other extract, transform and load tools to load the databases used by the BI tools.

Business people are grouped by business function and processes, so enterprises tend to build (or purchase) business applications in discrete silos. The initial wave of reporting that business people use is from these application silos. Enterprises then try to expand this reporting, but they typically focus the BI projects on the same applications that the business groups have been using, without examining how these projects should fit into an overall architecture. As a result, many BI environments have become a collection of technology, product and data silos that are loosely connected and require an intensive commitment of resources to operate, upgrade, maintain and enhance.

Copyright info

This excerpt is from the book Business Intelligence Guidebook: From Data Integration to Analytics, by Rick Sherman. Published by Morgan Kaufmann Publishers, Burlington, Mass. ISBN 9780124115286. Copyright 2014, Elsevier BV. To download the full book for 25% off the list price of this and other books, visit the Elsevier store and use the discount code PBTY15.

Business people are frustrated with the state of their BI environments, which take longer and longer to enhance over time, and are always a release away from becoming pervasive throughout the enterprise. They remember the significant investments of time, resources and budget for BI projects, and they ask why they still have to use spreadsheets (i.e., data shadow systems or spreadmarts) as the superglue for reporting and analysis.

IT people are also frustrated as more and more of their time is spent on reconciling data between these silos and maintaining these systems, rather than expanding the breadth and value of BI for the business. The temptation, too often reinforced by industry hype, is that an enterprise can get out of this mess by simply using the latest technology marvel -- but it always ends up as the next silo.

Architectural framework

Successful enterprise BI solutions with enduring business value are not completed in a "one and done" project, but rather, evolve over time. BI will, if done right, expand in terms of the number of business people using it, business processes affected, data consumed and analytics performed. An architectural framework, i.e., a set of architectural blueprints, is needed as each new BI project is undertaken to enable these projects to complement each other and create a cohesive, cost-effective BI solution. The framework needs to be designed to accommodate expansion and renovation based on evolving requirements, capabilities, and skills. Although the framework designer will not know the future, she can design the framework to meet those challenges. Besides adding BI capabilities for the enterprise, the designer needs to include support for development, testing, ongoing operations, performance monitoring and documentation. Many of these areas get shortchanged or overlooked if the focus is merely on blueprints for implementing only the current project.

The four architecture categories.
Figure 4.1. The four architecture categories.

As shown in Figure 4.1, a BI framework is composed of four architectural layers:

  • Information architecture
  • Data architecture
  • Technical architecture
  • Product architecture

Next Steps

Is standardizing BI systems a smart strategy?

Tips for designing a BI system that meets business needs

What you need to know about BI tools before buying them

Speed matters in BI

BI development can make your business run more efficiently

 

This was last published in May 2015

Dig Deeper on Business intelligence architecture and integration

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

What are your tips for building an effective BI architecture?
Cancel

-ADS BY GOOGLE

SearchDataManagement

SearchAWS

SearchContentManagement

SearchCRM

SearchOracle

SearchSAP

SearchSQLServer

SearchSalesforce

Close