A popular credit card commercial asks, “What’s in YOUR wallet?” I’ve been asking a similar question of data architects at several different organizations – “What’s in YOUR data architecture?” In Part One of this article, I rephrased this question more precisely to be, “What specification artifacts should be in your target enterprise data architecture?” and identified three major components of enterprise data architecture. In Part Two, I described the core of any enterprise data architecture – the enterprise data model. In  Part Three, I will overview two major complimentary components — information value chain analysis and related data delivery architecture.

Figure 1. Enterprise Architecture Artifacts

The enterprise data model is the core of any enterprise data architecture, but by itself the enterprise data model does not describe how data relates to other aspects of enterprise architecture. It is critical to understand how data relates to business strategy, process, organization, application systems and technology infrastructure.

A data model is what Zachman calls a primitive model; a data model defines the relationships between data objects (data-to-data relationships). Likewise, a process model defines the relationships between processes (process-to-process relationships). The Zachman Framework defines a robust set of primitive model artifacts.

Zachman refers to models that define the relationships between different types of model components as composite models. Composite models relate elements from one row of the Zachman Framework to elements from a different row. The Zachman Framework does not specifically identify composite models. But the relationships between the elements in each enterprise model are every bit as important as the relationships between the elements themselves! Composite models define these enterprise component relationships.

The enterprise data architecture includes composite models that relate data components with different types of components. The two most frequently defined forms of composite models that include data objects are 1) information value chain analysis deliverables, and 2) related data delivery architecture deliverables.

What Is Information Value Chain Analysis?

Information value chain analysis maps the relationships between data model elements and other kinds of enterprise model elements in one or more two-dimensional matrices. The most common such matrix is an entity/process relationship matrix.   This matrix is often referred to as a “CRUD” matrix, because the matrix documents which processes “Create, Read, Update and/or Delete” each business data entity. The example below defines some of the process responsibilities for creating, reading, updating and deleting data about some of the business entities found within an Inventory & Warehousing subject area.

Figure 2. An Entity/Process “CRUD” Relationship Matrix

Building such matrices is a long-standing practice in enterprise modeling. The practice was first introduced by IBM in its Business Systems Planning (BSP) methodology, and popularized by James Martin in his Information Systems Planning (ISP) methodology. The practice is just as valid and useful today.

Mapping the relationships between enterprise model elements has come to be known asinformation value chain analysis. The term refers to the practice of sorting the presentation of processes from left to right in the order of occurrence, reflecting the dependencies on data between processes. The value of information created in earlier processes is shown by its use in later processes.

The sequence of processes represents the business value chain, a concept introduced by Michael Porter of MIT in several books and articles on business strategy. The business value chain identifies the functions of an organization that contribute directly and indirectly to the organization’s primary purpose (commercial profitability, education, etc.), and arranges the directly contributing functions from left to right in a diagram based on their dependencies and event sequence. Indirect support functions are shown below this arrangement. The diagram below depicts the business value chain for an insurance company.

Figure 3. Insurance Business Value Chain

Data/process relationship matrices can be created at different levels of detail. Data can be represented as subject areas, business entities or even essential data attributes. Business processes can be represented as high-level functions, mid-level activities or low-level tasks.

Other matrices can define the relationships between data model components and other aspects of the enterprise architecture besides business processes. For instance:

• Data can be related to business roles, depicting which roles have responsibility for creating, updating, deleting and using data about which business entities.
• Data can be related to specific business organizational structures, defining which organizations have create, read, update and delete responsibilities.
• Data can be related to applications which may cross business functions.
• Data can be related to different locations (where differences occur).

Other matrices can be defined that identify the data that supports business goals and strategies (using just an X instead of a C,R,U or D).

What Is Related Data Delivery Architecture?

Enterprise data architecture defines not only “what” data is important to the enterprise, but also “how” this data can be effectively delivered and managed. Several composite models may be used to express the controlled flow of data across databases and applications.

Most data warehouse architecture defines the flow of data from source transactional databases through data extract, transformation and load (ETL) programs and staging databases into data warehouses and data marts, where the data is available for access, reporting and analysis by business intelligence tools. Traditionally the data in these high level data flow application diagrams flows from left to right.

Figure 4. Data Warehouse Architecture

Data integration architecture focuses on ensuring data quality, particularly for reference and master data. Data integration identifies the database of record for reference and master data where a “golden” version of this data is maintained and controlled. Data integration architecture defines how other systems may read this data or subscribe to synchronized copies of the golden version of this data.

Data warehouse architecture and data integration architecture may be subsets of a larger, more complete enterprise data delivery architecture to improve and control data quality, especially the quality of shared reference and master data across transaction processing databases, operational data stores, data warehouses and data marts. The Corporate Information Factory (CIF) concept developed by Bill Inmon and Claudia Imhoff is perhaps the best known form of a data delivery architecture.

Just as data integration architecture defines how data flows across applications, so meta data architecture defines the managed flow of meta data — how meta data is created, integrated, controlled and accessed. The meta data repository is the core of any meta data architecture. Meta data architecture is the design for integration of meta data across software tools, repositories, directories, glossaries and data dictionaries. While the focus of data integration architecture is to ensure the quality, integration  and effective use of reference, master and business intelligence data, the focus of meta data architecture is to ensure the quality, integration and effective use of meta data.

Enterprise data architecture may include other artifacts, such as enterprise taxonomies and namespaces. These and other artifacts may provide additional business value to your organization, but these three major components – the enterprise data model, the information value chain analysis, and the related data delivery architecture – have proven to provide significant business value to many organizations, both large and small. These three components are found in the enterprise data architecture of many organizations – are they in YOUR enterprise data architecture?

About the Author

Mark Mosley, Principal Consultant with EWSolutions (www.ewsolutions.com), is a leading expert in enterprise information management (EIM). Mark has over 25 years experience in data modeling, data warehousing, data architecture and organizational change management. As a consultant, enterprise data architect and director of data resource management for multiple corporations, Mark has coordinated several successful data governance programs, developed enterprise data models and implemented enterprise data warehouses and master data management solutions. During his 13 years with IBM, Mark led the development of IBM’s AD Effectiveness Consulting Methodology and trained consultants worldwide in its techniques. Mark has B.S and M.S. degrees from the University of Illinois at Urbana-Champaign. Mark is a guest lecturer at DePaul University and a Certified Data Management Professional (CDMP). Mark serves as chief editor for The DAMA Guide to the Data Management Body of Knowledge (DAMA-DMBOK Guide) and the editor of the DAMA Dictionary of Data Management. He is the author of the DAMA-DMBOK Framework white paper, available for free download at www.dama.org. You can email Mark at mmosley@ewsolutions.com.