Building a better enterprise data architecture

8/3/2019 Building a better enterprise data architecture

1/15

Satyajeet DhumneDeloitte Consulting LLPJanuary 24, 2011

Building a better enterprise

data architectureThe top 10 enterprise dataarchitecture mistakes andhow to avoid them


2/15

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


3/15

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) andBusiness Intelligence (BI), learn the hard way about the importance of their Enterprise DataArchitecture (EDA). Quite often, these initiatives are executed without the overarching data guidancethat 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 satisfyimmediate 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 ineffectiveEDA then becomes a scapegoat for data confusion shared by the stakeholders driving theseinitiatives.

The fact of the matter is, a foundational EDA which includes the enterprise data model andinformation value chain analysis is a prerequisite for any DW or BI initiatives. An EDA providesthe blueprint to leverage the organizations data as assets toward profitability and/or improvedperformance. It also facilitates data standardization and provides data integration guidance acrossthe enterprise. In other words, the EDA should be initiated first to establish the overall framework forother IT initiatives, such as DW and BI. However, at many organizations, the IT department startswith BI/DW initiatives first and then tries to introduce data standardization and integration across theenterprise.

To avoid cost overruns and expensive program failures (due to ineffective data delivery systems andnonsingular interpretation of data), it is imperative for organizations to invest in the creation of afoundational EDA. Building an EDA is no mean feat, however. It is a complex undertaking that isfraught with pitfalls and challenges. This paper describes the top 10 mistakes that organizationsmake when they undertake an EDA initiative. It provides strategies to avoid these mistakes andfacilitates a more effective EDA build process.


4/15

Mistake One: Making the EDA optional


Mistake One: Making theEDA optional

In todays fast-paced, highly complex IT world, the EDA is often perceived simply as a nice-to-havearchitectural product. IT managers also tend to put aside the EDA effort if their IT budget is curtailed.Many times, IT managers dont understand the importance of an EDA until its too late. By makingthis critical effort optional, however, the organization becomes vulnerable to a plethora of informationmanagement issues. The following are just a few symptoms of not having afunctional EDA:

Missing or competing versions of business data entities

An incomplete understanding of the organizat ions 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 sourcesystems, 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 todefine data requirements, integrate data across the enterprise, and more efficiently manage its dataassets. IT and business users have shared responsibility in defining and maintaining this criticalarchitectural 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 effortsand should allocate the resources necessary both human and capital to build an EDA that willserve both short- and long-term business, functional, and IT needs.


5/15

Mistake Two: Limiting the scope of the EDA


Mistake Two: Limiting the scopeof the EDA

IT managers often define the EDA as simply a collection of numerous data models or data designartifacts in a single place. However, this approach only covers the data design component of thedata 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 theEDA design. They are:

The Enterprise Data Model an integrated set of key data elements to support the mission ofthe organization

The Information Value Chain describing how data originates and how it flows throughvarious systems

