1. Planning and Managing the Data Warehouse Project
Schedule: Timing Topic
45 minutes Lecture
20 minutes Practice
65 minutes Total

2. Objectives
After completing this lesson, you should be able to do the following:
Explain the financial issues to be managed in developing and implementing a data warehouse
Outline techniques for obtaining business commitment to the warehouse
Outline the key tasks involved in managing a warehouse project
Discuss gathering business and user requirements
Discuss implementation requirements
Overview
This lesson introduces the planning that is critical to the success of a data warehouse project. Planning phases, deliverables, and project roles are identified. Overall warehouse strategy and project scope are defined.

3. Managing Financial Issues
Financial justifications for the data warehouse solution:
Intangible benefits:
Remain competitive
Respond to changing business conditions
Support reorganization
Better data and better decision making:
Reduce information system (IS) costs
Better response time
Rigorous reporting
Managing Financial Issues
A data warehouse project is a big investment in resources and finances. Management must be able to report on how the data warehouse benefits the business. Justification is divided into three main areas:
The intangible benefits are that the business can remain competitive, respond to changing business conditions, and support reorganization.
Better data and decision making reduce information technology costs, provide better response times, and provide rigorous reporting.

4. Managing Financial Issues
Productivity or ROI:
For internal users
For external users
Managing Financial Issues (continued)
Productivity or Return on Investment (ROI) benefit internal and external users.

5. ROI and Associated Costs
Build a strong case to establish:
Costs
ROI
Profitability
Efficiency
Objectives
Consider:
Impact of time for ETL
Additional storage requirements
Cost of redundant data
Cost of database, software licenses, labor
ROI and Associated Costs
The financial justification must set out a strong case that clearly establishes measurements such as cost versus return on investment, and increased efficiency and profit. It must also set clearly defined objectives that can be monitored and measured.
Associated Costs
Along with cost justification, you should provide a plan that specifies other factors that will impact the cost of the project and other aspects of the business.
The cost of developing ETL or purchasing the ETL tools
The actual time required for data cleansing, transformation, and extraction, which may impact day-to-day operations
Storage requirements for extract, summarization, work space, log space, backup, recovery, and maintenance
The cost of redundant data
Hardware and software costs, including server and software licenses
Labor costs

6. Computing ROI: Benefits
Three types of benefits:
IT staff salaries saved by not doing traditional DSS
Managers’ time (and money) saved due to automated collection and dissemination of information
Money saved or gained from better decisions

7. Computing ROI: Typical Costs
Initial Costs
Recurring Costs
Hardware
Server, disk, applications server, network
Support and maintenance
Software
Database, options, BI tools, ETL tools
Support and updates
Labor
Project manager, analysts, trainer, developers, DBA
DBA, System admin, modeler, training

8. Computing ROI: Example
Initial Cost: $1,350,000
Recurring costs: $250,000 per year
Recurring savings:
IT report generators freed to do other tasks
Cost savings: $150,000 per year
Better management inventory reduces waste by half
Cost savings: $125,000 per month = $1.5 million per year
Conclusion:
This system will pay off itself in one year.

9. Funding the Project
State that initial system integration costs are high
Determine who funds the project:
Information systems - development group
Department - users
Department
Selected
subject for
pilot
Information
systems
Department
Department
Small staff
Short duration
Funding the Project
Initially, the information technology group may fund the project up until the pilot run of the first increment. After the pilot, when the process is proven, funding usually passes to the individual departments, particularly if the implementation is a departmentalized data mart.
Debates often arise between information systems and individual departments about who should pay for resources, such as the hardware and software, system (warehouse) monitoring tools, and OLAP tools. Individual departments often express concern that, if they fund tools in the development of one of the first subject areas that will be used for warehouse initiatives, they should be able to recoup part of the investment from other departments who build subject areas and benefit from those tools at a later time. If the information systems department funds the tools, they absorb the cost or can bill back to individual departments as required, over the depreciation life of the tools. In the case of specific data marts (for departments), the cost is often the responsibility of the local department.
Some warehouses do not charge for the first few months, usually while the project is being funded by information systems development groups. Once the warehouse is piloted and has proved successful, then charges are normally levied.
More subjects
funded by end-user
organizations

