My online series of articles is focused on the need for businesses to get serious about approaches to developing an enterprise business intelligence (BI) and data warehouse (DW) capability. When pursuing this capability, it is important to adopt a holistic view, followed by disciplined investment and execution. To develop the future vision for this capability, one should consider seven interrelated areas:


  1. Strategy
  2. People
  3. Process
  4. Metrics
  5. Applications
  6. Data
  7. Architecture

This column explores an additional consideration of architecture - specifically addressing the role of packaged BI applications in an enterprise BI/DW architecture.


The Promise of Packaged Analytics


Many companies these days run their business, or at least significant areas of their business, using packaged applications configured to automate business processes across major functional areas such as finance, human resources (HR), manufacturing, supply chain management, customer service, sales, marketing, etc. These systems are good at capturing detailed transactional data about what is happening in the business.


The vendors that sell these enterprise applications systems usually also sell BI applications providing out-of-the-box reporting solutions that use the data from the enterprise applications. These BI applications usually come preconfigured with a set of reports that gather information from data structures (typically star schema data marts). They are populated using extract, transform and load (ETL) processes that source data from the enterprise application’s data stores. The good news is that these packaged analytic solutions enable reports to be delivered quickly with the data from the enterprise applications.


The Challenges of Packaged Analytics


Companies face several issues when they begin to implement packaged analytics applications:

  • Technology Architecture Challenges. Packaged analytics applications from the various enterprise application vendors typically are built using BI tools different from the other enterprise application vendors for things such as ETL, reporting and online application processing (OLAP). Some of the enterprise application vendors have pursued a strategy where they have, for the most part, developed their own independent BI tools that are only used with their packaged applications. Other enterprise application vendors have used tools that can be used by others in building custom BI applications. If you have enterprise applications from multiple vendors (as many companies do) and implement the packaged BI applications from each of them, you may find that you have inadvertently implemented multiple competing BI stacks. Also, these may likely be in conflict with the custom BI stack you are using for internally developed custom BI applications.


    All of this can create challenges to end users who may become confused, frustrated and less productive when having to use multiple reporting tools to answer questions. This inefficiency on the part of the end users can result in less effective and less timely decision-making, which negatively impacts the company’s bottom line.


    It also results in the need to implement, support and maintain multiple toolsets on multiple physical servers that are all basically performing the same function. This results in larger costs for hardware and software versus a scenario where you have one standardized BI stack used for all BI applications.


  • Organizational Challenges. In most IT departments, teams are organized around the functions they serve. For example one team handles the IT needs of finance while another handles the IT needs of manufacturing.


    If each of these teams is implementing enterprise applications and the related packaged analytics applications from different vendors, then each of these teams will have to develop and maintain skills on in the competing BI technologies. This results in increased labor costs rather than a scenario where you have one set of people and skills that you use to develop and support all BI applications using the standardized BI stack.


    Additionally, if the data required by a BI application needs to come from an enterprise architecture application that is outside the team’s domain, it can create turf battles over who should do the work.


  • Data and Metrics Challenges. The data and metrics challenges presented by packaged BI applications can be even more troublesome than the others. When there are multiple packaged BI applications being used, it can quickly result in a situation where the enterprise BI goal of “one version of the truth” is much more difficult to attain.


    For example, when end users require information from transaction systems of multiple vendors or need to include significant amounts of information from other “home grown” systems or even external third-party information sources, the benefits of packaged BI applications start to become less evident. To meet these needs you have to make hard choices to determine which packaged BI application should be customized in order to deliver the new solution or whether to develop a fully custom BI solution that pulls all the right data together.


    Before an integrated BI solution is implemented, the pioneering end users will assuredly be trying to solve the problem themselves by downloading data from each of the independent BI applications into spreadsheets or desktop databases. Inevitably, the end users will be defining metrics calculations differently than others, inadvertently creating more confusion within the company over the real numbers.

What to Do?


The first step in addressing the issue is recognizing the problem. Basically, it’s important to recognize that the implementation of packaged BI applications can actually cause the types of issues outlined above. Secondly, construct a plan to deal with them, preferably in advance of going too far down the path.


Companies must figure out which of the following three paths is best suited for their situation:

  1. Packaged Analytics Approach:

    • Enterprise BI applications are primarily slightly customized versions of the out-of-the-box analytic application provided by the enterprise architecture vendor.
    • Further customization or custom development - using the packaged analytics tools - are done to satisfy the occasional needs for data from other applications or external sources.
    • This approach works best when the vast majority ofinformation needed for enterprise BI solutions is all coming from one enterprise application from one vendor.
  2. Custom BI/DW Approach:

    • When on this path, BI applications are primarily custom applications using the standard BI stack, possibly implemented by a centralized BI team, using many of the principles outlined in my previous articles.
  3. Hybrid Approach:

    • This is the most common path being considered in many companies these days. So when on this path, there must be rules defined and followed that govern what will be done in the custom BI environment and the packaged BI solutions:
    1. Use packaged BI applications primarily for operational reporting by front-line employees using data sourced only from one enterprise application.
    2. Use custom BI applications for analytical reporting, dashboards and scorecards to be used by company leaders who need to have data sourced from multiple applications and external sources in order to support their decision-making.
    • Rules must be determined and detailed as appropriate for each company’s specific situation.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access