ICT616 Data

Resources
Managemen
t
Topic 3: Data
Architecture
Management
Lecture Outline

1. What is Data Architecture (DA)?

2. Zachman Framework
3. Goals and objectives of DA Management (DAM)
4. DAM Activities
5. Guiding Principles of DAM

2
Learning Objectives

At the completion of this topic, you should be able to:

-Discuss the main features of the Zachman framework
and how it impacts on data management
-Define data architecture and explain why an
enterprise data architecture is required
-List and define the components of an enterprise data
architecture
-Discuss the goals and objectives of data architecture
management
-List and define the activities associated with data
architecture management
3
Data Architecture
Management (DAM)
The DAMA-DMBOK tells us that DAM is:
Defining the data needs of the organisation and
designing the master blueprints to meet those
needs

In order to better understand how this can be

achieved, it may help to discuss what Data
Architecture is…

4
What is Data Architecture?
(1/3)

Many different definitions

Short Definition: Data architecture is the set of models,
policies, rules or standards that govern which data is
collected, and how it is stored, arranged and put to use
in a database system and/or in an organization

5
What is Data Architecture?
(2/3)
A second, longer definition (next slide) is combined
from:
http://www.dataversity.net/data-architecture-and-infor
mation-architecture-whats-the-difference/
and
http://www.learn.geekinterview.com/data-warehouse/d
ata-architecture/what-is-data-architecture.html

6
What is Data Architecture?
(3/3)

Data Architecture describes, in a given system, the

way data will be processed and stored; how the data
flows and is used by the project teams, including the
data models.
It is concerned with the design and use of data in
structured formats such as databases and file
systems.
It lays out the criteria for data processing operations
including the whole flow of data in the system.

7
Architectural Processes

Conceptual - represents all business entities.

Logical - represents the logic of how entities are
related.
Physical - the realization of the data mechanisms for a
specific type of functionality.

These correlate somewhat to items in the Zachman

Framework.

8
Data Architecture

DAMA suggests that the DA is:

- “…A master set of data models and design
approaches identifying the strategic data requirements
and the components of data management solutions,
usually at an enterprise level.”

9
10
Deliverables

DAMA lists 6 typical components of an enterprise DA:

1. Enterprise Data Model
2. State Transition Diagrams
3. Information Value Chain Analysis
4. Data Integration Architecture
5. Lists of controlled domain values
6. Responsibility assignments of data stewards

11
We will look at some of those in more
detail

12
Enterprise Information
Needs

In order to create an enterprise data architecture, the

enterprise needs to first define its information needs.

An Enterprise Data Model is a way of capturing and

defining enterprise information needs and data
requirements.
It is a master blueprint for enterprise-wide data
integration.

13
Enterprise Data Model
(EDM)
Enterprise data architecture is as much about data as
it is about terminology
So, the EDM is a set of deliverables that provides a
common consistent view of shared data across the
enterprise.
- It is a critical input to all future systems development
projects and the baseline for additional data
requirements analysis and data modeling efforts
undertaken at the project level

14
This Week’s Workshop

Workshop: Read the following article on the EDM, as well as the

paper that you can find on LMS under Topic 4. Discuss in your
group, and then with your classmates, the relevant questions that
you will find on LMS.
https://tdan.com/the-enterprise-data-model/5205

15
But how can we understand
enterprise information
needs? (1/2)

-Evaluate the current inputs and outputs required by

the organization
-Use system documentation and reports
-Interview the participants
-And then…

16
But how can we understand
enterprise information
needs? (2/2)

-Organize the material (data entities, data attributes

and calculations) that you have gathered
-By business unit and subject area
- Review the list with the participants to ensure proper
categorization and completeness
-Then, the contents of the list become the basic
requirements for an enterprise data model

17
Developing and Maintaining
the EDM (1/7)

-Business entities are the concepts and classes of

things, people and places that are familiar and of
interest to the enterprise
-Data is the set of facts we collect about business
entities
-Data models define these business entities and the
kinds of facts (data attributes) needed about these
entities to operate and guide the business

18
Developing and Maintaining
the EDM (2/7)

-A data model is a set of data specifications and

related diagrams that reflect data requirements and
designs.
-An Enterprise Data Model is an integrated, subject-
oriented data model defining the essential data
produced and consumed across an entire organisation.

19
Developing and Maintaining
the EDM (3/7)

-Integrated-> all of the data and rules in an

organisation are depicted once, and fit together
seamlessly. 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 attribute also has a single name and
definition.

20
Developing and Maintaining
the EDM (4/7)

- Subject-oriented -> the model is divided into

commonly recognized subject areas that span across
multiple business processes and application systems
- Essential -> regarding only the data that is critical to
the effective operation and decision-making of the
organisation. Few, if any, enterprise data models
define all the data within an enterprise.

21
Developing and Maintaining
the EDM (5/7)

-Essential data requirements may or may not be common to