10. Obtaining Business Commitment
Ensure that the warehouse:
Has total support
Is driven by the business
Research the problem
Identify goals, visions, priorities
Research the solution
Identify the benefits
Identify the constraints
Obtaining Business Commitment
A data warehouse implementation requires the total support of those who control the business and make the decisions that drive the business forward. The warehouse is a business-driven project, not an information technology drive for the latest hardware, software, tools, and techniques.
Business objectives must be clear, well defined, measurable, and achievable:
Research and study the business problem; identify the business vision, goals, and priorities
Research the solution and define what the warehouse solution may do
Identify the benefits of the solution, such as efficiency, people power, customer satisfaction, and returns
Identify the constraints, such as schedule, costs, and experience

11. Data Warehouse Champion
Maintains intergroup communication
Settles conflicts
Identifies and solves issues
Articulates the vision
Brings in business expertise
Organizes and supports the team
Communicates progress
Brings the data warehouse to life
Data Warehouse Champion
There must be someone within the organization who remains focused and works to:
Ensure all groups within the development team communicate.
Settle conflicts between groups.
Identify and solve issues or problems at any level.
Articulate the vision and wisdom of the warehouse to everyone involved in developing and using the warehouse.
Bring business expertise to the task.
Organize and support the team.
Communicate progress, processes, and achievements throughout the organization.
Bring the data warehouse to life.

12. Steering Committee Business executives
Information systems representatives
Knowledge workers
Provides direction
Decides upon implementation issues
Sets priorities
Assists with resource allocation
Communicates to all levels at all times
Steering Committee
The steering committee should comprise representatives of different sectors within the business:
Business executives
Information systems representatives
Users
The aim of the committee is to:
Provide business direction
Decide upon enterprisewide implementation issues
Determine and set development priorities
Assist with resource allocation
Communicate consistently to all areas and levels of the organization
Each subject area may have its own detailed project plan, which can be rolled up to a master plan weekly or monthly. The steering committee must be aware of how changes to business direction and priorities affect existing project plans, milestones, and deliverables. They must approach the renegotiation of existing plans tactfully and diplomatically.
Note: The steering committee is not a substitute for the project manager.

13. Warehouse Data Ownership
Users must own the data
Users must be involved throughout
Users must be part of the steering committee:
Enhances cooperation
Reduces friction
Helps meet requirements
Enhances feedback
Warehouse Data Ownership
It is important that users feel they own the warehouse and the data within it. If they have a vested interest in the project, they are eager for more information and have an interest in the future use and maintenance of the content.
You should involve users throughout the project, making them part of the steering committee.
Involving the users in this way leads to:
Enhanced cooperation between different departments in the business
Reduced friction among groups or departments, with problem resolution and formal project and change management
Meeting business requirements
Continuous and useful feedback

14. Setting Expectations Incremental Scope Rollout over time Phases
Expectations for each data warehouse project phase should be established early on. Every organization has heard something about data warehousing, data marts, data mining, and so on. To set the expectations throughout the organization you first need to determine what each member of the organization is expecting from the data warehouse.
Set Expectations for the Incremental Approach
Educate all members of the organization in advance that the data warehouse project will be incrementally developed. Explain that there is no formal implementation of the entire data warehouse all at once. Help the user community to understand that the data warehouse provides views of the business over time and under continually changing strategic environments.

15. Managing Expectations
Documenting
Informing sponsors
Reporting progress to end users
Managing Expectations
Documenting Deliverables
Managing expectations during the data warehouse project management cycle can be completed by documenting the deliverables that were completed within each phase.
Keeping Sponsors Informed
Keep the executive sponsor of the warehouse, as well as the end-user community, abreast of the iterative development that is taking place during each phase.
Reporting Incremental Progress to End Users
Highlight all new progress and functionality to inform the user community of the incremental advances that are being made to increase the amount of information that can be gained from the data warehouse.

