NIST Enterprise Architecture Model

Last updated

NIST Enterprise Architecture Model. NIST Enterprise Architecture Model.jpg
NIST Enterprise Architecture Model.

NIST Enterprise Architecture Model (NIST EA Model) is a late-1980s reference model for enterprise architecture. It defines an enterprise architecture [1] by the interrelationship between an enterprise's business, information, and technology environments. [2]

Contents

Developed late-1980s by the National Institute of Standards and Technology (NIST) and others, the federal government of the United States promoted this reference model in the 1990s as the foundation for enterprise architectures of individual U.S. government agencies and in the overall federal enterprise architecture. [2]

Intro

The NIST Enterprise Architecture Model is a five-layered model for enterprise architecture, designed for organizing, planning, and building an integrated set of information and information technology architectures. The five layers are defined separately but are interrelated and interwoven. [2] The model defined the interrelation as follows: [3]

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 operate one or more operation systems, which in turn contain data organized and stored in any number of data systems. [4]

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. [3]

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. [3]

The notion of a three-schema model was first introduced in 1975 by the ANSI/X3/SPARC three level architecture, which determined three levels to model data. 4-2 ANSI-SPARC three level architecture.svg
The notion of a three-schema model was first introduced in 1975 by the ANSI/X3/SPARC three level architecture, which determined three levels to model data.

One of the first overall approaches to building information systems and systems information management from the 1970s was the three-schema approach. It proposes to use three different views in systems development, in which conceptual modelling is considered to be the key to achieving data integration: [6]

At the center, the conceptual schema defines the ontology of the concepts as the users think of them and talk about them. The physical schema according to Sowa (2004) "describes the internal formats of the data stored in the database, and the external schema defines the view of the data presented to the application programs". [7]

Since the 1970s the NIST had held a series of four workshops on Database and Information Management Directions. Each of the workshops addresses a specific theme: [8]

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. [9]

NIST workshop on Information Management Directions

The fifth Information Management Directions workshop in 1989 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, [10] Robert E. Fulton, [11] Alan H. Goldfine, [12] Dale L. Goodhue, [13] Richard J. Mayer, Shamkant Navathe, T. William Olle, W. Bradford Rigdon, Judith A. Quillard, Stanley Y. W. Su, [14] and John Zachman.

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. [15] The five working groups met to discuss different aspects of integration:

In the third working group on systems planning was chaired by John Zachman, and adopted the Zachman Framework as a basis for discussion.

Model of Enterprise Architecture, 1989 NIST AE model 1989.jpg
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) [16] 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." [17] In order to do so, the working group addressed three issues: [18]

To illustrate the levels of architecture, what has become known as the NIST Enterprise Architecture Model, was presented (see image). In this concept the three layers of the three-schema approach are divided into five layers.

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. [19] Software architecture, for example. become an important topic not until the second half of the nineties. [20]

To support the NIST Enterprise Architecture Model in the 1990s, it was widely promoted within the U.S. federal government as Enterprise Architecture management tool. [2] The NIST Enterprise Architecture Model is applied as foundation in multiple Enterprise Architecture frameworks of U.S. Federal government agencies and in the overall Federal Enterprise Architecture Framework. [2] In coordinating this effort the NIST model was further explained and extended in the 1997 "Memoranda 97-16 (Information Technology Architectures)" issued by the US Office of Management and Budget., [21] see further Information Technology Architecture.

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". [22] It may for example represent "a view of a current situation with islands of automation, redundant processes and data inconsistencies" [23] or a "future integrated automation information structure towards which the enterprise will move in a prescribed number on years." [24] The role of standards in architecture is to "enable or constrain the architecture and serve as its foundation". [23]

In order to develop an enterprise architecture Rigdon acknowledge: [17]

The different levels of an enterprise architecture can be visualized as a pyramid: On top the business unit of an enterprise, and at the bottom the delivery system within the enterprise. The enterprise can consist of one or more business units, working in specific business area. The five levels of architecture are defined as: Business Unit, Information, Information System, Data and Delivery System. [23]

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.

Sample elements of an Enterprise Architecture (1989). Sample Elements of an Enterprise Architecture (1989).jpg
Sample elements of an Enterprise Architecture (1989).

Levels of architecture

Each layer of architecture in the model has a specific intention: [25]

Some sample elements of how the Enterprise Architecture can be described in more detail is shown in the illustration.

