4 Data Architecture Management

Within the framework, Data Architecture Management is the first function that interacts
with and is influenced by the Data Governance function. Chapter 4 defines and explains the
concepts and activities involved in managing Data Architecture.

4.1 Introduction
Data Architecture management is the process of defining and maintaining specifications
that:
• They provide a common vocabulary of business standards;
• Express strategic data requirements;
• They outline integrated designs at a high level to meet these requirements; and
• They align with the business strategy and related business architecture.
Data architecture is an integrated set of specification artifacts used to define data
requirements, guide integration and control of data assets, and align data investments with
business strategy. It is also an integrated collection of master plans at different levels of
abstraction. Data architecture includes formal data names, complete data definitions,
efficient data structures, precise data integrity rules, and robust data documentation.
Data Architecture is most valuable when it supports the information needs of the entire
enterprise and enables standardization and integration of data across the enterprise.
Although this chapter focuses on enterprise data architecture, the same techniques can be
scaled down for use in a specific function or department of the organization.
Data Architecture is part of the larger architecture, and integrates with technology and
business architectures. Enterprise Architecture integrates data, processes, organizations,
applications, and technology architecture. It helps organizations manage change and
improve effectiveness, agility, and accountability.
Context for this function is shown in Figure 4.1.
 2. Data Architecture Management
Definition: Define the needs of the company and design master plans to meet these needs.
Goals:
1. Plan with vision and foresight to provide high-quality data.
2. Identify and define common data requirements.
3. Design conceptual structures and plans to meet current and long-term data requirements of the company.

Activities:
1. Understanding the Information Needs of the Company (P)
Tickets: 2. Develop and Maintain the Enterprise Data Model (P) Primary Deliveries:
• Business Objectives 3. Analyze and Align with Other Business Models (P) • Enterprise Data Model
• Business Strategies 4. Defining and Maintaining Data Architecture Technology (P) • Value Chain Information Analysis
• Business Architecture Define and Maintain Data Architecture Integration (P) • Data Technology Architecture
• Architecture Processes 5. Defining and Maintaining DW/BI Architecture (P) • Data Integration/MDM Architecture
• IT Objectives Defining and Maintaining Taxonomies and Namespaces • DW/BI Architecture
• IT Strategies 6. Company (P) • Metadata Architecture
• Data Problems Defining and Maintaining Metadata Architecture (P)
8. • Company Taxonomies and Namespaces
• Data Needs
• Technical Architecture • Metadata Architecture Document
Participants: Tools: Management
• Data Administrators • Data Modeling Tools
• Subject Matter Experts (SMEs) • Model Management Tools
Suppliers: • Data Architects • Data Warehouse
• Executives • Analysts and Data Modelers • Office Productivity Tools. Consumers:
• Data Administrators • Other Enterprise Architects
• Data Administrators
• Data Producers • DM Administrators and Executives
• CIO and Other Executives • Data Architects
• Customer Information • Data Analyst
• Database Administrators
• Data Model Manager • Database Administrators
• Software Developers
• Project Managers
• Data Producers
Activities: (P) - Planning (C) - Control (D) - Development (O) - Operational • Knowledge Workers
• Managers and Executives

Figure 4.1 Data Architecture Management Diagram

Enterprise Data Architecture is an integrated set of artifacts that includes three broad categories of
specifications:
1. Enterprise Data Model: It is the central component of the architecture
business data
2. Information value chain analysis: Aligning data with processes
business and other components of enterprise architecture and
3. Related Delivery Data Architecture: This includes architectures
database, data integration, data warehousing, business intelligence, document content, and
metadata.
Enterprise Data Architecture is a misnomer. Architecture captures the data and terminology that defines the
things that are important and necessary to operate the business. Data entities and attributes, ie, features,
describe these things. In addition, enterprise data architecture establishes a common vocabulary of data
entities and attributes, and provides a semantic foundation for understanding enterprise data assets.

4.2 Concepts and Activities

Chapter 1 indicates that data architecture management is the function of defining the model for data assets.
Data architects play an important role in this critical function. Activities and concepts related to data
architecture management and the role of data architects are presented in this section.

4.2.1 Description of Architecture Architecture is an organized arrangement of elements that