16. Assembling the Project Team
Project manager/Project leader
Architect
Executive sponsor
Data analyst
Database or system administrator
Metadata administrator
Assembling the Project Team
During the life cycle of a data warehouse project, you will need to call on staff from both the business side and Information Systems sides of your organization. Often, project roles will be shared and switched over the project life cycle.
Project Manager/Project Leader
Manages and defines the data warehouse project plan
Is responsible for the overall design and function of the data warehouse
Coordinates project resources, controls the budget, documents project status, resolves issues, coordinates vendor activity, and manages change control
On large data warehouse projects, the project manager and project leader are typically two different individuals.
Architect
Designs and documents data warehouse architecture and technical infrastructure
On a small data warehouse project, may also be responsible for integrating all networking products and host connectivity

17. Assembling the Project Team (continued)
Executive Sponsor
Provides clout; influences resource availability, funding, and scheduling
Provides understanding of the organization and its business
Data Analyst
Is responsible for the data model and schema design
Manages data quality, data integration, aggregation, and updates
On a small data warehouse project, may also be involved in data extraction and transformation
On a large data warehouse project, may also be involved in exploring end-user data requirements and deploying business intelligence and analysis tools
Database or System Administrator
Is responsible for physical database implementation
Installs all hardware and software products for the data warehouse environment
Manages database installation, configuration, security, and administration
May also be involved in helping programmers with data extraction, transformation, loading, backup, and archiving

18. Recognizing Critical Success Factors
Focus on the business, not the technology
Use an iterative development methodology
Include end users on the project team
Recognizing Critical Success Factors
Each data warehouse project management phase has critical success factors. The critical success factors for the overall data warehouse project typically include the following three items:
Design the data warehouse with a focus on the business, not the technology. In a successfully managed data warehouse project there are no technical decisions, only business decisions.
Use an iterative development methodology. Include short phases that provide frequent deliverables to help manage expectations throughout the project.
Include end users on the project team. End user input is necessary for design decisions that enable the data warehouse project to meet the business goals.

19. Business User Requirements
Physical
Design
Application
Specification
Business User
Requirements
Technical
Architecture
Deployment
Plan
Project
Scope
Maintenance
and Growth
Business User Requirements
The intent of a data warehouse is to provide the data that supports warehouse users accessing their own information when they need it. For that reason, business requirements reside at the center of the data warehouse development process and drives many activities throughout the design and implementation of a data warehouse.
Discuss with business users their jobs, their objectives, their challenges, and find out how they make decisions.
Attend data audit meetings with DBAs or source transaction system experts and find out whether there is complete, reliable data available to support what users are asking for.

20. Techniques for Uncovering Requirements
Interviews
One-on-one with individuals
Small groups
Facilitated group sessions
Brainstorming
Consensus and issue resolution
Research
Available recourses (Annual report, Marketing literature, Web content)
Organization chart (understand org chart)
Previous warehousing initiatives (what worked, what did not, and why)
Techniques for Uncovering Requirements
Interviewees
Horizontal representation
Obtain representation at relatively high levels of the organization
Look at the big picture
Ensure data warehouse is extensible across the organization
Vertical representation
Senior management
Middle management
Individual contributors
IT data audit interviewees
Speak with individuals that know the data (possibly responsible for core source systems)

21. Techniques for Uncovering Requirements (continued)
Interview Content
Business executives
Big-picture understanding and vision
What are the objectives of your organization?
How is success being measured and how often? (Identify key business processes and facts.)
What the key business issues and vision of the organization?
What opportunities are there to leverage information within the organization? (Identify expectations and business benefits.)
Business manager/analyst
Understand departmental objectives, vision, and expectations
Understand current analyses and opportunities for improvement
What are the objectives of your department?
How is success being measured? What are the key metrics?
What opportunities are there to impact business with improved access to information?
What type of routine or ad hoc analysis is performed? How often? How can current methods be improved?
IT data audit
Explore feasibility of supporting requirements
Overview key operational source system
How often is data updated?
Is historical data available?
Are there any data caveats or quality issues?