Information Technology Architecture

The "Memoranda 97-16 (Information Technology Architectures)" gave the following definition of enterprise architecture: [21]

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. [Note 1] For example, the agency's overall management environment, including the balance between centralization and decentralization and the pace of change within the agency, should be clearly understood when developing the Enterprise Architecture. Within that environment, principles and goals set direction on such issues as the promotion of interoperability, open systems, public access, end-user satisfaction, and security.

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: [21]

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. [21]

Applications

FDIC EA Framework. FDIC's Enterprise Architecture Framework.jpg
FDIC EA Framework.

The NIST Framework was picked up by several U.S. federal agencies and used as the basis for their information strategy. [27] The reference model is applicated the following frameworks:

See also

Notes

  1. 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 Department of Energy's Information Architecture Volume 1.
  2. 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.
  3. 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.
  4. The US Department of Energy incorporates Business Applications into its Applications Subarchitecture, while the US Department of Treasury includes them in its Functional Architecture.
  5. 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.
  6. 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.

Related Research Articles

<span class="mw-page-title-main">Zachman Framework</span> Structure for enterprise architecture

The Zachman Framework is an enterprise ontology and is a fundamental structure for enterprise architecture which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two dimensional classification schema that reflects the intersection between two historical classifications. The first are primitive interrogatives: What, How, When, Who, Where, and Why. The second is derived from the philosophical concept of reification, the transformation of an abstract idea into an instantiation. The Zachman Framework reification transformations are: identification, definition, representation, specification, configuration and instantiation.

Enterprise architecture (EA) is a business function concerned with the structures and behaviours of a business, especially business roles and processes that create and use business data. The international definition according to the Federation of Enterprise Architecture Professional Organizations is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."

A federal enterprise architecture framework (FEAF) is the U.S. reference enterprise architecture of a federal government. It provides a common approach for the integration of strategic, business and technology management as part of organization design and performance improvement.

Data architecture consist of models, policies, rules, and standards that govern which data is collected and how it is stored, arranged, integrated, and put to use in data systems and in organizations. Data is usually one of several architecture domains that form the pillars of an enterprise architecture or solution architecture.

<span class="mw-page-title-main">Enterprise architecture framework</span> Frame in which the architecture of a company is defined

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models – typically matrices and diagrams – for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

<span class="mw-page-title-main">Enterprise modelling</span>

Enterprise modelling is the abstract representation, description and definition of the structure, processes, information and resources of an identifiable business, government body, or other large organization.

<span class="mw-page-title-main">John Zachman</span> American computer scientist

John A. Zachman is an American business and IT consultant, early pioneer of enterprise architecture, chief executive officer of Zachman International, and originator of the Zachman Framework.

Information Framework (IFW) is an enterprise architecture framework, populated with a comprehensive set of banking-specific business models. It was developed as an alternative to the Zachman Framework by Roger Evernden.

<span class="mw-page-title-main">Three-schema approach</span> Approach to building information systems

The three-schema approach, or three-schema concept, in software engineering is an approach to building information systems and systems information management that originated in the 1970s. It proposes three different views in systems development, with conceptual modelling being considered the key to achieving data integration.

<span class="mw-page-title-main">Enterprise life cycle</span> Process of changing an enterprise over time

Enterprise life cycle (ELC) in enterprise architecture is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance, disposition and disposal of existing elements of the enterprise.

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

<span class="mw-page-title-main">Business reference model</span>

Business reference model (BRM) is a reference model, concentrating on the functional and organizational aspects of the core business of an enterprise, service organization or government agency.

<span class="mw-page-title-main">Treasury Enterprise Architecture Framework</span>

Treasury Enterprise Architecture Framework (TEAF) was an enterprise architecture framework for treasury, based on the Zachman Framework. It was developed by the US Department of the Treasury and published in July 2000. May 2012 this framework has been subsumed by evolving Federal Enterprise Architecture Policy as documented in "The Common Approach to Federal Enterprise Architecture".

<span class="mw-page-title-main">FDIC Enterprise Architecture Framework</span>

FDIC Enterprise Architecture Framework was the enterprise architecture framework of the United States Federal Deposit Insurance Corporation (FDIC). A lot of the current article is about the enterprise architecture framework developed around 2005, and currently anno 2011 out-of-date.

