Client Resource Requirements for Data Warehouse Projects

data warehouse concepts

white paper

the Overview

A data warehouse is a set of databases designed for query and analysis rather than for transaction processing. In a nutshell, data is brought into the data warehouse and transformed into information which is then published to a set of subscribers. The data can come from a number of sources in a number of different formats. The data warehouse should import and combine the data. Data quality issues should be addressed to promote trust in the published information.
This document serves to explain what resources a potential customer would need in order to ensure successful implementation of an enduring solution.

the Objectives

The main objective is to implement a robust, secure and flexible data warehouse where data quality is assured and which is fit for purpose.
Put simply, the data warehouse should do what it is meant to do, and it must do it for the minimum period of time agreed by all stakeholders.

the Customer Resource Requirements

The customer resourcing requirements can be split into two main phases:

• Initial delivery of the solution up to the point of go-live
• Ongoing operations of the enduring solution

Once go-live has been achieved it is likely that enhancements and/or changes may be required. This will require the availability of the same group of people in the initial delivery phase. Several roles are mentioned below, but in reality every organisation is different. There are two very important roles required to ensure ongoing and enduring use of the data warehouse:

• Application Owner
• Data Owners

If these two roles are not well defined and managed the result would most likely be a failed project (after approximately two to three years)

the Initial delivery of the Solution

The following resources would be deemed essential for a successful data warehouse project implementation:

• Main Stakeholders

This includes decision makers for:

• Financial matters
• Functional requirements

In many cases there is a mix and mash of the above. Usually a single person is identified at the main stakeholder or the application owner for the initial planning and delivery. It is important to identify and appoint someone to this role because a multi-headed project is often not effective.

• Subject Matter Experts

These are people that may be required to provide additional information in order to design and complete and suitable solutions.

• Infrastructure Resources

This role is often performed by the “IT department”. It may be necessary to know about existing technology, future plans, acceptable technology, current providers, infrastructure standards, etc.

• Data Providers

Data providers are essential during various phases of the solution delivery. They will be required during the planning phase to provide information about the data that they will provide. They may then be necessary when data quality issues arise. Finally, they will be required to plan and agree how the incoming feeds will be provided and ongoing responsibility.

• Testers

Suitable testers will need to sign-off on various stages of delivery including the final delivered solution.

• Super-Users and Trainers

Most data warehouse systems involve a train-the-trainer approach, some customers prefer regular planned training sessions. This is one of the most important aspects of the project and usually takes place as the final step before sign-off of the delivered solutions.
There could (and usually should) be a strong overlap between this role and all others mentioned above.

the Ongoing Resource Requirements

Any neglected data warehouse will fail. It is essential that issues of trust and data quality are addressed on an ongoing basis. Data, if left to itself, tends to a state of chaos. Chaos does not co-exist with trusted information quality.
The application owner may not make financial decisions, but would have access to the decision-maker (who is not listed separately because it’s obvious this role exists anyway)

the Application Owner

Applications, including data warehouses, should have one clear owner (a person or a well-structured team). Multi-ownership simply does not work. The owner is accountable for the overall system, including ensuring that other roles are not neglected.
Most likely an in-house resource.

the Data Owners

This role is often neglected. Without clear ownership of incoming data it is virtually impossible to provide enduring quality and trust. Data owners should be identified, appointed and held accountable for the data. Clear communication plans should be drawn up.
Clear ownership of the published information should also be defined. This role could (and often is) handled by the application owner. Put simply, someone must be responsible for ensuring that the published data is fit for purpose.
The data owners would most likely be a combination of in-house and external.

the Security Owner

Every system that contains any degree of sensitive data should have very clear security ownership defined. This could include multiple roles, but the general rule of single person or team accountability should be defined. Broadly speaking, these are the two roles required:

• General security of the hosted solution (on-premise or cloud) – most likely sub-contracted but could be in-house
• Monitoring access to data – could be sub-contracted or in-house

the Help desk

It may be necessary to appoint a separate person or team to handle day to day queries, access requests etc. Usually this role also owns the communication plan.
This role could be combined with the monitoring of access to information and could be sub-contracted.
The help desk role could also be responsible for training new users.

the Stakeholders and Subscribers

It goes without saying that there will be stakeholders and subscribers. These will be the people who actually use the information produced by the data warehouse. In order to ensure good return on investment it is necessary to identify stakeholders and subscribers to determine how they use the information produced by the data warehouse. If nobody actually uses the information, it may be necessary to make other changes or decommission the system altogether.