22. User Requirements Checklist
Areas to focus:
How users do business
What are the business drivers
What attributes users need (required versus good to have)
What the business hierarchies are
What data users use and what they like to have
What levels of detail or summary are needed
What type of front-end data access tool is used
How users expect to see the query results
User Requirements Checklist
You must approach data warehouse end-user requirements gathering in a radically different way than with operational systems.
The following are the areas to focus in gathering user requirements:
How users do business
What the business drivers are
What attributes users need
Which attributes are absolutely required and which attributes are good to have
What the business hierarchies are
What data users use now and what they would like to have
What levels of detail or summary the users need
What type of front-end data access tool will be used
How the users expect to see the results of their queries

23. Gathering User Requirements: Possible Obstacles
The following are some of the possible obstacles:
Business objective of the data warehouse has not been specifically defined
Scope of the data warehouse is too broad
Misunderstanding about the purpose and function of a decision support systems and operational systems
Gathering User Requirements: Possible Obstacles
The following are some of the possible obstacles to gathering user requirements:
The business objective of the data warehouse has not been specifically defined
The scope of the data warehouse is too broad
There is a misunderstanding about the purpose and function of a decision support systems and operational systems

24. Data Access Strategy Define and analyze user requirements
Determine the choice of tools
Identify user roles and access requirements
Data Access Strategy
Given the importance to warehouse users of the data and accessing that data, the choice of tools employed by users is primary and must be defined and determined early in the definition of the data warehouse.

25. Data Access Tool Requirements
Simple reports
Complex trend analysis
Regression analysis
Multidimensional data analysis
Exceptions reporting
Forecasting
Data manipulation
Data mining
Parameterized reports for batch execution
Web-based or client-server-based (or both)
Data Access Tool Requirements
The front-end tools must be able to associate common business terms that are used on a day-to-day basis, with a combination of clear and easy-to-understand data definitions. This enables the users to use the product quickly, without the need for extensive training. Metadata provides definitions of the data that the user can understand, in simple, straightforward business terminology.
The tool must be flexible, to provide different reporting requirements such as:
Simple reports
Complex trend analysis
Regression analysis
Multidimensional data analysis
Exceptions reporting
Forecasting
Data manipulation
Data mining
Parameterized reports for batch execution
Web-based or client-server based (or both)

26. User Query Progression
Starts simple
Becomes more analytical
Requires different techniques and flexible tools
What?
Why?
User Query Progression
The tools that you employ must provide the flexibility to answer a user’s immediate and future needs. The answer to a question may not be immediately obvious, and one question can often lead to another. Querying the warehouse is an iterative process.
For example, a user may start with a query that answers reasonably simple questions, such as: “What are the sales figures for Sprock tennis rackets during the first half of 2002 in the U.S.A. as a whole?”
Once the query is answered, the user may start to ask more analytical questions, such as: “Why did the sales figures for Sprock tennis rackets in the U.S.A. increase during that period?”
The answer proves to be that the World Tennis Championships ran in Miami in March Obviously, tennis caught everyone’s attention. Now that the answer to that is known, the process continues: “Which U.S. state sold the most Sprock tennis rackets? Why?”
To answer these types of question, the user needs to be able to analyze data in a number of different ways.

27. Query Efficiency User considerations Successful completion
Faster query execution
Less CPU used
More opportunity for further analysis
Query Efficiency
User’s Perspective
An efficient query has the following characteristics from a user’s perspective:
Runs successfully, completely, and produces the desired results
Takes less time to run and is therefore more beneficial to productivity
Uses less CPU power and therefore utilizes fewer system resources
Enables the user to move more quickly on to further analysis

