Federal enterprise architecture framework pdf

The NIST model has been promoted within the Federal Government as a management tool that illustrates the interrelationship of enterprise business, information, and technology environments. The five-layered model allows 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 Federal Enterprise Architecture is a strategic information asset base that defines the business, information necessary to operate the business, technologies necessary to support the business operations, and transitional processes for implementing new technologies in response to the changing needs of the business.

The Federal Enterprise Architecture Framework is a conceptual model that begins to define a documented and coordinated structure for cross-cutting businesses and design developments in the Government. Collaboration among the Agencies with a vested interest in a Federal segment will result in increased efficiency and economies of scale. Agencies should use the Framework to describe segments of their architectures. September Why develop a Federal Enterprise Architecture Framework? A Federalwide collaboration tool is needed to collect common architecture information and build a repository for storing this information.

A Federal Enterprise Architecture Framework is such a tool and repository. The Framework allows the Federal Government to accomplish the following. Increasingly, Federal Agencies are finding that architecture development is tied to capital IT investment planning processes. This development process is, even at an Agency level, a large, complex, resource-intensive effort. By collaborating on cross-cutting activities, Federal Agencies can share staff efforts and products, thereby leveraging budget resources and lessening burdens.

Collaboration can also encourage development of interoperability standards, which in turn, promote Federalwide information sharing and common capabilities. A better understanding of common Federal processes, information, and other areas where economies of scale might be applied can also evolve through collaboration. The Federal Enterprise Architecture Framework is recommended for use in the following efforts.

The Framework must be flexible to allow for new activities and focus on common Federal Enterprise Architecture activities, address the realities of the Federal workplace, and provide immediate successes.

First, a framework must be developed that shows how to prepare an architecture description. Second, the current baseline must be described. Finally, a target architecture must be described. Only after these activities are completed, implementing needed architecture changes through design, development, and acquisition of systems can begin.

Although this approach appears to be sound, it may result in "paralysis by analysis," because of the complexity of the Federal effort. This approach focuses on major business areas e. This approach would result in business rework, decreased productivity, and lost and missed opportunities, as well as failure to comply with Clinger-Cohen Act requirements.

Today, many initiatives and interAgency efforts are underway for implementing Agency architectures. Agency initiatives are necessary to support Federal business needs and should not be delayed pending the development of current and target Federal Architectures. The Federal Enterprise Architecture effort should not impede individual Agency architecture efforts. To mitigate the risk of overreaching with minimal returns, curtail startup costs for a conventional architecture, and realize returns quickly, the CIO Council selected the segment approach.

A conventional architecture methodology would probably cease in-progress architecture initiatives to develop Federalwide current and target architectures. Obviously, this paradigm is unrealistic and does not meet Government business needs. The solution is a framework that supports immediate response to urgent Agency business needs. The Federal Enterprise Architecture Framework allows critical parts of the overall Federal Enterprise, called architectural segments, to be developed individually, while integrating these segments into the larger Enterprise Architecture.

The CIO Council proposed a form or petition for designating a Federal information architecture segment. For more information on identifying and approving Federal segments, visit the ArchitecturePlus web site refer to appendix D, References. Framework Components In designing the Framework, the CIO Council identified eight components necessary for developing and maintaining the Federal Enterprise Architecture, then drilled down to a further granularity of detail.

The flow and detail of the Framework are discussed in the Federal Enterprise Architecture Framework section of this document.

The following is a brief overview of the eight Framework components. The business drivers could be new legislation, new administration initiatives, budget enhancements for accelerated focus areas, and market forces. Design drivers include new and enhanced software and hardware and their combinations with a variety of deployment approaches.

Strategic Direction - Guides the development of the target architecture and consists of a vision, principles, and goals and objectives. Current Architecture - Defines the "as is" enterprise architecture and consists of two parts: current business and design architectures i.

This is a representation of current capabilities and technologies and is expanded as additional segments are defined. Target Architecture - Defines the "to-be-built" enterprise architecture and consists of two parts: target business and design architectures i. This represents the future capabilities and technologies resulting from design enhancements to support changing business needs.

