Sie sind auf Seite 1von 41

PLANNING YOUR DATA

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.

 Once you have a list of roles, you are ready to


assign individual persons to the team roles.
Roles and Responsibilities
 In the OLTP system project, you will find
the job titles of project manager, business
analyst, systems analyst, programmer, data
analyst, database administrator, and so on
 Data warehousing authors and
practitioners tend to classify roles or job
titles in various ways. They first come up
with broad classifications and then include
individual job titles within these
classifications.
classifications of the roles:
 Staffing for initial development, staffing for
testing, staffing for ongoing maintenance,
 staffing for data warehouse management
 IT and end-users, then sub classifications
within each of the two broad classifications,
followed by further sub classifications
 Front office roles, back office roles
Coaches, regular lineup, special teams
 Management, development, support
Administration, data acquisition, data storage,
information delivery
Roles and responsibilities of a data
warehouse project team.
 Executive Sponsor
Direction, support, arbitration.
 Project Manager
Assignments, monitoring, control.
 User Liaison Manager
Coordination with user groups.
 Lead Architect
Architecture design.
 Infrastructure Specialist
Infrastructure design/construction.
 Business Analyst
Requirements definition.
 Data Modeler
Relational and dimensional modeling.
Roles and responsibilities of a data
warehouse project team.
 Data Warehouse Administrator
DBA functions.
 Data Transformation Specialist
Data extraction, integration, transformation.
 Quality Assurance Analyst
Quality control for warehouse data.
 Testing Coordinator
Program, system, tools testing.
 End-User Applications Specialist
Confirmation of data meanings/relationships.
 Development Programmer
In-house programs and scripts.
 Lead Trainer
Coordination of User and Team training.
Skills and experience levels required
for a data warehouse project team.
 Executive Sponsor
Senior level executive, in-depth knowledge of
the business, enthusiasm and ability to moderate
and arbitrate as necessary.
 Project Manager
People skills, project management experience,
business and user oriented, ability to be practical
and effective.
 User Liaison Manager
People skills, respected in user community,
organization skills, team player, knowledge of
systems from user viewpoint.
 Lead Architect
Analytical skills, ability to see the big picture,
expertise in interfaces, knowledge of data
warehouse concepts.
Skills and experience levels required
for a data warehouse project team.
 Infrastructure Specialist
Specialist in hardware, operating systems,
computing platforms, experience as
operations staff.
 Business Analyst
Analytical skills, ability to interact with users,
sufficient industry experience as analyst.
 Data Modeler
Expertise in relational and dimensional
modeling with case tools, experience as data
analyst.
Skills and experience levels required
for a data warehouse project team.
 Data Warehouse Administrator
Expert in physical database design and
implementation, experience as relational DBA,
MDDBMS experience a plus.
 Data Transformation Specialist
Knowledge of data structures, in-depth knowledge
of source systems, experience as analyst.
 Quality Assurance Analyst
Knowledge of data quality techniques, knowledge
of source systems data, experience as analyst.
 Testing Coordinator
Familiarity with testing methods and standards,
use of testing tools, knowledge of some data
warehouse information delivery tools, experience as
programmer/analyst.
Skills and experience levels required
for a data warehouse project team.
 End-User Applications Specialist
In-depth knowledge of source applications.
 Development Programmer
Programming and analysis skills, experience
as programmer in selected language and
DBMS.
 Lead Trainer
Training skills, experience in IT/User training,
coordination and organization skills.
User participation in data
warehouse development.
 Project Planning
Provide goals, objectives, expectations,
business information during preliminary
survey; grant active top management
support; initiate project as executive
sponsor.
 Requirements Definition
Actively participate in meetings for
defining requirements; identify all source
systems; define metrics for measuring
business success, and business dimensions
for analysis; define information needed from
data warehouse.
User participation in data
warehouse development.
 Design
Review dimensional data model, data extraction
and transformation design; provide anticipated usage
for database sizing; review architectural design and
metadata; participate in tool selection; review
information delivery design.
 Construction
Actively participate in user acceptance testing; test
information delivery tools; validate data
extraction and transformation functions; confirm data
quality; test usage of metadata; benchmark
query functions; test OLAP functions; participate in
application documentation.
User participation in data
warehouse development.
 Deployment
Verify audit trails and confirm initial data
load; match deliverables against stated
expectations; arrange and participate in
user training; provide final acceptance.
 Maintenance
Provide input for enhancements; test and
accept enhancements.
Guiding Principles( 26 sep)
 Sponsorship.
No data warehouse project succeeds without
strong and committed executive sponsorship
 Project Manager.
It is a serious mistake to have a project manager
who is more technology- oriented than user-oriented
and business-oriented.
 New Paradigm.
Data warehousing is new for most companies;
innovative project management methods are essential to
deal with the unexpected challenges.
 Team Roles.
Team roles are not to be assigned arbitrarily; the
roles must reflect the needs
of each individual data warehouse project.
Guiding Principles( 26 sep)
 User Requirements.
Although obvious, user requirements alone form
the driving force of every task on the project
schedule.
 Building for Growth.
Number of users and number of queries increase
very quickly after deployment; data warehouses not
built for growth will crumble swiftly.
 Project Politics.
The first data warehouse project in a company
poses challenges and threats to users at different
levels; trying to handle project politics is like walking
the proverbial tightrope, to be trodden with extreme
caution.
Guiding Principles( 26 sep)
 Realistic Expectations.
It is easy to promise the world in the first data
warehouse project; setting expectations at the right and
attainable levels is the best course.
 Dimensional Data Modeling.
A well-designed dimensional data model is a required
foundation and blueprint.
 External Data.
A data warehouse does not live by internal data alone;
data from relevant external sources is an absolutely
necessary ingredient.
 Training.
Data warehouse user tools are different and new. If the users
do not know how
to use the tools, they will not use the data warehouse. An
unused data warehouse is a failed data warehouse.
Warning Signs
 you must keep a close watch for any warning
signs that may spell disaster.
 be vigilant and keep a close watch.
 Your corrective action for potential problems
may be different depending on your
circumstances.
Success Factors
 Queries and reports—rapid increase in the
number of queries and reports requested by
the users directly from the data warehouse
Success Factors- Cont’d
 Query types—queries becoming more
sophisticated
 Active users—steady increase in the
number of users
 Usage—users spending more and more
time in the data warehouse looking for
solutions
 Turnaround times—marked decrease in
the times required for obtaining strategic
information
Adopt a Practical Approach
 Adopt a practical approach to managing the
project.
 you are totally results oriented.
 You constantly balance the significant activities
against the less important ones and adjust the
priorities
 Rearrange the priorities as and when
necessary.
 Let project schedules act as guides for smooth
workflow and achieving results, not just
to control and inhibit creativity.
Adopt a Practical Approach
 Review project task dependencies
continuously.
 Avoid too much analysis and too much
planning.
 Avoid bleeding edge and unproven
technologies.
 These deliverables will sustain the interest
of users and also serve as proof-of-concept
systems.
 Build the architecture first, and only then
the tools.
Analysis of a successful data
warehouse.
Business Context
Challenges
Technology and Approach
Success Factors
Benefits Achieved

----END----

Das könnte Ihnen auch gefallen