Continue in 2 seconds

Enterprise Data Architecture: Who Needs It?

  • January 01 2004, 1:00am EST

If your goal is enterprise-wide data sharing, an enterprise data architecture (EDA) is what you need for revamped decision support. As we enter the 21st century, many organizations are exactly where they were 20 years ago. The technology infrastructure supporting them is full of complex interfaces creating impediments to rapid and lasting business change. Companies have consciously ignored staff warnings regarding building and maintaining this technological Tower of Babel. Building an EDA can give your staff an integrated view of enterprise data organization for strategic and tactical decision support. However, it's critical to understand the business value of an EDA and the factors that can make or break your EDA.

A typical organization has a complex web of interrelated business systems and databases that impede change. An EDA enables organizational change because it organizes data around the enterprise's data subjects. Such organization permits multiple application systems to use the shared data resource. An EDA pulls together, validates, cleanses and integrates data from disparate source application systems, providing the end-user community with an integrated view of enterprise data. As a result, operational departments can access the data for strategic and tactical decision support, day-to-day operations and general reporting.

Constructing Your Enterprise Data Architecture

You wouldn't start building a skyscraper without first planning the entire building. The architect must meet with the customer to determine the structure's specifications, which are translated into a set of architectural blueprints providing steelworkers, carpenters, electricians and plumbers with the customer's vision. With the overall plan, separate teams can go to work with the knowledge that the building components will fit together.

Similarly, the information technology (IT) world is full of inspired tradespeople (programmers, systems analysts, database designers and system designers) who crave the challenge and excitement of solving problems with their own unique approaches. They usually do an excellent job. However, the data and process objects they use overlap substantially.

How do you create order from IT development and deployment chaos? You start with a well-conceived plan that details the tasks, milestones, resources, time and personnel required to design an enterprise business model. The next step is to create an enterprise data model and an enterprise process model. Finally, you identify the relationships among data and process objects to create the enterprise business model. Figure 1 shows typical data subject areas.

Figure 1: Enteprise Data

To implement the EDA specified in the enterprise business model, you create a plan that provides executives and middle managers with a concise understanding of the current IT state as compared to the enterprise model's vision. The plan drives and reports ongoing progress. In terms of an approach, increments are most effective for creating an EDA environment, ensuring that you're building only currently required components. The first EDA implementation will create the first subject area data objects deployed as part of the EDA environment. After initially deploying the environment, the team should focus on creating the next iteration.

Each successive EDA environment iteration should benefit from reusing knowledge gained in previous iterations, experience and even currently deployed data objects. You should deploy each successive iteration to end users on a quarterly basis. In order to meet this schedule, the EDA team must ensure that the scope of the new data objects included in the environment is manageable within the quarter.

Data Boundaries

All matter is built on the foundation of a small number of atomic building blocks. If you can label and construct matter from a few atomic constructs, why is it that data processors can't construct and label such data based on a finite number of "core" data elements? Why is it that a typical IT shop's source code libraries contain hundreds or even thousands of data element names? Are all data molecules formed from a finite number of data atoms?

Fortunately, you can reduce these bloated amounts of data element names. The majority of names are homonyms, synonyms and aliases created in the absence of three factors: naming standards, an EDA perspective and planning for data creation and use. Many programmers, analysts and database specialists create data element names and label their own data without regard for the way others in the enterprise do so.

Using the EDA construct, your organization can design and implement a solid foundation of core data elements and entities from which you can derive reusable, accurate, integrated and reliable information.

Executing Your Enterprise Data Architecture

It's critical that you pay attention to five primary project factors to ensure EDA success:

  • Direct participation by top management. To implement an integrated, cross-functional EDA, it's imperative to gain corporate top management commitment. In most organizations, data integration projects face a great deal of resistance within and outside the IT department. Data processors are a creative lot by nature who enjoy the challenge of unraveling the nightmare world of data interfaces. In addition, end users want exclusive rights over their own data. Top management must motivate both groups to jump aboard the EDA initiative. Additionally, top management must participate directly in the initiative's planning and quality view. Without this commitment level, you might encounter political roadblocks.
  • Well-defined scope. The EDA team must have the time and energy to learn about building an EDA without being encumbered by in-house politics. In other words, the team must learn to walk before it runs. First time, large-scale EDA projects have a tendency to fail due to political and organizational conflicts.
  • Design stability. Stability doesn't imply that the EDA will never change; you can make most changes without requiring anyone to rewrite application systems. The EDA's underlying logical data model should produce physical tables independent of their physical implementation on current hardware and systems software. As the underlying technology changes over time, the EDA's logical data structures will remain valid.
  • Data object abstraction and generalization. You must design the EDA's logical data model with an appropriate data normalization level; as a result, you'll be able to add entities and attributes to the model without rewriting existing applications.
  • A data modeling team with one or two members. Integrating data across business areas represents the EDA's primary value. Many users think that the time it takes to integrate the data into a coherent data model results in additional delay for little return. This perception is erroneous. The efforts of one or two data modelers over the span of a few months will result in a coherent model. Enterprise-level data modeling is not a multithreading discipline.