optimizes the function, performance, feasibility, cost, and aesthetics of a structure or system as a whole.
The word “architecture” is frequently used in the field of information technology. It is useful for
introducing and discussing systems design concepts. The architecture presents integrated tours that reflect
the problems and perspectives of different interest groups. Understanding the underlying architecture
enables one to understand complex systems and structures.
Architecture can exist at different levels of the enterprise. At each level, standards and protocols help
ensure that components work together as a whole. Architecture includes standards and their application to
specific design needs.
In the context of information systems, architecture is “the design of any complex technical object or
system.”
The information technology field benefits greatly from architectural designs that help manage the
complexity of hardware and software products. Technology architecture includes “closed” and “open”
design standards. “Closed” standards are specific to a particular technology vendor, while “open” standards
are available to any vendor.
Integrating disparate parts of an organization to meet strategic business objectives often requires an overall
business architecture. The architecture should include common designs and standards for business
processes, objectives, organizational structures, and organizational roles. Architecture has to define a vision
for integration. In fact, organizations that grow through acquisition face significant integration challenges
and thus benefit greatly from an effective architecture.
The addition of isolated applications, data access, and data migration activities between applications adds
complexity to the enterprise application portfolio. The cost of maintaining and understanding this growing
complexity, and the benefits of restructuring applications and databases with a global architecture, becomes
increasingly attractive.
4.2.1.1 Enterprise Architecture
Enterprise architecture is an integrated set of business models, information technology specifications,
artifacts that reflect enterprise integration, and data normalization requirements. It defines the context for
integrating business data, processes, organizations, technology, and the alignment of business resources
with business objectives. Enterprise Architecture encompasses business and information systems
architectures.
Enterprise architecture provides a systematic approach to managing information and systems assets;
addresses strategic business requirements; and enables informed management of the enterprise project
portfolio. Enterprise architecture supports strategic decision making when the impacts of changes to
systems and the enterprise are managed.
Enterprise Architecture includes many models and related artifacts:
• Information architecture: Business entities, relationships, attributes, definitions, and reference
data.
• Process architecture: Functions, activities, workflows, events, cycles, products, and procedures.
• Business Architecture: Goals, strategies, roles, organizational structures, and locations.
• Systems architecture: Applications, software components, interfaces, and projects.
• Technology architecture: Networks, hardware, software platforms, standards, and protocols.
• Information Value Chain Analysis: Artifacts as mappings of the relationships between data,
business processes, systems, and technology.
Enterprise models generate many related integrated specification artifacts, including graphical diagrams,
tables, analysis matrices, and textual documents. These describe how the organization functions and
consumes resources in varying degrees of detail. Specifications should align with goals and objectives that
support and meet enterprise standards for content and presentation. Few organizations have an enterprise
architecture that includes every potential component and artifact.
Enterprise architecture often distinguishes between the current “as is” state and the target “to be” state.
Sometimes it includes intermediate stages and migration plans. Some enterprise architectures attempt to
identify an ideal state as a reference model. The destination model is defined as a pragmatic, achievable
step towards the ideal state. To ensure that enterprise architecture remains relevant and useful,
specifications for current and future states require frequent updates. No organization is fully equipped to
maintain and enrich its enterprise architecture.
Each organization invests in developing and maintaining enterprise architecture based on its understanding
of business needs and risks. Some organizations choose to define enterprise architecture in detail to better
manage risk.
Enterprise architecture is an important knowledge asset that provides several benefits. It is a tool for
planning, information technology governance, and portfolio management that can:
• Enable integration of data, processes, technologies, and efforts.
• Align information systems with business strategy.
• Enable coordination and effective use of resources.
• Improve communication and understanding across the organization.
• Reduce the cost of managing information technology infrastructure.
• Guide business process improvement.
• Enabling organizations to respond effectively to changing market opportunities, industry
challenges, and technological advances. Enterprise architecture helps assess business risk, manage
change, and improve business effectiveness, agility, and accountability.
Some methods for defining enterprise architecture include “Business Systems Planning” (BSP) by IBM.
The information engineering method created by James Martin is “Information Systems Planning” (ISP).
4.2.1.2 Frameworks of architecture
Architecture frameworks provide a way to think about and understand how businesses identify, organize,
and manage enterprise resources.
There are two different types of architecture frameworks:
• Classification frameworks organize the structure and views that encompass enterprise
architecture. They define and standardize the language used to describe and relate different points
of view within the organization. Some artifacts of these frameworks include diagrams, tables, and
matrices.
• Process frameworks specify methods for business and systems planning, analysis, and design
processes. Life cycles for some information technology and software development planning (SDLC)
methods include their own composite classifications. Not all process frameworks specify the same
set of things and some are highly specialized.
The scope of architecture frameworks is not limited to information systems architecture. Architectural
frameworks help define the logical, physical, and technical artifacts produced in software analysis and
design, and guide the design of solutions for specific information systems. Organizations should adopt
architectural frameworks for information technology governance and architectural quality control.
Organizations may require delivery of certain artifacts prior to approval of a system design.
Many frames are in stock, such as:
• TOGAF: The Open Architecture Framework is a software development life cycle (SDLC) process
framework and standard developed by The Open Group. The Group is a consortium that defines and
promotes open standards among technology providers to facilitate global interoperability. Version 8
of the framework is the enterprise edition. “TOGAF 8” can be licensed by any organization.
• ANSI/IEEE 1471-2000: A recommended practice specification for describing the architecture of
software-intensive systems. This method will likely become the ISO/IEC 25961 standard for defining
 solution design artifacts.