28. Query Efficiency Designer considerations Use indexes
Select minimum data
Employ resource governors
Minimize bottlenecks
Develop metrics
Use prepared and tested queries
Use quiet periods
Query Efficiency (continued)
Designer’s Role
Efficient query access is dependent on the good design of the data warehouse. The following points are important to ensure query efficiency:
Create indexes on key values to minimize full-table scans.
Select only the minimum amount of data required.
Administer resource governors on the server to:
Prevent access
Cut off a query after it has run for a specified time
Inform the user how long a query will take (Resource governors may be set for the entire application or by user group. Governors are vital where data volumes are very large.)
Minimize intensive I/O bottlenecks.
Develop metrics to support queries.
Make more use of prepared and tested queries.
Submit large jobs outside of working hours, or when CPU usage, network, and I/O contention is minimal.

29. Query Scheduling and Monitoring
Manages information usage
Directs queries
Executes queries
Sets job queue priorities
Query monitoring:
Track resource-intensive queries
Detect unused queries
Catch queries that use summary data inefficiently
Catch queries that perform regular summary calculations at the time of query execution
Detect illegal access
Query Scheduling and Monitoring
Query Scheduling
Once the warehouse is operational, queries are submitted to the warehouse server. You need to create a process that:
Manages the use of information in the data warehouse
Directs queries to the appropriate data source, using metadata
Schedules the execution of a query
Sets job queue priorities

30. Query Scheduling and Monitoring (continued)
Query Monitoring
You need to keep a check on warehouse query activity. The query management program (or tool) must:
Track resource-intensive queries, which require analysis to identify why they are so resource-intensive, followed by tuning to improve performance.
Detect queries that are never used and remove them. Do not forget to ensure that the users need to be advised of this kind of change.
Catch queries that use summary data inefficiently; the summary strategy may need revision.
Catch queries that perform regular summary calculations at the time of query execution. You may decide to include another summary table in the data warehouse with the pre-summarized data to provide immediate access, which improves overall speed of access.
Detect illegal access. A user may need access to currently denied data.

31. Query Access Architectures
Web Server
Client-Server
Web
Query Access Architectures
In the computer industry today, there are many architectures, and in the warehouse environment the two most prominent are client-server and Web access.
Client-Server Access
The principle behind the client-server approach is to split the processing among servers and localized processing on the client.
This openness among systems provides a configuration with total flexibility. Different users may run different tools that access the data warehouse. They are:
Simple query tools
Complex analysis tools
Data mining tools

32. Web Access Better-informed decision making
Lower costs of deployment and management
Lower training costs
Remote access
Enhanced customer service and improved image as a technology leader
Greater collaboration among users
Web Access
Web access enables your users to perform ad hoc queries against the database by using Web browsers of their choice. It provides remote offices and mobile professionals with the information that they need to make tactical business decisions.
Companies are increasingly aware that the Internet can help them reach out to new markets and increase their values to customers, particularly by offering individualized, one-to-one marketing.

33. Security Do not overlook security. Subject area sponsors:
Review and authorize request for access rights
Identify enhancements
Transparent security
Easy to implement, maintain, and manage
Security
Security is commonly controlled by the database administrator (DBA). It must be considered early in the development to ensure that access to the key resource information is controlled. Information is a key company resource that needs protection. Therefore never assume that you can overlook security because user access is query-only. There are some simple guidelines about security that you can follow:
Ensure that each subject area has a sponsor who can carry out the following tasks:
Review and authorize requests for access rights
Identify further enhancements to the security setup (Data may be separated into that which is accessible to all users and that which is accessible to a select few.)
Ensure that the security is transparent and does not impair access from the user perspective
Ensure that the strategy is easy for you to implement, maintain, and manage

34. Fine-Grained Access Control in Oracle8i and Oracle9i
Who am I?
Where am I?
Application context
Oracle9i or 8i
Fine-Grained Access Control in Oracle8i and Oracle9i
Fine-grained access control gives customers a way to extend their table-based and view-based security to finer levels of granularity than previously possible. It is implemented by attaching security policies to tables or views. These security policies can limit access by users to only specific rows within the table or view.
Application Context
Application context is a feature that is related to fine-grained access control that can be used to implement a security policy. It is provided so that customers who want to do fine-grained access control can base their security policies on information about the user, such as, who the user is, which machine he or she is using, and what is his or her management hierarchy? Application context provides a secure framework to store such information so that it may be used to implement access to database objects.
Among others, the main justification for fine-grained access control are:
Application-based security can be bypassed.
Views work best for a limited number of user groups.
Internet and remote access demand data-driven, user-based security.
Building security in one place reduces cost of ownership.
Table
Access policy

