Misplaced Pages

#490509

56-565: NIST Enterprise Architecture Model ( NIST EA Model ) is a late-1980s reference model for enterprise architecture . It defines an enterprise architecture by the interrelationship between an enterprise's business, information, and technology environments. 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

112-520: A M.S. from Columbia University , and a diplôme from the University of Paris . DeMarco started working at Bell Telephone Laboratories in 1963, where he participated in ESS-1 project to develop the first large scale Electronic Switching System , which became installed in telephone offices all over the world. Later in the 1960s he started working for a French IT consulting firm, where he worked on

168-491: A basis for development of TOGAF, where architecture meant IT architecture. TOGAF started out taking a strategic and enterprise-wide, but technology-oriented, view. It emerged from the desire to rationalize a messy IT estate. Right up to version 7, TOGAF was still focused on defining and using a Technical Reference Model (or foundation architecture) to define the platform services required from the technologies that an entire enterprise uses to support business applications. In 1996,

224-567: A classification scheme for descriptive artifacts, not a process for planning systems or changes to systems. In 1998, The Federal CIO Council began developing the Federal Enterprise Architecture Framework (FEAF) in accordance with the priorities enunciated in Clinger-Cohen and issued it in 1999. FEAF was a process much like TOGAF's ADM, in which “The architecture team generates a sequencing plan for

280-778: A clear distinction between the architecture domains (business, information/data, application/integration and technical/infrastructure). These domains can be further divided into Sub domain disciplines. An example of the EA domain and subdomains is in the image on the right. Many enterprise architecture teams consist of Individuals with Skills aligned with the Enterprise Architecture Domains and sub-domain disciplines. Here are some examples: enterprise business architect, enterprise documentational architect, enterprise application architect, enterprise infrastructure architect, enterprise information architect, etc. An example of

336-455: A major milestone in the field. In the 1980s with Tim Lister , Stephen McMenamin, John F. Palmer, James Robertson and Suzanne Robertson, he founded the consulting firm "The Atlantic Systems Guild" in New York. The Guild developed into a New York- and London-based consulting company specializing in methods and management of software development. DeMarco has lectured and consulted throughout

392-476: A paper by Zachman and Sowa started thus "John Zachman introduced a framework for information systems architecture (ISA) that has been widely adopted by systems analysts and database designers." The term enterprise architecture did not appear. The paper was about using the ISA framework to describe, “...the overall information system and how it relates to the enterprise and its surrounding environment.” The word enterprise

448-547: 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. Each layer of architecture in the model has a specific intention: Some sample elements of how the Enterprise Architecture can be described in more detail is shown in the illustration. The "Memoranda 97-16 (Information Technology Architectures)" gave

504-467: A view to the wide and long term benefits of the enterprise. Many of the aims, principles, concepts and methods now employed in EA frameworks were established in the 1980s, and can be found in IS and IT architecture frameworks published in that decade and the next. By 1980, IBM's Business Systems Planning (BSP) was promoted as a method for analyzing and designing an organization's information architecture, with

560-412: Is "a clear representation of a conceptual framework of components and their relationship at a point in time". It may for example represent "a view of a current situation with islands of automation, redundant processes and data inconsistencies" or a "future integrated automation information structure towards which the enterprise will move in a prescribed number on years." The role of standards in architecture

616-493: Is about the choice of and relationships between applications in the enterprise's application portfolio, not about the internal architecture of a single application (which is often called application architecture). Many EA frameworks combine data and application domains into a single (digitized) information system layer, sitting below the business (usually a human activity system) and above the technology (the platform IT infrastructure ). For many years, it has been common to regard

SECTION 10

#1732802227491

672-580: Is applied as foundation in multiple Enterprise Architecture frameworks of U.S. Federal government agencies and in the overall Federal Enterprise Architecture Framework . 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., see further Information Technology Architecture . According to Rigdon et al. (1989) an architecture

