Data Data Modeling

Architecture & Design

Data Quality Data Storage

& Operations

Data Data
Metadata
Governance Security

Data Warehousing Data Integration &

& Business Interoperability
Intelligence
Reference Document
& Master & Content
Data Management

DAMA-DMBOK2 Data Management Framework

Data Architecture
Copyright © 2017 by DAMA International

1. Introduction

A
rchitecture refers to the art and science of building things (especially habitable structures) and to the
results of the process of building – the buildings themselves. In a more general sense, architecture
refers to an organized arrangement of component elements intended to optimize the function,
performance, feasibility, cost, and aesthetics of an overall structure or system.
 Agenda

o Enterprise Architecture
o The Zachman Framework
o Enterprise Data Model
o Information Value Chain Analysis
o Data Delivery Architecture
 The IT Mindset

We have a high-level
strategy…
That’s not a clear
requirement…

Tell me what you want me to

build
Then I will design it
Then I will build it
Then I will turn it over to you
Then I will walk away

IT CxO

• IT people just want to build stuff and hand it off to other people
• They want business sponsors who will pay for this stuff and tell them exactly
what is needed
• Strategy does not match this mindset

© AskGet.com Inc., 2012. All rights reserved

 Design without Architecture

Stairway to Ceiling

All Design – No Architecture

Rooms: 160; Doorways: 467; Doors: 950; Fireplaces: 47 (gas, wood,
coal); Bedrooms: 40
“Circular” Stairway
Constructed 1884 – 1922 (38 continuous years); Cost: $5.5M
Blueprints: Never made; Individual rooms sketched out by Sarah “…staggering amount of creativity, energy, and
Winchester on paper or other media (e.g. tablecloths) expense poured into each and every detail”
http://www.winchestermysteryhouse.com
• The Winchester Mystery House
• Lots of design – but no architecture

© AskGet.com Inc., 2012. All rights reserved

 What is Architecture ?
o “The design of any complex object or system”
◦ Enables management of complexity
◦ Inherent organization of natural things – biology, geology, mathematics
◦ Design of human-made things – buildings, music, literature, machines,
◦ organizations, processes, software, databases, semantics
◦ Macro Level – city planning, the universe
◦ Micro Level – Machine parts, computer chips, atoms
◦ Abstraction of the system – not the system itself
◦ The more complexity, the greater the need / value

o “An organized arrangement of component elements…

◦ …to optimize function, performance, feasibility, cost and/or aesthetics”
◦ Helps attain a goal
◦ Addresses requirements and constraints
◦ Requires both analysis and design

o The fundamental organization of a system, embodied in its components,

their relation-ships to each other and the environment, and the principles
governing its design and evolution (ANSI/IEEE Std 1471-2000)
 Architectural Framework
o Ways to Think About and Understand Architecture
◦ “Architecture for Architecture”
o Including:
◦ The Zachman Framework For Enterprise Architecture
◦ TOGAF – The Open Group Architecture Framework
◦ RM-ODP - Reference Model of Open Distributed Processing (ISO/IEC 10746)
◦ ANSI/IEEE 1471-2000 “Recommended Practice for Architecture Description of
Software-Intensive Systems”
◦ ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture
description and a comparison table.
◦ PRISM Architecture Framework (1986 -- Hammer, Champy and Davenport)
◦ CAP Gemini and other consulting firms
◦ Government and Defense Frameworks
◦ FEA – US Federal Enterprise Architecture – from the Office of Management and Budget
◦ DODAF - US Department of Defense Architecture Framework
◦ MODAF -- The UK Ministry of Defence Architecture Framework
◦ AGATE -- The France DGA Architecture Framework
◦ GEA – Government Enterprise Architecture – Queensland, Australia provincial
government
The Zachman
o The most widely known and adopted architectural framework
◦ “A logical structure for identifying and organizing the descriptive representations (models) useful in the management of
enterprises and the development of their systems (automated and manual).” (John Zachman)
◦ A generic classification scheme for designing any complex system, not just enterprises and information systems
◦ White paper published in IBM Systems Journal, 1986 – still available!
◦ Studied the fields of architecture and construction (buildings) and aerospace engineering (airplanes)