Some consulting firms have developed useful architectural frameworks of their own. Several governments
and defense departments have also developed architecture frameworks, including:
• Federal Enterprise Architecture (FEA): Produced by the Office of Management and Budget for use
within the United States government.
• Public Enterprise Architecture (GEA): This framework was legislated for use by departments of the
Queensland (Australia) provincial government.
• DODAF: United States Department of Defense Architecture Framework.
• MODAF: UK Ministry of Defence Architecture Framework.
• AGATE: Framework of the architecture of France DGA.
4.2.1.3 The Zachman Framework for Enterprise Architecture
The Zachman2 TM Enterprise Framework is the most widely known and adopted architecture framework.
Enterprise data architects, in particular, have embraced and used this framework since it was published in
the IBM Systems Journal in 1987.
The Zachman Enterprise Framework2 TM, shown in Figure 4.2, has oriented the terminology toward
business management, while retaining the elaborations used by the data and information systems
communities. The types of contributors in perspective (in the last column), affirmation of the content in
perspective (in the first column) and identification of generic answers for the questions (in the first row)
carry a level of clarification and understanding for each simple classification.

Figure 4.2 Zachman2 TM Business Framework

(Licensed for use by DAMA International in the DAMA-DMBOK Guide)
Enterprise architecture modeling is a common practice in the US Federal Government to inform its Capital
Planning and Investment Control (CPIC) process. The Clinger-Cohen Act, known as the “Information
Technology Management Reform Act of 1996,” requires that all U.S. federal agencies must have and use a
formal enterprise architecture.
Access to the new Zachman2 TM Enterprise Framework standards and graphics is available at no cost at
www.ZachmanInternational.com. A concise definition of the framework, written by John Zachman, is also
available on the website.
According to its creator, John Zachman, the framework is a logical structure for identifying and organizing
descriptive representations (ie, models) used to manage businesses and develop systems. In fact, the
Zachman Framework is a generic classification scheme of design artifacts for any complex system. It is not
a method that defines how to create representations of any cell. It is a framework for describing
architecture businesses and models.
To understand systems architecture, Zachman studied how the fields of construction and aerospace
engineering define complex systems, and mapped information systems artifacts against these examples.
The Zachman Framework is a 6 by 6 matrix that represents the intersection of two classification schemes,
ie, two dimensions of systems architecture.
In the first dimension, Zachman recognizes that in the creation of buildings, airplanes, or systems, there are
many interest groups and each has different perspectives on “architecture.” The planner, owner, designer,
builder, implementer, and participant each have different problems to identify, understand, and solve.
Zachman presents these perspectives as rows.
• The Planner Perspective (Scope Contexts): Lists of business elements that define the scope
identified by Strategists as Theorists.
• The Owner Perspective (Business Concepts): Semantic models of the relationships between
business elements defined by Executive Leaders as Owners.
• Designer Perspective (System Logical): Logical models detailing system requirements and
unconstrained design represented by Architects as Designers.
• The Constructor Perspective (Physics of Technology): Physical models that optimize design for
implementation and use, constrained by specific technology, people, costs, and timeframes required
by Engineers as Constructors.
• The Implementer Perspective (Component Sets): A view that is technology-specific, and is outside
the context of how the components are configured and operated by Technicians as Performers.
• Participant perspective (Classes of Operations): Actual instances of the operating system used by
Workers as Participants.
For the second dimension, the issues of each perspective require different ways of answering fundamental
questions: who, what, why, when, where and how. Zachman represents each fundamental question as a
column.
The revised labels for each column are in parentheses:
• That? (data column): Materials used to build the system (Inventory Set).
• As? (function column): Activities performed (Process Transformations).
• Where? (network spine): Locations, topography, and distribution technology (Network Nodes).
• Who? (people column): Functions and organizations (Organization Groups).
• When? (time column): Events, cycles, and schedules (Time Periods).
• Because? (goal column): Objectives, strategies and initiatives (Motivating Reasons).
Each cell in the Zachman Framework represents a unique type of design artifact, defined by the intersection
of row and column.
While the columns in the frame are not ordered by importance, the order of the rows is significant. The
content and order for cells in each column impose a hierarchy of information. Transforming between
perspectives ensures alignment between the intentions of business owners and subsequent decisions.
Each cell describes a primitive model at an appropriate level of detail limited in focus by the unique
perspective of the column. Depending on the model, each cell should contain sufficient detail for
understanding and to eliminate ambiguity.
There is no inherently correct or complete architectural framework. Also, adopting an architectural
framework does not guarantee success. Some organizations adopt the Zachman Framework as a “thinking
tool.” Others use it as quality assurance for the design and implementation of solutions.
There are several reasons why the Zachman Framework has been so widely adopted:
• It is relatively simple to understand since it only has two dimensions.
• He leads the company in a holistic manner, managing the architecture for individual divisions and
departments.
• Use non-technical language to help people think and communicate more accurately.
• It is useful for framing and helping to understand a wide variety of topics.
• It helps solve design problems, focusing on the details without losing sight of the whole.
• Facilitates knowledge transfer on various topics in information systems.
• It is a useful planning tool that provides context to guide better decisions.
• It is independent of specific tools or methods. Any design tool or method can be mapped to the
framework to determine the degree of compatibility of the tool or method.

