Long Term Objectives

Larissa Moss and Sid Adelman

This article is excerpted from a book tentatively titled, Data Warehouse Project Management (Addison-Wesley, Spring 2000). All material is copyright Addison Wesley Longman, Sid Adelman and Larissa Moss.  It is the third in a three-part series on Data Warehouse Goals and Objectives.

In our previous article (DM Review, date) we reviewed common short term data warehouse objectives. In this article we will conclude our series with a discussion about long term data warehouse objectives and the importance of synchronizing all data warehouse objectives with the strategic goals of the organization.

The long term data warehouse objectives resemble many of the original data management objectives from the early 1980’s.  If you focus on your short term objectives during your data warehouse iterations, your long term objectives will almost assuredly be realized.

Here are some examples of long term data warehouse objectives:

1. Reconcile different views of the same data – If your short term goals include minimizing inconsistent reports and providing the capability for data sharing, you are already addressing this reconciliation effort to some degree.  You may have to make sub-optimal choices from an organizational perspective in order to complete your project within the scheduled time frame and within your budget, both of which were based on your cost benefit analysis.  This means that you may not achieve comprehensive reconciliation of different views one project at a time.  However, as your data warehouse grows with each iteration, more and more different views of the same data will be addressed and resolved.If your organization is committed to achieving the highest level of maturity in terms of data management, your Data Administration unit is most likely chartered with the task of reconciling the remaining different views of the same data.  However, this activity is outside the scope of a data warehouse project.  As project manager your involvement in this activity ends with your communication to Data Administration about:
   1. All the different views of the same data you have discovered
   2. The views you are planning to reconcile in your project
   3. The views you are not addressing in your project
2. Provide a consolidated picture of enterprise data – One of your project deliverables will be a logical data model of the data within the scope of your project.  As you add new data and new requirements to the data warehouse in future iterations, you will expand the logical data model.  Over time, this model will grow into a consolidated picture of enterprise data within the scope of the data warehouse.An organization trying to achieve the highest level of maturity in terms of data management, will have chartered the Data Administration unit with the task of completing that picture.  We have to remember that even a fully completed and populated data warehouse will not have all of the operational data used by the organization.  To complete the picture, Data Administration will create or obtain the logical data models from all other systems and merge them into a high-level enterprise model.  Clearly, this activity is outside the scope of a data warehouse project.  As project manager your only involvement is to share your logical data model with Data Administration.
3. Create a virtual “one-stop-shopping” data environment – One-stop-shopping means that
   1. all the data in the data warehouse environment is accessible through one common interface or “point-of-entry”
   2. a suite of standard query and reporting tools is available and easy to use
   3. the physical location of the data is transparent to the users
   4. the data is integrated, clean and consistent, or at least reconcilable
   5. the query results are consistent, or at least reconcilableIn order to achieve this long term objective, two types of architectures must be very well designed and redesigned with every data warehouse iteration: the technical architecture and the data architecture.
   6. Technical architecture – There are many parts to technical architecture, but in this context we will address only three:  the application layer, data access tools, and database structure.
      1. Application layer – This is a “store front”, a point of entry.  It can be a home-grown application written in a conventional programming language with a desktop icon to launch it, or it can be a purchased software package, or a web application.  All data warehouse components are “hooked” into it and are launched from it.  This type of an application layer could even be expanded to provide user access to systems other than the data warehouse.
      2. Data access tools – The second tier in this architecture is a suite of data access tools. This should include a query library of pre-written queries using these tools, or written in native SQL.
      3. Database structure – Also part of the second tier are the actual database files.  Their physical placements on one server or another, in one physical location or another, will be completely transparent to the users.  All the communication and synchronization between the physical files are handled by the database management system (DBMS) or middleware.If these three components are designed properly, it will ensure that all the data is accessible through one common interface, that a suite of standard tools is easy to use, and that the physical placement of data is transparent to the users.
   7. Data architecture – There are two parts to data architecture:  the logical data architecture, which is a paper model, and the physical data architecture, which is comprised of the actual physical databases.
      1. Logical data architecture – Data issues are addressed at the logical level with a logical data model and meta data.  The logical data model will help attain data integration and data sharing, the meta data will help achieve sanctioned definitions and domains.
      2. Physical data architecture – Access and performance issues are addressed at the physical level with the appropriate database designs.  Since one logical data model can, and often will, be implemented as two or three differently designed databases, it is important to capture the mapping between the logical and physical data architectures as meta data.If these two data architectures are well designed, it will ensure that all the data is integrated, clean and consistent, and that all query results are consistent, or at least reconcilable.

Matching the Strategic Company Goals

All of your short term and long term data warehouse objectives are for not, if they don’t match the strategic goals and objectives of your organization.  Let’s say that one of your data warehouse objectives is to integrate data in order to get a better understanding of your customers’ buying habits so that you can sell them more profitable products. On the other hand, your company’s strategic goal is to reduce production costs.  With this kind of mismatch between company goals and data warehouse objectives you will not get upper management support for your data warehouse.

The strategic goals of an organization usually revolve around eliminating some business pain.  That business pain could be loss of revenue, inability to keep up with competitors, high production costs, and inability to expand the market share.  The development of a data warehouse must support the strategic goals of your organization.

As you are identifying the goals and objectives for your data warehouse project, keep asking yourself:

1. What is the business pain?
2. Do my objectives match the business pain?
3. Will the data warehouse contribute to the relief of that pain?

To build a costly data warehouse just for the principal of having one, or because it is a trendy thing to do, is an unwise business decision.

Conclusion

While some of the long term data warehouse objectives can be seen as a natural outcome of implementing the short term data warehouse objectives, other long term objectives, especially those that span across the organization, will require significant participation from Data Administration.  But most importantly, all data warehouse objectives, whether short term or long term, must be aligned with the strategic goals of the organization.

About the Authors

Larissa Moss is president of Method Focus Inc., a consulting firm specializing in data warehousing.  Larissa  has published numerous articles on various data  management topics. She frequently teaches seminars in the United States, Canada and Europe.

Larissa can be reached at methodfocus@earthlink.net

Sid Adelman is a charter member of Business Information Alliance.  He co-authored a methodology and project planning product tailored specifically for data warehouse.  Sid is an international speaker at data warehouse and industry conferences.

He can be reached at sidadelman@aol.com