The document outlines the key aspects of developing a successful data warehouse technical architecture. It discusses establishing an architecture task force to collect requirements, develop models, design subsystems, and document the technical architecture. The architecture aims to integrate technologies, serve as a communication tool within and outside the team, and ensure consistent technical requirements. It also describes the product selection and installation process, developing analytic applications, deploying the data warehouse, and providing ongoing maintenance and user support.

3. ARCHITECTURE

4. TECHNICAL
ARCHITECTURE
is the blueprint for the
warehouse technical
services and elements.

5. ARCHITECTURE
PLAN
- To support integration
of technologies
- Serves as a communication
tool.

6. SUPPORTS
COMMUNICATION
REGARDING A
CONSISTENT SET
OF TECHNICAL
REQUIREMENTS
1) Within Team
2) Upward to Management
3) Outward to Vendors

7. 1) Within Team
To ensure that
everyone is aware of
technical requirements,
and any
issues/challenges are
addressed promptly.

8. 2) Upward to
Management To ensure that
managements understand
the Technical Architecture of
data warehouse, so they can
make informed decisions
and provide support when
necessary.

9. 3) Outward to
Vendors
To ensure that they
understand the Technical
requirements and can
provide the necessary
product/services.

10. TECHNOLOGY TRACK

11. 8 - Step Process
1. Establish an
Architecture Task Force.
2. Collect Architecture-
Related Requirements
3. Document Architecture
Requirements
4.Develop a high-level
Arch. Model

12. 5. Design and Specify the
Subsystems
6. Determine Architectural
implementation Phases
7. Document the Technical
Architecture
8. Review and finalize the
technical architecture

13. PRODUCT
SELECTION AND
INSTALLATION
• Understand corporate purchasing process
- expenditures need to be approved by the
capital appropriations committee. Or you
may be asked to provide a bank guarantee
against the funds released to buy hardware.
• Product evaluation matrix
- The more specific the criteria, the better. If
the criteria are too vague or generic, every
vendor will say it can satisfy our needs. On
the other hand, if the criterion is too
specific, everyone will shout favoritism.

14. PRODUCT
SELECTION AND
INSTALLATION
• Market research
- We must be informed buyers when
selecting products, which mean more
extensive market research to better
understand the players and their offerings.
• Narrow options, perform detailed
evaluations
- By comparing preliminary scores from the
evaluation matrix, we should focus on a
narrow list of vendors about whom we are
serious and disqualify the rest. If possible,
the references should represent similarly
sized installations.

15. PRODUCT
SELECTION AND
INSTALLATION
• Conduct prototype, if necessary
-If one clear winner bubbles up, it is good.
-Winner due to experience, relationship,
commitment
-Prototype with no more than two products
-Demonstrate using a limited, yet realistic
application using flat text file.
• Keep the competition “hot”
- Even if a single winner is left, it is a good
piece of advice that always keep at least
two.

16. PRODUCT
SELECTION AND
INSTALLATION
• Select product, install on trial, and
negotiate
- Embark on a trial period where you have
the opportunity to put the product to real
use in your environment. As the trial draws
to a close, you have the opportunity to
negotiate a purchase that's beneficial to all
parties involved.

17. ANALYTIC
APPLICATIONS TRACK

18. ƒ
Set standards: Menu, O/P,
look feel.
ƒ
From standard: Template,
layout, I/P variables,
calculations.
ƒ
Common understanding
between business & IT
users.
Analytic Applications
Specification
ƒ
Starter set of 10-15
applications.
ƒ
Prioritize and narrow to
critical capabilities.
ƒ
Single template use to get
15 applications.

19. ƒ
Tools: Product specific
high performance tricks,
invest in tool-specific
education.
ƒ
Benefits: Quality problems
will be found with tool
usage => staging.
ƒ
Actual performance and
time gauged.
Analytic Applications
Development
ƒ
Standards: naming,
coding, libraries etc.
ƒ
Coding begins AFTER DB
design complete, data
access tools installed,
subset of historical data
loaded.

20. DEPLOYMENT

21. DEPLOYMENT
- The technology, data, and analytic application
tracks converge at deployment.
- In data warehousing, even if the data isn't fully
available or ready, some people often still
proceed with deployment because we have told
the warehouse users that they'd be served on a
specific date and time.

22. HOW TO ASSURE
THAT DATA WILL
HAVE A
SUCCESSFUL
DEPLOYMENT ON
A SPECIFIC DATE
AND TIME?
1. Readiness assessment
- A successful deployment
demands the
courage and willpower to
assess the project's
preparedness to deploy.

23. HOW TO ASSURE
THAT DATA WILL
HAVE A
SUCCESSFUL
DEPLOYMENT ON
A SPECIFIC DATE
AND TIME?
2. Education
- The education program
needs to focus on the
complete
warehouse deliverable: data,
analytic applications, and the
data access tool.

24. EFFECTIVE EDUCATION PROGRAMS
- Understand the audience, don’t
overwhelm.
- Train after delivery of data and analytic
applications
- Postpone education, if DWH not ready.
- “No education, no access policy”.

25. MAINTENANCE AND
GROWTH

26. Maintenance and Growth
• Support
• Education
• Technical support
• Program support
• Growth

27. Support
• Critical to hook the user.
• For first several weeks, work
with users.
• No news is NOT good news.
• Relocate to the users if
needed.
• If problems uncovered, be
honest, immediate action to fix.
• If deliverable is of not high
quality, rework could be
substantial.

28. User
Support
It is crucial immediately following
the deployment in order to ensure
that the business community gets
hooked. For the first several weeks
following user education, the
support team should be working
proactively with the users.
Relocate (at least temporarily) to
the business community so that
the users have easy access to
support resources.

29. Education
• Continuing education
program.
• Formal refresher, as well as
advanced courses and repeat
introductory course.
• Informal education for
developers and power users for
exchange of ideas.

30. Technical
Support
• No longer nice-to-have, but to
be treated as a production
environment.
• Performance to be monitored
proactively and usage trends
noted.
• Business users not
responsible to tell that the
performance has degraded.

31. Program
Support
• A DWH phase may wind-
down, but the DWH program lives.
• Market your success.
• Ensure implementation on
track and address to business
needs.
• Ongoing checkpoint to be
implemented.
• Don’t loose focus, else failure.

32. Group Members:
 Abbariao, Christian
 Appegu, Aubrey
 Cababag, Joy
 Malenab, Jeacella Mae
 Pagulayan, Angelica
 Pamittan, Jasmin
 Soriano, Jesstine Mae
 Ursua, Christian
 Zalun, Anna Mae