4.2.1.4 The Zachman Framework and Enterprise Data Architecture

Data Architecture is an important part of the larger enterprise architecture that includes business processes,
systems, and technology architecture. Data architects collaborate with other architects within the enterprise
to integrate architectures.
It typically consists of three large sets of design components:
1. An enterprise data model, identifiable subject areas, business entities, business rules governing
relationships between entities, and essential enterprise data attributes.
2. The information value chain analysis that aligns data model components, e.g., subject areas and
business entities, with business processes and other enterprise architecture components. These may
include organizations, roles, applications, goals, strategies, projects, and technology platforms.
3. Data delivery architecture includes data technology architecture, data integration architecture,
data warehousing, business intelligence architecture, enterprise taxonomies for content
management, and metadata architecture.
The cells in the “Inventory Sets” column represent familiar artifacts such as data models and database
designs. [See Chapter 5 for more details.]
• Planner View (Scope Contexts): A list of subject areas and business entities.
• Owner View (Business Concepts): Conceptual data models that show the relationships between
entities.
• Designer View (System Logical): Fully normalized and attributed logical data models.
• Generator View (Technology Physics): Optimized physical data models to constrain the technology.
• Implementer View (Component Assemblies): Detailed representations of data structures typically
defined in “SQL” Data Definition Language (DDL).
• Company Operation: Implemented cases operate within the company.
The Zachman Framework enables designers to see both details and the global context to incrementally
build the “big picture” view of the enterprise.

4.2.2 Activities
The data architecture management function contains several activities related to defining the model for
managing data assets. An overview of these activities is presented in the following sections.
4.2.2.1 Understanding Business Information Needs
In order to create the enterprise data architecture, the business first needs to define its information needs.
An enterprise data model is a way to capture and define information needs and data requirements. It
represents a master plan for data integration across the enterprise. The enterprise data model is a critical
input for future systems development, data requirements analysis, and data modeling projects.
Conceptual and logical data models for specific projects are based on the applicable parts of the enterprise
data model. Depending on the scope, some projects may benefit from integrating the enterprise data model
into solution design. Virtually every major project has the potential to impact the enterprise data model.
Designers can determine the information needs of the enterprise by evaluating inputs, outputs, internal and
external data sources, current system documentation, reports, interviews with system stakeholders, and
other artifacts required by the organization. These materials, organized and classified by business unit and
subject area, provide important entities, data, data attributes, and calculations. The list becomes the basic
requirements of the enterprise data model.
4.2.2.2 Develop and Maintain the Enterprise Data Model
Business entities are the classes of real things and concepts that describe the business. Data are the facts
that uniquely describe business entities. Data models maintain business entities, and data types, ie, data
attributes, necessary to operate and guide the business. Data modeling is an analysis and design method
used to:
1. Define and analyze data requirements.
2. Design the logical and physical data structures that support these
requirements.
A data model is a set of data specifications and related diagrams that reflect data requirements and designs.
The Enterprise Data Model (EDM) provides an integrated, subject-oriented view of essential data produced
and consumed by the organization.
• Integrated means that all of an organization's data and rules are represented once and fit together
seamlessly. An important goal of the model is to provide a view of the enterprise as a whole, which
also reflects functional and departmental views. Each business entity such as a “Customer” or
“Order” must be uniquely identifiable. The data attributes that define a business entity must be
complete, accurate, and provide clear definitions. In addition, the data model can identify common
synonyms and important distinctions between different subtypes of the same common business
entities.
• Subject-oriented means that the model is divided into commonly recognized subject areas that
span across multiple business functions and application systems. Subject areas focus on the most
essential business entities.
• Essential means data that is critical to the effective functioning and decision making of the
organization. Few enterprise data models define all the data within the enterprise. Essential data
requirements are generally not common across multiple applications and projects. Multiple systems
can share some data defined in enterprise data models. Other data may be critically important, but is
still created and used in some systems. Over time, the enterprise data model should define all data
 that is important to the business. The definition of essential data changes with changes in the
