Jump to content

Architecture domain

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by RussBot (talk | contribs) at 15:56, 19 June 2009 (Robot-assisted fix links to disambiguation page Enterprise). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Structure of the "Federal Enterprise Architecture Framework" (FEAF), presented in 2001, which determined four architectural domains.[1]

An architecture domain in enterprise architecture is a broad view of an enterprise or system. It is a partial representation of a whole system that addresses several concerns of several stakeholders. It is a description that hides other views or facets of the system described.

Overview

In the context of the creation of enterprise architecture it is common, according to Péter Bernus (2005)[2], to recognise three or four types of architecture, each corresponding to its particulair domain. Examples of such domains are Business architecture, Information systems architecture, often subdivided into Data and Application architecture) and Technology architecture. Architectural domains are a structuring criterion for a collection of architecture products. They should not be confused with the application domain of the framework as such.[2]

Typical architecture domains

Typical architecture domains are summarised below, along the lines described in several sources:[3]

  • Business architecture: The structure and behaviour of a business system (not necessarily related to computers). Covers business goals, business functions or capabilities, business processes and roles etc. Business functions and business processes are often mapped to the applications and data they need.
  • Data architecture: The data structures used by a business and/or its applications. Descriptions of data in storage and data in motion. Descriptions of data stores, data groups and data items. Mappings of those data artifacts to data qualities, applications, locations etc.
  • Applications architecture: The structure and behaviour of applications used in a business, focused on how they interact with each other and with users. Focused on the data consumed and produced by applications rather than their internal structure. In application portfolio management, the applications are usually mapped to business functions and to application platform technologies.
Application (or Component) architecture: The internal structure, the modularisation of software, within an application. This is software architecture at the lowest level of granularity, as in reference 3. It is usually below the level of modularisation that solution architects define. However, there is no rigid dividing line.
  • Technical architecture or infrastructure architecture: The structure and behaviour of the technology infrastructure. Covers the client and server nodes of the hardware configuration, the infrastructure applications that run on them, the infrastructure services they offer to applications, the protocols and networks that connect applications and nodes.

See also

References

  1. ^ Chief Information Officer Council (2001) A Practical Guide to Federal Enterprise Architecture. Feb 2001.
  2. ^ a b Péter Bernus (2005). Knowledge Sharing in the Integrated Enterprise. p.133-139.
  3. ^ Several sources name a series of architecture domains, for example:
    • The "Open Reference Model for Enterprise and Solution Architects" used in the Avancier Method.
    • The FEAF
    • TOGAF (The Open Group Architecture Framework).