Jump to content

Data architecture

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by GUS JOHN GEORGE (talk | contribs) at 20:05, 14 February 2006 (New article: Data Architecture). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

Data architecture is a term used to describe the scheme by which data is stored, processed, accessed, and otherwise managed by the entity that has ownership of the data. Data architecture also 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 physical data processing related computer hardware. For example, the data architecture of an information system is not the same as a technology plan. As its name implies, the technology plan is focused on the actual physical elements to be used in the implementation of the data architecture design.

Data architecture should not be confused with database architecture. Database architecture is a schema of the actual database technology that will support the designed data architecture.


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 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.


The Forces at Work

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 will generally include such elements as economical and effective system expansion, acceptable performance (access speed) level, transaction reliability, and transparent management of data. In addition, the conversion of data to information through such features as data warehouses is also a common organizational requirement.

Technology drivers 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 are also important factors that must be considered during the data architecture phase. It is possible that some solutions, while optimal, 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 purchase decisions relevant to data architecture requirements.

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 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).


Sources

Achieving Usability Through Software Architecture Bass, L.; John, B.; & Kates, J.

Enterprise Information System Data Architecture Guide, An Lewis, G.; Comella-Dorda, S.; Place, P.; Plakosh, D.; & Seacord, R.


Achieving Usability Through Software Architecture http://www.sei.cmu.edu/publications/documents/01.reports/01tr005.html

Enterprise Information System Data Architecture Guide, An http://www.sei.cmu.edu/publications/documents/01.reports/01tr018.html