Continuing my recent focus on packaged business intelligence (PBI), this month's column addresses some of the major architectural considerations in the purchase of PBI, particularly those that are Category 2 (i.e., expected to have enterprise-wide impact). The major areas of consideration, other than price, are methodology, data sourcing, the applications and the data model.

Methodology

One of the most valuable byproducts of the data warehousing revolution in the early 1990s was the development of several sophisticated iterative development methodologies –­ for example, Iterations from Prism. These have become standard in the industry for customer relationship management (CRM), data warehousing and business intelligence projects, and for many others as well.

Be sure an iterative approach can be followed with your PBI. You need to grow into any enterprise solution. Can you grow by application module, source system or subject area with your PBI, or is it an all-or-nothing solution? Even though the industry has become much more adaptive to the need for speed, and PBIs are a manifestation of that, some things are still "too good to be true." Fully populated 30-day enterprise data warehouses supporting cross-enterprise applications for Fortune 50 companies fall into this category.

Data Sourcing

Look at the data latency in the PBI data warehouse. How fresh is the data? Is it possible to make the loads occur more frequently? If so, what is the process? This is an extremely relevant question today because most of the people I speak with would like more current data in their data warehouse.

Of course, loads are useless without fresh data to load from the operational systems. If the extracts can only happen daily, loads would only happen daily as well. Operational systems must be co- conspirators in achieving more "real-time" data warehouse loading. They must be built for concurrent access and extract activities. No PBI can remedy operational problems of this nature that may exist. However, many PBIs are built to function with newer operational systems, so-called ERPs. Many ERPs are "data warehouse-ready" in that they are built not only for concurrent activities, but can also ­ through built-in capabilities ­ push various data that may be interesting to data warehouses.

Look at the PBI's provisions for late-arriving data. Due to various operational difficulties, operational systems frequently are unable to consistently supply data feeds. What happens then? Can it pick up the data later or will it wait until the data arrives, potentially impacting availability windows?

Does the PBI support all your potential data sources? If so, how does it support those sources? While many PBIs have built-in ETL tools or functionality nearly equivalent to modern ETL tools, determine if they "natively" support your source systems with built- in knowledge about the system. If not, that will need to be built. Also, understand how you can change the preset transformations.

You need options with your data sourcing. Make sure your PBI does not lock you into a data sourcing situation that is not scalable.

The Applications

There is a wide array of applications available within Category 2 PBIs, spanning CRM, enterprise performance management and strategic management areas as well as several industry-specific offerings. For cost- effectiveness, many of these applications need to have a relevancy within your organization. Involve the relevant prospective users when evaluating the usefulness of each application.

Regardless of the variety of applications, ad hoc access to data is always required in a data warehouse. If this layer is not provided in any way, it will have to be added.

While the applications are usually the sizzle that sells the steak and the point of interest on behalf of the business unit funding the purchase, make sure the application presentation quality remains only one criterion in the mix.

The Data Model

We have filled volumes with specifics about the relevancy of a generic data model to an individual business. While the models may support the PBI applications, they may not support the business in areas of completeness, subject-area relationships and dimension depth. For example, how many levels are in your customer dimension? We have clients with one level and others with twelve levels. Neither fits into a setup of six fixed levels.

Suffice it to say that it will be necessary to make changes to the data model! Therefore, how the solution is equipped to deal with model changes is a major criterion. Especially important is the ability to make your changes and synchronize them with the changes that the PBI vendor will continue to make to the solution in later releases.

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