o Two dimensions of systems architecture – a 6 by 6 matrix

◦ Different stakeholders required different levels of abstraction (rows)
◦ The planner view – lists of system elements defining scope
◦ The owner view – a semantic model showing the relationships between the elements
◦ The designer view – a logical view detailing requirements and unconstrained design
◦ The contractor view – a physical view optimizing the design for specific use and constraints
◦ The implementer view – an out-of-context view of how components are assembled and operate
◦ The user view -- The actual implementation

o Different perspectives answered different questions (columns):

◦ What – the “data” column -- materials used to build the system
◦ How – the “function” column -- processes performed
◦ Where – the “network” column – topography and technology
◦ Who – the “people” column – roles and organizations
◦ When – the “time” column – events, cycles and schedules
◦ Why – the “motivation” column – goals, strategies, rules
◦ Each cell represents a unique type of model
 Zachman Framework
DATA ARCHITECTURE 103

What How Where Who When Why

Inventory Process Distribution Responsibility Timing Motivation

Executive Identification Identification Identification Identification Identification Identification Scope Context

Inventory Process Distribution Responsibility Timing Motivation

Business definition Definition Definition Definition Definition Definition Business
Management Concepts

Inventory Process Distribution Responsibility Timing Motivation

Architect Representation Representation Representation Representation Representation Representation System Logic

Inventory Process Distribution Responsibility Timing Motivation

Technology
Engineer Specification Specification Specification Specification Specification Specification
Physics

Inventory Process Distribution Responsibility Timing Motivation Tool

Technician Configuration Configuration Configuration Configuration Configuration Configuration Components

Inventory Process Distribution Responsibility Timing Motivation Operational

Enterprise Instantiations Instantiations Instantiations Instantiations Instantiations Instantiations Instances

Inventory Process Distribution Responsibility Timing Motivation

Sets Flows Networks Assignments Cycles Intentions

Figure 22 Simplified Zachman Framework

 Zachman Framework : “What”
o The executive perspective (business context): Lists of business
elements defining scope in identification models.
o The business management perspective (business concepts):
Clarification of the relationships between business concepts defined by
Executive Leaders as Owners in definition models.
o The architect perspective (business logic): System logical models
detailing system requirements and unconstrained design represented
by Architects as Designers in representation models.
o The engineer perspective (business physics): Physical models
optimizing the design for implementation for specific use under the
constraints of specific technology, people, costs, and timeframes
specified by Engineers as Builders in specification models.
o The technician perspective (component assemblies): A technology-
specific, out-of-context view of how components are assembled and
operate configured by Technicians as Implementers in configuration
models.
o The user perspective (operations classes): Actual functioning
instances used by Workers as Participants. There are no models in this
perspective.
 Enterprise Architecture in Practice

o An integrated collection of (business and IT) models and documents

reflecting enterprise integration and standardization requirements and
high- level design.
◦ Usually defines both an “as is” and “target” state
◦ May also include “reference” and “transition” states
◦ All versions must be kept current to be relevant and useful

o A tool for planning, IT governance and portfolio management, that

helps:
◦ Align information systems with business strategy.
◦ Align organization and operating model with business strategy. Guide integration of data,
processes, technologies and efforts. Enable effective coordination of resources.
◦ Improve communication and understanding across the organization.
◦ Reduce the cost of managing the IT infrastructure.
◦ Guide business process improvement.
◦ Enable leadership to respond effectively to changing market opportunities, industry
challenges and technological advances. Enterprise architecture helps evaluate business
risk, manage change and improve business effectiveness, agility and accountability.
 Enterprise Architecture in Practice

