56-435: FEAF may refer to: Federal Enterprise Architecture Framework Far East Air Force , which may refer to: Far East Air Force (Royal Air Force) Far East Air Force (United States) Topics referred to by the same term [REDACTED] This disambiguation page lists articles associated with the title FEAF . If an internal link led you here, you may wish to change
112-570: A common language and framework to describe and analyze investments. Overall the Federal Enterprise Architecture (FEA) is mandated by a series of federal laws and mandates. These federal laws have been: Supplementary OMB circulars have been: The Collaborative Planning Methodology (CPM) is a simple, repeatable process that consists of integrated, multi-disciplinary analysis that results in recommendations formed in collaboration with leaders, stakeholders, planners, and implementers. It
168-487: A core mission area, business service, or enterprise service. Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff. From an investment perspective, segment architecture drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for segment architecture are business owners and managers. Segment architecture
224-614: A hierarchy, the TRM categorizes the standards and technologies that collectively support the secure delivery, exchange, and construction of business and application Service Components that may be used and leveraged in a component-based or service-oriented architecture . In the FEA, enterprise, segment, and solution architectures provide different business perspectives by varying the level of detail and addressing related but distinct concerns. Just as enterprises are themselves hierarchically organized, so are
280-419: A high-level depiction of the TRM. Aligning agency capital investments to the TRM leverages a common, standardized vocabulary, allowing interagency discovery, collaboration, and interoperability. Agencies and the federal government will benefit from economies of scale by identifying and reusing the best solutions and technologies to support their business functions, mission, and target architecture. Organized in
336-562: A number of existing approaches to performance measurement, including the Balanced Scorecard , Baldrige Criteria, value measuring methodology , program logic models , the value chain, and the Theory of Constraints . In addition, the PRM was informed by what agencies are currently measuring through PART assessments, GPRA, enterprise architecture , and Capital Planning and Investment Control. The PRM
392-508: A set of interrelated reference models designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of federal agency operations in a common and consistent way. Through the use of the FEAF and its vocabulary, IT portfolios can be better managed and leveraged across
448-538: 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-415: 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
560-416: Is a component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of Service Components and capabilities. It also unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the reuse and standardization of technology and Service Components from a government-wide perspective. The TRM consists of: The figure on the right provides
616-554: Is also designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services. In September 1999, the Federal CIO Council published the "Federal Enterprise Architecture Framework" (FEAF) Version 1.1 for developing an Enterprise Architecture (EA) within any Federal Agency for a system that transcends multiple inter-agency boundaries. It builds on common business practices and designs that cross organizational boundaries, among others
SECTION 10
#1732848649480672-573: 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-415: Is commonly related to segment architecture and enterprise architecture through definitions and constraints. For example, segment architecture provides definitions of data or service interfaces used within a core mission area or service, which are accessed by individual solutions. Equally, a solution may be constrained to specific technologies and standards that are defined at the enterprise level. Results of
784-539: Is currently composed of four measurement areas: The "FEA business reference model " is a function-driven framework for describing the business operations of the Federal Government independent of the agencies that perform them. This business reference model provides an organized, hierarchical construct for describing the day-to-day business operations of the Federal government using a functionally driven approach. The BRM
840-535: Is designed to ease sharing of information and resources across federal agencies, reduce costs, and improve citizen services. It is an initiative of the US Office of Management and Budget that aims to comply with the Clinger-Cohen Act . The PRM is a standardized framework to measure the performance of major IT investments and their contribution to program performance. The PRM has three main purposes: The PRM uses
896-512: Is effectively used. The functional approach promoted by the BRM will do little to help accomplish the goals of E-Government if it is not incorporated into EA business architectures and the management processes of all Federal agencies and OMB. The Service Component Reference Model (SRM) is a business and performance-driven, functional framework that classifies Service Components with respect to how they support business and/or performance objectives. The SRM
952-597: Is intended as a full planning and implementation lifecycle for use at all levels of scope defined in the Common Approach to Federal Enterprise Architecture: International, National, Federal, Sector, Agency, Segment, System, and Application. The Consolidated Reference Model of the Federal Enterprise Architecture Framework (FEAF) equips OMB and Federal agencies with a common language and framework to describe and analyze investments. It consists of
1008-456: Is intended for use to support the discovery of government-wide business and application Service Components in IT investments and assets. The SRM is structured across horizontal and vertical service domains that, independent of the business functions, can provide a leverage-able foundation to support the reuse of applications, application capabilities, components, and business services. The SRM establishes
1064-453: Is related to EA through three principles: " Solution architecture " defines agency IT assets such as applications or components used to automate and improve individual agency business functions. The scope of a solution architecture is typically limited to a single project and is used to implement all or part of a system or business solution. The primary stakeholders for solution architecture are system users and developers. Solution architecture
1120-528: 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. The most familiar federal enterprise architecture is the enterprise architecture of the Federal government of the United States , the U.S. "Federal Enterprise Architecture" (FEA) and
1176-426: Is the first layer of the Federal Enterprise Architecture and it is the main viewpoint for the analysis of data, service components and technology. The BRM is broken down into four areas: The Business Reference Model provides a framework that facilitates a functional (as opposed to organizational) view of the federal government's LoBs, including its internal operations and its services for the citizens, independent of
SECTION 20
#17328486494801232-621: 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
1288-632: The NIST Enterprise Architecture Model . The FEAF provides an enduring standard for developing and documenting architecture descriptions of high-priority areas. It provides guidance in describing architectures for multi-organizational functional segments of the Federal Government. At the time of release, the Government's IT focus on Y2K issues and then the events of September 2001 diverted attention from EA implementation, though its practice in advance and subsequent to this may have ameliorated
1344-675: 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 . 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
1400-409: 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
1456-410: The Federal Enterprise Architecture program are considered unsatisfactory: 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 by the interrelationship between an enterprise's business, information, and technology environments. Developed late-1980s by
1512-415: The Federal Government. The Common Approach promotes increased levels of mission effectiveness by standardizing the development and use of architectures within and between Federal Agencies. This includes principles for using EA to help agencies eliminate waste and duplication, increase shared services, close performance gaps, and promote engagement among government, industry, and citizens. On January 29, 2013,
1568-532: 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
1624-490: The U.S. Federal Government. Enterprise Architecture became a recognized strategic and management best practice in U.S. Federal Government with the passage of the Clinger-Cohen Act in 1996. There are numerous benefits that accrue from implementing and using an enterprise architecture within the U.S. Federal Government. Among them is to provide a common approach for IT acquisition in the United States federal government . It
1680-565: The White House released Version 2 of the Federal Enterprise Architecture Framework (FEAF-II), to government agencies, making it public about a year later. The document meets the criteria set forth by Common Approach, emphasizing that strategic goals drive business services, which in turn provide the requirements for enabling technologies. At its core is the Consolidated Reference Model (CRM), which equips OMB and Federal agencies with
1736-434: The agencies, bureaus and offices that perform them. By describing the federal government around common business areas instead of by a stovepiped, agency-by-agency view, the BRM promotes agency collaboration and serves as the underlying foundation for the FEA and E-Gov strategies. While the BRM does provide an improved way of thinking about government operations, it is only a model; its true utility can only be realized when it
FEAF - Misplaced Pages Continue
1792-462: The agency mission and strategic goals and objectives. From an investment perspective, EA is used to drive decisions about the IT investment portfolio as a whole. Consequently, the primary stakeholders of the EA are the senior managers and executives tasked with ensuring the agency fulfills its mission as effectively and efficiently as possible. By contrast, " segment architecture " defines a simple roadmap for
1848-476: 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
1904-632: The core reference models (see below), as well as a very robust methodology for actually developing an architecture in a series of templates forming the Federal Segment Architecture Methodology (FSAM) and its next generation replacement, the Collaborative Planning Methodology (CPM), which was designed to be more flexible, more widely applicable, and more inclusive of the larger set of planning disciplines. These federal architectural segments collectively constitute
1960-438: The corresponding U.S. "Federal Enterprise Architecture Framework" (FEAF). This lemma will focus on this particular enterprise architecture and enterprise architecture framework . Enterprise architecture (EA) is a management best practice for aligning business and technology resources to achieve strategic outcomes, improve organizational performance and guide federal agencies to better execute their core missions . An EA describes
2016-505: The creation a Federal Enterprise Architecture Project and the creation of the FEA Office at OMB. This was a shift from the FEAF focus on Information Engineering, to a J2EE object re-use approach using reference models comprising taxonomies that linked performance outcomes to lines of business, process services components, types of data, and technology components. Interim releases since that time have provided successive increases in definition for
2072-425: The current and future state of the agency, and lays out a plan for transitioning from the current state to the desired future state. A federal enterprise architecture is a work in progress to achieve these goals. The U.S. Federal Enterprise Architecture (FEA) is an initiative of the U.S. Office of Management and Budget , Office of E-Government and IT, that aims to realize the value of enterprise architecture within
2128-469: The data and information that support government program and business line operations. This model enables agencies to describe the types of interaction and exchanges that occur between the federal government and citizens. The DRM categorizes government information into greater levels of detail. It also establishes a classification for federal data and identifies duplicative data resources. A common data model will streamline information exchange processes within
2184-473: The different views provided by each type of architecture. The Federal Enterprise Architecture Practice Guidance (2006) has defined three types of architecture: By definition, Enterprise Architecture (EA) is fundamentally concerned with identifying common or shared assets – whether they are strategies, business processes, investments, data, systems, or technologies. EA is driven by strategy; it helps an agency identify whether its resources are properly aligned to
2240-546: The federal enterprise architecture. In 2001, the Federal Architecture Working Group (FAWG) was sponsoring the development of Enterprise Architecture products for trade and grant Federal architecture segments. Methods prescribed way of approaching a particular problem. As shown in the figure, the FEAF partitions a given architecture into business, data, applications, and technology architectures. The FEAF overall framework created at that time (see image) includes
2296-483: The federal government and between government and external stakeholders. Volume One of the DRM provides a high-level overview of the structure, usage, and data-identification constructs. This document: The DRM is the starting point from which data architects should develop modeling standards and concepts. The combined volumes of the DRM support data classification and enable horizontal and vertical information sharing. The TRM
FEAF - Misplaced Pages Continue
2352-455: The federal government, enhancing collaboration and ultimately transforming the Federal government. The five reference models in version 1 (see below) have been regrouped and expanded into six in the FEAF-II. The FEA is built using an assortment of reference models that develop a common taxonomy for describing IT resources. FEA Version 1 reference models (see image) included the following: It
2408-713: 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
2464-495: 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
2520-553: The first three columns of the Zachman Framework and the Spewak 's Enterprise Architecture Planning methodology. In May 2012 OMB published a full new guide, the "Common Approach to Federal Enterprise Architecture". Released as part of the federal CIO's policy guidance and management tools for increasing shared approaches to IT service delivery, the guide presents an overall approach to developing and using Enterprise Architecture in
2576-563: 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
2632-699: The following domains: Each Service Domain is decomposed into Service Types. For example, the three Service Types associated with the Customer Services Domain are: Customer Preferences; Customer Relationship Management; and Customer Initiated Assistance. And each Service Type is decomposed further into components. For example, the four components within the Customer Preferences Service Type include: Personalization; Subscriptions; Alerts and Notifications; and Profile Management. The Data Reference Model (DRM) describes, at an aggregate level,
2688-629: The impact of these events. As part of the President's Management Agenda, in August 2001, the E-Government Task Force project was initiated (unofficially called Project Quicksilver). A key finding in that strategy was that the substantial overlap and redundant agency systems constrained the ability to achieve the Bush administration strategy of making the government "citizen centered". The Task Force recommended
2744-554: 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
2800-493: 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
2856-419: 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
SECTION 50
#17328486494802912-468: 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
2968-441: The link to point directly to the intended article. Retrieved from " https://en.wikipedia.org/w/index.php?title=FEAF&oldid=745090098 " Category : Disambiguation pages Hidden categories: Short description is different from Wikidata All article disambiguation pages All disambiguation pages Federal Enterprise Architecture Framework A federal enterprise architecture framework ( FEAF )
3024-482: 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"
3080-431: 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
3136-603: 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,
#479520