business. The enterprise data model must keep up with those changes.
Data modeling is an important technique used in data architecture management and data development. Data
development implements data architecture in a way that extends and adapts enterprise data models to meet
the needs of specific business applications and project requirements.
4.2.2.2.1 The Enterprise Data Model
The enterprise data model is an integrated set of closely related deliverables. Many deliverables are
generated using a data modeling tool. The central repository for the data model may be in the form of a file
or repository created and maintained by a data modeling tool. This artifact provides metadata for enterprise
data assets. [See Chapter 11 for more details.]
An enterprise data model represents an investment in defining and documenting vocabulary, business rules,
and business knowledge. Creating, maintaining, and enriching the model requires ongoing investments of
time and effort, even when architects begin the design process with an industry-standard model. The results
of data modeling activities include a common view, understanding of entities, data, data attributes, and
their relationships across the enterprise.
Organizations can purchase an enterprise data model, or build one. Several vendors provide industry-
standard logical data models. Both options require some customization.
Enterprise data models differ widely in terms of levels of detail. When a business first recognizes the need
for a data model, it must make decisions about the time and effort that can be devoted to building the
model. As business needs dictate, the scope and level of detail captured within the enterprise data model
typically expands. Successful enterprise data models are built gradually and incrementally.
An enterprise data model is built on layers of information organized as a hierarchy, as shown in Figure 4.3.
Regarding, an enterprise data model is built in layers from the top down. The content at the highest level of
the hierarchy is fundamental and broad, while the lower levels define the details and dependencies between
the data. Model inputs are results of analysis and synthesis of insights and details from existing logical and
physical data models. Integrating business perspectives and influences from existing models can enhance
the development of an entrepreneurial vision.
4.2.2.2.2 The Thematic Area Model
The highest layer of an enterprise data model is the subject area model (SAM). This model is a list of the
main subject areas that together express the essential scope of the company. The list represents a “scope”
view of data, presented in the Zachman Framework. At a more detailed level, business entities and object
classes are also displayed as lists.
There are two main ways to communicate a subject area model:
• A scheme that organizes subjects from high to low in order of priority.
• A diagram that presents and organizes subject areas visually for easy reference.
Designating the core subject areas of the enterprise is important to the success of the entire enterprise data
model. The list of topics is essential for developing critical taxonomies, and allows for further refining of
entities and data in the business model. The thematic area model is optimal when it is accepted by all
participants and constituents of the company. Furthermore, the subject area model should be useful as an
organizing construct for data governance, data management, and enterprise data modeling.
Subject areas typically share the same name with a central business entity. Some subject areas align closely
with core business functions. Other topic areas cover a super-type business entity and its family of
subtypes.
Also, subject areas are important for data management and governance. They define the scope of
responsibilities for data management teams assigned to specific subject areas.
4.2.2.2.3 The Conceptual Data Model
The next lowest level in the enterprise data model hierarchy governs the conceptual data model, its subject
areas, and its business entity relationships.
Business entities are the basic organizational structures in a conceptual data model. They represent the
concepts and kinds of things, people, and places that are important to the company. Business entities are
referred to using business terms. For example, for the business entity it is called “Account”, the Lord
account represents an instance.
The scope boundaries of subject areas generally overlap with some business entities included in other
subject areas. For governance and administration purposes, each business entity should have a primary
subject area that “owns” the master version of that entity.
Conceptual data model diagrams do not represent the data attributes of business entities. Models can
include many-to-many and other types of relationships between essential entities. Conceptual data models
typically represent relationships between essential entities, without normalized data.
The conceptual data model should include a glossary with business definitions and other metadata
associated with all business entities, and their relationships. Other metadata may include entity synonyms,
instance examples, and security classifications.
A conceptual data model can foster improved business understanding and semantic reconciliation. It can
serve as a framework for developing integrated information systems that support both transactional
processing and business intelligence. [See Chapter 5 for more details.]
4.2.2.2.4 Business Logical Data Models
Some enterprise data models include diagrams of the logical data models for each subject area. This level
of detail below the conceptual data model addresses the essential data attributes for each instance of the
business entity. Essential data attributes consist of common data requirements and standardized definitions
that are necessary for the enterprise. Determining which data attributes to include in the enterprise data
model is a very subjective decision.
Logical data model diagrams reflect the changing perspective of the enterprise. They are neutral and
independent of any particular need, use, or context of application. Other more traditional logical models
reflect specific usage and application requirements.
Business logical data models are only partially allocated. They can be normalized to some extent, but they
do not have to be as normalized as logical data models being designed for solutions.
Enterprise Logical Data Models should include a glossary of all business terms, other types of metadata
about entities, their data attributes, and the data domains for the attributes. [See Chapter 5 for more details.]
4.2.2.2.5 Other Components of the Enterprise Data Model
Some enterprise data models include other optional components such as:
• Assignments of responsibility for metadata distributed by subject areas, entities, attribute sets, or
reference data. [See Chapter 3 for more details.]
• Reference data management: Maintaining sets of values controlled by codes, labels, and their
business meaning. These sets of business values are sometimes used to cross-reference equivalent
data in other departments, divisions, or regions. [See Chapter 8 for more details.]
• Additional data quality specifications and rules for essential data attributes, such as accuracy,
precision requirements, timeliness (of data), integrity rules, voidability, format, data
agreement/merge rules, and audit requirements. [See Chapter 12 for more details.]
• Entity life cycles are state transition diagrams that represent the different states of major entities
and the events that cause changes in states. Lifecycles are very useful for determining a rational set
of state values, e.g. codes or labels, for a business entity. [See Section 4.2.2.5 for more details.]