o Data architecture
◦ Subject areas, business entities, business relationships, data attributes, business definitions,
taxonomies, entity lifecycle states, valid reference values, data quality rules, data security
classifications, data flow
o Process architecture
◦ Functions, activities, tasks, steps, workflow, products, events, cycles, procedural rules
o Business architecture
◦ Goals and objectives, strategies and initiatives, roles and job positions, organization
structures, locations, operating principles
o Application architecture
◦ Business system portfolio, software components (SOA), program structure and flow, portals
and user interfaces, implementation projects
o Technology architecture
◦ Hardware and software platforms, standards, protocols, network topology
o Information value chain analysis
◦ Mapping the relationships between data, process, business, applications and technology
technical architecture. Table 6 describes and compares these domains. Architects from different domains must
address development directions and requirements collaboratively, as each domain influences and put constraints
on the other domains. (See also Figure 22.)
Enterprise Architecture Domain
Table 6 Architecture Domains

Domain Enterprise Enterprise Data Enterprise Enterprise

Business Architecture Applications Technology
Architecture Architecture Architecture

Purpose To identify how an To describe how data To describe the To describe the
enterprise creates should be organized structure and physical technology
102 DMBOK2
value for customers and managed functionality of needed to enable
and other applications in an systems to function
stakeholders enterprise and deliver value
Domain Enterprise Enterprise Data Enterprise Enterprise
Business Architecture Applications Technology
Architecture Architecture Architecture

Elements Business models, Data models, data Business systems, Technical platforms,
processes, definitions, data software packages, networks, security,
capabilities, mapping databases integration tools
services, events, specifications, data
strategies, flows, structured data
vocabulary APIs

Dependencies Establishes Manages data created Acts on specified Hosts and executes
requirements for the and required by data according to the application
other domains business architecture business architecture
requirements

Roles Business architects Data architects and Applications Infrastructure

and analysts, modelers, data architects architects
business data stewards
stewards
ENTERPRISE DATA ARCHITECTURE
 Data Domain
(Godinez et al.)

o Metadata Domain—Defined as “data about the data.” Metadata is the

information that describes the characteristics of each piece of corporate
data asset and other entities.
o Master Data Domain—Refers to instances of data describing the core
business entities, such as customer or product data.
o Operational Data Domain—Also referred to as transactional data
capturing data, which is derived from business transactions.
o Unstructured Data Domain—Also known as content, typically
managed by an enterprise content management application.
o Analytical Data Domain—Usually derived through transformation
from operational systems to address specific requirements of decision
support applications.
Data Domain
(Godinez et al.)
o Information Reference Model
 Data Domain
(Godinez et al.)

o Data domain can be classified according to

some criteria, for example:
◦ Format: structured vs unstructured
◦ Scope of integration:
◦ Local scope: This scope means the data is used only within a
team, department, or a LOB. Example: market analysis, design
document of a software component.
◦ Enterprise-wide scope: This scope indicates that the data is
used enterprise-wide. Example: product and customers.
◦ Cross-enterprise scope: This scope indicates that the data is
used across enterprises but is not necessarily used across all
LOBs internally. Example: supply-chain data
◦ Etc.
 Enterprise Data Architecture

o “Enterprise data architecture is

◦ An integrated set of specification artifacts
◦ That define strategic data requirements,
◦ guide integration of data assets
◦ And align data investments with business strategy.” (DAMA-DMBOK)

o “Data architecture defines how data is stored,

managed, and used in a system which describes :
◦ how data is persistently stored
◦ how components and processes reference and manipulate this data
◦ how external/legacy systems access the data
◦ interfaces to data managed by external/legacy systems
◦ implementation of common data operations “(CMU/SEI-2001-TR-018)
Enterprise Data Architecture
 Enterprise Data Architecture
o Enterprise Data Model
◦ Subject areas, business entities, relationships, super and sub-types
◦ Business definitions, data stewardship assignments
◦ Essential data attributes
◦ Entity lifecycle states, valid reference values, data quality requirements

o Information Value Chain Analysis

◦ Alignment with process, technology and strategy

o Data Delivery Architecture

