Data architecture: Difference between revisions

Revision as of 21:56, 31 October 2016

Latest revision as of 23:21, 29 August 2025

(43 intermediate revisions by 33 users not shown)

Line 1:

{{Short description|Standards on data collection and storage}}

{{Refimprove|date=November 2008}}

In [[information technology]], '''dataData architecture''' is composedconsist of models, policies, rules, orand standards that govern which [[data]] is collected, and how it is stored, arranged, integrated, and put to use in data systems and in organizations.<ref>[http://www.businessdictionary.com/definition/data-architecture.html Business Dictionary - Data Architecture] {{Webarchive|url=https://web.archive.org/web/20130330185324/http://www.businessdictionary.com/definition/data-architecture.html |date=2013-03-30 }}; [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap09.html TOGAF 9.1 - Phase C: Information Systems Architectures - Data Architecture]</ref> Data is usually one of several [[architecture ___domain]]s that form the pillars of an [[enterprise architecture]] or [[solution architecture]].<ref>[http://www.learn.geekinterview.com/data-warehouse/data-architecture/what-is-data-architecture.html What is data architecture] GeekInterview, 2008-01-28, accessed 2011-04-28</ref>

== Overview ==

A data architecture should{{POVaims statement|date=March 2013}}to set data standards for all its data systems as a vision or a model of the eventual interactions between those data systems. [[Data integration]], for example, should be dependent upon data architecture standards since data integration requires data interactions between two or more data systems. A data architecture, in part, describes the [[data structure]]s used by a business and its computer [[applications software]]. Data architectures address data in storage, data in use, and data in motion; descriptions of data stores, data groups, and data items; and [[data mapping|mappings]] of those data artifacts to data qualities, applications, locations, etc.

Essential to realizing the target state, Datadata Architecturearchitecture describes how data is processed, stored, and utilizedused in an [[information system]]. It provides criteria for [[data processing]] operations so as to make it possible to design [[data flow]]s and also control the flow of data in the system.

The [[data architect]] is typically responsible for defining the target state, aligning during development and then following up to ensure enhancements are done in the spirit of the original blueprint.

During the definition of the target state, the Datadata Architecturearchitecture 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 3three traditional architectural processesstages:

* Conceptual - represents all [[Business object|business entities]].

* Logical - represents the logic of how entities are related.

* Physical - the realization of the data mechanisms for a specific type of functionality.

Line 16 ⟶ 17:

The "data" column of the [[Zachman Framework]] for enterprise architecture &ndash;

{| class="wikitable"

{| border=1

|'''! Layer''' ||!! '''View''' ||!! '''Data (Whatwhat)''' ||!! '''Stakeholder'''

|-

|1 || '''Scope/Contextualcontextual''' || List of things and architectural standards<ref>[https://web.archive.org/web/20160305023946/http://www.strins.com/data-architecture-standards.html Data Architecture Standards]</ref> important to the business || Planner

|-

|2||'''Business Modelmodel/Conceptualconceptual''' || Semantic model or [[Entity-relationshipConceptual modelschema|Conceptualconceptual]]/[http://tdan.com/the-[enterprise- data- model/5205 Enterprise Data Model]] || Owner

|-

|3||'''System Modelmodel/Logicallogical''' || Enterprise/[[Logicallogical data model|Logical Data Model]] || Designer

|-

|4||'''Technology Modelmodel/Physicalphysical''' || [[Physical data model|Physical Data Model]] || Builder

|-

|5||'''Detailed Representationsrepresentations''' || Actual [[database]]s || SubcontractorDeveloper

|}

In this second, broader sense, data architecture includes a complete analysis of the relationships among an organization's functions, available [[technologies]], and [[data type]]s.

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 abstractedabstract thing about which an organization or individual wishes to store data.

== Physical data architecture ==

Physical data architecture of an information system is part of a [[Technology roadmapping|technology plan]]. As its name implies, theThe technology plan is focused on the actual tangible [[element (mathematics)|elements]] to be used in the implementation of the data architecture [[design]]. Physical data architecture encompasses database architecture. Database architecture is a [[Model (abstract)|schema]] of the actual database technology that willwould support the designed data architecture.

== Elements of data architecture ==

Certain elements must be defined during the design phase of the data architecture schema. For example, an administrative structure that willis to be established in order to manage the data resources must be described. Also, the methodologies that willare to 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 willare to manipulate the data. It is also important to design [[interface (computing)|interfaces]] to the data by other systems, as well as a design for the [[infrastructure]] that willis to support common data operations (i.e. emergency procedures, [[data import]]s, [[data backup]]s, external [[data transfer|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]] [[Product (business)|products]]).

Properly executed, the data architecture phase of information system planning forces an organization to precisely specify and describe both internal and external information flows. These are patterns that the organization may not have previously taken the time to conceptualize. It is 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.<ref>{{cite book|last=Mittal|first=Prashant|title=Author|year=2009|publisher=Global India Publications|___location=pg 256|isbn=978-93-8022-820-4|pages=314|url=https://books.google.com/books?id=BpkhYDj4tm0C&dq=inauthor:%22PRASHANT+MITTAL%22&source=gbs_navlinks_s}}</ref>

== 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), [[Financial transaction|transaction]] reliability, and transparent [[data management]]. In addition, the [[Data conversion|conversion]] of raw data such as transaction [[Record (computer science)|records]] and [[image]] [[Computer file|files]]s into more useful [[information]] forms through such features as [[data warehouse]]s 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 [[Automatic identification and data capture|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]]). In many cases, the integration of multiple legacy systems requires the use of [[data virtualization]] technologies.

; 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 agency|regulatory bodies]], professional standards, and applicable governmental [[laws]] that can vary by applicable [[government agency|agency]]. These policies and rules will help describe the manner in which the enterprise wishes to process theirits data.

; Data processing needs: These include accurate and reproducible [[data transaction|transactions]] performed in high volumes, data warehousing for the support of management information systems (and potential [[data mining]]), repetitive periodic [[Data reporting|reporting]], ad hoc reporting, and support of various organizational initiatives as required (i.e. annual budgets, new [[Product (business)|product]] development).

== See also ==

* [[Enterprise Information Security Architecture]] - (EISA) positions data security in the enterprise information framework.

* [[FDIC Enterprise Architecture Framework]]

* [[Controlled vocabulary]]

* [[Data mesh]], a ___domain-oriented data architecture

* [[Information silo]]

* [[Disparate system]]

* [[Enterprise Informationinformation Securitysecurity Architecturearchitecture]] - (EISA) – positions data security in the enterprise information framework.

* [[Data Warehouse]]

* [[FDIC Enterprise Architecture Framework]]

* [[Information silo]]

* [[TOGAF]]

== References ==

Line 77 ⟶ 79:

* [http://www.sei.cmu.edu/library/abstracts/reports/01tr005.cfm Achieving Usability Through Software Architecture], sei.cmu.edu 2001

* [http://sunsite.uakom.sk/sunworldonline/swol-07-1998/swol-07-itarchitect.html The Logical Data Architecture], by Nirmal Baid

* [https://community.hpe.com/t5/Infrastructure-Insights/Building-a-modern-data-and-analytics-architecture/ba-p/7051366 Building a modern data and analytics architecture]

* [https://medium.com/data-ops/the-right-to-repair-data-architecture-with-dataops-48ea79361f2c The “Right to Repair” Data Architecture with DataOps], the DataOps Blog

* [https://www.technoblink.com/useful-guide-for-earning-the-open-group-togaf-9-certification/ TOGAF 9: Preparation Process]

{{Data model}}

[[Category:Computer data]]

[[Category:Data managementengineering]]

[[Category:Enterprise architecture]]