The FEA is being constructed through a collection of interrelated "reference models" designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across Federal Agencies. These models are defined as:
Performance Reference Model (PRM)
Business Reference Model (BRM)
Service Component Reference Model (SRM)
Data and Information Reference Model (DRM)
Technical Reference Model (TRM)
A BUSINESS-DRIVEN APPROACH
·Budget Allocation
·Horizontal and Vertical Information Sharing
·Performance Measurement
·Budget / Performance Integration
·Cross-Agency Collaboration
·E-Government
·Component-Based Architectures
·and more...
The PRM establishes a common set of general performance outputs and measures that agencies use to achieve much broader program and business goals and objectives
The model articulates the linkage between internal business components and the achievement of business and customer-centric outcomes
To align and leverage existing federal guidance and application/architecture recommendations. It facilitates resource allocation decisions based on comparative determinations of which programs/organizations are more efficient and effective
The PRM will be designed to integrate with and complement OMB's development of the Program Assessment Rating Tool (PART) and common measures initiative. By defining outcome and output measures for lines of business and sub-functions, the PRM will provide the tools necessary to measure cross-agency initiatives at the federal enterprise level. Additional guidance on both the PRM and PART will be provided as these two models undergo continued development.
The Performance Reference Model (PRM) is scheduled to be released later this year.
The Business Reference Model Version 2.0 provides an organized, hierarchical construct for describing the day-to-day business operations of the Federal government. While many models exist for describing organizations - org charts, location maps, etc. - this model presents the business using a functionally driven approach. The Lines of Business and Sub-functions that comprise the BRM represent a departure from previous models of the Federal government that use antiquated, stovepiped, agency-oriented frameworks. The BRM 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 identifies four (4) Business Areas that provide a high-level view of the operations the Federal Government performs. The four Business Areas comprise a total of thirty nine (39) external and internal Lines of Business and one hundred and fifty three (153) Sub-Functions.
Services for Citizens
The Services For Citizens Business Area describes the mission and purpose of the United States government in terms of the services it provides both to and on behalf of the American citizen. It includes the delivery of citizen-focused, public, and collective goods and/or benefits as a service and/or obligation of the Federal Government to the benefit and protection of the nation's general population.
Mode of Delivery
The Mode of Delivery Business Area describes the mechanisms the government uses to achieve the purpose of government, or its Services to Citizens. It includes Financial Vehicles, Direct Government Delivery, and Indirect Government Delivery.
Support Delivery of Services
Support Delivery of Services provides the critical policy, programmatic and managerial Foundation to support federal government operations.
Management of Government Resources
Management of Government Resources refers to the back office support activities that enable the government to operate effectively.
The SRM 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.
Customer Services
The Customer Services Domain defines the set of capabilities that are directly related to an internal or external customer, the business’ interaction with the customer, and the customer driven activities or functions. The Customer Services domain represents those capabilities and services that are at the front end of a business, and interface at varying levels with the customer.
Process Automation Services
The Process Automation Services Domain defines the set of capabilities that support the auto-mation of process and management activities that assist in effectively managing the business. The Process Automation Services domain represents those services and capabilities that serve to automate and facilitate the processes associated with tracking, monitoring, maintaining liaison throughout the business cycle of an organization.
Business Management Services
The Business Management Services Domain defines the set of capabilities that support the man-agement of business functions and organizational activities that maintain continuity across the business and value-chain participants. The Business Management Services domain represents those capabilities and services that are necessary for projects, programs and planning within a business operation to successfully be managed.
Digital Asset Services
The Digital Asset Services Domain defines the set of capabilities that support the generation, management and distribution of intellectual capital and electronic media across the business and extended enterprise.
Business Analytical Services
The Business Analytical Services Domain defines the set of capabilities supporting the extraction, aggregation and presentation of information to facilitate decision analysis and business evaluation.
Back Office Services
The Back Office Services Domain refers to the set of capabilities that support the management of enterprise planning transactional-based functions.
Support Services
The Support Services Domain defines the set of cross-functional capabilities that can be leveraged independent of Service Domain objective and / or mission.
The DRM will categorize the government's information along general content areas and decomposes those content areas into greater levels of detail. The DRM establishes a commonly understood classification for Federal data and leads to the identification of duplicative data resources. A common data model will streamline the processes associated with information exchange both within the Federal government between the government and its external stakeholders.
Currently, there is no scheduled release date for the Data and Information Reference Model (DRM).
The Technical Reference Model (TRM) provides a foundation to describe the standards, specifications, and technologies to support the construction, delivery, and exchange of business and application components (Service Components) that may be used and leveraged in a Component-Based or Service-Orientated Architecture. The TRM unifies existing Agency TRMs and electronic Government (e-Gov) guidance by providing a foundation to advance the re-use of technology and component services from a Government-wide perspective.
Service Access and Delivery Area
Refers to the collection standard and specifications to support external access, exchange, and delivery of Service Components or capabilities. This area also includes the Legislative and Regulator requirements governing the access and usage of the specific Service Component.
Service Platform and Infrastructure
The Service Platform and Infrastructure Area defines the collection of platforms, hardware and infrastructure specifications that enable Component-Based Architectures and Service Component re-use.
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. The Component Framework consists of the design of application or system software that incorporates interfaces for interacting with other programs and for future flexibility and expandability. This includes, but is not limited to, modules that are designed to interoperate with each other at runtime. Components can be large or small, written by different programmers using different development environments and may be platform independent. Components can be executed on stand-alone machines, a LAN, Intranet or on the Internet.
Service Interface and Integration
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.
如果您有任何问题和建议，请直接和管理员联系。
Copyright© 1998-2008
ITCore版权所有. All rights
reserved.