◦ Data Integration Architecture
◦ Macro-level data flow: “The Corporate Information Factory”
◦ Reference Data and MDM Hubs, ODS, Data Warehouses and Data Marts
◦ SOA Data access services
◦ Database technology architecture
◦ Information content and delivery architecture – portals, taxonomies, …
◦ Meta data architecture – integration, control, delivery, meta model
Enterprise Data Model Layers
Enterprise data model is usually arranged according to common architectural layers
Reference
Architecture
Assimilate best Conceptual
architectural Architecture
practices from the IT
industry. All relevant Match/select Logical
component classes architectural Architecture
and patterns are component classes
understood. and patterns to the Detailed design of Physical
business needs, future state Architecture
(including future architecture.
plans). Influencing actual
physical
implementations to
ensure conformance
Common Architectural Layers with logical
architecture

A reference architecture is the highest level of architecture. It can be

undertaken prior to even thinking about the enterprise. Its advantages
are that it can be very high level and can cover the entire enterprise.
Useful for thinking about high level data layers
 Reference Data Architecture - Example

• Example of a simple reference data architecture

• Just data layers – no services or components
BUT – just having a picture can be problematic

© AskGet.com Inc., 2011. All rights reserved

Need Definitions, Explanations – Not Just Picture

Layer
Characteristic Transactional
Data Warehouse Data Mart
Application
View of data across the Data structured and filtered
Data produced via the
enterprise. Supports to support specific
Purpose automation of business
dissemination, derivation of information needs of small
processes
knowledge and history groups of users.
Derivations (including Data from Warehouse is
All base (non-derived) data
Data Life Cycle originates here
aggregations) produced transformed to support
here, and history is inferred specific reporting

Create / Source / Read / Extract / Transform / Load / Subscribe / Transform /

Data Operations Update / Delete / Archive Derive / Publish / Archive Archive

Subject Oriented / Information Requirement

Data Model Normalized to 3NF Snowflaked / Conformed Oriented / Snowflaked /
Dimensions Conformed Dimensions

• Much more is needed than the above

• Definitions are a technical reference; explanations help stakeholders to
understand the reference architecture

© AskGet.com Inc., 2011. All rights reserved

 Enterprise Data Model

o An enterprise data model (EDM) is an integrated subject-oriented data model

defining the essential data produced and consumed across an entire
organization.
◦ Essential means the data critical to the effective operation and decision-making of the
organization. Few (if any) enterprise data models define all the data within an enterprise.
Decisions must be made (and revisited) about the scope of enterprise data modeling
efforts. “Essential” does not mean “common” or “shared.” Essential data requirements
may or may not be common to multiple applications and projects. Some data defined in
the enterprise data model may be shared by multiple systems, but other data may be
critically important yet created and used within a single system. Over time, the enterprise
data model should define all data of importance to the enterprise.
◦ Integrated means that all of the entities, attributes and rules in the model are defined
once, without redundancy. The concepts in the model fit together as the CEO sees the
enterprise, not reflecting separate and limited functional or departmental views. There is
only one version of the Customer entity, one Order entity, etc. Every data element also has
a single name and definition. The data model may also identify common synonyms and
important distinctions between different sub-types of the same common business entity.
◦ Subject-oriented means the model is divided into commonly recognized subject areas that
span across multiple business processes and application systems. Subject areas are focused
around the most essential business entities.
Enterprise Data Model layers
 The Subject Area Model

o Zachman Framework Column 1 Row 1 (Scope View) Model – a list!

o Organizes the Enterprise Data Model

◦ A very significant enterprise taxonomy, get it “right” from the start!

o An essential structure for data governance and stewardship

◦ Entities frequently appear in multiple subject areas, but should be assigned one
primary subject area for governance
◦ Business data stewards are assigned accountability for entities or entire subject
areas
◦ Data stewardship teams organized by subject area for modeling, data quality
requirements definition and reference data (code table) management
 The Subject Area Model

A Subject Area Model is a taxonomy of the major areas in the enterprise

that are relevant to data management
A necessary starting point for MDM
1 – A subject area should have stable definitions of entities
2 – Production of master data should not cross subject area boundaries
Identify the major data concepts in each subject area – may will be
master data entities.

© Askget.com Inc., 2011. All rights reserved

 DATA ARCHITECTURE 107

An Example: Subject Area Model

