1. Write a note on growth management.

Growth Management By conservative estimate, the data in a BI decision-support

environment doubles every two years. The good news is that the cost per query for most BI
decisionsupport environments goes down with properly managed growth. The bad news is
that the overall cost climbs, assuming that more and more business people use the BI
decision-support environment as time progresses. The three key growth areas to watch are
data, usage, and hardware. Growth in Data Growth in data means not only adding new rows
to the tables but also expanding the BI target databases with additional columns and new
tables. Adding new columns to a dimension table is not as involved as adding new dimension
tables to an existing star or snowflake schema, which usually requires the following:
Unloading the fact table Adding another foreign key to the fact table to relate to the new
dimension table Recalculating the facts to a lower granularity (because of the new
dimension) Reloading the fact table BI target databases need a large amount of disk space,
with workspace and indices taking up as much as 25 to 40 percent of that space. In the
relational world, the data is only a fraction of the overall database size; a major portion of it
is index space. Indexing is required to provide better response time when enormous volumes
of data are read. When calculating space requirements, it might be prudent to use the
standard engineering maxim: Calculate how large the BI target databases will be (including
indices), and then triple those numbers. As data volumes increase, there needs to be a plan
to aggregate and summarize the data as it ages. Business analysts rarely require the same
level of granularity for very old data as they do for recent data. Therefore, the level of
granularity should decrease with a moving calendar. For example, assume the business
people want to store ten years of historical data. They require monthly summary data by
department for two years but are satisfied with monthly summaries by region for the
remaining eight years. Before a new month is loaded into the BI target database, the
department-level data for the 24th month is summarized into regional totals and rolled off
into another fact table so that the 23rd month becomes the 24th month, the 22nd month
becomes the 23rd month, and so on.
The following list contains some of the new technologies available to support the massive
data volumes and the analysis capabilities of these huge databases: Parallel technologies
Multidimensional databases New indexing technologies Relational online analytical
processing (ROLAP) tools Distributed database maintenance tools and utilities Growth in
Usage Another key growth area is usage. Organizations that have built successful BI
applications have often uncovered a pent-up need for information throughout the
organization. This need translates to more business people using the existing BI applications
and asking for new ones. The number of business people accessing the BI target databases
can easily double or triple every year, which drives up growth in usage exponentially. Since
different business people want to see different data and look at it in different ways, they
want to slice and dice the data by new business dimensions, which increases the data
volume. Although the data volume is a far more critical factor in determining processor
requirements, the number of people accessing the BI target databases is equally important.
Technicians view growth in usage as something negative. Managers, however, think of
growth in usage as something positive, as long as there is a return on investment (ROI).
Purchasing new hardware or updating existing hardware to handle the growth may not be a
concern if the organization is making a sizable profit due to better decision-making
capabilities with the BI applications. Therefore, growth in usage may mean that the BI
strategy is working. BI target databases are by nature read-only and growonly. Therefore, the
key is to stop trying to conserve disk space if the BI applications and BI data are helping the

1
 organization make a profit. Growth in Hardware Given the information about the growth in
data and the growth in usage, it should be obvious that scalability of the BI hardware
architecture is key. But before you plan five years ahead, remember that the hardware cost is
only one part of the total BI cost. Look at a planning horizon of 12 to 24 months; it is best to
start small but also plan for long-term growth. Consider the following factors. Keep in mind
the capacity threshold of your BI platform. If you exceed that capacity, you have to add more
processors, I/O channels, independent disk controllers, and other high-speed components to
keep the BI decision-support environment at an acceptable level of performance. Of all the
BI hardware, the BI server platform is the most important. When ordering new hardware of
any kind, there must be enough lead time to have the equipment delivered, tested, and
prepared for the development and production environments. Parallel technology is an
absolute must for VLDBs. The ability to store data across striped disks and the ability to have
multiple independent disk controllers play an enormously important role in the performance
of processes running against the BI target databases. The Transmission Control
Protocol/Internet Protocol (TCP/IP) is appropriate for most hardware platforms. TCP/IP is
rapidly becoming a standard for scalability, growth considerations, and multiplatform
environments. Consider the advantages of a data mart approach with separate BI target
databases. This approach permits scalability in smaller and less expensive increments

2. Discuss in detail implementation activities.

Implementation Activities The activities for implementation do not need to be performed
linearly. Figure 15.5 indicates which activities can be performed concurrently. The list below
briefly describes the activities associated with Step 15, Implementation. Plan the
implementation. Set the implementation date and make sure that all the resources needed
for the implementation will be available. Depending on the progress you have made, the
lessons you have learned, and the difficulties you have encountered, you may want to roll
out the BI application to the business community in phases. Start with a small group of
business people, learn from the experience, and modify your approach if necessary (e.g.,
increase the time for training or change the security measures) before making the BI
application available to more people. If the BI application has any organizational impact,
prepare to make those organizational changes (e.g., business process improvement changes
or shifted roles and responsibilities). 1. Set up the production environment. In most large
organizations, strict procedures have to be followed to prepare the production environment.
– Set up the production program libraries (ETL, application, meta data repository). 1. –
Create the production databases (BI target databases, meta data repository database). 2. 3. –
Grant appropriate access authority on the production databases. – Grant appropriate access
authority to developers, operations staff, and business people to execute programs from
production program libraries. 4. – Write operating procedures for the operations staff with
instructions for running the ETL process, as well as the regularly scheduled application report
jobs. 5. – Prepare a reference guide for the help desk staff and the business people with
instructions on how to use the BI application. 6. – Determine production security levels for
all components of the BI application. 7. 2. Install all the BI application components. Move all
ETL programs, application programs, and meta data repository programs to their respective
production libraries. 3. 4. Set up the production schedule. All ETL programs, application
report programs, and meta data repository programs that will run on a regular basis have to
be set up on the job scheduler. The ETL job schedule has to include the meta data programs
that are part of the ETL process (e.g., capture load statistics, reconciliation totals, data
reliability factors). 4. Load the production databases. Load the BI target databases by running

