Your SlideShare is downloading. ×

Deloitte Analytics - Building a Better Enterprise Data Architecture


Published on

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 …

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.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Building a better enterprise data architecture The top 10 enterprise data architecture mistakes and how to avoid themSatyajeet DhumneDeloitte Consulting LLPJanuary 24, 2011
  • 2. ContentsIntroduction 1Mistake One: Making the EDA optional 2Mistake Two: Limiting the scope of the EDA 3Mistake Three: Not following an industry standard framework 4Mistake Four: Not defining the operational view of the EDA 5Mistake Five: Treating the EDA as a project 6Mistake Six: Developing a technology-driven EDA 7Mistake Seven: Not having business owner and executive support 8Mistake Eight: Not defining a target EDA 9Mistake Nine: Following a bottom-up approach 10Mistake Ten: Hiring a senior data modeler as the enterprise data architect11Conclusion 12 The top 10 enterprise data architecture mistakes and how to avoid them
  • 3. IntroductionIntroductionMany 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 organization’s 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. The top 10 enterprise data architecture mistakes and how to avoid them 1
  • 4. Mistake One: Making the EDA optionalMistake One: Making theEDA optionalIn 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 don’t understand the importance of an EDA until it’s 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 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- pipesBuilding 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 thepriorities 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. The top 10 enterprise data architecture mistakes and how to avoid them 2
  • 5. Mistake Two: Limiting the scope of the EDAMistake Two: Limiting the scopeof the EDAIT 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 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 ITmanagers will be better able to provide the desired 360-degree view of enterprise data to thestakeholders. The top 10 enterprise data architecture mistakes and how to avoid them 3
  • 6. Mistake Three: Not following an industry standard frameworkMistake Three: Not following anindustry standard frameworkIn 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 mayleave them facing a difficult audit situation in the future.Instead, IT managers should choose a design framework that is in line with their organization’senterprise 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 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 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. The top 10 enterprise data architecture mistakes and how to avoid them 4
  • 7. Mistake Four: Not defining the operational view of the EDAMistake Four: Not definingthe operational view of the EDAHaving 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 datasupply 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 CEO’s viewpoint and the viewpoint of those in IT. The top 10 enterprise data architecture mistakes and how to avoid them 5
  • 8. Mistake Five: Treating the EDA as a projectMistake Five: Treating the EDA asa projectTreating 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 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 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. The top 10 enterprise data architecture mistakes and how to avoid them 6
  • 9. Mistake Six: Developing a technology-driven EDAMistake Six: Developing atechnology-driven EDAIT 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 theEDA. 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. The top 10 enterprise data architecture mistakes and how to avoid them 7
  • 10. Mistake Seven: Not having business owner and executive supportMistake Seven: Not havingbusiness owner and executivesupportBusiness 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 architect’sexperience 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. The top 10 enterprise data architecture mistakes and how to avoid them 8
  • 11. Mistake Eight: Not defining a target EDAMistake Eight: Not defining atarget EDAMost 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 enterprisemission, 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 entitiesBy 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. The top 10 enterprise data architecture mistakes and how to avoid them 9
  • 12. Mistake Nine: Following a bottom-up approachMistake Nine: Following abottom-up approachSome 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 needsBy starting at the bottom layer of the EDA, IT will miss the opportunity to understand the enterprise’sdata 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. The top 10 enterprise data architecture mistakes and how to avoid them 10
  • 13. Mistake Ten: Hiring a senior data modeler as the enterprise data architectMistake Ten: Hiring a seniordata modeler as the enterprisedata architectOne 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, primarilybecause 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 department’s overall technology direction. The top 10 enterprise data architecture mistakes and how to avoid them 11
  • 14. ConclusionConclusionDeveloping 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 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. ( ISBN 1-9316245-6. Zachman Framework: Zachman, John A. DAMA — DMBOK: First Edition, DAMA International. ( [ISBN 978-1-9355040-2-3] Enterprise Architecture Planning, Steven Spewak and Steven Hill. John Wiley & Sons, Inc. — QED [ISBN 0-471-599859] The top 10 enterprise data architecture mistakes and how to avoid them 12
  • 15. About DeloitteDeloitte 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 for a detailed descriptionof the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see for a detaileddescription of the legal structure of Deloitte LLP and its subsidiaries.Copyright © 2011 Deloitte Development LLC. All rights reserved.Member of Deloitte Touche Tohmatsu Limited