4.2.2.3 Analyze and Align with Other Business Models

Value chain analysis maps the relationships between elements of the business model and other business
models. The term derives from the concept of the business value chain, introduced by Michael Porter, in
several books and articles on business strategy. The analysis identifies organizational functions that
contribute directly and indirectly to the organization's ultimate purpose, such as commercial profit or
education. Directly contributing functions are ordered from left to right in an outline based on their
dependencies and sequence of events. Functions that provide indirect support appear below this
arrangement. The diagram in Figurehttps://www.safaribooksonline.com/library/view/the-dama-guide/
9781634620116/Chapter-8.xhtml%23_idTextAnchor021 4.4 shows the business value chain for an
insurance company.
Information value chain matrices are composite models. Although analysis is a product of data architecture,
each matrix is also part of a business process, organization, or application architecture. In this sense,
information value chain analysis consolidates the diverse forms of “primitive models” in enterprise
architecture. Data architects, data stewards, other enterprise architects, and subject matter experts share
responsibility for the content of each matrix.
4.2.2.4 Defining and Maintaining Data Technology Architecture
Data technology architecture guides the selection and integration of technology-related data. It is part of the
company's technology and data architectures. Data technology architecture defines standard categories of
tools, preferred tools in each category, technology standards, and protocols for technology integration.

Figure 4.4 Example of Value Chain for Insurance Business