approaches is usually recommended; starting with bottom-up using existing models and completing the
enterprise data model by populating the models by delegating Subject Area modeling to projects.

Product Design Commercial Sales Subject

Subject Area Offer Subject Area
Area
Market
Product Sales
Product Group Offering
Platform Order
Portfolio

Offering Range Occurs in

Uses

Sales Sales
Belongs to Product
Item Order Item

Product Design
Bill-of-material Specifies
(BOM)
Sales Bundle
Bill-of-material
(BOM)

Product
Part Sales
Details Order Item
Part Configuration
Structure

Figure 24 Subject Area Models Diagram Example

The Subject Area discriminator (i.e., the principles that form the Subject Area structure) must be consistent
throughout the enterprise data model. Frequently used subject area discriminator principles include: using
normalization rules, dividing Subject Areas from systems portfolios (i.e., funding), forming Subject Areas from
 A Subject Area Model is Not Costly

Data Management

10-15 subject areas per model is the norm

Do not need elaborate data modeling tools
Much more about a standardized view of the enterprise
Can be done with 1-3 people
Gets a lot of bang for the buck
Is high-level and important

© Askget.com Inc., 2011. All rights reserved

 A Subject Area Model is a Taxonomy
I don’t like
your definition
of this subject
Your model
does not tell
CLIENT MARKETING area!
me what is AND MANAGEMENT
financial data!
CLIENT MEETING ADDRESS

CONTACT PLAN
CONTRIBUTION /
SERVICE REQUEST WITHDRAWAL
You mean to tell me
every one of these
subject areas
includes access
security for data!

People think a taxonomy is a way of unlocking the secrets of the universe

Taxonomies are a tools – you can have as many as you need to do your
job
You can never expect the boundaries of a subject area model to be
exactly precise and never changing

© Askget.com Inc., 2011. All rights reserved

 Create a Metadata Subject Area Model

The Fundamental Ontology of Metadata for the Enterprise

© Askget.com Inc., 2011. All rights reserved

 Metadata Subject Area Model
Advantages
1. Standardizes the metadata in the enterprise at a high level.

2. Can be used to prioritize projects and programmes.

3. Useful in communications.
4. Shows what metadata is being produced by subject area. This is a high-level
inventory.
5. Can distinguish data-related metadata from other data
6. Within each subject area, definitions should be constant. There may be
variations across subject areas.
7. Subject areas are candidates for conceptual models.

Disadvantages
1. It is a taxonomy and can be argued over. No one taxonomy will satisfy every
perspective. We use data categorization for that (see later). The Subject Area
Model should be the most common and natural perspective.
2. The Subject Area Model often has more things expected of it than it can
deliver. Managing expectations can be tricky.

The Subject Area Model is itself Metadata and needs to be managed

© Askget.com Inc., 2011. All rights reserved
Defining the Conceptual View
o Identify and name business entities
o Identify super-type / sub-types
◦ “X is a kind of Y”
◦ Isolate most class hierarchies in separate subject areas
o Draft, review and refine entity business definitions
o Identify and specify examples, synonyms, acronyms
◦ Document distinctions from closely related terms
o Assign primary subject area
o Assign data stewardship accountability
o Define potential business identifiers
◦ Define initial draft primary key attribute
o Identify and specify business relationships
◦ Relationship names, cardinality
 Defining the logical view

o Still usage (application) neutral – NOT the application

logical model
o Identify essential data attributes
◦ Unique identifiers, others
◦ Brainstorm by data type (names, codes, dates, measures, …)
◦ Analyze existing data models, databases, screens and reports
◦ Do NOT accept the status quo
◦ Exclude anything application or implementation specific
o Assign to logical data types (domains)
◦ Inherit standard length for the domain
o Name according to standards
o Draft, review and refine attribute definitions
o Determine null-ability – should some value be
mandatory?
o Identify best (if any) default value
RELATED DATA ARCHITECTURE
(DATA FLOW DESIGN)
Data Flow Design
o A type of data lineage documentation that
depicts how data moves through business
processes and systems.
o Data flows map and document relationships
between data and
◦ Applications within a business process
◦ Data stores or databases in an environment
◦ Network segments (useful for security mapping)
◦ Business roles, depicting which roles have
responsibility for creating, updating, using, and
deleting data (CRUD)
◦ Locations where local differences occur
Data flows can be documented at different levels of detail: Subject Area, business entity, or even the attribute
level. Systems can be represented by network segments, platforms, common application sets, or individual
servers. Data flows can be represented by two-dimensional matrices (Figure 25) or in data flow diagrams
(Figure 26).
Data Flow Matrix
Business Processes

