Beruflich Dokumente
Kultur Dokumente
WAREHOUSE
improper planning and inadequate project
management tend to result in failures.
You need to develop criteria for assessing the value
expected from your data warehouse.
Type of DWH built and where to keep it.
Data incoming and out going.
Who will manage
KEY ISSUES
Value and Expectations
Risk Assessment
Top-Down or Bottom-Up
Build or Buy
Single Vendor or Best-of-Breed
Business Requirements, Not Technology
Top Management Support
Justifying Your Data Warehouse
The Overall Plan
Value and Expectations
Some companies jump into DWH without
assessing the value to be derived from
their proposed DWH.
First establish the suitability of solution.
Will your data warehouse help the
executives and managers to do better
planning and make better decisions?
Is it going to improve the bottom line?
Is it going to increase market share? If so,
by how much?
Risk Assessment
Associate project risks.
What are the risks faced by the company
without the benefits derivable from a data
warehouse?
What are the loses and opportunities.
Use the culture and business conditions of
your company to assess the risks. Include
this assessment as part of your planning
document.
Top-Down or Bottom-Up
The top-down approach is to start at the
enterprise-wide data warehouse, and
possibly build it iteratively.(Then data from
the overall , large enterprise-wide data
warehouse flows into departmental and
subject data marts)
The bottom-up approach is to start by
building individual data marts, one by one.
The conglomerate of these data marts will
make up the enterprise data warehouse.
Build or Buy
The real question is how much of your data
marts should you build yourselves?
Single Vendor or Best-of-Breed
Choose the product from the single
vendor(high level of integration , constant
and free negotiation) or multiple( builds
environment fit to your organization and
compromise between the DB and support
tools , best suited for the specific functions)
However, the multivendor approach is not
advisable if your environment is not heavily
technical.
Business Requirements, Not
Technology
Remember, data warehousing is not about
technology, it is about solving users’ need
for strategic information. Do not plan to
build the data warehouse before
understanding the requirements.
As part of the preliminary survey, include a
source system audit. Even at this stage, you
must have a fairly good idea from where the
data is going to be extracted for the data
warehouse.
Top Management Support
No major initiative in a company can succeed
without support from senior management.
In some companies, a senior executive
outside of IT becomes the primary sponsor.
Justifying Your Data Warehouse
Here the justification is based mainly on
intuition and potential competitive pressures.
The top management is able to readily
recognize the benefits of data integration,
improved data quality, user autonomy in running
queries and analyses, and the ease of
information accessibility.
Approaches for preparing the
Justification
1. Calculate the current technology costs to
produce the applications and reports
supporting strategic decision making.
2. Calculate the business value of the proposed
data warehouse.
3. Identify all the components that will be
affected by the proposed data warehouse
and those that will affect the data
warehouse.
The Overall Plan
INTRODUCTION
MISSION STATEMENT
SCOPE
GOALS & OBJECTIVES
KEY ISSUES & OPTIONS
VALUES & EXPECTATIONS
JUSTIFICATION
EXECUTIVE SPONSORSHIP
IMPLEMENTATION STRATEGY
TENTATIVE SCHEDULE
PROJECT AUTHORIZATION
THE DATA WAREHOUSE PROJECT
Methods needed to build the applications
from planning through implementation.
If you are new to data warehousing, your
first data warehouse project will reveal the
major differences.
How is it Different?
A comparison with an OLTP application
project will help us recognize the
differences.
Differences: DWH & OLTP
First you have the data acquisition
component.
Next is the data storage component.
There is the information delivery
component.
Consciously recognize that a data
warehouse project has broader scope,
tends to be more complex, and involves
many different technologies.
Allow for extra time and effort for newer
types of activities.
Differences: DWH & OLTP
A data warehouse project has many out-of-
the-ordinary tasks.
Metadata in a data warehouse is so
significant that it needs special treatment
throughout the project.
plan to include time for the evaluation and
selection of tools.
Allow time to build and complete the
infrastructure.
Include enough time for the architecture
design.
Assessment of Readiness
Lower the risks of big surprises occurring
during implementation
Provide a proactive approach to problem
resolution
Reassess corporate commitment
Review and reidentify project scope and
size
Identify critical success factors
Restate user expectations
Ascertain training needs
The Life-Cycle Approach
You know how to begin with a project plan,
move into the requirements analysis phase,
then into the design, construction, and
testing phases, and finally into the
implementation phase.
It enforces orderliness and enables a
systematic approach to building computer
systems.
The life cycle methodology breaks down the
project complexity and removes any
ambiguity with regard to the responsibilities
of project team members.
Sample outline of a data warehouse
project plan.
INTRODUCTION
PURPOSE
ASSESSMENT OF READINESS
GOALS & OBJECTIVES
STAKEHOLDERS
ASSUMPTIONS
CRITICAL ISSUES
SUCCESS FACTORS
PROJECT TEAM
PROJECT SCHEDULE
DEPLOYMENT DETAILS
THE DEVELOPMENT PHASES
Establish the underlying infrastructure
to support the architecture for ensuring the
Data Acquisition, Data Storage and
Information Delivery.
Project plan
Requirements definition
Design
Construction
Deployment
Growth and maintenance
Adopting Agile Development
Agile development methodology encourages
collaboration among project team members
and users, and promotes iterative and
incremental development efforts.
Core Values.
Values that are emphasized include
striving for simplicity and not being
bogged down in complexity, providing and
obtaining constant feedback on individual
development tasks, fostering free and
uninhibited communication, and rewarding
courage to learn from mistakes.
Adopting Agile Development
Core Principles.
Principles that are followed include encouraging
quality, embracing change, changing incrementally,
adopting simplicity, and providing rapid feedback.
Core Practices.
Practices that are implemented include
creating short releases of application components,
performing development tasks jointly (“pair
programming”),
Variables.
Control variables that can be manipulated
for trade-offs to achieve results are
time, quality, scope, and cost.
THE PROJECT TEAM
The success of a data warehouse project rides
on the shoulders of the project team.
It takes several trained and specially skilled
persons to form the project team.
Two things can break a project:
(1) complexity overload
The project team minimizes the
complexity of the effort by sharing and
performing. When the right person on the
team, with the right type of skills and with the
right level of experience, does an individual
task, this person is really resolving the
complexity issue.
(2)Responsibility ambiguity.
In a properly constituted project team, each
person is given specific responsibilities or a
particular role based on his or her skill and
experience level. In such a team, there is no
confusion or ambiguity about responsibilities.
Organizing the Project Team
If you are organizing and putting together a
team to work on an OLTP system
development, you know that the required
skills set is of a reasonable size and is
manageable.
Organizing the Project
Team(cont’d)
You would need specialized skills in the areas
of project management, requirements analysis,
application design, database design, and
application testing.
----END----