Technology categories in data technology architecture include:
• Database management systems (DBMS).
• Database management utilities.
• Data modeling and model management tools.
• Business intelligence software for reporting and analysis.
• Extract, transform, and load (ETL), change data capture (CDC), and other data integration tools.
• Data quality analysis and data cleaning tools.
• Metadata management software, including metadata repositories.
Component categories in technology architecture include:
• Current: Products that are currently supported and used.
• Deployment Period: Products that have been deployed for use in the next 1-2 years.
• Strategic Period: Products expected to be available for use in the next 2+ years.
• Retired: Products that have been retired or are expected to be retired this year.
• Preferred: Products that are preferred for use by most applications.
• Containment: Products that are limited to use by certain applications.
• Emerging: Products being researched and tested for possible future deployment.
[See Chapter 6 for more details.]
4.2.2.5 Define and Maintain Data Integration Architecture Data integration architecture defines how
data flows across all systems from end to end. It requires both data and application architectures. Together,
databases and applications control the flow of data between systems. Data lineage and data flow are also
useful in describing these concepts.
The relationships between elements within each model are just as important as the relationships between
the elements themselves. A series of two-dimensional matrices can map and document the relationships
between different types of business model elements. Matrices can define relationships with other aspects of
the enterprise architecture, outside of business processes, such as:
• Data related to business roles that have responsibility for creating, updating, deleting, and using
data for specific business entities (CRUD).
• Data relating to the specific business organizations that have these responsibilities.
• Data related to applications that may cross business functions.
• Data related to the locations where local differences occur.
Building these matrices is a long-term practice in business modeling. IBM, in its “Business Systems
Planning” (BSP) method, first introduced this practice. James Martin later popularized this practice in his
method, “Information Systems Planning” (ISP). The practice is still valid and useful today.
The corporate information factory (CIF) concept is an example of data integration architecture.
Architecture defines the environment for the production and maintenance of data used to support business
decisions. Data integration architecture is organized around tools, technology, processes, and delivery
capabilities that enable the enterprise to use data for competitive advantage. [See Chapter 8 for more
details.]
Matrices showing the relationship of process and data can have different levels of detail. Subject areas,
business entities, or even essential data attributes can all represent data at different levels. High-level
functions, middle-level activities, and low-level tasks all represent business processes.
4.2.2.6 Defining and Maintaining Architecture
Data warehouse architecture focuses on how data changes and snapshots are stored in data warehouse
systems for maximum utility and performance. Data integration architecture shows how data moves from
source systems through staging databases into data warehouses and data marts. Business intelligence
architecture defines data availability, business processes, and tools that enable decision support capabilities
across the enterprise. [See Chapter 9 for more details.]
4.2.2.7 Defining and Maintaining Enterprise Taxonomies and Namespaces
Taxonomy is a hierarchical structure used to delineate topics. The best-known example of taxonomies
classifies all living things. This system was originally developed by the biologist Linnaeus. The decimal
system, created by Dewey, is an example of a taxonomy designed for organizing and searching books in
libraries. Formal taxonomies are class hierarchies, whereas informal taxonomies are subject schemes that
may not involve inheritance of characteristics from supertypes.
Organizations develop their own taxonomies to organize collective thinking on topics. Taxonomies have
proven to be particularly important in presenting and searching information on websites. In general,
enterprise data architecture includes organizational taxonomies. The definition of terms used in such
taxonomies should be consistent with the enterprise data model, related models, and ontologies.
4.2.2.8 Defining and Maintaining Metadata Architecture
Just as data integration architecture defines how data flows between applications, metadata architecture
defines the orderly flow of metadata. Metadata architecture defines how metadata is created, integrated,
controlled and accessed. The metadata repository is the core of any metadata architecture. Metadata
architecture is the design for the integration of metadata across software tools, repositories, directories,
glossaries, and data dictionaries. The focus of data integration architecture is to ensure quality, integration,
and effective use of reference data, master data, and business intelligence data. The focus of metadata
architecture is to ensure quality, integration, and effective use of metadata. [See Chapter 11 for more
details]

4.3 Summary
Defining and maintaining data architecture is a collaborative effort that requires active participation from
data stewards and other subject matter experts, facilitation, and support from data architects and other data
analysts. Data architects and analysts must work to optimize the valuable experience provided by data
stewards. The Data Management executive must frequently communicate the business case for defining
and maintaining the data architecture. In addition, the executive must ensure that critical resources are
available and committed to project goals.
Data architecture is driven by changes in the business. Maintaining data architecture requires periodic
reviews by data stewards. Routine updates to existing data architecture, such as reference data, can solve
many problems quickly. The most significant issues often require project authorizations.
The value of data architecture is limited until data stewards actively manage data architecture, or
management designates data architecture as a best practice for systems implementation. The data
governance council or other body that can approve the enterprise data architecture is critical to coordinating
data, business processes, systems, and technology architectures.
Data architecture is only one part of the overall enterprise architecture. It serves as a guide for integration.
It is useful to consult the data architecture during:
• Defining and evaluating new information systems projects: The enterprise data architecture serves
as a zoning plan for the long-term integration of information systems. It affects project goals and
objectives, and influences the priority of projects in the project portfolio. Enterprise data
architecture also influences project scope boundaries and system versions.
• Defining project data requirements: Enterprise data architecture provides data required for
individual projects, which speeds up the identification and definition of these requirements.
• Project Data Design Review: Design reviews ensure that conceptual, logical, and physical data
models fit and contribute to the long-term implementation of the enterprise data architecture.

4.3.1 Guiding Principles

The application of the data architecture management function in organizations follows eight basic
principles:
1. Data architecture is an integrated set of data artifacts.
specification (ie, master plans) used to define data requirements, guide data integration, control data
assets, and align data investments with business strategy.
2. Enterprise data architecture is part of the structure
general enterprise architecture, along with process architecture, business architecture, systems
architecture, and technology architecture.
3. Enterprise data architecture includes three broad categories of
specifications: enterprise data model, information value chain analysis, and data delivery
architecture.
4. Enterprise data architecture encompasses more data. Helps to establish
a semantic foundation for the enterprise, using common business vocabulary.
 5. An enterprise data model is integrated and subject-oriented. Define
