Moss L.T., Atre S. Business intelligence roadmap: The complete project lifecycle for decision-support applications
Подождите немного. Документ загружается.
[ Team LiB ]
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, 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
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
441/631
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.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
442/631
[ Team LiB ]
Risks of Not Performing Step 15
If you got this far, you will obviously deploy your BI application. If you perform this
step with diligence, you can be reasonably assured that the BI decision-support
environment will be as stable, robust, and secure as any other production
environment. If you perform this step hastily, you run the risk that your BI decision-
support environment will not be the robust and secure environment the business
people expect it to be.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
443/631
[ Team LiB ]
Bibliography and Additional Reading
Bischoff, Joyce, and Ted Alexander. Data Warehouse: Practical Advice from the
Experts. Upper Saddle River, NJ: Prentice Hall, 1997.
Corey, Michael J., and Michael Abbey. Oracle Data Warehousing: A Practical Guide to
Successful Data Warehouse Analysis, Build, and Roll-out. Berkeley, CA: Osborne
McGraw-Hill, 1997.
Imhoff, Claudia, Lisa Loftis, and Jonathan G. Geiger. Building the Customer-Centric
Enterprise: Data Warehousing Techniques for Supporting Customer Relationship
Management. New York: John Wiley & Sons, 2001.
Inmon, William H.. Building the Data Warehouse. New York: John Wiley & Sons,
1996.
Inmon, William H., Claudia Imhoff, and Greg Battas. Building the Operational Data
Store. New York: John Wiley & Sons, 1996.
Inmon, William H., Claudia Imhoff, and Ryan Sousa. Corporate Information Factory.
New York: John Wiley & Sons, 1998.
Inmon, William H., J. D. Welch, and Katherine L. Glassey. Managing the Data
Warehouse: Practical Techniques for Monitoring Operations and Performance,
Administering Data and Tools and Managing Change and Growth. New York: John
Wiley & Sons, 1997.
Kimball, Ralph, and Richard Merz. The Data Webhouse Toolkit: Building the Web-
Enabled Data Warehouse. New York: John Wiley & Sons, 2000.
Kimball, Ralph, Laura Reeves, Margy Ross, and Warren Thornthwaite. The Data
Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and
Deploying Data Warehouses. New York: John Wiley & Sons, 1998.
The Information Systems Audit and Control Association & Foundation:
http://www.isaca.org
Information Systems Control Journal: http://www.isaca.com
MIS Training Institute: http://www.misti.com
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
444/631
[ Team LiB ]
Chapter Sixteen. Step 16: Release
Evaluation
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
445/631
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
446/631
Chapter Overview
This chapter covers the following topics:
Things to consider about release evaluation
Guidelines for using the application release concept when developing BI
applications
How to organize a post-implementation review meeting, including when and
where to schedule the session, who to invite, and what to discuss
The process flow of a post-implementation review session, including
responsibilities for conducting the meeting
Brief descriptions of the activities involved in release evaluation, the
deliverables resulting from those activities, and the roles involved
The risks of not performing Step 16
Things to Consider
Post-Implementation Review
How soon after the rollout should we schedule a formal project
review?
Should the business sponsor or the project manager run the review
session? Or should we ask a trained facilitator who was not involved
with the BI project to facilitate the review session?
Who should attend the review session?
Should it be held offsite? Where?
Who will prepare and distribute the agenda?
What topics should appear on the agenda?
Who will be responsible for taking notes?
Will we invite stakeholders from other departments?
Will we invite the data owners?
Who will track the assigned action items? The project manager?
How will we communicate to other teams and stakeholders the
lessons we learned from the review? Who else can benefit from this
review?
Measures of Success
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
447/631
Is the business sponsor satisfied with the BI application?
Do the business people like the BI application? Is it easy to use?
What do they like? What do they dislike? Why?
Are they using the meta data repository? Do they find it helpful?
Is the business sponsor willing to support another BI application?
Plans for the Next Release
Do we have leftover requirements that did not get implemented
due to time constraints or other project constraints?
Do we know how we want to address these requirements? Will they
go into the next release? Will they be reprioritized?
Are we planning another release of this BI application for the same
business area?
Are we switching to a different department and a different business
sponsor?
Do we want to invite the new business sponsor to the review
session as one of the stakeholders?
Are we prepared to split the core team into two groups the next
time so we can work on two BI projects at the same time?
Who will continue with the next release of this BI application?
Who will lead the new BI project for the new business sponsor?
Building a BI decision-support environment is a never-ending process. Unlike most
operational systems, which have sharply defined functionalities, BI applications must
evolve to handle emerging information needs. As the needs and goals of your
organization change, so must the BI decision-support environment. There is no
practical way to anticipate all possible questions in the initial design of the BI
decision-support environment or of any BI application. The best you can do at any
given time is to have an environment that supports the current organizational goals
and that can be easily adapted to new goals. Plan to design flexible and easy-to-
change BI applications so that you have the ability to modify them when the
organization's goals change. This applies to all BI initiatives, from small
departmental data marts to large industrial-strength enterprise data warehouses. Be
prepared to modify all BI applications and BI target databases in future releases in
order to provide new query and reporting capabilities and more data.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
448/631
[ Team LiB ]
The Application Release Concept
BI projects introduce many new practices: new techniques for business analytics,
new prototyping techniques, new design techniques, new architectures, and new
technologies. These practices are relatively new not only to organizations but also to
the information technology (IT) industry as a whole. In addition, BI projects usually
involve a significant level of capital investment. All of these factors add up to make
IT managers and business executives quite anxious. When a BI application does not
turn out flawless or is not complete on its initial implementation, some IT managers
and business executives get very unnerved.
A major shift must occur in how IT managers and business executives approach BI
projects. The approach of "get it right the first time" has never worked, even though
people have pretended for years that it does—or that it should. That misconception
should have been put to rest long ago. No major invention or significant endeavor
has ever worked right the first time. Usually, good things evolve over time. Nature
evolves. This fact is generally accepted. Technology evolves (Figure 16.1), and this
fact is also accepted. But the truth that software evolves as well is usually not
accepted, at least not when the software is developed in-house.
Figure 16.1. Evolving Technologies
When software is purchased from a vendor, it seems to be more palatable to accept
an imperfect and evolving product because a software vendor never promises that
the first product release will be the last. Vendors also never claim that their software
products will not have to be enhanced; on the contrary, we want them to be
enhanced. Why, then, do we have exact opposite expectations of internally
developed software?
For example, when vendors publish a new release of their products, they include new
functionality, new screens, new modules—and of course some fixes to defective parts
of the prior release. Sometimes, the new software release is completely redesigned
and is not even compatible with the previous release. We do not hesitate to pay good
money to upgrade purchased software products under those conditions. But when
the in-house IT technicians have to redesign a BI target database or portions of a BI
application after the third or fourth release, the situation is treated like a disaster.
Organizations must accept the fact that internally developed applications evolve over
time, just as vendor software products do. Hence, it is high time to embrace the
application release concept.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
449/631
Guidelines for Using the Release Concept
When developing BI applications under the release concept, IT and business
management must agree on and follow some basic guidelines (Table 16.1). When
following these guidelines, there should never be any concern about the
completeness of a BI application on its initial release. Any incomplete functionality
that was negotiated out of the scope due to unforeseen roadblocks will be bundled
with new functionality in the next release or some future release. Business
management gets to decide how long to defer the functionality, and the decision will
probably be based on the priorities of outstanding requirements.
Table 16.1. BI Application Release Guidelines
Dos and Don'ts of Application Releases
Releases should be delivered every three to six months (the first release will
take longer).
Releases must have very small and manageable deliverables.
Expectations regarding deliverables must be managed continuously and must
remain realistic.
A release does not have to equal a completed BI application. It may take
several releases to complete a BI application.
The first release of a BI application should deliver only the basics.
Business management must be willing to accept a partial delivery of a BI
application (e. g., the basics).
Nothing is cast in concrete. Everything is negotiable. That includes scope,
schedule, budget, resources, and quality.
The enterprise infrastructure, both technical and nontechnical, must be robust.
Meta data must be an integral part of each release; otherwise, the releases
will not be manageable.
The development process must be sound and flexible. Developing releases
feels like prototyping, but the effort is more disciplined and controlled because
the results are treated as production-worthy deliverables.
Designs, programs, and tools must be flexible to allow for occasional redesigns
of BI target databases and BI applications.
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
450/631