 William
McKnight is founder and president of McKnight
Associates, Inc., a consultancy dedicated to
building business intelligence by providing
ROI-generating data warehouse/business intelligence
services, solutions, specialized resources and
training. McKnight has designed numerous data
warehouses in diverse industries and has more
than 15 years of data management experience.
He can be reached at (214) 514-1444 or wmcknight@mcknight-associates.com. |
Imagine trying to build
a home without a blueprint. It would be nearly impossible
to see how each nail, beam and piece of wood fit
together to create a usable space. While the process
of building a data warehouse from the ground up
might seem just as daunting to owners of multiple,
disparate data marts, it really is composed of logical,
ordered steps.
You can build a complete
enterprise data warehouse one subject area at a
time, with minimal rework of future subject areas.
Too often, data warehouses end up with subject areas
that are incongruent with needs beyond the initial
application, which results in duplicity of data
and efforts and siloed mindsets. Data is an enterprise
asset. As such, a single version of the data should
be made available across the enterprise for the
benefit of all users.
Architectural efficiencies
aside, numerous business objectives are supported,
or outright met, with enterprise data. For instance,
marketing can have access to sales and return data
to improve the effectiveness of its programs. Additionally,
customer support can have access to sales, returns,
marketing promotions the customer has received and
customer demographics. This alleviates much of the
burden placed on customers to repeat this information.
For example, we’ve
been buying software from the same company for years.
It soon became clear that their marketing, sales
and customer support departments were working from
siloed databases. Marketing materials were addressed
to “McKnight & Associates,” sales
were credited to “McKnight Associates, Inc.”
and customer support recognized us as “McKnight
Inc.”
Originally, when they greeted
us as “McKnight Inc.” we didn’t correct
them. But it became difficult to overlook this inconvenience
as our product set grew. Providing background again
and again for each new question was difficult to
justify.
The support reps have cordially
answered product questions for years. But soon each
interaction became the beginning of a new adventure.
And even if marketing and customer support could
correct our name in their systems, they still wouldn’t
have known our product set and purchases.
With each contact point
creating different customer attributions, they could
never know how profitable we are or be able to household
us or determine any realistic customer lifetime
value. Our phone calls would never be answered any
sooner or by more experienced representatives. What
a time waster we must look like tocustomer support.
On the other hand, to the sales department we look
great—too great! We resolved the issue by selecting
a different vendor.
Sharing brings us closer
This example was about customer data, but the
value of an integrated view applies to all enterprise
data. The value of call center data is multiplied
when it is integrated with other views, such as
business schedule, communication channel, application
or product, to provide context to agent and call
analysis.
The integrated data warehouse
is the collection point for all customer-facing
operational systems. It is the data launching pad
for more specific application needs, but it ensures
a common view of important business data incorporating
multi-department and multi-touchpoint wisdom. The
higher the degree of sharing and integration, the
better the realization of the enterprise data goal.
This enterprise approach
requires cross-functional cooperation, which in
turn requires a high degree of data warehouse leadership.
The business process problems encountered when trying
to accommodate multiple enterprise needs in a subject
are more complex than the technology issues.
•
Ownership: Enterprise subject areas require
shared ownership.
•
Privacy: Often, all data is available to
all applications.
•
Concurrency: Multiple application interests
mean creating an architecture built for high concurrency.
•
Funding: Sharing funding may be required
to build leverageable components.
•
Results measurement: Whose vision and leadership
produced the value in the enterprise subject area?
One look at these issues
could send many a data warehouse project leader
to the sidelines to build multiple single application
warehouses. However, many business environments
today are encountering severe challenges due to
early abandonment of a fundamental element of successful
data warehousing—that is, an enterprise view
of the data.
Some take the term “enterprise”
literally and can apply it to their entire organization
at once. Others might initially use a subdivision
of their true enterprise, delivering value and evangelizing
that value out to other parts of the organization
as a means to grow the impact of the data warehouse.
Enterprise data warehousing is the mindset of approaching
each iteration as a progression toward building
comprehensive, multipurpose views for each business
subject.
Foresight is 20/20
In building the enterprise view of any subject
area, we need to look at user interests from a cross-functional,
business-interest point of view. In order to accomplish
this, we need to anticipate the business applications
and subjects that the data warehouse will eventually
address. This foresight gives an indication of who
will be contributing to the development of any specific
subject area.
For example, if we know
that both Project A, which we are building now,
and Project B, which is scheduled for six months
out, need customer data, then we can seek user input
for the customer data parameters we’re building
now. While initially this can be accomplished during
a business discovery phase, like that which is offered
by Teradata, user input and subject area continuity
are essential during all phases of warehouse development.
The payoff? Everyone is
on the same page and working toward the same goal.
T
|
|
 Steve
