By using website you agree to our use of cookies as described in our cookie policy. Learn More


Ten Mistakes to Avoid when Creating a Business Intelligence Road Map

Ten Mistakes to Avoid When Creating a Business Intelligence Road Map

Before undertaking a major BI architecture or restructuring initiative, organizations should create a road map to help them create a business case, assess their current state, and plan a phased implementation.

Ten Mistakes to Avoid

Download full publication


Understanding the business better or achieving business intelligence (BI) is a requirement for many organizations. The underlying architecture is critical to success. Business intelligence architecture consists of the people, processes, and technology that enable sophisticated reporting and analytics, improve data integrity, and ultimately drive decision making. Before undertaking a major BI architecture or restructuring initiative, organizations should create a road map that will enable them to:

  • Create a business case
  • Assess their true current state
  • Plan a phased implementation

A road map sets the direction and can be adjusted for changing realities.

This publication discusses 10 key components that a road map should address that are often overlooked, forgotten, or glossed over without the appropriate level of detail.

Mistake 1: Failing to Map Architecture Needs Back to Business Requirements

Start the road map project with a firm understanding of the organization’s goals for growth and the business challenges or requirements driving the project. Technologists find it easy to get excited about—and caught up in—the latest “cool” technology. However, new technology should be seriously questioned if the business requirements do not support it. Prioritize requirements from business users and data consumers as you gather them. Many CIOs will not entertain technology changes without understanding the business drivers first.

Determine the appropriate level of detail for the requirements.When deciding how to enhance the architecture or improveits maturity, it is not necessary to document requirements tothe level of a traceability matrix. Such a level of detail canbe captured at each phase of the project. The level of detailcaptured should be sufficient for business sponsors and/or CIOs to understand the justification and business valuefor the proposed architecture changes and improvements.Focusing on the business challenge (the requirements), thesolution, and the business value will lead to justification forthe project.

Mistake 2: Overlooking Requirements for Implementation and Support

Suppose you determine that, in order to meet the business requirements or service-level agreements (SLAs), you must replace existing tools with new products. You should consider and plan for the cost of training current staff, hiring new staff, and/or using consultants to develop and provide ongoing support for the new products.

Consider the example of an organization that needed to support its rapidly growing business and thus had an increasing need for accurate and timely data. The business model it had been using centered on data gathering and data output. The company needed to change its ETL tool and database platform and to add robust data matching tools and an e-commerce engine to its architecture. It planned for the cost of training current employees, hired two new people experienced with its new products, and used consultants to conduct the vendor selections and lead the e-commerce, database, and ETL design efforts to ensure that the foundation was laid correctly. Although the up-front investment was large, the company knew the long-term success of its business and its ability to compete depended on its decisions about a new platform.

If you determine that changing products will be too costlybut aren’t sure whether the current toolset will meet therequirements, confirm that the current tools are being usedto their fullest capacity. For more information on using the existing toolset, see Mistake Five.

Mistake 3: Failing to Divide the Road Map into Smaller Modules or Phases

Road maps that include many components (datamodeling, a data warehouse with many sources, ETL,business intelligence reporting, product acquisition orchanges, database platform changes, or business processmanagement) can take years to complete. Business and ITowners typically prefer to see results within a few months.

Dividing the road map into modules or phases, prioritizing them, and understanding their interdependency allows for an iterative delivery schedule. Create a dependency grid to help you visualize the order in which to implement the modules and to determine whether there is sufficient flexibility to change that order as business priorities change.

For example, consider an organization that did not have itstransactional data feed processes automated, scheduled, orimplemented with exception handling. Incorporating thesefeatures into the data feed was module one and priority one.Every other module for building a data warehouse and BIwas dependent on this module and thus could not have ahigher priority. This organization considered implementing abusiness process management tool, which was considereda “nice-to-have” product without any dependencies. It couldbe added when and if time and money allowed.

Mistake 4: Inaccurately Assessing the Maturity of the Current Environment

Many road map projects begin because the organization feels the need to improve the maturity of its BI capability. Organizations that want more sophisticated architectures need to take an honest assessment of the current state. For example, if they do not have—or follow—basic version control practices, then striving to implement predictive analytics or a service-oriented architecture (SOA) may be too aggressive and unrealistic.

Consider the following when assessing the maturity of the BI architecture:

  • Standardization—includes basic configuration management (such as version control processes, separating development, test, and production environments, and processes for quality assurance and defect reporting). Standardization also includes processes that allow business users to request reports and access data.
  • Consolidation—includes the ability to consolidate data in a structure (such as an operational data store or a data mart), to identify and correct data anomalies, and to develop rudimentary business intelligence.
  • Integration—provides a unified view of the data and can be real time (via concepts such as data virtualization or operational BI). Business concepts such as having one view of a customer can be achieved here.
  • Extensibility—improves business agility and enables integrating processes as well as data. Extensibility usually refers to an SOA and involves systems as well as data.

Other maturity models have been published that are specificto BI. Regardless of which maturity model you choose, it iscritical to take an honest and realistic assessment of yourcurrent state.

Mistake 5: Failing to Build on Existing Tools

As you begin to design and implement phases of the road map, do not assume that new products are always needed to achieve each goal. You can save money if you can leverage existing tools in new or more advanced ways. For example, an organization concerned that its reporting tool would not allow it to perform “slicing and dicing” found, upon closer examination, that the tool could support cubes, which they then implemented to increase their analysis capabilities.