35. Implementation Requirements
Data acquisition
Data quality
Documentation
Testing
Training
Post-implementation support
Implementation Requirements
Some of the implementation requirements for a data warehouse project are:
Data acquisition
Data quality
Documentation
Testing
Training
Post-implementation support

36. Data Acquisition
Identify, extract, transform, and transport source data
Consider internal and external data
Move data between sources and target
Perform gap analysis between source data and target database objects
Define first-time load and refresh strategy
Define tool requirements
Build, test, and execute data acquisition modules
Data Acquisition
The data acquisition process identifies, extracts, transforms, and transports all source data necessary for the operation of the data warehouse. Data acquisition is performed among several components of the warehouse, including operational and external data sources to data warehouse, data warehouse to data mart, and data mart to individual marts.
Early in the data acquisition process, data sources are identified and evaluated against the subject areas, and gap analysis is conducted to ensure that the data is available to support the information requirements. Strategies are developed for the first-time load of the warehouse and for the subsequent refreshes of the warehouse.
You evaluate tools against high-level requirements and make recommendations.
With the detailed analysis output, modules are designed and built to extract, transform, transport, and load the source data into the warehouse. Once built, the modules are tested and executed and the production database objects are populated.

37. Data Quality Ensure data consistency, reliability, accuracy
Develop a strategy for:
Cleansing
Integrity functions
Quality management procedures
Identify business rules for:
Error handling
Audit and control
Define data quality tool requirements
Build, test, and execute data quality modules
Data Quality
The data quality process ensures the following:
Consistency, reliability, and accuracy of the data in the warehouse. A data quality strategy is developed based upon a clear understanding of the agreements and contractual obligations for data cleansing, audit and control, and integrity functions.
Data management procedures are defined.
Data quality tools are evaluated and recommended.
The process identifies the business rules for error exception and handling, scrubbing and cleansing, and audit and control. The business rules for error handling may vary between the initial load and subsequent updates to the data warehouse. Using the data quality strategy, procedures, and tools, modules are developed to support the requirements for data quality.

38. Documentation Produce textual deliverables Glossary
User and technical documentation
Online help
Metadata reference guide
Warehouse management reference
New features guide
Documentation
The documentation process focuses on producing all user and technical documentation for the data warehouse, including references, user and system operations guides, and online help.
To ensure active and successful use of the warehouse, the metadata reference guide describes the contents of the data warehouse in business terms and provides a navigational road map to the contents of the data warehouse.
In addition, the warehouse management documentation outlines the workflow and manual and automated management procedures.
The new features guide highlights any enhancements to warehouse functionality that result from the implementation of the solution.

39. Testing Develop a test strategy
Create test plans, scripts, and scenarios
Test all components:
Data acquisition
Data access
Ad hoc access
Regression
Volume
Backup
Recovery
Support acceptance testing
Testing
The testing process is an integrated approach to testing the quality of all components of the data warehouse. The testing strategy is developed and approved before the test system is created. System integration and module test plans, test scripts, and test scenarios are developed. Each test is performed and proven. Testing includes proving the physical design of the database.
Data acquisition modules, data access tools, and canned queries and reports also undergo thorough module and integration testing. The testing strategy addresses all components of the solution, including the ad hoc access processes.
Regression testing is performed, testing changes to the data warehouse against a baseline, to ensure past functionality works when an enhancement is added.
Volume testing is conducted on the production platform to ensure that performance meets established objectives.
Preparation of the acceptance environment and support for acceptance testing are also performed during the testing process.