Hoberman, lead data warehouse developer
for Mars, Inc., has been in the field of
data modeling since 1990. Hoberman specializes
in data modeling training, design strategy
and technique development. He wrote the
book Data Modeler’s Workbench and is
the founder of Design Challenges, a discussion
group that tackles complex data modeling
scenarios. He can be reached at www.stevehoberman.com. |
Twelve of us sat around
a conference table tasked with determining how
new reporting requirements would impact our
existing data warehouse architecture. Being
the only data modeler in the group, I prepared
for this meeting by creating an enterprise data
model at a subject area level and highlighting
in color which of the new reporting requirements
already existed in our data warehouse.
For example, I highlighted
Order in green to indicate that this already
existed. I highlighted
Customer in yellow to indicate that this was
part of the new requirements that existed in
part but not in its entirety. I
highlighted Contract in red to indicate that
this did not exist at all in the data warehouse.
What was fascinating
was that this entire subject area enterprise
data model containing the overlap between the
data warehouse and new reporting requirements
fit on a single sheet of legal paper. Within
hours, the team was able to agree on the overlap,
identify several possible integration issues
with adding these new reporting requirements
to the data warehouse and validate the meaning
of each of the subject areas. The senior executive
in the room was so impressed with this one-page
view of the organization that he referred to
the model as a compass because it will be used
to determine our direction for adding new subject
areas based on their impact to the data warehousing
architecture.
Don’t let the
details get you down
I’ve had several successes like this
that resulted from creating a subject area model.
This type of data model is a diagram containing
standard data modeling syntax that describes
the business in non-technical terms at a subject
area level. Examples of subject areas include
Customer, Employee, Account, Order, Promotion,
Organization and Product.
Each subject area requires
a clear and agreed-upon definition. Definitions
are critical because if you can get everyone
to agree on what a Customer is, imagine how
much easier it will be to agree on all of the
detailed logical components of Customer, such
as Customer Location, Customer Association and
Customer Demographics.
Relationships in a
subject area model capture business rules, as
illustrated by the following rules of an Order:
•
An Order must be placed by a single Customer.
•
An Order must be for one or more Products.
•
An Order can contain many Shipments.
•
An Order can include many Promotions.
•
An Order must be serviced by a single
Employee.
The subject area model
is an ideal medium for representing a broad
scope, such as an enterprise view. An enterprise
view at a very detailed logical or physical
level can be a nightmare to maintain and overwhelming
to comprehend. The subject area model’s
elegance lies in its ability to depict the important
concepts—the subject areas—and leave
the details within each subject area for the
next round of analysis. The result? On a single
page you can review, validate and make decisions
that impact projects before the work actually
begins.
Creating a subject
area enterprise data model helps an organization
achieve a single and unambiguous understanding
of the business. It forces the manufacturing
and sales departments to agree on a single definition
of Product, the marketing and sales departments
to agree on the meaning of a Customer, or the
logistics department to articulate the relationship
between an Order and a Shipment.
The model is also a
great tool to help bring new people up to speed.
Before I started working for a large manufacturing
company, I received an enterprise model to study.
I started my first day on the job with a clear
understanding of the key concepts within the
business. When new people join my team, before
showing them any logical or physical data models,
I walk them through a subject area model to
give them the necessary high-level understanding.
A subject area level
understanding of the enterprise eases the pain
of:
•
Determining how something new fits in with
an existing architecture. For example, how
do the new reporting requirements fit within
the context of the existing data warehouse?
•
Integrating, replacing or merging existing
applications. Through the use of color and
other highlighting techniques, the subject area
model can visually show where integration issues
might exist, which subject areas of the ERP
solution will be replaced with data from the
legacy order processing application, or how
Company X and Company Y’s logistics applications
compare in terms of gaps and redundancies.
•
Prioritizing projects based on their dependencies
and importance to the business. For example,
if a profitability reporting application is
identified as a very high priority to the business,
its subject areas will be highlighted to distinguish
them from less important subject areas.
The bold, the simple,
the powerful
The subject area model is a powerful technique
used to capture key concepts in the business
and the ideal medium to represent an enterprise
view. The subject area model promotes broad
business understanding and leads to better decision
making. T
|
Quick Links