Transitional Processes - Support the migration from the current to the target architecture. Critical transition processes for the Federal Enterprise include capital IT investment planning, migration planning, configuration management, and engineering change control. Architectural Segments - Consist of focused architecture efforts on major cross-cutting business areas, such as common administrative systems; program areas, such as trade and grants; or small purchases via electronic commerce.

They represent a portion segment of the overall enterprise architecture. A segment is considered to be an enterprise within the total Federal Enterprise.

Standards - Refer to all standards some of which may be mandatory , guidelines, and best practices. The Federal CIO Council seeks to develop, maintain, and facilitate the implementation of the top-level enterprise architecture for the Federal Enterprise. This architecture will serve as a reference point to facilitate the efficient and effective coordination of common business processes, information flows, systems, and investments among Federal Agencies.

Principles The Federal Enterprise Architecture principles adopted by the CIO Council govern and represent the criteria against which all potential investment and architectural decisions are weighed. Standards: Establish Federal interoperability standards. Rationale: The Federal Government has not achieved data, applications, and technology interoperability. Connectivity is often the last requirement addressed. It is difficult to control lifecycle costs and schedules and improve performance, take advantage of commercial items and technology, and maintain and evolve systems.

In addition, the Federal Government requires connectivity between multiple processing environments and applications operating on a variety of technology platforms Implications: The Federal Government should adopt open system standards in which the interrelationships of components are fully defined by interface standards available to the public and maintained by group consensus. The Federal Government should adopt, acquire, and integrate those components that conform to specification.

An open system architecture is the goal; however, initially only partially open systems will be attained. The Federal Government should be able to ensure compliance with these standards. Investments: Coordinate technology investments with the Federal business and architecture. Rationale: The completed current architecture, or a portion of it, should be considered the baseline or the starting point for optimization.

Optimization will occur over time and investments made consistent with the business needs i. It is important to define the current and target positions and identify those investments in the architecture that will achieve the target position. Implications: Compliance mechanisms are necessary to ensure that investments are funded by business and architectural decisions and consistently align the architecture with business needs.

This alignment applies to multiagency and Governmentwide investments, as well as Agency and Bureau investments to achieve vertical integration.

Technology advances are welcome, and the technology blueprint can change when compatibility with the current infrastructure, improvement in operational efficiency, or a required capability is demonstrated.

Data Collection: Minimize the data collection burden. Rationale: The Federal Government should be able to collect, manipulate, and transmit accurate and consistent data quickly and easily.

The lack of data integration due to incompatible database structures; poor quality and integrity of data; and the mixture of organizations, processes, and business rules with data, hinder data collection, manipulation, and transmission. Data should be shared across the Federal Government. Implications: Data standardization, including a common vocabulary and data definition, will be difficult to achieve but is critical.

A common organization eliminates redundancy and ensures data consistency. To ensure success, business units as well as IT personnel should be involved. Each data element should have a trustee accountable for data quality.

Security: Secure Federal information against unauthorized access. Rationale: The Federal Government must be aware of security breaches and data compromise and the impact of these events. Appropriate security monitoring and planning, including an analysis of risks and contingencies and the implementation of appropriate contingency plans must be completed to prevent unauthorized access to Federal information.

Information security must be ensured and increased, commensurate with increased access to Federal information. The business unit manager, where each system is implemented, must take responsibility for security measures and contingency plans as required by Presidential Decision Directive PDD , Critical Infrastructure Protection.

Functionality: Take advantage of standardization based on common functions and customers. Rationale: Due to a lack of standardization on common functions and customers, Federal Agencies have not taken advantage of reuse or incorporated commercial products into Federal systems. Applications have not been developed using standard system components shared across the organization. Additionally, similar or duplicative applications have been developed. Implications: Federal Agencies should develop or design reusable components or purchase architecture components, recognizing that these items are designed to obtain a particular functionality.

