deloitte analytics - building a better enterprise data architecture
DESCRIPTION
Many organizations pursue strategic enterprise initiatives, such as data warehousing and business intelligence, without first investing in Enterprise Data Architecture (EDA). As a result, these initiatives often lead to data silos. This paper describes the top 10 mistakes that organizations make when they undertake an EDA initiative.TRANSCRIPT
Satyajeet Dhumne
Deloitte Consulting LLP
January 24, 2011
Building a better enterprise
data architecture
The top 10 enterprise data
architecture mistakes and
how to avoid them
The top 10 enterprise data architecture mistakes and how to avoid them
Contents
Introduction 1
Mistake One: Making the EDA optional 2
Mistake Two: Limiting the scope of the EDA 3
Mistake Three: Not following an industry standard framework 4
Mistake Four: Not defining the operational view of the EDA 5
Mistake Five: Treating the EDA as a project 6
Mistake Six: Developing a technology-driven EDA 7
Mistake Seven: Not having business owner and executive support 8
Mistake Eight: Not defining a target EDA 9
Mistake Nine: Following a bottom-up approach 10
Mistake Ten: Hiring a senior data modeler as the enterprise data architect11
Conclusion 12
Introduction
The top 10 enterprise data architecture mistakes and how to avoid them 1
Introduction
Many organizations pursuing strategic enterprise initiatives, such as Data Warehousing (DW) and
Business Intelligence (BI), learn the hard way about the importance of their Enterprise Data
Architecture (EDA). Quite often, these initiatives are executed without the overarching data guidance
that is core to building and maintaining an EDA that meets the current needs of the organization,
and is flexible enough to grow with it. As a result, these initiatives often lead to data silos that satisfy
immediate information needs of a few business groups, but rarely integrate with the process,
business, and systems and technology architecture of the organization as a whole. An ineffective
EDA then becomes a scapegoat for data confusion shared by the stakeholders driving these
initiatives.
The fact of the matter is, a foundational EDA — which includes the enterprise data model and
information value chain analysis — is a prerequisite for any DW or BI initiatives. An EDA provides
the blueprint to leverage the organization’s data as assets toward profitability and/or improved
performance. It also facilitates data standardization and provides data integration guidance across
the enterprise. In other words, the EDA should be initiated first to establish the overall framework for
other IT initiatives, such as DW and BI. However, at many organizations, the IT department starts
with BI/DW initiatives first and then tries to introduce data standardization and integration across the
enterprise.
To avoid cost overruns and expensive program failures (due to ineffective data delivery systems and
nonsingular interpretation of data), it is imperative for organizations to invest in the creation of a
foundational EDA. Building an EDA is no mean feat, however. It is a complex undertaking that is
fraught with pitfalls and challenges. This paper describes the top 10 mistakes that organizations
make when they undertake an EDA initiative. It provides strategies to avoid these mistakes and
facilitates a more effective EDA build process.
Mistake One: Making the EDA optional
The top 10 enterprise data architecture mistakes and how to avoid them 2
Mistake One: Making the
EDA optional
In todays fast-paced, highly complex IT world, the EDA is often perceived simply as a nice-to-have
architectural product. IT managers also tend to put aside the EDA effort if their IT budget is curtailed.
Many times, IT managers don’t understand the importance of an EDA until it’s too late. By making
this critical effort optional, however, the organization becomes vulnerable to a plethora of information
management issues. The following are just a few symptoms of not having a
functional EDA:
Missing or competing versions of business data entities
An incomplete understanding of the organization’s data life cycle
The existence of redundant data stores representing similar data objects
The inability to perform impact analysis on IT systems due to events, such as changes in source
systems, business changes, and mergers and/or acquisitions.
Continued implementation of data extraction, data integration,, and data exchanges as stove-
pipes
Building an EDA is not really optional; it is foundational. A robust EDA allows an organization to
define data requirements, integrate data across the enterprise, and more efficiently manage its data
assets. IT and business users have shared responsibility in defining and maintaining this critical
architectural product. Instead of placing its construction and maintenance at the bottom of the
priorities list, organizations should think of the EDA as the underpinning of their BI/DWBI/DW efforts
and should allocate the resources necessary — both human and capital — to build an EDA that will
serve both short- and long-term business, functional, and IT needs.
Mistake Two: Limiting the scope of the EDA
The top 10 enterprise data architecture mistakes and how to avoid them 3
Mistake Two: Limiting the scope
of the EDA
IT managers often define the EDA as simply a collection of numerous data models or data design
artifacts in a single place. However, this approach only covers the data design component of the
data architecture, depicting the data elements and relationships at various levels of granularity.
There are other significant aspects of data architecture that should be included in the scope of the
EDA design. They are:
The Enterprise Data Model — an integrated set of key data elements to support the mission of
the organization
The Information Value Chain — describing how data originates and how it flows through
various systems
The Data Delivery Architecture — the architecture to deliver data to its consumers (people
and applications)
Unfortunately, data architects seldom address these aspects during the design of the EDA.
However, if these components of the EDA are included in the original design, it is more likely that IT
managers will be better able to provide the desired 360-degree view of enterprise data to the
stakeholders.
Mistake Three: Not following an industry standard framework
The top 10 enterprise data architecture mistakes and how to avoid them 4
Mistake Three: Not following an
industry standard framework
In some organizations, the EDA seems to have organically evolved over time, with no guiding plan
or methodology in place. This situation is similar to executing a software development project
without following a proven methodology and architecture framework. The result is that the
organization is often left with an end product that serves a limited purpose, such as satisfying the
checklist of deliverables mandated by the program management office or external fiscal monitoring
authority. By not following an industry standard framework, an organization may not be able to
effectively define and leverage the EDA. This situation is especially vexing for organizations with
stringent audit requirements, particularly in the public sector. The lack of a clearly defined EDA may
leave them facing a difficult audit situation in the future.
Instead, IT managers should choose a design framework that is in line with their organization’s
enterprise architecture efforts. Leveraging a design framework will help them establish — and
follow — a critical path in the EDA design, and it will facilitate the construction of an EDA that better
serves a broad range of data needs.
For building EDA, there is no “one-size-fits-all” solution. However, there are well-known architecture
frameworks and standards that are practiced by many IT organizations today, including:
Federal Enterprise Architecture — Data Reference Model (FEA — DRM). The FEA is a
methodology, established by U.S. Office of Management and Budget (OMB), that delineates a
common methodology building an EDA and for acquisition and installation of IT systems and
services for the U.S. federal government. It helps government agencies share information
resources, contain costs, and improve services across organizational boundaries. The DRM
component of the FEA describes the types of data, interaction and exchanges that occur between
the various federal agencies, and between those agencies and the public. The DRM establishes a
common data model to help streamline data acquisition, storage, and delivery. Although the FEA
was developed for U.S. government use, its principles can be applied to private sector initiatives.
The Open Group Architecture Framework (TOGAF). TOGAF is a framework for EDA design and
deployment that provides a well-rounded methodology for the design, planning, implementation,
and governance of an EDA. The TOGAF framework typically contains four areas: business,
application, data, and technology. TOGAF provides a high-level starting point for an EDA design
that can be built with the flexibility to meet current and future needs. It stresses modular design
concepts, standardization, and the use of proven technologies to build the EDA.
Zachman Framework. The Zachman Framework formally defines the data structure of the
organization via a data classification matrix. It is not an EDA methodology per se because it does
not define processes for collecting, managing, or distributing data. Rather, it is a taxonomy for
organizing data that clarifies what the data is used for, the transformations the data goes through,
and by whom it is used.
Each of these frameworks has its advantages, and it is not essential to rigidly follow any particular
framework. An organization may decide to adopt all or part of either of these frameworks to build an
EDA based on its unique business and/or organizational requirements.
Mistake Four: Not defining the operational view of the EDA
The top 10 enterprise data architecture mistakes and how to avoid them 5
Mistake Four: Not defining
the operational view of the EDA
Having both a strategic and operational view of enterprise data is critical. However, at many
organizations, the EDA is defined only at a high level that provides a view of the key enterprise data
elements, but does not provide an operational view of the data organization. As a result, the EDA
cannot be easily used by IT or the business for planning, impact analysis, development, or
maintenance purposes.
Instead, when designing the EDA, IT managers should envision how it will be used for both tactical
and strategic purposes. They should then strive to articulate the details of the EDA — including data
supply chain analysis (how data gets generated and fed into IT systems), database architectures,
DI/BW architectures, meta-data architecture, etc.).The EDA should also describe any external data
suppliers and external data consumers. By having an operational and top-down view of the EDA,
various groups within IT, from strategic planners to data administrators, will be able to understand
both CEO’s viewpoint and the viewpoint of those in IT.
Mistake Five: Treating the EDA as a project
The top 10 enterprise data architecture mistakes and how to avoid them 6
Mistake Five: Treating the EDA as
a project
Treating the EDA as a one-off project commonly occurs when an organization is reacting to the EDA
needs. By definition, a project is an effort that has specific objectives and is to be executed over a
finite time period. Once the objectives are met or results are delivered, the effort comes to an end.
Building EDA is not a project for several reasons, including:
The Data Architecture of an enterprise must be constantly updated due to internal changes or
external mandates/requirements.
The IT department is expected to define and drive the existing EDA to a target state in a process
that will be ongoing, with no finite timeframe or endpoint.
The target objectives of EDA of an enterprise may change due to fundamental changes to the
business, such as a change in business model, merger or acquisition, or government legislation.
Instead, building the EDA should be treated as an ongoing technology program, which directs
various IT projects from a data standpoint and also receives building blocks as inputs from these IT
projects. These projects may be new software development, BI/DW, or data administration. The
program can also be viewed as a hub-and-spoke architecture process, where various groups within
IT provide input to, and benefit from, the EDA at the same time.
Mistake Six: Developing a technology-driven EDA
The top 10 enterprise data architecture mistakes and how to avoid them 7
Mistake Six: Developing a
technology-driven EDA
IT managers are often advised to start with a tool and/or repository to build an EDA. However, this
approach merely creates a collection of data design artifacts in one repository, which can be
accessed by interested IT staff or business users, rather than a true EDA. A large collection of
disconnected data models and design artifacts rarely posses the integrity required by a true EDA.
While it is true that a repository can provide a consistent and scalable solution to store artifacts,
technology by itself should not drive the definition of the EDA.
Instead, IT managers should focus their initial efforts on developing a formal business case for the
EDA. This task will not only force the organization to consider the business drivers, business
requirements, and the development plan; for the EDA, it will provide a baseline to measure the
success of the initiative over time. To this end, technology for the EDA tools and repository should
be carefully evaluated for how well they meet organizational needs by following industry standard
methodologies. Also, in using the business case approach to the EDA, the technology and tools
become an integral part of the EDA solution, but they are not the solution itself.
Mistake Seven: Not having business owner and executive support
The top 10 enterprise data architecture mistakes and how to avoid them 8
Mistake Seven: Not having
business owner and executive
support
Business owners are, in the end, the drivers for the EDA program, because their information needs
will largely determine the scope and structure of the EDA. Without commitment and support from the
business owners, EDA development essentially becomes purely an IT exercise. Further, without
business sponsorship, business subject matter experts (SME) may not provide sufficient insight into
the business processes and its information needs to construct an EDA that meets those needs.
Thus, the quality and the depth of the EDA in this situation will depend solely on the data architect’s
experience and knowledge, and the end product is less likely to be accepted by the business
owners.
To improve business acceptance and usability of the EDA, it is imperative to get business
representatives involved in the initiative at the start. Business SMEs’ participation is critical,
especially when building the enterprise data model of the data architecture. By involving business
users and getting sponsorship for the effort from business leaders, IT can build a sustainable EDA
that meets business needs, is widely accepted, and provides a high return on investment.
In order to make EDA effective in the organization, executive sponsorship is equally important for
many reasons including: high visibility, staff commitment, resource allocation, PMO support etc.
Having executive support will also help in continued fiscal commitment towards the on-going EDA
program.
Mistake Eight: Not defining a target EDA
The top 10 enterprise data architecture mistakes and how to avoid them 9
Mistake Eight: Not defining a
target EDA
Most organizations exercise due diligence in articulating and documenting their current EDA. But in
many cases, the effort stops there. Describing the current EDA certainly helps IT personnel and
business users understand the current data organization; however, it is left to development
managers to define the target data architecture. Often, the direction taken by development
managers will affect the quality of the EDA — for example, by using data entities that are not aligned
to enterprise business entities and/or by not sourcing data from authoritative systems.
In order to facilitate the alignment of the EDA with the overall business strategy or enterprise
mission, and to more effectively manage data as a critical enterprise asset, it is essential to develop
a clear definition of the target-state EDA.
It is important to consider the following factors in defining the target data architecture:
Business model
Information needs — both current and anticipated
Strategic impact of information on business success
Data-sharing requirements
Overall organizational and industry trends
A conceptual data model describing key data entities
By knowing both where the EDA is — and where it is supposed to be in one, three, even five
years — IT will have a better probability of success in managing enterprise data, in both the short
and long term.
Mistake Nine: Following a bottom-up approach
The top 10 enterprise data architecture mistakes and how to avoid them 10
Mistake Nine: Following a
bottom-up approach
Some organizations view their EDA as merely a collection of data models that are available in some
format within the IT department. In this situation, in order to jumpstart the EDA initiative, IT
management will most likely conduct a quick survey of the availability of the physical data models for
key enterprise information systems and select a stable target environment. The data modeling
notation may also be standardized in order to collectively hold the data models in one place
(hopefully a repository).
However, with this bottom-up approach, critical components of the EDA might be overlooked.
These include:
Key enterprise data entities
An overarching, top-down view of the data organization
Data dependencies
Data usage patterns and needs
By starting at the bottom layer of the EDA, IT will miss the opportunity to understand the enterprise’s
data organization from a C-suite standpoint. At the same time IT may arrive at inconsistent
enterprise data model and information value chain. In other words by following bottoms-up
approach; EDA may become IT-centric rather than business-centric.
Instead, IT managers should kick-start the EDA effort by building a conceptual Enterprise Data
Model first and then refining the model through the logical to the physical. This process will then set
the foundation for the remaining components. Designing and assimilating the individual data models
should be performed as an ongoing activity to keep work products current and to accommodate
changing or additional data needs.
Mistake Ten: Hiring a senior data modeler as the enterprise data architect
The top 10 enterprise data architecture mistakes and how to avoid them 11
Mistake Ten: Hiring a senior
data modeler as the enterprise
data architect
One common mistake made by organizations today is to try and quickly advance the EDA initiative
and deliver quick results to management by hiring a senior data modeler to be the Enterprise Data
Architect. A senior data modeler usually has strong data modeling skills with a focus on specific
business processes or subject areas. However, most data modelers typically do not demonstrate
cross-organizational knowledge nor do they work on enterprise-level initiatives.
A better solution is to promote a senior data modeler from within the organization. The enterprise
data architect should obviously have hands-on data modeling experience with large-scale enterprise
systems. The architect should also have database administration knowledge, meta-data
management experience, and cross-organizational business analysis experience as well. Further,
he or she should have solid systems implementation experience in order to understand real-life
challenges, conceptualize critical data at the enterprise level, and articulate the data architecture
implementation to IT. The architect should also have the breadth of technical knowledge and
leadership skills to play an ever-evolving role and drive related EDA initiatives, such as defining an
enterprise meta-data strategy.
Finally, an enterprise data architect must also have a strong business background, primarily
because he or she is expected to serve as the liaison between the business and the IT organization
to help define a suitable target state for the organization. Ideally, the person should have worked in
the organization long enough to demonstrate a solid understanding of its business processes and
strategic direction, as well as the IT department’s overall technology direction.
Conclusion
The top 10 enterprise data architecture mistakes and how to avoid them 12
Conclusion
Developing an EDA is a strategic IT investment and, as such, requires careful planning and an
understanding of the organization as a whole. Data standardization and integration guidance are
critical to the success of DW/BI programs. By defining key components of the EDA — such as the
enterprise data model — as high-priority, ongoing initiatives, IT managers can facilitate data
standardization and integration across the enterprise.
The scope and methodology to build the EDA must be customized for the individual needs of the
organization. By following the guidelines above, organizations can increase their probability of
success in defining their EDA.
Satyajeet works as a Consulting Manager at Deloitte Consulting LLP in Arlington, Virginia; where he
provides consulting services to public sector clients in the areas of data warehousing, business
intelligence, and data management.
Satyajeet has a Masters in Management of Information Technology from the University of Virginia
and has been in leadership and management positions in IT for the past 25 years. He can be
reached at [email protected].
References
FEA DRM: Federal Enterprise Architecture Data Reference Model Released by the U.S. OMB
TOGAF: The Open Group, TOGAF. The Open Group Architecture Framework. The Open Group.
(www.opengroup.org) ISBN 1-9316245-6.
Zachman Framework: Zachman, John A. www.ZachmanInternational.com
DAMA — DMBOK: First Edition, DAMA International. (www.dama.org) [ISBN 978-1-9355040-2-3]
Enterprise Architecture Planning, Steven Spewak and Steven Hill. John Wiley & Sons, Inc. —
QED [ISBN 0-471-599859]
About Deloitte
Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of
member firms, each of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed description
of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see www.deloitte.com/us/about for a detailed
description of the legal structure of Deloitte LLP and its subsidiaries.
Copyright © 2011 Deloitte Development LLC. All rights reserved.
Member of Deloitte Touche Tohmatsu Limited