multiple applications and projects
-Multiple systems may share some data defined in the
enterprise data models, but other data may be critically
important, yet created and used within a single system
-Over time, the EDM should define all data of importance to
the enterprise.
-However, over time the definition of essential data will
change as the business changes and EDM must be up to
date
22
Developing and Maintaining
the EDM (6/7)

-An EDM is a significant investment in defining and

documenting an organisation’s vocabulary, business rules
and business knowledge
- It aligns business and IT around common understandings
-Creating, maintaining and enriching it require continued
investments of time and effort
-Most successful enterprise data models are built
incrementally and iteratively

23
Developing and Maintaining
the EDM (7/7)

-How should an EDM be built?

- In layers, focusing initially on the most critical business
subject areas.
-The higher layers are the most fundamental, with lower
layers dependent on the higher layers.
-Although the EDM is built in a top-down manner, the
contents of the model often benefit from bottom-up
input

24
25
Enterprise Data Model –
Subject Area Model
Gives the overall SCOPE of the enterprise
May be presented as
• an outline of subject areas
• a diagram

Subject areas often correspond to individual business

activities

26
Enterprise Data Model –
Conceptual Model (1/2)
Defines relationships between business entities for each
subject area
Business entities are named using business terms. A single
example of a business entity is an instance.
Many business entities will appear within the scope of
several subject areas, as the scope boundaries of subject
areas normally overlap. For data governance and
stewardship purposes, every business entity should have
one primary subject area which “owns” the master version
of that entity

27
Enterprise Data Model –
Conceptual Model (2/2)
Conceptual data models may include many-to-many
business relationships between entities
Since they are mainly for business understanding ,
they do not need data attributes
- Data attribute: a property of an entity, e.g.,
the attribute Student Last Name describes the last
name of each student

28
Enterprise Data Model – Enterprise
Logical Data Model (1/2)

Add another level of detail below conceptual

Still ensure model has only a logical perspective
e.g.
Customers -> Customers Addresses
Customers (first name, middle name, surname, date of
birth, phone number, mobile number, email,
comments)
Customers Addresses (billing or delivery, active,
address line 1, address line 2, address line 3, city, zip
code, state, country, comments)
29
Enterprise Data Model – Enterprise
Logical Data Model (2/2)

- Depicts the essential data attributes for each entity

- Common data requirements and standardized
definitions for widely shared data attributes.
-Essential data attributes are those without which the
enterprise cannot function. Determining them is a very
subjective decision
-The enterprise logical data model diagrams need to
be neutral and independent from any particular need,
usage and application context

30
Data Integration Architecture

DIA defines how data flows through ALL systems from

beginning to end.
It includes both the datasets and the applications that
control the data flow into the system, between
databases, and back out of the system.

31
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…
The value of information created in earlier processes is
shown by its use in later processes.”
(Mosely, 2009)

32
33
Summing up…
DA is:
-Integrated set of specification artifacts used to:
-Define data requirements
-Guide integration and control of data assets
-Align data investments with business strategy
-Integrated collection of master blueprints
-A collection of
-formal data names
-comprehensive data definitions
-Effective data structures
-Precise data integrity rules
-Robust data documentation
34
So then, what is DAM?

DAM is the process of defining and maintaining

specifications that:
-Provide a standard common business vocabulary
-Express strategic data requirements
-Outline high–level integrated designs to meet these
requirements, and
-Align with enterprise strategy and related business
architecture

35
Goals of DAM

-Plan to provide high-quality data

-Identify and define common data requirements
-Design conceptual structures and plans to meet the
enterprise data requirements

36
Drivers

-These may come from a number of areas

-Enterprise requirements
-Technology drivers
-Business policies

37
Drivers - Enterprise

• Economical and effective system expansion

• Acceptable performance levels (SLA)
• Transaction reliability
• Transparent management of data

38
Drivers - Technology

• Existing integration frameworks (e.g middleware,

software that enables communication and
management of data in distributed applications)
• Existing infrastructure standards (Business
continuity)
• Existing site resources (Licenses)

39
Drivers - Business

• Internal policies
• Regulatory policies
• Laws

40
Lifecycle

• A Data Architecture project can be considered to go

through a lifecycle not unlike other kinds of projects
• E.g.
• Planning, Analysis, Design,
Development/Implementation, Deployment

41
Lifecycle –
Planning/Initiation
• Scope definition
• Architecture standards
• Metadata
• High level architecture standards
• Methodologies
• Data Discovery

42
Lifecycle – Analysis

• High level conceptual modelling

• Data analysis
• Data design standards

43
Lifecycle – Design
• Logical data modelling
• Physical database design
• Sizing
• HW/Storage

• System Architecture
• Data flows
• External interfaces

• Technical Architecture
• Failover:switching to a redundant/standby computer server,
system, hardware component or network upon the failure
or abnormal termination of the previously active
application, server, system, hardware component, or network