Increasingly, the Federal Government is becoming a consumer as opposed to the producer of components; this role requires new skills and abilities. Standardization on common functions and customers will help Federal Agencies implement change in a timely manner. For commercial and Government-off-the-Shelf GOTS software applications, current choices may be limited, as many of these applications are technology and platform dependent.

Information Access: Provide access to information. The right information should be attainable any place, any time, and in the right format.

Implications: The Federal Government should encourage a diversity of public and private access methods for Government public information, including multiple access points, the separation of transactional from analytical data, and data warehousing architecture.

Accessibility involves the ease with which users obtain information. Information access and display must be sufficiently adaptable to a wide range of users and access methods, including formats accessible to those with sensory disabilities. Proven Technologies: Select and implement proven market technologies. Rationale: Federal Agencies often concentrate attention on "bleeding edge" technology, which results in wasted time and effort.

The Federal Enterprise Architecture should focus on proven market technologies implemented within a reasonable period. Business flexibility has been lost and the Government has not adjusted quickly to change. Unfortunately, the environment is often a tangled web of systems, making implementation of proven market technology difficult.

Systems should be decoupled to allow maximum flexibility. Incorporating new or proven technology in a timely manner will help Agencies to cope with change. Privacy: Comply with the Privacy Act of Rationale: Federal Agencies should know and apply the principles of the Privacy Act of and incorporate them into investments.

Implications: A privacy notice that includes the purpose for the information request should be provided anytime the public provides or enters data. The public should be given the right to choose whether or not to provide information. When information is used for other purposes or those other than originally intended, an alternative privacy notice should be provided. Again, the public should be allowed to choose whether or not to provide the information. Protecting the privacy of the citizen is a tremendous burden and management must consider the potential uses of information.

In addition, privacy information maintained by the Government will be properly secured. The Framework does not contain architecture content, but rather, is a place-holder for the content once developed.

What is the Federal Enterprise Architecture Framework? The Federal Enterprise Architecture Framework is an organizing mechanism for managing the development and maintenance of architecture descriptions. The Federal Enterprise Architecture Framework also provides a structure for organizing Federal resources and describing and managing Federal Enterprise Architecture activities. Eight components needed for developing and maintaining a Federal Enterprise Architecture were identified.

A decomposition or drill-down process was performed on each component to achieve a further granularity of detail. The drill-down process resulted in a four-level Federal Enterprise Architecture Framework. Each level provides an understanding or frame of reference for the next. The first three levels, illustrate the progression of eight increasingly detailed components leading to a logical structure for classifying and organizing the descriptive representations of the Federal Enterprise in level IV.

One component is external to the Framework, Architecture Drivers, the other seven are internal. As shown in exhibit 2, the flow of the Framework is from left to right and represents the continuous process of the Federal Enterprise Architecture. Full characterization may be significantly beyond its worth and maintenance.

Level II Level II the view from 10, feet shows, at a greater level of detail, the business and design pieces of the Federal Enterprise Architecture and how they are related. Viewed horizontally, the top half of the Framework deals with the business of the enterprise, while the bottom half deals with the design architectures used to support the business. Examples of design drivers are the Internet and electronic access to services by the public, creating challenges for the design to support the business mission.

There are two types of architecture drivers. For example, the need for public access, the Clinger-Cohen Act requiring the development of architectures and other new laws requiring electronic access or use of electronic signature, and the various re-invention of Government activities.

For example, the Internet. The current architecture has two parts. S Current Business Architecture - Defines the current business needs being met by the current design. What are the business functions and capabilities now in place?

S Current Design Architectures - Define the currently implemented or "as built" data, applications, and technologies used to support the current business needs. What are the data structures, applications, and supporting technology in place that meet some or all of the business needs?

The target architecture has two parts. S Target Business Architecture - Defines the future business needs of the enterprise to be addressed through new or future designs. What are the new or altered processes required by the business? S Target Design Architectures - Define the future data, applications, and technology to be used to support the future business needs.

As in most formalized information architectures, models are the basis for managing and implementing changes in the Federal Enterprise. They are the artifacts that describe, using appropriate notations, the detail specifications from which the applications and technology will be designed and implemented or purchased and installed.