Most vendors continually look for ways to improve their products, and they will share their near-term product road maps with customers. When you have a good relationship with vendors, it is easy to make recommendations and requests for functionality you would like to see in their upcoming product releases.

Mistake 6: Failing to Include Security and Compliance

Security and compliance are multi-faceted areas that should be included in your initial BI architecture plans. Security can include physical security and storage of the data, authentication and authorization, configuration management, and breaches related to viruses, spam, and hackers. The meaning of compliance varies by industry. For example, enterprises in the healthcare industry must comply with HIPAA regulations; publicly traded companies must comply with Sarbanes-Oxley; and the public sector should follow Federal Information Security Management Act regulations.

Not all of these security and compliance considerations will be relevant to your organization. It is important to identify any vulnerabilities in your BI architecture and determine who, if anyone, is responsible for addressing them.

Many large organizations have a security division responsible for securing applications and data to reduce breaches. This responsibility includes the physical security as well as protecting applications. Organizations that do not have a security division should assess authentication, authorization, configuration management policies, and compliance audits. Control who can access each environment and what activities can be performed there. For example, the number of resources that have access to production servers, code, and data should be small, and those without this access should be able to perform only a limited set of activities.

Mistake 7: Failing to Anticipate Scalability Challenges

Scalability is a concern for many organizations. Common questions include:

  • How will more data volume affect performance?
  • When should I add more hardware?
  • Will my ETL jobs be able to run in the allotted amount of time?
  • Do I have too much data to do meaningful analysis?

Forecasting your business’s growth will help you create a plan to ensure that the technology solutions scale appropriately. Understanding goals for new customer or client acquisitions, existing customer or client retention, or product-line expansion can help you calculate expected data growth. To get more specific estimates, apply volumetrics to your data models.

Information estimates in which you have some confidence will help you decide when and how to solve potential scalability problems. To address scalability challenges, consider moving inactive data into a different storage mechanism (or medium) and consider a data appliance built for performance and heavy processing.

Mistake 8: Failing to Let the Road Map Evolve as the Business Grows

In today’s global market, organizations must adjust quickly to meet customer demands and to gain or maintain a competitive edge. Review and validate your BI architecture road map regularly; modify the plan if a module or phase becomes unnecessary or needs to be reprioritized.

The road map should be reviewed by a governance or steering committee, which should meet at regular intervals (biweekly is common). Typical participants in the committee include business sponsors, representatives from the security division (if one exists), executive sponsors, data architects, and BI directors. Topics for each meeting should include the status of the road map, risks, dependencies, and pertinent business updates that the steering committee contributes. The group should also determine when one road map phase is complete and the next is to begin.

An organization in the pharmacy-network industry, for example, set goals to triple its client base in one year; to do so would more than triple the organization’s data. The business and executive members of the steering committee tracked these goals and helped reprioritize the road map to acquire an analytic appliance much sooner than originally planned. The steering committee provided valuable insight that allowed the road map to evolve in line with the business.

Mistake 9: Overlooking the Overall Enterprise Architecture

As you prepare your road map to meet business goals, provide more capabilities, or improve the overall maturity of your architecture, consider overall enterprise IT goals. Many organizations today are moving toward an SOA. Data management in the SOA is a critical component that is sometimes overlooked. An SOA and a data warehouse can and should coexist, and many product vendors today have upgraded to include data services as part of their functionality.

A data service allows data to be consumed or exposed in a “black box” manner to another party. A service can be written to protect the integrity, uniqueness, and relationships of the data. One hot topic today is master data management in an SOA. Master data services can act as the authoritative source for master data (such as customers, products, events, and assets). Whether or not your organization’s IT initiatives include SOA, there likely are initiatives that the data team should be aware of, plan for, and use to determine ways to consume, expose, and protect data.

Mistake 10: Restricting Your Tools to Traditional Data Management Technology

In creating a BI road map, many IT organizations fail to think outside the traditional data management technology stack or to include solutions such as business process management or text analytics. They still focus on ETL, database platforms, and reporting products as the primary tools in their data arsenal. There are many other options for solving challenging problems, such as data matching, real-time data integration, searching unstructured data, and achieving performance to meet service-level agreements.

An organization was using custom Java code filled with regular expressions and if/then/else statements to cleanse and match incoming data from text files. It found that such logic is prone to error and difficult to maintain. This organization recognized that its data cleansing challenges were much more difficult than what a traditional ETL tool could handle. It was willing to invest time and resources in finding a data quality tool that performed mathematical algorithms on the incoming data to match it against a master list.

There are many best-of-breed solutions that can specifically meet challenging business requirements or technical problems. By researching and considering these products, you can add tremendous value to your BI architecture road map as you create and implement it. Attending conferences or Webinars and reading industry journals are good ways to keep up to date about products in the data industry.


About the Author

Mary Beth Kush is the director of performance management at Acumen Solutions, a business and technology consulting firm. For more than 10 years, she has been delivering mission-critical solutions for commercial clients, nonprofit organizations, and the federal government. Acumen’s performance management practice focuses on solutions for data warehousing, data integration, business intelligence, program assurance, and cost optimization.

TDWI Membership

Get immediate access to training discounts, video library, BI Teams, Skills, Budget Report, and more

Individual, Student, and Team memberships available.