1

Data Architecture
Understanding the Role and Importance

Eng. Mohamed Elyas Abakar

 What is Data Architecture ?

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.

2
What is the goal of Data
Architecture?
Identify data storage and processing requirements.

Design structures and plans to meet the current and long-term data requirements of
the enterprise (standardization and consistency).

Strategically prepare organizations to quickly evolve their products, services, and data
to take advantage of business opportunities inherent in emerging technologies
(Business alignment).

3
The goal of Data
Architecture is to
be a bridge
between
business strategy
and technology
execution.

4
What are the responsibilities of
Data Architect?
Strategically prepare organizations to quickly evolve their products, services, and data to take
advantage of business opportunities inherent in emerging technologies

Translate business needs into data and system requirements so that processes consistently have
the data they require

Manage complex data and information delivery throughout the enterprise

Facilitate alignment between Business and IT

Act as agents for change, transformation, and agility

5
What are the Primary Data Architecture
outcomes?

Designs of
structures and
Data storage plans that meet
and processing the current and
requirements long-term data
requirements of
the enterprise

6
7
How do Data Architects define and maintain
specifications to reach their goals?

Define the current state of data in the organization

Provide a standard business vocabulary for data and components

Align Data Architecture with enterprise strategy and business architecture

Express strategic data requirements

Outline high-level integrated designs to meet these requirements

Integrate with overall enterprise architecture roadmap

8
What are the overall elements that included in
Data Architecture practice?

Using Data Architecture

Collaborating with,
artefacts (master Using Data Architecture
learning from and
blueprints) to define to establish the
influencing various
data requirements, semantics of an
stakeholders that are
guide data integration, enterprise, via a
engaged with improving
control data assets, and common business
the business or IT
align data investments vocabulary
systems development
with business strategy

9
Enterprise Architecture Domains

10
 Zachman Framework for Enterprise Architecture

The most well-known enterprise architectural framework, the Zachman Framework,

was developed by John A. Zachman in the 1980s. (See Figure 22.) It has continued to
evolve. Zachman recognized that in creating buildings, airplanes, enterprises, value
chains, projects, or systems, there are many audiences, and each has a different
perspective about architecture. He applied this concept to the requirements for
different types and levels of architecture within an enterprise.

The Zachman Framework is an ontology – the 6x6 matrix comprises the complete set
of models required to describe an enterprise and the relationships between them. It
does not define how to create the models. It simply shows what models should exist.

11
12
Translated to enterprise architecture, the columns can be
understood as follows:

What (the inventory column): Entities used to build the architecture

How (the process column): Activities performed

Where (the distribution column): Business location and technology location

Who (the responsibility column): Roles and organizations

When (the timing column): Intervals, events, cycles, and schedules

Why (the motivation column): Goals, strategies, and means

13
the rows:
The executive perspective (business context): Lists of business elements defining scope in identification models.

The business management perspective (business concepts): Clarification of the relationships between business concepts
defined by Executive Leaders as Owners in definition models.

The architect perspective (business logic): System logical models detailing system requirements and unconstrained design
represented by Architects as Designers in representation models.

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.

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.

The user perspective (operations classes): Actual functioning instances used by Workers as Participants. There are no models
in this perspective.

14
Enterprise Data Architecture

Enterprise Data Architecture defines standard terms and designs for the
elements that are important to the organization. The design of an
Enterprise Data Architecture includes depiction of the business data as
such, including the collection, storage, integration, movement, and
distribution of data.

As data flows in an organization through feeds or interfaces, it is

secured, integrated, stored, recorded, catalogued, shared, reported on,
analyzed, and delivered to stakeholders. Along the way, the data may
be verified, enhanced, linked, certified, aggregated, anonymized, and
used for analytics until archived or purged.
15
The Enterprise Data Architecture descriptions must include both Enterprise Data
Models (e.g., data structures and data specifications), as well as Data Flow Design:

Enterprise Data Model (EDM): The EDM is a holistic, enterprise-level, implementation-independent

conceptual or logical data model providing a common consistent view of data across the enterprise. Itis
common to use the term to mean a high-level, simplified data model, but that is a question of abstraction for
presentation. An EDM includes key enterprise data entities (i.e., business concepts),their relationships,
critical guiding business rules, and some critical attributes. It sets forth the foundation for all data and data-
related projects. Any project-level data model must be based on the EDM. The EDM should be reviewed by
stakeholders, so that there is consensus that it effectively represents the enterprise.

Data Flow Design: Defines the requirements and master blueprint for storage and processing across
databases, applications, platforms, and networks (the components). These data flows map the movement of
data to business processes, locations, business roles, and to technical components.

16
17
18
Data Flow Design

Data flows are a type of data lineage documentation that depicts how data moves
through business processes and systems. End-to-end data flows illustrate where
the data originated, where it is stored and used, and how it is transformed as it
moves inside and between diverse processes and systems. Data lineage analysis
can help explain the state of data at a given point in the data flow.

Product PlatformProductProduct PartMarket OfferingPortfolioSales ItemSales

BundleBill-of-material (BOM)Sales OrderSales Order ItemProduct
GroupPartStructureProduct Design Bill-of-material (BOM)Belongs toUsesOffering
RangeOccurs inSpecifiesDetailsProduct Design Subject AreaCommercial Offer
Subject AreaSales Subject AreaSales Order Item Configuration

19
20
21
Activities
Data and enterprise architecture deal with complexity from two
viewpoints:

Quality-oriented: Focus on improving execution within business and IT

development cycles. Unless architecture is managed, architecture will deteriorate.
Systems will gradually become more complex and inflexible, creating risk for an
organization. Uncontrolled data delivery, data copies, and interface 'spaghetti’
relationships make organizations less efficient and reduce trust in the data.

•Innovation-oriented: Focus on transforming business and IT to address new

expectations and opportunities. Driving innovation with disruptive technologies
and data uses has become a role of the modern Enterprise Architect.

22
An Enterprise Data Architecture practice generally includes the
following work streams, executed serially or in parallel:

Strategy: Select frameworks, state approaches, develop roadmap

Acceptance and culture: Inform and motivate changes in behavior

Organization: Organize Data Architecture work by assigning accountabilities and responsibilities

Working methods: Define best practices and perform Data Architecture work within development projects, in coordination
with Enterprise Architecture

Results: Produce Data Architecture artefacts within an overall roadmap

23
Enterprise Data Architecture also influences the
scope boundaries of projects and system
releases:

Enforcing Data Architecture

standards: Formulating and
Determining data lineage
Defining project data enforcing standards for the
impact: Ensures that
requirements: Data Enterprise Data Architecture
business rules in the
Architects provide enterprise lifecycle. Standards can be
applications along the data
data requirements for expressed as principles and
flow are consistent and
individual projects. procedures, guidelines and as
traceable.
well as blueprints with
compliance expectations.

Data replication control:

Replication is a common way to
Reviewing project data improve application performance
designs: Design reviews and make data more readily Guide data technology and
ensure that conceptual, available, but it can also create renewal decisions: The Data
logical, and physical data inconsistencies in the data. Data
Architect works with
models are consistent with Architecture governance ensures
that sufficient replication control Enterprise Architects to
architecture and in support of
(methods and mechanisms) are manage data
long-term organizational
strategy. in place to achieve required
consistency. (Not all applications
need strict consistency.)

24
25