728-460: Is natural, since business people need information to make decisions and carry out business processes. In 2011, the TOGAF 9.1. specification says: "Business planning at the strategy level provides the initial direction to enterprise architecture." Normally, the business principles, business goals, and strategic drivers of the organization are defined elsewhere. In other words, Enterprise Architecture

784-442: Is not a business strategy, planning or management methodology. Enterprise Architecture strives to align business information systems technology with given business strategy, goals and drivers. The TOGAF 9.1 specification clarified, that, "A complete enterprise architecture description should contain all four architecture domains (business, data, application, technology), but the realities of resource and time constraints often mean there

840-402: Is not enough time, funding, or resources to build a top-down, all-inclusive architecture description encompassing all four architecture domains, even if the enterprise scope is [...] less than the full extent of the overall enterprise." In 2013, TOGAF is the most popular Architecture framework (judged by published certification numbers) that some assume it defines EA. However, some still use

896-527: Is published as ISO/IEC/IEEE 42010:2011 . The standard defines an architecture framework as conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders , and proposes an architecture framework is specified by: Architecture frameworks conforming to the standard can include additional methods, tools, definitions, and practices beyond those specified. Nowadays there are now countless EA frameworks, many more than in

952-618: Is to "enable or constrain the architecture and serve as its foundation". In order to develop an enterprise architecture Rigdon acknowledge: 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. The separate levels of an enterprise architecture are interrelated in

1008-408: 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. One of

1064-462: The 1990s as the foundation for enterprise architectures of individual U.S. government agencies and in the overall federal enterprise architecture . 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. The model defined

1120-963: The Americas, Europe, Africa, Australia and the Far East. He is a member of the ACM and a Fellow of the IEEE. He lives in Camden, Maine , and is a principal of the Atlantic Systems Guild, and a fellow and Senior Consultant of the Cutter Consortium . DeMarco was the 1986 recipient of the Warnier Prize for "lifetime contribution to the field of computing", and the 1999 recipient of the Stevens Award for "contribution to

1176-576: The IT systems to digitise those processes.") and to engage business managers with the benefits that strategic cross-organisational process integration and/or standardisation could provide. A 2008 research project for the development of professional certificates in enterprise and solution architecture by the British Computer Society (BCS) showed that enterprise architecture has always been inseparable from information system architecture, which

SECTION 20

#1732802227491

1232-535: 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. The fifth Information Management Directions workshop in 1989 focused on integration and productivity in information management . Five working groups considered specific aspects of

1288-639: The National Institute of Standards and Technology (NIST) published the NIST Enterprise Architecture Model . This was a five-layer reference model that illustrates the interrelationship of business, information system, and technology domains. It was promoted within the U.S. federal government. It was not an EA framework as we see it now, but it helped to establish the notion of dividing EA into architecture domains or layers. The NIST Enterprise Architecture Model seemingly

1344-636: The US IT Management Reform Act , more commonly known as the Clinger-Cohen Act , repeatedly directed that a US federal government agency's investment in IT must be mapped to identifiable business benefits. In addition, it made the agency CIO responsible for, “...developing, maintaining and facilitating the implementation of a sound and integrated IT architecture for the executive agency.” By 1997, Zachman had renamed and refocused his ISA framework as an EA framework; it remained

1400-452: The above. Zachman has always focused on architecture description advice. The application and technology domains (not to be confused with business domains) are characterized by domain capabilities and domain services. The capabilities are supported by the services. The application services are also referred to in service-oriented architecture (SOA). The technical services are typically supported by software products. The data view starts with

1456-510: The architecture domains as layers, with the idea that each layer contains components that execute processes and offer services to the layer above. This way of looking at the architecture domains was evident in TOGAF v1 (1996), which encapsulated the technology component layer behind the platform services defined in the "Technical Reference Model" - very much according to the philosophy of TAFIM and POSIX. The view of architecture domains as layers can be presented thus: Each layer delegates work to

1512-482: The components, which consist of: 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. The NIST Framework

