Moss L.T., Atre S. Business intelligence roadmap: The complete project lifecycle for decision-support applications
Подождите немного. Документ загружается.
[ Team LiB ]
Step 2, Section B: Nontechnical Infrastructure
Evaluation
Things to Consider
Logical Data Model
Do we already have logical data models for the source systems? If
not, who is responsible for creating a logical data model for this BI
project?
Who are the data owners and business people who have to
participate in the validation of the logical data model and the business
meta data?
How many trained data administrators do we have? Will we have to
hire more?
Who will integrate our logical data model into the enterprise logical
data model?
Who will validate the expanded enterprise logical data model?
What CASE tool do we have for logical data modeling? Will we need
to license (buy) one?
Meta Data
Do we already have a meta data repository? Will we need to license
(buy) or build a meta data repository?
If we have one, how easy is it for the business people to access and
navigate through the meta data repository? Do we need to enhance it?
Who is responsible for capturing all the meta data components?
Who is responsible for loading the meta data into the meta data
repository?
How will we merge the new business meta data from the CASE tool
with the new technical meta data from the ETL tool and the OLAP tool?
Standards, Guidelines, and Procedures
Are our current standards too lax or too stringent?
Where are the standards documented? Are they being followed?
How effective are our data quality guidelines for measuring dirty
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
101/631
data and and triaging data cleansing?
Are our change-control procedures easy to use? Do we have a
template?
Do we have a template for an issue log?
What are our testing standards?
Are we habitually testing too much or too little? Are we testing the
right things?
How are we currently resolving technical and business disputes?
Do we need to create or change our dispute resolution procedure?
What are the roles and responsibilities that will be assigned to the
core team members?
Is our current team structure effective?
Enterprise-wide nontechnical infrastructure is a critical success factor for a BI
decision-support environment. Without a cross-organizational infrastructure, BI
applications would only contribute to the existing chaos of stovepipe applications and
databases.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
102/631
[ Team LiB ]
The Effects of Stovepipe Development
In the past, the mental model for providing an automated information technology
(IT) solution to a business problem has been to "divide and conquer."
Divide a large problem into smaller "digestible" pieces, that is, prioritize and
separate the deliverables.
1.
Conquer the problem by working on each piece individually, that is, build each
deliverable separately.
2.
This approach works very well for reducing risk by breaking a complex problem into
small, manageable chunks. However, this approach also has a severe drawback
when applied without a nontechnical infrastructure. Namely, it produces stovepipe
systems (automation silos). The effects of stovepipe systems are lost business
knowledge and lost cross-organizational business view, which severely impact
business analytics and data mining activities.
Most businesses are very complex, and as organizations mature, their business
complexity increases. As business complexity is broken apart into smaller and less
complex components, the interrelationships among those individual components are
lost. Much of the business intelligence is contained in these lost interrelationships,
and that is a problem for BI applications. Most BI applications, and especially data
mining applications, expect to find "golden nuggets" of business wisdom embedded
in these complex interrelationships.
Although business managers can answer most questions about the business
functions of their own departments, when asked a question spanning two or three
lines of business (where complex interrelationships have been lost), those managers
must scramble for weeks to piece together the answer. Fundamental business
questions, such as the ones illustrated in Figure 2.7, present multimillion-dollar
problems to large organizations.
Figure 2.7. Fundamental Business Questions
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
103/631
The answers to these and many other questions do exist in the real business world.
We have just been neglecting to design our systems in a cross-functional manner
that would allow us to find these answers quickly.
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
104/631
[ Team LiB ]
The Need for Nontechnical Infrastructure
An organization needs to create a nontechnical infrastructure to prevent the BI
decision-support environment from becoming as fragmented as the operational and
traditional decision-support environments, from which cross-organizational questions
cannot be answered. Creating this infrastructure involves cross-organizational
activities such as those listed below.
Conduct an extensive business analysis involving business people from many
lines of business. During this activity, define or redefine the lost complex
interrelationships among business functions and business data.
Adopt a system of peer reviews to support cross-organizational attendance and
evaluation of business analysis activities.
Resolve age-old disputes about data definitions and domains (valid data
contents).
Standardize data names and data values to reflect true business rules and
business policies.
Get agreement from the business people on the business rules and business
policies in the first place.
Create a regular forum for business people to maintain and review the
standards, business rules, and business policies on an ongoing basis.
Over time, create one consolidated, nonredundant data architecture for the
entire enterprise to reflect the complex reality of the business; that is, create an
enterprise logical data model. This model documents the data inventory of an
organization. It is also the primary vehicle for mapping the inventory of
operational data to the inventory of BI data.
Create a meta data repository and populate it with nonredundant meta data.
Create an inventory of source data and map it to the applicable BI target
databases. Also create an inventory of other system components, such as
programs, reports, screens, and so on, thereby identifying the reusability of
data and process components.
Create and manage one expanding central staging area (per load periodicity)
for the ETL processes. Do not allow independent ETL processes for each data
mart solution.
Enterprise infrastructure activities, technical as well as nontechnical, are strategic
cross-organizational activities. A central enterprise architecture group (Figure 2.8)
must manage and coordinate these activities. Many large organizations have a
strategic enterprise architecture group whose charter is to integrate and manage the
IT infrastructure components as assets of an organization. These infrastructure
components are inventories or models of business functions, business processes,
business data, meta data, applications, and other technical implementation
elements. If an organization does not have an enterprise architecture group, then
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
105/631
data administration can perform the information architecture subfunction, which
includes creating and managing the enterprise logical data model and the meta data
repository. If the organization has a separate meta data administration, the
information architecture responsibilities would be divided between those two groups
(data administration and meta data administration).
Figure 2.8. Enterprise Architecture Group
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
106/631
[ Team LiB ]
Enterprise Architecture
An enterprise architecture is comprised of a set of pictorial representations (models)
of the organization in terms of business functions, business processes, and business
data. Each enterprise architecture model is supplemented with supporting meta
data, such as standard definitions, business rules, and policies. The purpose of these
models is to document the set of business actions performed on any real-world
object in the course of conducting business. In other words, enterprise architecture
models describe the actual business in which the organization engages.
Every active organization has an enterprise architecture by default, even if it is not
documented. With undocumented architecture, the organization's business actions
and business objects are most likely not consistently understood by everyone in the
organization. The goal of documenting the architecture is to avoid abusing, misusing,
or redundantly recreating unique processes or data about business objects, which
can lead to losing sight of the cross-organizational picture.
A fully documented enterprise architecture includes at least five architectural
components (Figure 2.9). The following subsections describe these components.
Figure 2.9. Enterprise Architecture Components
The Business Function Model
This model depicts the hierarchical decomposition of an organization's nature of
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
107/631
business; it shows what the organization does. This model is instrumental for
organizing or reorganizing the structure of an organization into its lines of business.
Usually one vertical line of business supports a major business function on this
model. Two examples of such an alignment are the loan-origination division and the
loan-servicing division of a mortgage-lending institution.
The Business Process Model
This model depicts the processes implemented for the business functions; it shows
how the organization performs its business functions. This model is essential for
business process reengineering as well as business process improvement initiatives,
which often result from BI projects. For example, a business process model could be
analyzed to determine whether it is possible to streamline a current business process
called loan payment processing because customers have complained about the long
delays in posting their loan payments while their loans continue to accrue interest.
The Business Data Model
This model, which is commonly called the enterprise logical data model or enterprise
information architecture, shows what data is part of the organization's business
activities. This model depicts the following:
Data objects participating in a business activity
Relationships among these objects as they exist in the actual business activities
Data elements stored about these objects
Business rules governing these objects
Since data objects and data elements are all unique, they appear in the real world
only once. Therefore, they are documented in the business data model only once,
regardless of the numbers of physical files and databases used for their storage.
There is only one business data model for an organization. This model and the meta
data repository are the two most important nontechnical infrastructure components
for an evolving BI decision-support environment.
The Application Inventory
The application inventory is an accounting of the physical implementation
components of business functions, business processes, and business data (objects as
well as data elements). It shows where the architectural pieces reside in the
technical architecture. Application inventory entries include the relationships among
the physical implementation components, such as programs, job streams, databases,
or files.
Organizations should always identify, catalog, and document their applications as
well as the business rules about their business data as part of the development work
on every project—but they seldom do. Such inventories are paramount for
performing impact analysis. Remember the colossal efforts of Y2K impact analysis
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
108/631
without such an inventory!
The Meta Data Repository
Although "a picture is worth a thousand words," business models without words are
not worth much. The descriptive details about the models are called meta data.
Business meta data is collected during business analysis, and technical meta data is
collected during design and construction. The two types of meta data are linked to
each other and made available to the business community of the BI decision-support
environment. Meta data is an essential navigation tool. Some examples of meta data
components include the following:
Column name
Column domain (allowable values)
Table name
Program name
Report name
Report description
Data owner
Data definition
Data quality metrics
[ Team LiB ]
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
109/631
[ Team LiB ]
Enterprise Standards
Organizations must establish architectural standards for their BI decision-support
environments in the same way they set up standards for their Web sites. An
organization would never consider building its Web site with a different look and feel
for each Web page. In the same vein, no organization should build a BI decision-
support environment in which each BI application had a different look and feel.
Therefore, all BI applications must adhere to the same enterprise standards within
an organization. Figure 2.10 lists the categories of standards to develop, which are
briefly described below.
Figure 2.10. Enterprise Standards
Development Approach
Business Intelligence Roadmap provides a complete list of all the major activities and
tasks that are appropriate for BI projects. However, since scope and deliverables of
BI projects can vary widely, not every BI project team has to perform every single
activity in every step. Some BI projects may justifiably skip activities within a step,
combine activities from different steps into one, or skip entire steps. However, no BI
project should be developed ad hoc. Organizations should have some guidelines that
list the minimum number of activities required (minimum work breakdown
structure), the mandatory deliverables, sign-off requirements, and workflow
dependencies in order to control the project risks.
Data Naming and Abbreviations
北斗成功社区 BeiDouWeb.com 教育音视频/电子书/实用资料文档/励志音乐影视 仅供免费试用/版权原著所有
110/631