Aligning Data Warehouses with Business Strategies

By Jane Griffin
President and CEO, Systems Techniques, Inc.

Introduction

A data warehouse is a collection center that offers an organization's decision makers access to "critical" information. But how does an organization decide which information is "critical" enough to be collected and stored within the warehouse and which information can remain outside? By analyzing their business strategies and identifying business objectives and critical success factors, organizations can begin to pinpoint the essential and "critical" information.

Business Plan: Prerequisite to Success

Critical success factors exist within an organization to support the achievement of the organization's goals and objectives. They are those things that the organization must do absolutely right to achieve their vision of success. Business objectives and CSFs are, or should be, present at all levels of the enterprise to support the achievement of the organization's vision and mission. They are fundamental to success and should be an integral part of an organization's business plan.

The business plan represents and defines all organizational elements, as depicted in Figure 1. One of these elements is the definition of Strategies that outline the approach for implementing the plan. Strategies are in turn supported by a variety of Processes necessary to implement the strategies.

Figure 1: Stages of the Business Plan Development

In implementing a data warehouse, the warehouse should link data to objectives, CSFs, strategies, and processes. The "musts" to ensuring you get a high return on your data warehouse dollar are:

• Look to the business plan for guidance.
• Identify and analyze the high-impact processes (HIPs) that are essential to business mission.
• Begin building data models that support these HIPs.
• Build access tools that connect the process to the data.

HIPs: The Driving Force

Deciding what key activities to track is essentially deciding what drives the business. In identifying key activities, it is important to determine what data needs to be tracked. Likewise, this data should map back to the key business drivers. The result of this exercise is a set of guiding business standards and measurements. These standards and measurements can be grouped into high impact processes (HIPs).

In building an enterprise-wide data warehouse, the HIPs for every business function must be analyzed. Because many HIPs are cross-functional, it is important for each function to support the common goals and objectives of the enterprise. Therefore, HIPs must be defined with the participation, guidance, and buy-in of the individuals and groups that will use them. Through consensus-building workshops, participants from across the organization, at all levels of the hierarchy, must identify business requirements and plan for the implementation of new strategies.

These group workshops are often led by consultants experienced in developing business strategies, re-engineering, and building process and data models. First Union National Bank of Charlotte, N.C., recently used the proprietary workshop analysis sessions of the Atlanta-based consultancy Systems Techniques, Inc., to identify a decision support strategy aligned with the institution's business goals and objectives.

"We used these workshop sessions to help us define a decision support platform and identify what information needs to be available for determining behavioral patterns of customers, defining our target market, and analyzing product and customer profitability," says Kellie Wells, vice president and assistant director of First Union's Automation Division. "This process also showed us what information needs to be available at what distribution point."

During HIP analysis, participants identify the specific data entities and attributes that support each process. Participants should understand the information source, quantities, trends, and historical data needed to help define the warehouse's scope and infrastructure. HIPs are then mapped to legacy data sources and entities before the warehouse project team moves on to defining the technical architecture. This architecture should be built in support of the present and future technical strategies of the organization.

The Technical Architecture

The warehouse's technical architecture must be cost-effective, adaptable, and easily implemented. Proven and reliable technology should be employed—technology that not only supports the current technical infrastructure of the organization but is flexible for future growth.

Implementing the right technical foundation is critical to the success of the data warehousing project. As companies spread out into multiple buildings across cities, states and even countries, their corporate communications infrastructure must be able to adequately support data collection, distribution, replication and access. By capitalizing on and enhancing existing networks, companies can realize optimal benefits with minimal investment in new technologies or equipment.

Storage capacity is another critical component. Large amounts of data is often a requirement for the data warehouse. Relational Data Base Management Systems (RDBMS) can be an effective way to store large amounts of data. Use of these databases can offer unsurpassed business analysis and management capabilities. Issues to consider for selecting the right storage media and method include data load times, synchronization, recovery, summarization levels, method of data security implementation, data distribution, data access and query speed, and ease of maintenance.

In large organizations, mainframes and parallel processors can ease the burdens of loading, retrieval, translation and distribution of large amounts of data. However, some organizations may choose to implement a client/server environment, which can provide convenience and strength at the desktop for accessing, manipulating and presenting data, and in some instances can be robust enough to house the entire warehouse.

Another considerations in storage is the distribution of data throughout the organization. Data must be put into the hands of the people who are responsible for the achievement of business objectives and strategies—the process managers. It does not make sense to build large centralized corporate warehouses when you are in a distributed business environment. The reverse is also true. Pay careful attention to the needs for the organization before designing the data warehouse network. Go back and look at the analysis of HIPs to determine the information needs at each distribution point.

Access to the information is the final technical component. For organizations that are "drowning in data and dying for information," a well-designed, properly aligned data warehouse can give the right people access to the right information at the right time. Tools, typically graphical user interface tools, that enable access to the warehouse should facilitate the retrieval, analysis and transfer of information to the process managers in the organization. When properly designed, the data warehouse and its access tools allow users to retrieve information quickly and easily. Access must also be supported by an infrastructure that builds a bridge between the questions process managers ask and the answers within the warehouse. The data model structure and the user interface must be aligned with strategies to make this a reality.

Enterprise Data Model

While the architectural team designs, selects and builds the technical infrastructure, a modeling team should concentrate on building a data model that supports the HIPs. Warehouse data models should be built top-down to ensure they are properly aligned with the business mission. This involves analyzing and defining the entities identified during the HIP analysis.