1568-455: The data classes which can be decomposed into data subjects which can be further decomposed into data entities. The basic data model type which is most commonly used is called merda (master entity relationship diagrams assessment, see entity-relationship model ). The Class, subject and entity forms a hierarchical view of data. Enterprises may have millions of instances of data entities. The Enterprise Architecture Reference Traditional Model offers

1624-521: The development of a conveyor system for the new merchandise mart at La Villette in Paris, and in the 1970s on the development of on-line banking systems in Sweden, Holland, France and New York. In the 1970s DeMarco was one of the major figures in the development of structured analysis and structured design in software engineering. In January 1978 he published Structured Analysis and System Specification ,

1680-751: 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 . With the proliferation of information technology starting in

1736-494: 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 : 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

NIST Enterprise Architecture Model - Misplaced Pages Continue

1792-562: The following definition of enterprise architecture: 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

1848-541: The following goals: In 1982, when working for IBM and with BSP, John Zachman outlined his framework for enterprise-level "Information Systems Architecture". Then and in later papers, Zachman used the word enterprise as a synonym for business. "Although many popular information systems planning methodologies, design approaches, and various tools and techniques do not preclude or are not inconsistent with enterprise-level analysis, few of them explicitly address or attempt to define enterprise architectures." However, in this article

1904-577: The following listing. Enterprise architecture frameworks that are released as open source : Tom DeMarco Tom DeMarco (born August 20, 1940) is an American software engineer , author, and consultant on software engineering topics. He was an early developer of structured analysis in the 1970s. Tom DeMarco was born in Hazleton, Pennsylvania . He received a BSEE degree in Electrical Engineering from Cornell University ,

1960-490: The fundamental Enterprise Architecture artifact. They relate data entities, use cases, applications and technologies to the functions/capabilities. In 2006, the popular book Enterprise Architecture As Strategy reported the results of work by MIT's Center for Information System Research. This book emphasises the need for enterprise architects to focus on core business processes ("Companies excel because they've [decided] which processes they must execute well, and have implemented

2016-549: 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 , Robert E. Fulton, Alan H. Goldfine, Dale L. Goodhue , Richard J. Mayer , Shamkant Navathe , T. William Olle , W. Bradford Rigdon , Judith A. Quillard, Stanley Y. W. Su, and John Zachman . Tom DeMarco delivered

2072-505: 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 ". 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: The fifth workshop in 1989 was held by the National Computer Systems Laboratory (NCSL) of

2128-417: The interrelation as follows: 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. The NIST Enterprise Architecture Model is initiated in 1988 in

2184-534: 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. 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. The fifth working group on architectures and standards

2240-415: The layer below. In each layer, the components, the processes and the services can be defined at a coarse-grained level and decomposed into finer-grained components, processes and services. The graphic shows a variation on this theme. In addition to three major framework components discussed above. An ideal EA framework should feature: Most modern EA frameworks (e.g. TOGAF, ASSIMPLER, EAF) include most of

2296-485: The list of reference architecture patterns in the application and information architecture domains are available at Architectural pattern (computer science) . A view model is a framework that defines the set of views or approaches used in systems analysis , systems design , or the construction of an enterprise architecture . Since the early 1990s, there have been a number of efforts to define standard approaches for describing and analyzing system architectures. Many of

NIST Enterprise Architecture Model - Misplaced Pages Continue

2352-577: The processes in TOGAF, FEAF, EAP and BSP were clearly related. In 2002/3, in its Enterprise Edition , TOGAF 8 shifted focus from the technology architecture layer to the higher business, data and application layers. It introduced structured analysis, after information technology engineering , which features, for example, mappings of organization units to business functions and data entities to business functions. Today, business functions are often called business capabilities. And many enterprise architects regard their business function/capability hierarchy/map as

2408-406: The recent Enterprise Architecture frameworks have some kind of set of views defined, but these sets are not always called view models . Perhaps the best-known standard in the field of software architecture and system architecture started life as IEEE 1471 , an IEEE Standard for describing the architecture of a software-intensive system approved in 2000. In its latest version, the standard