Product Marketing Industrial Order

Manufacturing Logistics Invoicing
development & Sales preparation management

Product

Product Part
Manufacturing
Plant
Customer
Major Entities

Sales Item
Assembly
Structure
Sales Order
Production
Order
Individual
Product
Shipping
Customer’s
Invoice

Create Read/use

Figure 25 Data Flow Depicted in a Matrix

 capabilities. Building such matrices is a long-standing practice in enterprise modeling. IBM introduced this
practice in its Business Systems Planning (BSP) method. James Martin later popularized it in his Information
Systems Planning (ISP) method during the 1980’s.

Data Flow Diagram

The data flow in Figure 26 is a traditional high-level data flow diagram depicting what kind of data flows
between systems. Such diagrams can be described in many formats and detail levels.

Service & repair statistics

Material returns

CRM

Service
Customer data & repair
Customer statistics
agreement

Product Design BOM

Product properties Aftermarket
PDM System Sales System
System

Product design BOM

Product properties Sales BOM
Sourcing data Order Contents

Manufacturing Manufacturing
Routing System Planning Serial numbers
Manufacturing BOM System Individual product BOM
Production line routing
Lead times

Figure 26 Data Flow Diagram Example

 Above and Beyond Data Modeling

o Entity lifecycle state-transition diagrams

◦ (Status values and trigger events)

o Valid reference values

◦ (codes, names and meanings)

o Business glossary
◦ (including general terms, more than entities)

o Enterprise content management taxonomies

◦ Standard topic hierarchies
 Above and Beyond Data Modeling

o Data attribute quality rules and requirements

◦ Integrity rules
◦ Format requirements
◦ Data cleansing rules and procedures
◦ Match / merge rules
◦ Accuracy / precision requirements
◦ Timeliness / “freshness” requirements
◦ Consistency requirements
◦ Security / privacy protection requirements
◦ Security classification (“restricted”, ”confidential”, ”internal only”, ”public”)
◦ Retention and archival requirements Regulatory compliance requirements
Audit requirements

Identify the most critical dimensions of data quality

 Not Just Primitive Model

o Zachman Framework identifies primitive

model artifacts
◦ Data-to-data relationships only

o Other relationships are also critical to the

enterprise – “composite” models
◦ Data-to-process
◦ Data-to-organization
◦ Data-to-role
◦ Data-to-application
INFORMATION VALUE CHAIN ANALYSIS
 Information Value Chain Analysis

o Matrix mapping of relationships between two sets

of elements
◦ Most data relationship matrices are “CRUD” matrices
◦ “Create, read, update, delete”

o Developed in early 1980’s for IBM business

systems planning (BSP)
◦ Incorporated into james martin’s information engineering
methodology - information systems planning (ISP) phase

o Still a critical component of enterprise

architecture!!!!
 Information Value Chain Analysis

o Technique re-named after Michael Porter’s Business Value

Chain concept
o Directly contributing functions sequenced left to right
o Indirect functions support from below or above
 Information Value Chain Analysis

o Element Sequenced Using the Business Value Chain

◦ Familiar, intuitive sequence
◦ Functions AND subject areas?
◦ X axis (left to right) AND Y axis (top-to-bottom)?

o Data / Process CRUD Matrices: Different Levels of Detail

◦ Subject areas / business functions
◦ Business entities / functions or processes
◦ Data attributes / processes and their information products

o Other Potentially Useful CRUD Matrices

