Envision the Mountain and the Path

A wise man once said that "a journey of a thousand mile begins with a single step." Quite true. However, taking the first step on such a journey without a map and a compass could be a career limiting move--especially if you are leading the expedition for your organization's data warehouse strategy. Poor planning, implementation and expectation management can cause the business sponsors who are depending on your hot project to turn cold on you in a minute. Before you know it, you're out of that corner office and back in the cubicle jungle. But with some forethought, you can avoid most of the pitfalls ahead--and maybe even get an office with a view.

First, we need to build a road map to validate the business vision and project methodology. Then we'll use four points of our data warehouse compass to validate our progress. The result should be a safe journey that concludes with our project crossing the information wilderness and marking a path for others to follow.

Business Vision and Expectation Management

Business vision should be identified, documented and validated to include a crisp description of what new information or insight is to be gained by building the data warehouse. Who are the business users to be supported? Are there unmet information demands? Do users expect to view the data warehouse as an executive information system (EIS), a decision support system (DSS) or a data mining (DM) framework? The architectural design and implementation will be quite different depending on which views are expected. To meet expectations, you must keep to the project scope and deliver incremental value before trying to change objectives during implementation.

Project Methodology--A Spiral Approach

Predictability--the cornerstone of project methodology. A guiding thought: the "principle of least astonishment." No unexpected surprises. Data warehouse projects are best developed with a combination of proven methodology components, customized for the unique nature of the task at hand. This combination of information engineering, iterative prototyping and object-oriented development works best. I refer to this as the Client/Server Spiral Methodology (CSSM).

CSSM incorporates data modeling from an information engineering approach--at a logical and physical implementation level. The physical implementation may support relational on-line analytical processing (ROLAP) or multidimensional on-line analytical processing (MOLAP). The physical implementation will determine which vendor products to eliminate from our technology architecture.

One of the principles of object-oriented development (OOD) centers on the generic abstraction of methods (business functions) and the data-driven nature of the properties (data attributes). Business analysis should be focused to understand the common information views and queries for the abstraction layer in the architecture. This could be meta data, summary tables or MOLAP dimensions. Generic business abstraction will greatly aid in productivity for new development and maintenance, as well as assist in the discovery of business rules.

Although methodology sounds scientific, not all business requirements or implementation techniques can be known in advance. Adding an iterative development process, with prototypes, forces realism and technical validation that can correct your course in midstream and avoid the unpleasant surprises that can surface without this proof of concept approach. Trust your methodology--but verify!

Four Points of the DW Compass

There are four points to validating a project that act as a compass against our business road map. Review of these points against business objectives and management expectations will improve the project success potential exponentially:

  1. Data Abstraction: Has the project isolated a rules-based abstraction process for generic data transformation? How hard is it to add new rules for unexpected data?
  2. Data Hygiene: Has the project created a rules-driven data scrubbing layer that is flexible for expansion? Have the rules been validated with volume and with users?
  3. Warehouse Architecture: Is the warehouse architecture appropriate for supporting all types of user information demands--EIS, DSS and DM? Does the physical data implementation schema maximize flexibility and performance (ROLAP vs MOLAP)?
  4. Interface Architecture: Can the interface architecture support ad hoc queries, canned reports, data mining and data visualization? How about accepting external rules processing of extracts of the warehouse data? Web browser (Internet, intranet or extranet) access to the data warehouse?

A vision, a road map and a compass. These are the essential tools you'll need for a successful data warehouse project. Trust in them. Go forth and blaze your trail. Others will follow.

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