40. Training Define requirements: Identify staff to be trained
Technical
End user
Business
Identify staff to be trained
Establish time frames
Design and develop materials
Focus on tool training and use of the warehouse
Training
The training process defines the development and user training requirements, identifies the technical and business personnel requiring training, and establishes time frames for executing the training plans.
Training plans and training materials are designed and developed. User and technical training is conducted.
The key objective is to provide both users and administrators with adequate training to take on the tasks of operating, maintaining and using the data warehouse solution. Training should focus on tool training and how business value is generated from the information in the data warehouse.

41. Training Needs Training audience Training responsibility
Initial
Continuing
Training topic
Training Needs
Training Needs by Audience
Data warehouse users
Data warehouse contents and navigation
Using ad hoc query and analysis tools
Data warehouse support
Tool installation and administration
IT help desk
Warehouse access tools
Data warehouse developers
Concepts and methods
Warehouse development tools
Training responsibilities fall on the following groups:
Development team
Key user departments
Tool vendor

42. Training Needs (continued)
Fundamental Training Topics
The basic training should include some of the following fundamental topics:
How to switch on the hardware and log on to the data warehouse
How to find out what data is there (access the metadata) and interpret its meaning
How to create and issue a query
How to prioritize queries
How to monitor query execution
How to interpret query results
How to save the query and store results
To have a basic understanding about the resources that are used within the query environment, particularly in the environment where query governors are used (as in a warehouse)
How the warehouse works:
Where the data comes from
The level of data quality and integrity (or lack of it)
What mapping is and how it is important
Backup and recovery responsibilities (if any)
Data and query availability
Scheduled down time

43. Post-Implementation Support
Evaluate and review warehouse use
Monitor warehouse use
Refresh the warehouse
Monitor and respond to problems
Conduct performance testing and tuning
Transfer responsibility
Evaluate and review the implemented solution
Post-Implementation Support
The post-implementation support process provides an opportunity to evaluate and review the solution. You evaluate the use of the warehouse by accessing metadata and evaluating queries and reports run against the warehouse. The information assists with management of standard queries and reports, and the user layer, and identifies required indexes.
The process also focuses on refreshing the warehouse, monitoring and responding to system problems, correcting errors, and conducting performance and tuning activities for all components of the data warehouse. Other actions at this time include:
Change control for information requirements
Roll out of metadata, queries, reports, filters, and conditions
Library of shared objects
Security
Incorporation of new users
Distribution of data marts and catalogs
During this process, responsibility for the data warehouse may be transferred from IS staff to the owning organization.

44. Summary In this lesson, you should have learned how to:
Explain the financial issues to be managed in developing and implementing a data warehouse
Outline techniques for obtaining business commitment to the warehouse
Outline the key tasks involved in managing a warehouse project
Discuss gathering business and user requirements
Discuss implementation requirements
Summary
This lesson discussed the following topics:
Explaining the financial issues to be managed in developing and implementing a data warehouse
Outlining techniques for obtaining business commitment to the warehouse
Outlining the key tasks involved in managing a warehouse project
Discussing gathering business and user requirements
Discussing implementation requirements

45. Practice 3-1 Overview This practice covers the following topics:
Generating a warehouse organizational readiness checklist
Generating a warehouse strategy deliverables checklist
Completing a user profile exercise
Answering true or false questions on user involvement in determining query access to the data warehouse

46. Practice 3-1
Warehouse Organizational Readiness Checklist
For each item in the following list that measures warehouse readiness, rate your own organization’s readiness. Rate each item’s relative importance in measuring your organization’s readiness.
Readiness Measure
Your Organization’s Readiness
Are the objectives and business drivers clearly defined, compelling, and agreed upon?
Have you selected a methodology for design,
development, and implementation?
Is the project scope clearly defined, with a
focus on business rather than technology?
Is there strong support from a business
management sponsor?
Does the business management sponsor have
specific expectations?
Are there cooperative relations between
business and Information Systems staff?
Have you identified which source data will be
used to populate the data warehouse?
What is the quality and “cleanliness” of the
source data?
Are you authorized to choose and acquire
hardware and software to implement the
warehouse?
Are you prepared to select and train your
implementation team?