essential data that is used by the entire organization. Enterprise data model is built in layers: general
subject area views, conceptual views of entities and their relationships to subject areas, and more
detailed, partially attributed views of these subject areas.
6. Value chain analysis information defines critical relationships
between data, processes, functions, organizations, and other elements of the company.
7. Data delivery architecture defines the master plan for how
data flows through databases and applications. This ensures the quality and integrity of data that
supports transactional business processes, business intelligence reporting, and analysis.
8. Architecture frameworks such as TOGAF and the Zachman Framework help
organize collective thinking about architecture. This allows groups with different goals and
perspectives to work together to meet common interests.

4.3.2 Process Summary

The process summary for the data architecture management function is shown in Table 4.1. Deliverables,
responsibility roles, and approver and
contributor roles are shown for each architecture management function activity. The table is also shown in
Appendix A9.
Activities Deliverables Papers Papers of Papers of
Responsible Approvers Contributors
2.1 Understanding Business Lists of Essential Information Enterprise Governing
Information Needs (P) Requirements Data Architect, Council of
Business Data,
Experts Committee of
Data
Architecture
Director, Data
Management
Executive,
Chief
Information
Officer
2.2 Develop and Maintain Enterprise Data Model Enterprise Data Data Architects,
the Enterprise Data Model • Subject Model Data Architect Governance Data
(P) Administrators
• Model Conceptual Council, Data
Data/Equipment
• Model Logical
Architecture
Steering
• Glossary Committee,
Data
Management
Executive,
Chief
Information
Officer
2.3 Analyze and Align with Information Value Chain Analysis Enterprise Data Data Architects,
Other Business Models (P) Matrices Data Architect Governance Data
• Entity/Function Council, Data Managers/Teams,
Enterprise
• Entity/Organizations Architecture
Architects
and Papers Steering
• Entity/Application
Committee,
Data
Management
Executive,
Chief
Information
Officer
2.4 Define and Maintain the Data Technology Architect Enterprise Data Database
Data Technology (Technology, Distribution, Usage) Data Architect Governance Administrators,
Architecture (P) Council, Other
Architecture Professionals of
Steering
Committee
Activities Deliverables Papers Papers of Papers of
Responsible Approvers Contributors

Data, Data Data

Management Management
Executive,
Chief
Information
Officer
2.5 Define and Maintain the Data Integration Architecture Enterprise Data Database
Architecture of • Lineage Data/Flows Data Architect Governance Administrators,
Data Integration (P)
• Life Cycles of Council, Data Data Integration
Specialists
Entities Architecture
Steering Other Data
Committee, Management
Data Professionals
Management
Executive,
Chief
Information
Officer
2.6 Define and Maintain Data Warehouse/Business Intelligence Warehouse Business
Intelligence Architecture Architecture Architect Enterprise Intelligence
Business/Data Storage (P) Data Data Specialists, Data
Architect, Integration
Data Specialists,
Governance Database
Council, Data Administrators,
Architecture Other Data
Steering Management
Committee, Professionals
Data
Management
Executive,
Chief
Information
Officer
2.7 Define and Maintain Enterprise Taxonomies, XML Enterprise Other Data
Company Taxonomies and Namespaces, Content Management Data Architect Data Architects,
Namespaces (P) Governance
Standards Others
Council, Data
Data
Architecture
Management
Steering
Professionals
Committee,
Data
Management
Executive,
Activities Deliverables Papers Papers of Papers of
Responsible Approvers Contributors
Chief
Information
Officer
2.8 Define and Maintain Metadata Architecture Metadata Metadata
Metadata Architecture (P) Architect Enterprise Specialists,
Data
Architect, Others
Data Professionals of
Governance Management of
Council, Data Data
Architecture
Steering
Committee,
Data
Management
Executive,
Chief
Information
Officer

Table 4.1 Data Architecture Management Process Summary

4.3.3 Organization and Culture Issues

Q1: Are there any ramifications for implementing an enterprise data architecture?
A1: Implementing enterprise data architecture can have many ramifications for an organization. Members
of the affected organization need to see value in the overall data architecture. There will be some discovery
of redundant systems and processes that may require changes to the roles and responsibilities of some staff
within the organization. For this reason, management should discourage fears of downsizing. People who
have been working on redundant systems are available to do work on other systems. Organization members
need to be committed to ensuring that the data architecture remains current as business needs or technology
landscapes change.
Implementing an enterprise data architecture can have many ramifications for an organization's culture.
Application-focused IT departments will have to make changes to their culture. They must grow awareness
of data and how data moves through their applications. Data awareness is a way to increase knowledge of
business needs and practices. As a result, the information technology department becomes a partner with
the business, rather than just a service provider.