The Data Delivery Architecture the architecture to deliver data to its consumers (peopleand 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 ITmanagers will be better able to provide the desired 360-degree view of enterprise data to thestakeholders.


6/15

Mistake Three: Not following an industry standard framework


Mistake Three: Not following anindustry standard framework

In some organizations, the EDA seems to have organically evolved over time, with no guiding planor methodology in place. This situation is similar to executing a software development projectwithout following a proven methodology and architecture framework. The result is that theorganization is often left with an end product that serves a limited purpose, such as satisfying thechecklist of deliverables mandated by the program management office or external fiscal monitoringauthority. By not following an industry standard framework, an organization may not be able toeffectively define and leverage the EDA. This situation is especially vexing for organizations withstringent 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 lin e with their organizationsenterprise architecture efforts. Leveraging a design framework will help them establish andfollow a critical path in the EDA design, and it will facilitate the construction of an EDA that betterserves a broad range of data needs.

For building EDA, there is no one -size-fits- all solution. However, there are well-known architectureframeworks and standards that are practiced by many IT organizations today, including:

Federal Enterprise Architecture Data Reference Model (FEA DRM). The FEA is amethodology, 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 andservices for the U.S. federal government. It helps government agencies share informationresources, contain costs, and improve services across organizational boundaries. The DRMcomponent of the FEA describes the types of data, interaction and exchanges that occur betweenthe various federal agencies, and between those agencies and the public. The DRM establishes acommon data model to help streamline data acquisition, storage, and delivery. Although the FEAwas 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 anddeployment 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 designthat can be built with the flexibility to meet current and future needs. It stresses modular designconcepts, standardization, and the use of proven technologies to build the EDA.

Zachman Framework. The Zachman Framework formally defines the data structure of theorganization via a data classification matrix. It is not an EDA methodology per se because it doesnot define processes for collecting, managing, or distributing data. Rather, it is a taxonomy fororganizing 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 particularframework. An organization may decide to adopt all or part of either of these frameworks to build anEDA based on its unique business and/or organizational requirements.


7/15

Mistake Four: Not defining the operational view of the EDA


Mistake Four: Not definingthe operational view of the EDA

Having both a strategic and operational view of enterprise data is critical. However, at manyorganizations, the EDA is defined only at a high level that provides a view of the key enterprise dataelements, but does not provide an operational view of the data organization. As a result, the EDAcannot be easily used by IT or the business for planning, impact analysis, development, ormaintenance purposes.

Instead, when designing the EDA, IT managers should envision how it will be used for both tacticaland 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 datasuppliers 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 understandboth CEOs viewpoint and the viewpoint of those in IT.


8/15

Mistake Five: Treating the EDA as a project


Mistake Five: Treating the EDA asa project

Treating the EDA as a one-off project commonly occurs when an organization is reacting to the EDAneeds. By definition, a project is an effort that has specific objectives and is to be executed over afinite 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 orexternal 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 thebusiness, 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 directsvarious IT projects from a data standpoint and also receives building blocks as inputs from these ITprojects. These projects may be new software development, BI/DW, or data administration. Theprogram can also be viewed as a hub-and-spoke architecture process, where various groups withinIT provide input to, and benefit from, the EDA at the same time.


9/15

Mistake Six: Developing a technology-driven EDA


Mistake Six: Developing atechnology-driven EDA

IT managers are often advised to start with a tool and/or repository to build an EDA. However, thisapproach merely creates a collection of data design artifacts in one repository, which can beaccessed by interested IT staff or business users, rather than a true EDA. A large collection ofdisconnected 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, businessrequirements, and the development plan; for the EDA, it will provide a baseline to measure thesuccess of the initiative over time. To this end, technology for the EDA tools and repository shouldbe carefully evaluated for how well they meet organizational needs by following industry standardmethodologies. Also, in using the business case approach to the EDA, the technology and toolsbecome an integral part of the EDA solution, but they are not the solution itself.


10/15

Mistake Seven: Not having business owner and executive support


Mistake Seven: Not havingbusiness owner and executive

support

Business owners are, in the end, the drivers for the EDA program, because their information needswill largely determine the scope and structure of the EDA. Without commitment and support from thebusiness owners, EDA development essentially becomes purely an IT exercise. Further, withoutbusiness sponsorship, business subject matter experts (SME) may not provide sufficient insight intothe 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 architectsexperience and knowledge, and the end product is less likely to be accepted by the businessowners.

To improve business acceptance and usability of the EDA, it is imperative to get businessrepresentatives 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 businessusers and getting sponsorship for the effort from business leaders, IT can build a sustainable EDAthat 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 formany 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 EDAprogram.


11/15

Mistake Eight: Not defining a target EDA


Mistake Eight: Not defining atarget EDA

Most organizations exercise due diligence in articulating and documenting their current EDA. But inmany cases, the effort stops there. Describing the current EDA certainly helps IT personnel andbusiness users understand the current data organization; however, it is left to developmentmanagers to define the target data architecture. Often, the direction taken by developmentmanagers will affect the quality of the EDA for example, by using data entities that are not alignedto 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 developa 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 fiveyears IT will have a better probability of success in managing enterprise data, in both the shortand long term.


12/15

Mistake Nine: Following a bottom-up approach


Mistake Nine: Following abottom-up approach

Some organizations view their EDA as merely a collection of data models that are available in someformat within the IT department. In this situation, in order to jumpstart the EDA initiative, ITmanagement will most likely conduct a quick survey of the availability of the physical data models forkey enterprise information systems and select a stable target environment. The data modelingnotation 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 t he EDA, IT will miss the opportunity to understand the enterprisesdata organization from a C-suite standpoint. At the same time IT may arrive at inconsistententerprise data model and information value chain. In other words by following bottoms-upapproach; EDA may become IT-centric rather than business-centric.

Instead, IT managers should kick-start the EDA effort by building a conceptual Enterprise DataModel first and then refining the model through the logical to the physical. This process will then setthe foundation for the remaining components. Designing and assimilating the individual data modelsshould be performed as an ongoing activity to keep work products current and to accommodatechanging or additional data needs.


13/15

Mistake Ten: Hiring a senior data modeler as the enterprise data architect


Mistake Ten: Hiring a seniordata modeler as the enterprise

data architect

One common mistake made by organizations today is to try and quickly advance the EDA initiativeand deliver quick results to management by hiring a senior data modeler to be the Enterprise DataArchitect. A senior data modeler usually has strong data modeling skills with a focus on specificbusiness processes or subject areas. However, most data modelers typically do not demonstratecross-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 enterprisedata architect should obviously have hands-on data modeling experience with large-scale enterprisesystems. The architect should also have database administration knowledge, meta-datamanagement experience, and cross-organizational business analysis experience as well. Further,he or she should have solid systems implementation experience in order to understand real-lifechallenges, conceptualize critical data at the enterprise level, and articulate the data architectureimplementation to IT. The architect should also have the breadth of technical knowledge andleadership skills to play an ever-evolving role and drive related EDA initiatives, such as defining anenterprise 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 organizationto help define a suitable target state for the organization. Ideally, the person should have worked inthe organization long enough to demonstrate a solid understanding of its business processes andstrategic direction, as well as the IT departments overall technology direction.


14/15

Conclusion


Conclusion

Developing an EDA is a strategic IT investment and, as such, requires careful planning and anunderstanding of the organization as a whole. Data standardization and integration guidance arecritical to the success of DW/BI programs. By defining key components of the EDA such as theenterprise data model as high-priority, ongoing initiatives, IT managers can facilitate datastandardization and integration across the enterprise.

The scope and methodology to build the EDA must be customized for the individual needs of theorganization. By following the guidelines above, organizations can increase their probability ofsuccess in defining their EDA.

Satyajeet works as a Consulting Manager at Deloitte Consulting LLP in Arlington, Virginia; where heprovides consulting services to public sector clients in the areas of data warehousing, businessintelligence, and data management.

Satyajeet has a Masters in Management of Information Technology from the University of Virginiaand has been in leadership and management positions in IT for the past 25 years. He can bereached 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]:[email protected]:[email protected]:[email protected]


15/15

About Deloitte Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network ofmember firms, each of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed descriptionof the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see www.deloitte.com/us/about for a detaileddescription of the legal structure of Deloitte LLP and its subsidiaries.

Cop right 2011 Deloitte De elopment LLC All rights r eser ed

Documents

Building a better enterprise data architecture