Content deleted Content added
Citation bot (talk | contribs) m [430]Combined duplicate references. User-activated. |
m WP:CHECKWIKI error fix for #61. Punctuation goes before References. Do general fixes if a problem exists. - using AWB (9369) |
||
Line 1:
[[File:NIST Enterprise Architecture Model.jpg|thumb|NIST Enterprise Architecture Model.]]
'''NIST Enterprise Architecture Model''' ('''NIST EA Model''') is a late 1980s [[Enterprise Architecture framework|reference model]] for [[Enterprise Architecture]], which defines the content of an enterprise architecture<ref name ="CIO 2001">Chief Information Officer Council (2001) ''[http://www.gao.gov/assets/590/588407.pdf A Practical Guide to Federal Enterprise Architecture Version 1.0]'' Preface. February 2001.
Developed late 1980s by the [[National Institute of Standards and Technology]] (NIST) and others, this reference model in the 1990s is widely promoted within the [[Federal government of the United States|U.S. federal government]] as Enterprise Architecture management tool.<ref name="CIOC99"/>
== Overview ==
Line 11:
* Data Architecture suggests specific data delivery systems, and
* Data Delivery Systems (Software, Hardware, Communications) support the data architecture.
The hierarchy in the model is based on the notion that an organization operates a number of business functions, each function requires information from a number of source, and each of these sources may operation one or more operation systems, which in turn contain data organized and stored in any number of data systems.<ref>John O'Looney (2002). ''Wiring Governments: Challenges and Possibilities for Public Managers''. Greenwood Publishing Group. p.67.</ref>
== History ==
The NIST Enterprise Architecture Model is initiated in 1988 in the fifth workshop on Information Management Directions sponsored by the NIST in cooperation with the [[Association for Computing Machinery]] (ACM), the [[IEEE Computer Society]], and the Federal Data Management Users Group (FEDMUG). The results of this research project were published as the NIST Special Publication 500-167, ''Information Management Directions: The Integration Challenge''.<ref name="FG89">
=== The emerging field of information management ===
With the proliferation of [[information technology]] starting in the 1970s, the job of [[information management]] had taken a new light, and also began to include the field of [[data maintenance]]. No longer was information management a simple job that could be performed by almost anyone. An understanding of the technology involved, and the theory behind it became necessary. As [[information storage]] shifted to electronic means, this became more and more difficult.
In this emerging field the NIST had held a series of four workshops on Database and Information Management Directions since the 1970s. Each of the workshops addresses a specific theme:<ref>Fong and Goldfine (1989, p. 5)
* "What information about [[database]] technology does the manager need to make prudent decisions about using new technology", in 1975.
* "What information can help a manager assess the impact on a database system?" in 1977.
Line 25:
* "The nature of information [[resource management]] practice and problems" in 1985.
The fifth workshop in 1989 was held by the National Computer Systems Laboratory (NCSL) of the NIST. By then this was one of the four institutes, that performed the technical work of the NIST. The specific goal of the NCSL was to conduct research and provide scientific and technical services to aid Federal agencies in the selection, acquisition, application, and use of computer technology.<ref>Fong and Goldfine (1989, p. i)</ref>
=== NIST workshop on Information Management Directions ===
The fifth Information Management Directions workshop focused on integration and productivity in [[information management]]. Five working groups considered specific aspects of the integration of knowledge, [[data management]], systems planning, development and maintenance, computing environments, architectures and standards. Participants came from academia, industry, government and consulting firms. Among the 72 participants were [[Tom DeMarco]], [[Ahmed K. Elmagarmid]], Elizabeth N. Fong, Andrew U. Frank,<ref>[http://www.geoinfo.tuwien.ac.at/staff/index.php?Current_Staff:Frank%2C_Andrew_U. Frank, Andrew U.] Research Group Geoinformation, Vienna. Accessed JUly 15, 2013.</ref>
Tom DeMarco delivered the keynote speech, claiming that standards do more harm than good when they work against the prevailing culture, and that the essence of standardization is discovery, not innovation.<ref>Fong and Goldfine (1989, p. ix)</ref> The five working groups met to discuss different aspects of integration:
Line 38:
In the third working group on systems planning was chaired by [[John Zachman]], and adopted the [[Zachman Framework]] as a basis for discussion.
[[File:NIST AE model 1989.jpg|thumb|Model of Enterprise Architecture, 1989]]
The fifth working group on architectures and standards was chaired W. Bradford Rigdon of the McDonnell Douglas Information Systems Company (MDISC), a division of [[McDonnell Douglas]]. Rigdon et al. (1989) <ref name="WBR 1989" >W. Bradford Rigdon (1989) "Architectures and Standards". In: ''Information Management Directions: The Integration Challenge''. E.N. Fong and A.H. Goldfine (eds.). NIST Sept 1989. p. 135-150</ref> explained that discussions about architecture in that time mostly focus on technology concerns. Their aim was to "takes a broader view, and describes the need for an ''enterprise architecture'' that includes an emphasis on business and information requirements. These higher level issues impact data and technology architectures and decisions."<ref name="Rigdon">Rigdon (1989), p. 136</ref> In order to do so, the working group addressed three issues:<ref>Fong and Goldfine (1989, p. 136)</ref>
* The levels of architecture in an enterprise
* Problems addressed by architecture
Line 45:
=== Application in the 1990s ===
In a way the NIST Enterprise Architecture Model was ahead of his time. According to Zachman (1993) in the 1980s the "architecture" was acknowledged as a topic of interest, but there was still little consolidated theory concerning this concept.<ref>J.A Zachman (1993) ''[http://www.ies.aust.com/pdf-papers/zachman3.pdf Concepts for Framework for EA - Enterprise Architecture Resources]''. Zachman International, Inc. paper. p. 1</ref> [[Software architecture]], for example. become an important topic not until the second half of the nineties.<ref>Leonor Barroca, Jon Hall and Patrick Hall (200) "[http://mcs.open.ac.uk/lmb3/introduction.pdf An Introduction and History of Software Architectures, Components, and Reuse]" in: ''Software Architectures'', 2000 p. 1</ref>
To support the NIST Enterprise Architecture Model in the 1990s, it was widely promoted within the [[Federal government of the United States|U.S. federal government]] as Enterprise Architecture management tool.<ref name="CIOC99"/>
== NIST Enterprise Architecture Model topics ==
=== Foundations ===
According to Rigdon et al. (1989) an architecture is "a clear representation of a conceptual framework of components and their relationship at a point in time".<ref>
In order to develop an enterprise architecture Rigdon acknowledge:<ref name="Rigdon" />
* There are multiple ways to develop an architecture
* There are multiple ways to implement standards
Line 62 ⟶ 63:
The separate levels of an enterprise architecture are interrelated in a special way. On every level the architectures assumes or dictates the architectures at the higher level. The illustration on the right gives an example of which elements can constitute an Enterprise Architecture.
[[File:Sample Elements of an Enterprise Architecture (1989).jpg|thumb|Sample elements of an Enterprise Architecture (1989).]]
=== Levels of architecture ===
Each layer of architecture in the model has a specific intention:<ref>
* Business Architecture level: This level can picture the total or a subunit of any corporation, which are in contact with external organizations.
* Information architecture level: This level specifies types of content, presentation forms, and format of the information required.
Line 69 ⟶ 71:
* Data Architecture level: Framework for maintenance, access and use of data, with data dictionary and other naming conventions.
* Data Delivery Systems level: Technical implementation level of software, hardware, and communications that support the data architecture.
A sample elements of how the [[Enterprise Architecture]] can be described in more detail is shown in the illustration.
=== Information Technology Architecture ===
Line 75 ⟶ 77:
:''The Enterprise Architecture is the explicit description of the current and desired relationships among business and management process and information technology. It describes the "target" situation which the agency wishes to create and maintain by managing its IT portfolio.''
:''The documentation of the Enterprise Architecture should include a discussion of principles and goals.<ref>Examples of published architectural "frameworks" include the [[Treasury Information System Architecture Framework]] (TISAF), the US Department of Defense [[Technical Architecture Framework for Information Management]] (TAFIM), and the [[:commons:Category:
In this guidance the five component model of the NIST was adopted and further explained. Agencies were permitted to identify different components as appropriate and to specify the organizational level at which specific aspects of the components will be implemented. Although the substance of these components, sometimes called "architectures" or "sub-architectures," must be addressed in every agency's complete Enterprise Architecture, agencies have great flexibility in describing, combining, and renaming the components, which consist of:<ref name="M-97-16"/>
* ''Business Processes'': This component of the Enterprise Architecture describes the core business processes which support the organization's missions. The Business Processes component is a high-level analysis of the work the agency performs to support the organizations's mission, vision, and goals, and is the foundation of the ITA. Analysis of the business processes determine the information needed and processed by the agency. This aspect of the ITA must be developed by senior program managers in conjunction with IT managers. Without a thorough understanding of its business processes and their relation to the agency missions, the agency will not be able to use its ITA effectively. <br>Business processes can be described by decomposing the processes into derivative business activities. There are a number of methodologies and related tools available to help agencies decompose processes. Irrespective of the tool used, the model should remain at a high enough level to allow a broad agency focus, yet sufficiently detailed to be useful in decision-making as the agency identifies its information needs. Agencies should avoid excessive emphasis on modeling business processes, which can result in a waste of agency resources.<ref>The US Department of Defense includes aspects of the Business Processes element in its Operational Architecture; the US Department of Treasury incorporates it into its business view.</ref>
* ''Information Flows and Relationships'': This component analyzes the information utilized by the organization in its business processes, identifying the information used and the movement of the information within the agency. The relationships among the various flows of information are described in this component. These information flows indicate where the information is needed and how the information is shared to support mission functions.<ref>The US Department of Agriculture has incorporated this component into its Business Architecture, while the US Department of Defense and Treasury have built it into their Operational Architectures.
* ''Applications'' : The Applications component identifies, defines, and organizes the activities that capture, manipulate, and manage the business information to support mission operations. It also describes the logical dependencies and relationships among business activities.<ref>The US Department of Energy incorporates Business Applications into its Applications Subarchitecture, while the US Department of Treasury includes them in its Functional Architecture.
* ''Data Descriptions'': This component of the Enterprise Architecture identifies how data is maintained, accessed, and used. At a high level, agencies define the data and and describe the relationships among data elements used in the agency's information systems. The Data Descriptions and Relationships component can include data models that describe the data underlying the business and information needs of the agency. Clearly representing the data and data relationships is important for identifying data that can be shared corporately, for minimizing redundancy, and for supporting new applications<ref>The US Department of Agriculture has included in this element in its Business/Data Architecture, while the US Department of Treasury incorporates it in its Information Architecture.
* ''Technology Infrastructure'' : The Technology Infrastructure component describes and identifies the physical layer including, the functional characteristics, capabilities, and interconnections of the hardware, software, and communications, including networks, protocols, and nodes. It is the "wiring diagram" of the physical IT infrastructure.<ref>The US Department of Agriculture had incorporated this architecture into its Technical Standard and Telecommunications Architectures. US DoD uses its System Architecture, and US Treasury its Infrastrucsture to describe the physical layer.
With the exception of the Business Processes component, the interrelationships among and priorities of these components are not prescribed by this guidance; there is no hierarchy of relationships implied. Furthermore, agencies should document not only their current environment for each of these components, but also the target environment that is desired.<ref name="M-97-16"/>
Line 95 ⟶ 97:
[[File:FDIC’s Enterprise Architecture Framework.jpg|thumb|FDIC EA Framework.<ref>OIG (2005). [http://www.fdicoig.gov/reports05/05-018-508.shtml Implementation of E-Government Principles]. May 2005</ref>]]
The NIST Framework was picked up by several U.S. federal agencies and used as the basis for their information strategy.<ref name="Zac06">[http://www.objectwatch.com/whitepapers/IASANewsletterApril2007.pdf "Exclusive Interview with John Zachman"] by Roger Sessions. In: ''Perspectives of the International Association of Software Architects''. April 2006.</ref> The reference model is applicated the following frameworks:
* [[United States Department of Energy|Department of Energy]] (DOE) Information Architecture <ref name="FAA98">
* [[FDIC Enterprise Architecture Framework]] is the Enterprise Architecture framework of the Federal Deposit Insurance Corporation (FDIC).
* [[Federal Enterprise Architecture Framework]] (FEAF) : The 1999 documentation of the [[Federal Enterprise Architecture Framework]] Version 1.1 explains how the NIST Framework is used as a foundation of the [[Federal Enterprise Architecture|FEA]] Framework.<ref name="CIOC99"/>
Line 111 ⟶ 113:
== External links ==
{{
[[Category:Enterprise architecture frameworks]]
| |||