47. Practice 3-1 (continued)
Warehouse Strategy Deliverables Checklist
Form into small groups, and consider each of the following strategy deliverables. For each deliverable, discuss briefly whether you would use it in your own strategy checklist back at your workplace, and rate its importance relative to the other deliverables.
Strategy Deliverable
Description
Will You Use? Why?
Business goals and
objectives
Documents the strategic business goals and objectives
Data warehouse
purpose, objectives,
and scope
Documents the purpose and
objectives of the enterprise data warehouse, its scope, and how it is intended to be used.
Enterprise data
warehouse logical
model
High-level, logical information
model that diagrams the major
entities and relationships for the enterprise
Incremental milestones
Documents a realistic scope of
the data warehouse, acceptable
delivery milestones for each
increment, and source data
availability
Source system data
flows
Outlines source system data,
where it originates, the flow of
data between business functions and source systems, degree of reliability, and data volatility
Subject area gap
analysis
Documents the variance
between the information
requirements and the ability of
the data sources to provide the
information
Data acquisition
strategy
Documents the approach for
extracting, transforming,
transporting, and loading data
from the source systems to the
target environments for the
initial load and subsequent
refreshes

48. Practice 3-1 (continued)
Warehouse Strategy Deliverables Checklist (continued)
Strategy Deliverable
Description
Will You Use? Why?
Data warehouse
architecture
Documents the set of rules or structures providing the framework for the centralized data warehouse, data marts, metadata repository, fact tables, multidimensional structures, and data access components
Technical infrastructure
Outlines the technologies, platforms, databases, gateways, and other components necessary to make the
architecture functional
Data access environment
Documents the identification, selection, and design of tools that support end-user access to the warehouse data
Data quality strategy
Outlines the approach for data management, error and exception handling, data cleansing, and the audit and control of the data
Administration strategy
Documents the warehouse administration tasks and considerations such as version control, archive, backup, and analysis of metadata and query profiles for optimization
Metadata strategy
Documents the strategy for capturing, integrating, and accessing metadata for all components of the warehouse environment
Training strategy
Outlines the technical and business personnel requiring training, and establishes time frames for executing the training plans

49. Practice 3-1 (continued)
3. Complete the user profile column in this exercise with one of the following user types:
Executive
Casual user or manager
Business analyst or power user
Name
Access Needs
Technology
User Profile
Brian O’Reilly
Need to develop simple forecast, such as budgets
Ease of use is important
Microsoft Office
Internet browser
Spreadsheets
Mary Ramos
One click access
Only need highly summarized information
Ease of use is very important
Kim Seng
Constantly wants to “get more data”
Understands the organization’s business processes
Oracle Reports
Oracle Discoverer
Oracle Express Analyzer
Amber Salinas
Lots of drilling
Customize graphical user interface (GUI)
Needs to know data structures
Extensive SQL programming
Oracle7i, Oracle8i
Oracle9i with Express Server

50. Practice 3-1 (continued)
4. Answer True or False to the following questions
5. Security Consideration Checklist exercise: Form into small groups, and discuss each of the following questions. For each question, discuss briefly whether you would use it in your own security consideration checklist back at your workplace, and rate its importance relative to the other questions on the checklist.
Question
True
False a
Do not involve users in the early process of the data warehouse implementation because they are going to delay your delivery date. b
Choose the warehouse data access tools by involving only IT staff because they are the ones who know what the users need. c
Prototype access methods with prospective users.
Security Consideration Question
Will You Use? Why? a
Security should be addressed at column level (and in some cases at the row level), at the table level, at the database level, at the tools level, at the client and server level, and at the network level. b
Create views to limit access to particular columns or, in unusual circumstances, rows. c
Do not rely on anything to protect the database except the database security. d
How are reports upgraded when new versions are released? e
Security should be implemented based on what makes the most sense for both the short-term and long-term health of the business. Judge security not only by its structure, but by how well it supports the entire corporate organization’s needs and survival.