Sharing Data

Data administrators typically have difficulty convincing management that information is an asset of the entire organization –­ not the private property of individual operating units exerting tremendous political pressure on the IT staff to build something at the expense of enterprise needs. It's imperative that you draft an enterprise data architecture strategy document that's tied directly to your organization's business strategy.

When you've conquered the politics of enterprise data modeling, created a robust enterprise data model and populated your enterprise-level databases, the DBMS (database management system) software provides the capabilities necessary to share data across the enterprise. The DBMS not only ensures that there will be data integrity, security, concurrency and high enterprise-level database availability, but it also provides fault-tolerant backup and recovery, performance monitoring and system management capabilities.

Data management theorists and practitioners have aimed for enterprise-wide data sharing for more than 25 years. With the enterprise-level database construct, we've taken bold steps in our pursuit of this goal. As shown in Figure 2, the enterprise-level database should evolve into the physical instantiation of the enterprise data model.

Figure 2: Enterprise Data Architecture

Migrating to an Enterprise Data Architecture

You can't implement an EDA in a single release, nor will all existing legacy systems migrate to it at the same time. You should implement your EDA in stages. However, you must factor a few issues into choosing the optimal migration strategy. There is your return on investment, for one thing. The migration strategy should follow a pay-as-you-go philosophy and provide tangible benefits to the organization as quickly as possible. The strategy should minimize both business and technical risks. Avoiding unproven new technology, for example, ensures that your basic architectural core and concepts will be sound.

Migration to an EDA from existing application-specific databases shouldn't be an end in itself. Rather, migration should take place as part of two initiatives:

  • Increments that follow operational systems portfolio restructuring, implementing new cross-departmental or cross-functional application systems.
  • Increments that respond to departmental and enterprise data requirements simultaneously.

You must carefully evaluate the degree of cultural change on the IT staff, the user community and your organization's customer base. You shouldn't let the rate of change be excessively rapid or drastic. Implementing an EDA should be evolutionary –­ not revolutionary.

Enterprise Data Architecture Business Value

It's difficult to dispute the value of having subject-oriented data at the corporate level, giving you a common view and understanding of data regardless of the business function. A customer is a customer, regardless of who's asking the question. This shared data environment offers more accurate and complete information for improved decision making. An EDA offers several benefits that will add business value to your company. The architecture will:

  • Provide an understanding of the fundamental health of the enterprise. Many Fortune 1000 companies can't accurately determine how many customers they have. They also can't figure out whether they're making or losing money on any one product or service. Normally, profit and loss metrics are accurate only at the profit center level. Rolling up these figures to the corporate level is impossible for most organizations. Enterprises that have built an EDA find themselves able to compete more successfully than their competitors.
  • Speed application system development. As you add more enterprise data subjects to the EDA, the application development rate increases because the data already exists.
  • Provide the tools and processes required for IT to effectively manage the complexities of your organization's most precious asset, its information.
  • Set the foundation for sharing data across the enterprise in a controlled and managed environment.
  • Provide a consistent enterprise-wide view to the end user ensuring data integrity and reliability across business systems at a global level.
  • Increase the ability of your knowledge-workers to transform data into information.
  • Provide a standard framework for addressing data issues and data design decisions in order to develop durable business solutions.
  • Enable your organization to have a high degree of control over the replication and duplication of data.
  • Enable your business units to process information in a more cost-effective fashion.

An Enterprise Data Architecture Pays for Itself

Our preoccupation with unraveling the decades of "silo" application system and data store design shouldn't surprise anyone. Organizations have dug themselves into a deep "data hole" that can only be filled by designing and implementing an EDA. An EDA offers a significant return on investment primarily because it supports creating reusable data. You build data once, and you can share it many times across many application systems.

An EDA is integral to solving the data integrity problems many organizations face. From an IT perspective, managing many application systems and redundant data stores is a difficult and complex endeavor. From a business perspective, identical queries often yield different answers because each functional area has its own data.

Unfortunately, most people want immediate gratification. It's worse in the business world because at the end of every quarter, you must perform for the bottom line. Increasing flexibility and reducing time to market won't happen accidentally through technology acquisitions, software packages or custom developed systems. It will only happen if you invest in the design and implementation of an EDA.

A Win/Win Data Solution

Most organizations are finding that corporate survival requires shifting course. By creating an EDA based on your organization's fundamental data building blocks, you'll provide a foundation on which to respond rapidly to the changing demands placed on your business in this millennium.

The shift from building departmental solutions to building enterprise solutions will require major cultural changes within the enterprise's business and IT departments. To compete and win in this century, you must discontinue building business systems and data stores that reflect management organization. Instead, focus on future business systems and data stores that reflect the true needs inherent in delivering products and services to the customer.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access