44
The Zachman Framework
(1/5)
The most widely known and adopted architectural
framework, since its first published description in
an IBM Systems Journal in 1987.
It provides a formal and structured way of
viewing and defining an enterprise. The ontology
is a two dimensional classification schema, a 6
by 6 matrix that reflects the intersection
between two historical classifications.

45
The Zachman Framework
(2/5)

To understand systems architecture, Zachman

studied how the fields of building construction
and aerospace engineering define complex
systems, and mapped his framework against
these examples
In the first dimension, Zachman recognised that in
creating buildings, airplanes or systems there
are many stakeholders, and each has different
perspectives about architecture. Zachman
depicted these perspectives as rows
46
The Zachman Framework
(3/5)
Planner perspective -> Lists of business elements defining
scope
Owner perspective -> Semantic models of the business
relationships between business elements
Designer perspective -> Logical models detailing system
requirements
Builder perspective -> Physical models optimizing the design
under the constraints of technology, people, costs,
timeframes
Implementer perspective->A technology-specific, out-of-
context view of how components are assembled and
operate
Participant perspective -> Actual functioning system
instances 47
The Zachman Framework
(4/5)

For the second dimension, each perspective’s

issues required different ways to answer the
fundamental questions: Who, What, Why, When,
Where and How
Each question required answers in different
formats
Zachman depicted each fundamental question as a
column

48
The Zachman Framework
(5/5)

The Zachman Framework is not a methodology in

that it does not imply any specific method or
process for collecting, managing, or using the
information that it describes.
It is an ontology for organizing architectural
artifacts (design documents, specifications, and
models) to take into account both who the
artifact targets are (for example, business owner
and builder) and what particular issue (for
example, data and functionality) is being
addressed.
49
50
 Zachman Framework

Row 1 – Scope
External Requirements and Drivers
Business Function Modeling
Row 2 – Enterprise Model
Business Process Models

Row 3 – System Model

Logical Models What How Where Who When Why
Requirements Definition
1 Contextual Contextual

Row 4 – Technology Model

Physical Models 2 Conceptual Conceptual

Solution Definition and

Development 3 Logical Logical

Row 5 – As Built 4 Physical Physical

As Built
Deployment 5 As Built As Built

Row 6 – Functioning Enterprise

Functioning Enterprise 6 Functioning Functioning

Evaluation What How Where Who When Why

51
Framework Rules

Basic Model = Entities and Relationships

 Rule 1: Entity Relationship Entity

Columns have no order

 Rule 2:
What How Where Who When Why
Each column has a simple, basic model
Contextual Contextual
 Rule 3:
Conceptual Conceptual
Basic model of each column is unique
Logical Logical
 Rule 4:
Each row represents a distinct view Physical Physical

 Rule 5: As Built As Built

Each cell is unique

Functioning Functioning

 Rule 6: What How Where Who When Why

Combining the cells in one row forms a

complete description from that view

52
TOGAF

The Open Group Architecture Framework (TOGAF) is a

popular Enterprise Architecture Framework.
It can be used in a complementary way to Zachman’s
framework to address the processes which will help
maintain the Enterprise Architecture (and in our case
the Data Architecture, as TOGAF is modelled at four
levels: Business, Application, Data, and Technology).
TOGAF can be helpful in implementing the Enterprise
Architecture but in order to define it the Zachman
framework is essential

53
DAM Activities

Understand Enterprise Information Needs

Develop and Maintain Enterprise Data Model
Analyse and Align with Other Business Models
Define and Maintain the Data Technology Architecture
Define and Maintain the Data Integration Architecture
Define and Maintain the DW/BI Architecture
Define and Maintain Enterprise Taxonomies and
Namespaces
Define and Maintain the Meta-data Architecture
54
8 Guiding Principles for
DAM
1. Data architecture is an integrated set of
specification artifacts used to:
- Define data requirements
- Control data assets
- Guide data integration
- Align data investments with business strategy

55
8 Guiding Principles for
DAM
2. Enterprise Data Architecture (EDA) is part of the
overall enterprise architecture, along with process
architecture, business architecture, systems
architecture and technology architecture
3. EDA includes the EDM and the Information Value
Chain Analysis (IVCA)

56
8 Guiding Principles for
DAM
4. EDA is about more than just data. It helps establish
the semantics of an enterprise, using a common
business activity
5. An EDM is an integrated data model defining the
essential data used across an entire organisation.

57
8 Guiding Principles for
DAM
6. IVCA defines the critical relationships between data,
processes, roles and organisations, and other enterprise
elements.
7. Data delivery architecture defines how data flows
across databases and applications. This ensures data
quality and integrity to support both transactional and
business processes and BI reporting and analysis
8. Architectural frameworks such as Zachman’s help
organise collective thinking about architecture. This
allows different people with different objectives and
perspectives to work together to meet common interests.
58