Smart organizations look at information horizontally—across customers, products and organizations. Organizations that use inflexible and costly reporting tools to access information from disparate mainframe applications are suffering the consequences. Their method requires extensive support from the information technology staff. Even worse, in many cases, the managers cannot access information at all. Data warehouses must be built with a broader horizontal view of data around an enterprise data model, integrating data from the legacy applications to consistently and accurately view customer relationships, products, services and profitability.

Consolidation and integration of information across legacy applications within the model provides the blueprint for the development of the data warehouse. When complete, the data model also provides the criteria to evaluate the completeness and consistency of a design that will allow the migration of legacy information to one common data structure. After the enterprise model is built, the model must be validated by the business users and data mapped from legacy applications to the model, with more validation to follow.

Building the Meta Model

The next stage is the implementation of the data model that supports the business requirements. The data model, which includes all entities and required attributes, is transferred from the data modeling tool into the selected repository or meta model. The repository, which is also referred to as a metadata, meta model, or business information directory, is used to store the model, all legacy application data dictionaries, data transformation rules, and ultimately business views and rules. The future use of the meta model is threefold:

• Defines target attributes for mapping all data that should be harvested from legacy applications.
• Provides data for online help and data dictionary in the user interface—linking business questions to answers.
• Documents the data model.

Harvesting Legacy Data

Following construction and loading of the data model and the legacy master file descriptions into a repository, the next step is to relate the data in the legacy applications or other data sources to the entities and attributes within the data model. The repository serves as the documentation of the origin and destination of all data elements that will be harvested from the legacy applications and mapped to the new data model, as well as the rules that relate to their validation, calculation, transformation, values, etc. Mapping is a "bottom-up" process, unlike the data model development process, which was "top-down." Every data element, or attribute, identified during requirements identification, and all data required from legacy systems, must be mapped and defined in the new data model.

By establishing these relationships within the repository, it can be used to control and drive the collection, loading and presentation of data-linking business strategies to business views which in turn link to actual data.

Validation Process

Before proceeding, validation of the data mapping activity is critical. The participants from the initial requirements analysis sessions and those consulted during the data mapping activities should reconvene to validate the data mapping and make sure it answers the questions they have about their business. The repository, supporting modeling tools, and reporting tools play another role here. They should be relied upon to produce the documentation, cross-reference matrices, and presentations for the review sessions. The information is presented to the group for identification of additional information regarding individual attributes, keys, summary levels, frequencies, and historical data requirements. Any changes from the group must be incorporated into the repository as updates.

Linking Business Views to the Data Model

With data models built that support the HIPs and legacy data collected, the completed model must be linked back to the processes by establishing business views that support the processes. Business views are clusters of data represented by one or more entities and attributes that are linked together to support the measurement of standards and performance objectives defined during the HIP analysis.

Figure 3: Business models and Views within InformEnt

Figure 3 is an example of how Fiserv Fusion, a Pittsburgh-based organization, has linked business models to business views within their Information Enterprise (InformEnt) product. Fiserv provides outsourcing services for over 200 banks across the United States. Their InformEnt data warehouse product consolidates data across dozens of legacy applications. The InformEnt product is supported by a repository which drives all data collection, transformation, loading, selection, and presentation of data. According to Bill O'Neil, President of Fiserv, "The key to our success was the Business Information Directory, or repository, which is the keystone of our product."

Linking Business Views in the User Interface

By linking business views to business models or HIPs, this road map can be used to support the access to information. Users are empowered and technical support is minimized. The InformEnt product is an excellent example of how a user interface can be built around these linkages. Developed with graphical tools, the interface provides push-button access to pre-defined reports, as well as ad hoc query tools that enable drill-down and trend analysis capabilities. The data housed in the repository that supports the interface includes HIPs linked within the repository to the report dictionary, business views, entities, and data elements or attributes, all within the confines of proper security.

The user interface is always the most critical component in aligning the data warehouse with the business strategies. Designed correctly with the incorporation of the repository, the user interface can result in significant productivity gains. Rather than building static screens that require extensive maintenance, users can interface with screens that pull data directly from the repository or meta data. As more data is added to the model, the only change is to repository resident data. This not only reduces maintenance, but provides greater flexibility to the user, reduces learning curves, hides the complexities of the data model, and minimizes support requirements. This translates into improved productivity.

Figure 4: Linkage to Entities and Attributes

The InformEnt screen illustrated in Figure 4 shows the next level of detail behind the business view: the linkage to the actual entities and attributes. The two windows on the left, Deposit Balance and Deposit Dates, are the data warehouse entities with the attributes shown within each window. The user can select the individual elements required for the report or extract. The window on the right shows additional entities that can be linked directly to the entities on the left. If the user does not know the definition of the entity or the attribute, they simply click on the right mouse button and the definition, code translation, source of attribution, and translation rules are retrieved from the repository and displayed. Not only can users drill down in the data that resides in the warehouse to make better decisions, they can also drill down from the High Impact Process level to the actual data that defines the success or failure of the process—yielding the final step in linking business strategies to the data warehouse.

Final Alignment

When building a data warehouse, the best time to ensure that it aligns with business goals and strategies is before the groundbreaking begins. To move forward, an organization must have a sound business plan that links to business strategies and processes. To succeed, the organization must gain buy-in and consensus on the common goals and objectives of the organization from all levels of the enterprise, then put the tools in place to measure their success.

Jane Griffin is a featured speaker at The DCI Data Warehouse Conference and DCI's Data Warehouse World. This article first appeared on the Systems Techniques Web site and is reprinted with permission.