◦ Data / organization CRUD matrix – who?
◦ Data / role crud matrix –who?
◦ Data / location crud matrix – where?
◦ Data / application system crud matrix – where?
Affinity Analysis
 Why Value Chain Analysis?

— Alignment with process models

— Validating the data model

— Understanding data sources

— Analyzing data quality issues

— Change impact analysis

— Defining information products

DATA DELIVERY ARCHITECTURE
 Data Delivery Architecture

o Data Integration Architecture

◦ How data flows across databases and applications
(OLTP, MDM, DW, BI)
◦ “The Corporate Information Factory”
◦ Master data management hubs
◦ Operational data stores
◦ Data warehouses and data marts
◦ Data replication and transformation
◦ Subscribe and publish
◦ Batch vs. near-real time (asynch MQ bus, …)
◦ XML, Web Services and SOA
◦ “Replacing feeds with reads”
DW/BI Architecture
The Corporate Information Factory &
The Web Environment

A corporate information factory

(CIF) is a logical architecture
created and promoted by a small
group of data professionals.
 Database Architecture

o Which DBMS tools?

o Which integration tools?

o When/where to use what technology?

o When to distribute? When to federate?

 Unstructured Information
Architecture

o Enterprise content management

o Enterprise taxonomies

o Enterprise portal strategy

o Document management and imaging systems

o Storage management / archival and retrieval

o Report format, storage and distribution

What’s essential for data alignment and data

integration?
 Metadata Architecture
o The Managed Meta Data Environment (MME) Architecture
◦ Dedicated hardware, software, staff and processes
◦ For integration, control and delivery of meta data
◦ Providing easier access to integrated meta data
◦ Centralized, hierarchical, distributed or federated?
DATA ARCHITECTURE ACTIVITIES
 Data Architecture

Definition: Identifying the data needs of the enterprise (regardless of structure), and
designing and maintaining the master blueprints to meet those needs. Using master
blueprints to guide data integration, control data assets, and align data investments with
business strategy.

Goals:
1. Identify data storage and processing requirements.
2. Design structures and plans to meet the current and long-term data requirements of the enterprise.
3. Strategically prepare organizations to quickly evolve their products, services, and data to take advantage
of business opportunities inherent in emerging technologies.
Business
Drivers

Inputs: Activities: Deliverables:

• Enterprise 1. Establish Enterprise Data • Data Architecture
Architecture Architecture (P) Design
• Business 1. Evaluate Existing Data • Data Flows
Architecture Architecture Specifications • Data Value Chains
• IT Standards and 2. Develop a Roadmap • Enterprise Data
Goals 3. Manage Enterprise Model
• Data Strategies Requirements within Projects • Implementation
(D) Roadmap
2. Integrate with Enterprise
Architecture (O)

Suppliers: Participants: Consumers:

• Enterprise • Enterprise Data Architects • Database
Architects • Data Modelers Administrators
• Data Stewards • Software Developers
• Subject Matter • Project Managers
Experts Technical • Support Teams
• Data Analysts Drivers

Techniques: Tools: Metrics:

• Lifecycle Reviews • Data modeling tools • Architecture standards
• Diagramming Clarity • Asset management software compliance rates
• Graphical design applications • Trends in implementation
• Business value metrics

(P) Planning, (C) Control, (D) Development, (O) Operations

DATA ARCHITECTURE ARTIFACTS RECOMMENDED
BY TOGAF
 Conclusions

o Data architecture is part of an enterprise

architecture

o EA can drive data architecture or reverse –

both are ultimately essential to a fully
functional enterprise

o Data architecture requires skills in several

areas, and is a discipline for experienced data
professionals, includes technical knowledge
 Reference

o These slides were adapted from the following

sources:
◦ http://www.dama-
ncr.org/Library/20080513DataArchitectureAMS.pdf
◦ Godinez at al. (2010) The Art of Enterprise
Information Architecture: A Systems-Based
Approach for Unlocking Business Insight, IBM Press
◦ Data Architecture for Data Governance, IASA,
http://www.slideshare.net/Dataversity/data-
architecture-for-data-governance-15146230
◦ Data Management Body of Knowledge, 2nd edition.