Deloitte Analytics - Building a Better Enterprise Data Architecture

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


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


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


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


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


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


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


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


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


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


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


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]

mailto:[email protected]

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