Analyzing an organization’s information value chain can provide important insights into its enterprise architecture, its data management practices, and gaps to be filled.
A popular credit card commercial asks, “What’s in YOUR wallet?” A similar question can be posed to data architects: “What’s in YOUR data architecture?” That question can be expanded to “What specification artifacts should be in the organization’s target enterprise data architecture?” Knowing what data should be accessible to the enterprise can lead to information value chain analysis and improved data delivery architecture.
Figure 1. Enterprise Architecture Artifacts
Enterprise Data Model and Enterprise Data Architecture
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. This understanding supports an enterprise approach to data management.
A data model is what John 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. However, 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 and 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, and all data management practitioners should be trained in enterprise data modeling.
Mapping the relationships between enterprise model elements has come to be known as information 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 is perhaps the best known form of data delivery architecture.
Just as data integration architecture defines how data flows across applications, so metadata architecture defines the managed flow of metadata — how metadata is created, integrated, controlled and accessed. The metadata repository is the core of any metadata architecture. Metadata architecture is the design for integration of metadata 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 metadata architecture is to ensure the quality, integration and effective use of metadata.
Conclusion
Enterprise data architecture may include other artifacts, such as enterprise taxonomies and namespaces. These and other artifacts may provide additional business value to an 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, in every industry.
