Building a better enterprise data architecture The top 10 enterprise data architecture mistakes and how to avoid them

Satyajeet Dhumne Deloitte Consulting LLP January 24, 2011

Contents
Introduction Mistake One: Making the EDA optional Mistake Two: Limiting the scope of the EDA Mistake Three: Not following an industry standard framework Mistake Four: Not defining the operational view of the EDA Mistake Five: Treating the EDA as a project Mistake Six: Developing a technology-driven EDA Mistake Seven: Not having business owner and executive support Mistake Eight: Not defining a target EDA Mistake Nine: Following a bottom-up approach 1 2 3 4 5 6 7 8 9 10

Mistake Ten: Hiring a senior data modeler as the enterprise data architect11 Conclusion 12

The top 10 enterprise data architecture mistakes and how to avoid them

Introduction

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 organizations 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.

The top 10 enterprise data architecture mistakes and how to avoid them

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 dont understand the importance of an EDA until its 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 organizations 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 stovepipes 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.

The top 10 enterprise data architecture mistakes and how to avoid them

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.

The top 10 enterprise data architecture mistakes and how to avoid them

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 organizations 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.
The top 10 enterprise data architecture mistakes and how to avoid them 4

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 CEOs viewpoint and the viewpoint of those in IT.

The top 10 enterprise data architecture mistakes and how to avoid them

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.

The top 10 enterprise data architecture mistakes and how to avoid them

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.

The top 10 enterprise data architecture mistakes and how to avoid them

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 architects 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.

The top 10 enterprise data architecture mistakes and how to avoid them

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.

The top 10 enterprise data architecture mistakes and how to avoid them

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 enterprises 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.

The top 10 enterprise data architecture mistakes and how to avoid them

10

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 departments overall technology direction.

The top 10 enterprise data architecture mistakes and how to avoid them

11

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 sdhumne@deloitte.com.

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]

The top 10 enterprise data architecture mistakes and how to avoid them

12

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