![Data Architecture in enterprise architecture is the design of data for use in defining the
target state and the subsequent planning needed to achieve the target state. It is usually one of
several architecture domains that form the pillars of an enterprise architecture or solution
architecture.
Contents
[hide]
1 Overview
2 Data Architecture Topics
o 2.1 Physical data architecture
o 2.2 Elements of data architecture
o 2.3 Constraints and influences
3 See also
4 References
5 Further reading
6 External links
[edit] Overview
A data architecture describes the data structures used by a business and/or its applications.
There are descriptions of data in storage and data in motion; descriptions of data stores, data
groups and data items; and mappings of those data artifacts to data qualities, applications,
locations etc.
Essential to realizing the target state, Data Architecture describes how data is processed,
stored, and utilized in a given system. It provides criteria for data processing operations that
make it possible to design data flows and also control the flow of data in the system.
The Data Architect is responsible for defining the target state, alignment during development
and then minor follow up to ensure enhancements are done in the spirit of the original
blueprint.
During the definition of the target state, the Data Architecture breaks a subject down to the
atomic level and then builds it back up to the desired form. The Data Architect breaks the
subject down by going through 3 traditional 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.
The "data" column of the Zachman Framework for enterprise architecture –
Layer View Data (What) Stakeholder
List of things important to the
1 Scope/Contextual Planner
business (subject areas)](https://image.slidesharecdn.com/dataarchitectureinenterprisearchitectureisthedesignofdataforuseindefiningthetargetstateandthesubsequentplanningneededtoachievethetargetstate-120305003728-phpapp02/85/Data-architecture-in-enterprise-architecture-is-the-design-of-data-for-use-in-defining-the-target-state-and-the-subsequent-planning-needed-to-achieve-the-target-state-1-320.jpg)
![Semantic model or
2 Business Model/Conceptual Owner
Conceptual/Enterprise Data Model
3 System Model/Logical Enterprise/Logical Data Model Designer
4 Technology Model/Physical Physical Data Model Builder
Detailed Representations/
5 Data Definition Subcontractor
out-of-context
In this second, broader sense, data architecture includes a complete analysis of the
relationships between an organization's functions, available technologies, and data types.
Data architecture should be defined in the planning phase of the design of a new data
processing and storage system. The major types and sources of data necessary to support an
enterprise should be identified in a manner that is complete, consistent, and understandable.
The primary requirement at this stage is to define all of the relevant data entities, not to
specify computer hardware items. A data entity is any real or abstracted thing about which an
organization or individual wishes to store data.
[edit] Data Architecture Topics
[edit] Physical data architecture
Physical data architecture of an information system is part of a technology plan. As its name
implies, the technology plan is focused on the actual tangible elements to be used in the
implementation of the data architecture design. Physical data architecture encompasses
database architecture. Database architecture is a schema of the actual database technology
that will support the designed data architecture.
[edit] Elements of data architecture
There are certain elements that must be defined as the data architecture schema of an
organization is designed. For example, the administrative structure that will be established in
order to manage the data resources must be described. Also, the methodologies that will be
employed to store the data must be defined. In addition, a description of the database
technology to be employed must be generated, as well as a description of the processes that
will manipulate the data. It is also important to design interfaces to the data by other systems,
as well as a design for the infrastructure that will support common data operations (i.e.
emergency procedures, data imports, data backups, external transfers of data).
Without the guidance of a properly implemented data architecture design, common data
operations might be implemented in different ways, rendering it difficult to understand and
control the flow of data within such systems. This sort of fragmentation is highly undesirable
due to the potential increased cost, and the data disconnects involved. These sorts of
difficulties may be encountered with rapidly growing enterprises and also enterprises that
service different lines of business (e.g. insurance products).
Properly executed, the data architecture phase of information system planning forces an
organization to specify and delineate both internal and external information flows. These are
patterns that the organization may not have previously taken the time to conceptualize. It is](https://image.slidesharecdn.com/dataarchitectureinenterprisearchitectureisthedesignofdataforuseindefiningthetargetstateandthesubsequentplanningneededtoachievethetargetstate-120305003728-phpapp02/85/Data-architecture-in-enterprise-architecture-is-the-design-of-data-for-use-in-defining-the-target-state-and-the-subsequent-planning-needed-to-achieve-the-target-state-2-320.jpg)
![therefore possible at this stage to identify costly information shortfalls, disconnects between
departments, and disconnects between organizational systems that may not have been evident
before the data architecture analysis.
[edit] Constraints and influences
Various constraints and influences will have an effect on data architecture design. These
include enterprise requirements, technology drivers, economics, business policies and data
processing needs.
Enterprise requirements
These will generally include such elements as economical and effective system
expansion, acceptable performance levels (especially system access speed),
transaction reliability, and transparent management of data. In addition, the
conversion of raw data such as transaction records and image files into more useful
information forms through such features as data warehouses is also a common
organizational requirement, since this enables managerial decision making and other
organizational processes. One of the architecture techniques is the split between
managing transaction data and (master) reference data. Another one is splitting data
capture systems from data retrieval systems (as done in a Data warehouse).
Technology drivers
These are usually suggested by the completed data architecture and database
architecture designs. In addition, some technology drivers will derive from existing
organizational integration frameworks and standards, organizational economics, and
existing site resources (e.g. previously purchased software licensing).
Economics
These are also important factors that must be considered during the data architecture
phase. It is possible that some solutions, while optimal in principle, may not be
potential candidates due to their cost. External factors such as the business cycle,
interest rates, market conditions, and legal considerations could all have an effect on
decisions relevant to data architecture.
Business policies
Business policies that also drive data architecture design include internal
organizational policies, rules of regulatory bodies, professional standards, and
applicable governmental laws that can vary by applicable agency. These policies and
rules will help describe the manner in which enterprise wishes to process their data.
Data processing needs
These include accurate and reproducible transactions performed in high volumes, data
warehousing for the support of management information systems (and potential data
mining), repetitive periodic reporting, ad hoc reporting, and support of various
organizational initiatives as required (i.e. annual budgets, new product development](https://image.slidesharecdn.com/dataarchitectureinenterprisearchitectureisthedesignofdataforuseindefiningthetargetstateandthesubsequentplanningneededtoachievethetargetstate-120305003728-phpapp02/85/Data-architecture-in-enterprise-architecture-is-the-design-of-data-for-use-in-defining-the-target-state-and-the-subsequent-planning-needed-to-achieve-the-target-state-3-320.jpg)
Data architecture in enterprise architecture is the design of data for use in defining the target state and the subsequent planning needed to achieve the target state
- 1. Data Architecture in enterprise architecture is the design of data for use in defining the target state and the subsequent planning needed to achieve the target state. It is usually one of several architecture domains that form the pillars of an enterprise architecture or solution architecture. Contents [hide] 1 Overview 2 Data Architecture Topics o 2.1 Physical data architecture o 2.2 Elements of data architecture o 2.3 Constraints and influences 3 See also 4 References 5 Further reading 6 External links [edit] Overview A data architecture describes the data structures used by a business and/or its applications. There are descriptions of data in storage and data in motion; descriptions of data stores, data groups and data items; and mappings of those data artifacts to data qualities, applications, locations etc. Essential to realizing the target state, Data Architecture describes how data is processed, stored, and utilized in a given system. It provides criteria for data processing operations that make it possible to design data flows and also control the flow of data in the system. The Data Architect is responsible for defining the target state, alignment during development and then minor follow up to ensure enhancements are done in the spirit of the original blueprint. During the definition of the target state, the Data Architecture breaks a subject down to the atomic level and then builds it back up to the desired form. The Data Architect breaks the subject down by going through 3 traditional 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. The "data" column of the Zachman Framework for enterprise architecture – Layer View Data (What) Stakeholder List of things important to the 1 Scope/Contextual Planner business (subject areas)
- 2. Semantic model or 2 Business Model/Conceptual Owner Conceptual/Enterprise Data Model 3 System Model/Logical Enterprise/Logical Data Model Designer 4 Technology Model/Physical Physical Data Model Builder Detailed Representations/ 5 Data Definition Subcontractor out-of-context In this second, broader sense, data architecture includes a complete analysis of the relationships between an organization's functions, available technologies, and data types. Data architecture should be defined in the planning phase of the design of a new data processing and storage system. The major types and sources of data necessary to support an enterprise should be identified in a manner that is complete, consistent, and understandable. The primary requirement at this stage is to define all of the relevant data entities, not to specify computer hardware items. A data entity is any real or abstracted thing about which an organization or individual wishes to store data. [edit] Data Architecture Topics [edit] Physical data architecture Physical data architecture of an information system is part of a technology plan. As its name implies, the technology plan is focused on the actual tangible elements to be used in the implementation of the data architecture design. Physical data architecture encompasses database architecture. Database architecture is a schema of the actual database technology that will support the designed data architecture. [edit] Elements of data architecture There are certain elements that must be defined as the data architecture schema of an organization is designed. For example, the administrative structure that will be established in order to manage the data resources must be described. Also, the methodologies that will be employed to store the data must be defined. In addition, a description of the database technology to be employed must be generated, as well as a description of the processes that will manipulate the data. It is also important to design interfaces to the data by other systems, as well as a design for the infrastructure that will support common data operations (i.e. emergency procedures, data imports, data backups, external transfers of data). Without the guidance of a properly implemented data architecture design, common data operations might be implemented in different ways, rendering it difficult to understand and control the flow of data within such systems. This sort of fragmentation is highly undesirable due to the potential increased cost, and the data disconnects involved. These sorts of difficulties may be encountered with rapidly growing enterprises and also enterprises that service different lines of business (e.g. insurance products). Properly executed, the data architecture phase of information system planning forces an organization to specify and delineate both internal and external information flows. These are patterns that the organization may not have previously taken the time to conceptualize. It is
- 3. therefore possible at this stage to identify costly information shortfalls, disconnects between departments, and disconnects between organizational systems that may not have been evident before the data architecture analysis. [edit] Constraints and influences Various constraints and influences will have an effect on data architecture design. These include enterprise requirements, technology drivers, economics, business policies and data processing needs. Enterprise requirements These will generally include such elements as economical and effective system expansion, acceptable performance levels (especially system access speed), transaction reliability, and transparent management of data. In addition, the conversion of raw data such as transaction records and image files into more useful information forms through such features as data warehouses is also a common organizational requirement, since this enables managerial decision making and other organizational processes. One of the architecture techniques is the split between managing transaction data and (master) reference data. Another one is splitting data capture systems from data retrieval systems (as done in a Data warehouse). Technology drivers These are usually suggested by the completed data architecture and database architecture designs. In addition, some technology drivers will derive from existing organizational integration frameworks and standards, organizational economics, and existing site resources (e.g. previously purchased software licensing). Economics These are also important factors that must be considered during the data architecture phase. It is possible that some solutions, while optimal in principle, may not be potential candidates due to their cost. External factors such as the business cycle, interest rates, market conditions, and legal considerations could all have an effect on decisions relevant to data architecture. Business policies Business policies that also drive data architecture design include internal organizational policies, rules of regulatory bodies, professional standards, and applicable governmental laws that can vary by applicable agency. These policies and rules will help describe the manner in which enterprise wishes to process their data. Data processing needs These include accurate and reproducible transactions performed in high volumes, data warehousing for the support of management information systems (and potential data mining), repetitive periodic reporting, ad hoc reporting, and support of various organizational initiatives as required (i.e. annual budgets, new product development