<span class="mw-page-title-main">Enterprise architecture planning</span>

Enterprise architecture planning (EAP) in enterprise architecture is the planning process of defining architectures for the use of information in support of the business and the plan for implementing those architectures.

<span class="mw-page-title-main">TAFIM</span>

Technical Architecture Framework for Information Management (TAFIM) was a 1990s reference model for enterprise architecture by and for the United States Department of Defense (DoD).

<span class="mw-page-title-main">Treasury Information System Architecture Framework</span>

The Treasury Information System Architecture Framework (TISAF) is an early 1990s Enterprise Architecture framework to assist US Treasury Bureaus to develop their Enterprise Information System Architectures (EISAs).

<span class="mw-page-title-main">James G. Nell</span> American engineer (born 1938)

James G. "Jim" Nell is an American engineer. He was the principal investigator of the Manufacturing Enterprise Integration Project at the National Institute of Standards and Technology (NIST), and is known for his work on enterprise integration.

The history of business architecture has its origins in the 1980s. In the next decades business architecture has developed into a discipline of "cross-organizational design of the business as a whole" closely related to enterprise architecture. The concept of business architecture has been proposed as a blueprint of the enterprise, as a business strategy, and also as the representation of a business design.

Warren Bradford "Brad" Rigdon is an American former business executive at McDonnell Douglas, also known for developing the NIST Enterprise Architecture Model.

References

PD-icon.svg This article incorporates public domain material from the National Institute of Standards and Technology

  1. Chief Information Officer Council (2001) A Practical Guide to Federal Enterprise Architecture Version 1.0 Preface. February 2001.
  2. 1 2 3 4 5 6 The Chief Information Officers Council (1999). Federal Enterprise Architecture Framework Version 1.1. September 1999.
  3. 1 2 3 Fong & Goldfine 1989
  4. John O'Looney (2002). Wiring Governments: Challenges and Possibilities for Public Managers. Greenwood Publishing Group. p.67.
  5. Matthew West and Julian Fowler (1999). High Quality Data Models. The European Process Industries STEP Technical Liaison Executive (EPISTLE).
  6. STRAP SECTION 2 APPROACH. Retrieved 30 September 2008.
  7. John F. Sowa (2004). "The Challenge of Knowledge Soup," in: Research Trends in Science, Technology and Mathematics Education. Edited by J. Ramadas & S. Chunawala, Homi Bhabha Centre, Mumbai, 2006.
  8. Fong & Goldfine 1989 , p. 5
  9. Fong & Goldfine 1989 , p. i
  10. Frank, Andrew U. Research Group Geoinformation, Vienna. Accessed July 15, 2013.
  11. David Terraso (2004) "Robert Fulton, 72, dies: Engineering professor and county commissioner". at whistle.gatech.edu
  12. Alan H. Goldfine at DBLP Bibliography Server
  13. Dale L. Goodhue at DBLP Bibliography Server
  14. Stanley Y. W. Su at DBLP Bibliography Server
  15. Fong & Goldfine 1989 , p. ix
  16. Rigdon 1989
  17. 1 2 Rigdon 1989 , p. 136
  18. Fong & Goldfine 1989 , p. 136
  19. J.A Zachman (1993) Concepts for Framework for EA - Enterprise Architecture Resources . Zachman International, Inc. paper. p. 1
  20. Leonor Barroca, Jon Hall and Patrick Hall (200) "An Introduction and History of Software Architectures, Components, and Reuse" in: Software Architectures, 2000 p. 1
  21. 1 2 3 4 Franklin D. Raines, US OBM (1997) Memoranda 97-16 (Information Technology Architectures) M-97-16, issued June 18, 1997.
  22. Rigdon 1989 , p. 136
  23. 1 2 3 Rigdon 1989 , p. 137
  24. Rigdon 1989 , pp. 137–138
  25. Rigdon 1989 , pp. 139–140
  26. OIG (2005). Implementation of E-Government Principles Archived January 14, 2009, at the Wayback Machine . May 2005
  27. "Exclusive Interview with John Zachman" by Roger Sessions. In: Perspectives of the International Association of Software Architects. April 2006.
  28. Federal Aviation Administration (1998) Federal Information Architecture Initiatives . February 1998
  29. Bobby Jones (2003) NWS Enterprise Architecture. In: 20th International Conference on Interactive Information and Processing Systems. 2004.

Sources