2
the initial load process, followed by the historical load process. Also load the meta data
repository with meta data from your various meta data sources such as spreadsheets,
computer-aided software engineering (CASE) tool, ETL tool, and online analytical processing
(OLAP) tool. 5. Prepare for ongoing support. Establish a schedule for on-call emergency
support. Schedule regular backups as well as occasional database reorganizations for all
production databases. Plan to use the DBMS-provided utilities for these database
maintenance activities. In addition, plan to monitor performance, growth, usage, and quality
as part of the ongoing database maintenance activities. Periodically review and revise
capacity plans for processors, disk storage, network, and bandwidth. 6. Figure 15.5.
Implementation Activities

Roles Involved in These Activities Application developers The application developers work
with the operations staff to move the report programs, query scripts, interface programs,
and online help function programs into the production application program library.
Application lead developer The application lead developer supervises the implementation
activities of the access and analysis portion of the BI application. He or she is in charge of
setting up the production application program library and writing the access and analysis
portion of the operating procedures and the reference guide. He or she also has the
responsibility of setting up the application report programs on the job scheduler. Data mining
expert The data mining expert works with the database administrator to create, revise, and
maintain the data mining databases for the planned data mining activities. Data mining is an
iterative and ad hoc endeavor that requires ongoing changes to the data mining databases,

3
 the analytical data models, and the data mining operations. Database administrator The
database administrator creates the production BI target databases and the production meta
data repository database and grants appropriate access authority for these production
databases. He or she must run the initial load process and the historical load process to load
the BI target databases. He or she schedules database maintenance activities (backups,
reorganizations) as well as ongoing database monitoring activities (for performance, growth,
usage). He or she also reviews the capacity plans for processors, disk storage, and network
bandwidth. ETL developers The ETL developers work with the operations staff to move the
ETL programs into the production ETL program library. ETL lead developer The ETL lead
developer supervises the implementation activities of the ETL portion of the BI application.
He or she works with the operations staff to prepare the production environment and set up
the production ETL program library. He or she should write the ETL portion of the operating
procedures and the reference guide. He or she is also responsible for setting up the ETL
process on the job scheduler. Meta data administrator The meta data administrator is
responsible for moving all the meta data repository programs into the production meta data
repository program library. He or she also has to run the meta data migration (load) process
and schedule ongoing data quality monitoring activities, such as gathering meta data metrics
and performing data quality spot checks. Meta data repository developers The meta data
repository developers assist the meta data administrator with moving all the meta data
repository programs into the production meta data repository program library. Web
developers The Web developers are responsible for moving their Web pages and scripts from
their local servers to the production Web server. Web master The Web master is responsible
for setting up the production Web server. He or she also has to work with the staff of security
services and network services to install and test the firewall and other required security
features

3. What are the important BI application release Guidelines.

4
4. Discuss in detail release evaluation activities.

5
Figure 16.4. Release Evaluation Activities

6
5. Write a note on post implementaion reviews

7
8
Organizing a Post-Implementation Review Consider the following items when organizing a
project review. How to prepare for the review: The project manager has to take some time to
prepare for the review by: - Examining the issues log to see which issues were effectively
resolved and which were not - Assessing the change-control procedure for its effectiveness -
Reviewing the project plan to determine whether all the appropriate tasks were included -
Studying the estimated and actual task completion times on the project plan to determine
which tasks were underestimated and which were overestimated - Noting any problems with
the technology platform, such as problems with tools or their vendors, hardware, network,
and so on - Reviewing the budget to see if the actual expenditures came close to the
estimated ones - Assessing the effectiveness of the training sessions All of these items are
potential topics for discussion at the review. When to schedule the review: It is advisable to
wait for two months after going into production before holding a formal review of the BI
application. This will give the project team time to iron out all the glitches that are common
during the first few weeks after "going live." It will also give the project manager and the
business sponsor time to: - Review the project charter, project plan, project reports, project
activities, and budget - Collect information and metrics about the usage of the BI application,

9
 the BI target databases, and the meta data repository - Organize the meeting Where to hold
the review: The review session should be held offsite. Pagers and cell phones should be used
for emergencies only; they should not ring during the session. The room should be set up as
a conference room supplied with: - Several flipcharts - An overhead or data projector -
Markers and masking tape - Two laptops, one for the facilitator and one for the scribe -
Coffee—lots of strong coffee How long the review should last: A well-organized, thorough
review usually lasts two full days, especially for the first release of a new BI application.
However, if time is in short supply, or if the release was small in scope and effort with no
significant hurdles, one full day could be scheduled with the option of a follow-up session
within two weeks if necessary. Who should attend the review: All team members from the
core team and the extended team should be invited to participate in the review. They must
be prepared to contribute. That means they must review the agenda and prepare to discuss
the topics listed on it. They must also review any documents sent to them ahead of time and
be prepared to discuss them. In short, every project team member should be an active
participant! What to discuss during the review: A preliminary agenda should be published
about four weeks before the scheduled review session. - The preliminary agenda should list
all topics, including introduction and wrap-up, with estimated time allocations for each topic.
- The time estimates must take into account the complexity of the topic and the number of
people participating. - Everyone who is invited should be given the opportunity to add to the
agenda and submit any pertinent documents to be reviewed. - About two weeks before the
review session, the fina

6. What are the backup strategies available to address the slow speed of data transfer between
server and backup device.

10
11
7. What are the roles involved in evaluation activities.

12
8. What are the application prototyping activities for BI

13
14
15
16
17