2464-424: The scale and complexity of this system, an architectural framework provides tools and approaches that help architects abstract from the level of detail at which builders work, to bring enterprise design tasks into focus and produce valuable architecture description documentation. The components of an architecture framework provide structured guidance that is divided into three main areas: The earliest rudiments of

2520-638: The step-wise planning methodology currently advocated by The Open Group Architecture Framework (TOGAF) and other EA frameworks can be traced back to the article of Marshall K. Evans and Lou R. Hague titled "Master Plan for Information Systems" published in 1962 in Harvard Business Review. Since the 1970s people working in IS/IT have looked for ways to engage business people – to enable business roles and processes - and to influence investment in business information systems and technologies – with

2576-564: The technology to implement the applications. Enterprise Architecture Planning is a data-centric approach to architecture planning. An aim is to improve data quality, access to data, adaptability to changing requirements, data interoperability and sharing, and cost containment. EAP has its roots in IBM's Business Systems Planning (BSP). In 1994, the Open Group selected TAFIM from the US DoD as

2632-459: The term "Enterprise Architecture" was mentioned only once without any specific definition and all subsequent works of Zachman used the term "Information Systems Architecture". In 1986, the PRISM architecture framework was developed as a result of the research project sponsored by a group of companies, including IBM, which was seemingly the first published EA framework. In 1987, John Zachman, who

2688-402: The term Enterprise Architecture as a synonym for Business Architecture, rather than covering all four architecture domains - business, data, applications and technology. Since Stephen Spewak's Enterprise Architecture Planning (EAP) in 1993 – and perhaps before then – it has been normal to divide enterprises architecture into four architecture domains . Note that the applications architecture

2744-633: The transition of systems, applications, and associated business practices predicated upon a detailed gap analysis [between baseline and target architectures].” In 2001, the US Chief CIO council published A practical guide to Federal Enterprise Architecture , which starts, “An enterprise architecture (EA) establishes the Agency-wide roadmap to achieve an Agency's mission through optimal performance of its core business processes within an efficient information technology (IT) environment." At that point,

2800-495: The working group addressed three issues: 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. In a way the NIST Enterprise Architecture Model was ahead of his time. According to Zachman (1993) in the 1980s the "architecture"

2856-423: Was a marketing specialist at IBM, published the paper, A Framework for Information Systems Architecture . The paper provided a classification scheme for artifacts that describe (at several levels of abstraction) the what, how, where, who, when and why of information systems. Given IBM already employed BSP, Zachman had no need to provide planning process. The paper did not mention enterprise architecture. In 1989,

SECTION 50

#1732802227491

2912-428: Was acknowledged as a topic of interest, but there was still little consolidated theory concerning this concept. Software architecture , for example. become an important topic not until the second half of the nineties. 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. The NIST Enterprise Architecture Model

2968-618: Was chaired W. Bradford Rigdon of the McDonnell Douglas Information Systems Company (MDISC), a division of McDonnell Douglas . Rigdon et al. (1989) 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." In order to do so,

3024-455: Was picked up by several U.S. federal agencies and used as the basis for their information strategy. The reference model is applicated the following frameworks: [REDACTED]  This article incorporates public domain material from the National Institute of Standards and Technology Enterprise architecture framework Enterprise architecture regards the enterprise as a large and complex system or system of systems . To manage

3080-412: Was the first publication that consistently used the term "Enterprise Architecture". In 1990, the term "Enterprise Architecture" was formally defined for the first time as an architecture that "defines and interrelates data, hardware, software, and communications resources, as well as the supporting organization required to maintain the overall physical structure required by the architecture". In 1992,

3136-418: Was used as a synonym for business. In 1993, Stephen Spewak's book Enterprise Architecture Planning (EAP) defined a process for defining architectures for the use of information in support of the business and the plan for implementing those architectures. The business mission is the primary driver. Then the data required to satisfy the mission. Then the applications built to store and provide that data. Finally

#490509