S Business Models - Model the emerging business needs prompted by the business drivers. Modeling involves a common set of definitions, diagrams, and, sometimes, automated tools that facilitate understanding of business functions, information inputs, processes, and products.

S Design Models - Model the data, applications, and technology required to support the emerging business needs. Modeling can include diagrams, specifications, and technical drawings to aid in understanding data structures, applications, and supporting technologies.

Each architecture segment is composed of a current and target architecture, limited in scope by the focus of the segment. The strategic direction incorporates the vision, a succinct and strategic statement describing the targeted end state for the architecture in 5 years, principles for guiding the architecture evolution, and goals and objectives for managing it and determining progress towards the vision. Level II further elaborates on the transitional processes e.

The standards may include mandatory standards, voluntary guidelines, and best practices that promote interoperability. Level III Level III the view from 5, feet expands the design pieces of the framework to show the three design architectures: data, applications, and technology. The current design architectures consist of the following three architectures. S Current Data Architecture - Defines what data is in place to support the business i.

S Current Application Architecture - Defines what applications are in place to manage the data and support the business functions i. S Current Technology Architecture - Defines what supporting technology is in place to provide an environment for applications that manage the data and support the business functions i. The target design architecture consists of the following three architectures. S Target Data Architecture - Defines the data needed to support the business i.

S Target Applications Architecture - Defines the applications needed to manage the data and support the business functions i. S Target Technology Architecture - Defines the supporting technology needed to provide an environment for applications that manage the data and support the business functions i. S Data Models - Define the enterprise.

S Application Models - Define the applications that control the data. S Technology Models - Define the current and target technology. A segment is selected and defined in accordance with the Framework and its architecture information and models are loaded into the Federal Enterprise Architecture Repository.

A segment can be considered to be an event-driven process such as grants that crosses the Federal Enterprise and possesses sufficient return-on-investment ROI to be considered for inclusion in the Federal Enterprise Architecture. Examples include the following. S Investment Management Review - Providing architecture information to support the investment review decision process. S Segment Coordination - Coordinating the integration of the segment architectures into the Federal Enterprise Architecture.

Configuration management and engineering change control processes must be in place. S Procurement Practices - Aligning procurement activities with the architecture and other transitional processes. S Architecture Governance - Coordinating the effort to avoid confusion, gross misunderstanding, and rework. Some standards may be proven, while others are evolving.

This component also includes configuration options for implementing the standards. S Security Standards - Apply to all levels of security from routine to classified. S Data Standards - Apply to data, meta data, and related structures. S Applications Standards - Apply to application software. S Technology Standards - Apply to the operating systems and platforms.

Level IV Level IV the view from 1, to feet identifies the kinds of models that describe the business architecture and the three design architectures: data, applications, and technology. It also defines enterprise architecture planning. At level IV, how the business architecture is supported by the three design architectures begins to evolve and be made explicit. Enterprise architects and engineers have historically used models as their primary descriptive method.

John Zachman and Steven Spewak are two of many recognized leaders in architecture conceptualization and enterprise architecture planning. This body of work is key at level IV in that it presents transitions from the general to a more specific set of methods and approaches. John Zachman is the author of the What is the Zachman Framework as it Framework for Information Systems applies to enterprise architecture? It has received context for understanding a complex structure.

Architecture is the glue that holds the structure together. The them. As it applies to enterprises, the Framework defines sets of architectures that Zachman Framework refer to exhibit 5 is a contain the development pieces of the structure.

Exhibit 5, The Zachman Framework The rows of the Zachman Framework represent different perspectives, which may be used to view a business i. The columns represent the product abstractions or the focus i. The Zachman Framework is a comprehensive, logical structure for descriptive representations i. It is neutral with regard to specific processes or tools used for producing the descriptions. The Framework, as applied to enterprises, is helpful for sorting out complicated technology and methodology choices and issues that are significant to general and technology management and identifying the kinds of models for a given project.

His approach to Federal Enterprise Architecture has EAP is the process of defining helped organizations with modeling, business architectures for the use of information in strategy planning, process improvement, data support of the business and the plan for implementing those architectures.

The design of systems begins in the third row, outside the scope of EAP. EAP focuses on defining what data, applications, and technology architectures are appropriate for and support the overall enterprise.

Exhibit 6 shows the seven components or steps of EAP for defining these architectures and the related migration plan. The seven components are in the shape of a wedding cake, with each layer representing a different focus of each major task or step.

Layer 2 - where we are today This layer provides a baseline for defining the to be architecture and the long-range migration plan. Layer 3 - the vision of where we want to be The arrows delineate the basic definition process flow: data architecture, applications architecture, and technology architecture.

It does not explain how to define the top two rows of the Zachman Framework in detail but for the sake of the planning exercise, abbreviates the analysis. The Zachman Framework provides the broad context for the description of the architecture layers, while EAP focuses on planning and managing the process of establishing the business alignment of the architectures.

EAP is planning that focuses on the development of matrixes for comparing and analyzing data, applications, and technology. Most important, EAP produces an implementation plan. The results of these efforts may be of Governmentwide value; therefore, as each segment completes EAP, the results will be published on the ArchitecturePlus web site refer to appendix D, References. Level IV shows the design architectures as column headings. The Planner and Owner rows focus on the business architecture definition and documentation.

When completed, these rows make explicit what the enterprise business is and what information is used to conduct it i. An upper row or perspective does not necessarily have a more comprehensive understanding of the whole than a lower perspective. Nor does an upper row decompose into greater detail in a lower row. Each row represents a distinct, unique perspective; however, the deliverables from each perspective must provide sufficient detail to define the solution at the level of perspective and must translate to the next lower row explicitly.

Each perspective must take into account the requirements of the other perspectives and the restraint those perspectives impose.

The constraints of each perspective are additive. For example, the constraints of higher rows affect the rows below. The constraints of lower rows can, but do not necessarily affect the higher rows. Understanding the requirements and constraints necessitates communication of knowledge and understanding from perspective to perspective. The Framework points the vertical direction for that communication between perspectives. However, the framework is based on a collaborative planning methodology that takes place in five steps, as follows:.

In this planning phase, stakeholder interests are assessed against the operational requirements, identifying and validating what needs to be accomplished. Planners or architects are critical in this step as they introduce stakeholders to organizers and sponsors, allowing collaboration to occur. Stakeholders and sponsors work hand-in-hand to identify what areas require attention, understand the driving factors behind these areas, and establish validated requirements. Some are evaluated based on their experiences and how they align with the situation being accessed in the framework.

Others are evaluated as potential partners. Research on all of these outside resources, organizations, and potential partners is assessed for quality and usefulness. In this phase, the architect or planner is responsible for facilitating the research. In this step, stakeholders and sponsors flesh out a plan. The adjustments decided upon can occur across any of the domains previously mentioned, such as strategy, business, data, applications, infrastructure, and security. The plan to adjust has several moving parts.

It answers the who, what, when, where, why, and how. What will it cost? In this step, the planner uses best practices and established techniques to create a plan for the required architecture across all domains. The architect is in a supportive role in this step, providing stakeholders and governance with what is needed, pulling the trigger on investments, and implementing a rollout. The architect leverages data to assume this role. Collaborative planning methodology takes into account the various interests of stakeholders and workers, helping them work together to create a plan that is actionable while moving in the direction of government goals and desired outcomes.

The Service Interface and Integration Area defines the discovery, interaction and communication technologies joining disparate systems and information providers.

Component-based architectures leverage and incorporate Service Interface and Integration specifications to provide interoperability and scalability. Skip to main content Search. Service Areas Service Access and Delivery Refers to the collection standard and specifications to support external access, exchange, and delivery of Service Components or capabilities.

Component Framework The Component Framework Area defines the underlying foundation and technical elements by which Service Components are built, integrated and deployed across Component-Based and Distributed Architectures.