The Federal Enterprise Architecture's reference models contain concepts that can be leveraged by state and local governments.

Transcription

1 G. Kreizman Research Note 28 July 2003 Commentary What the Federal Enterprise Architecture Means to You The Federal Enterprise Architecture's reference models contain concepts that can be leveraged by state and local governments. On 12 June 2003, the U.S. government released two new and one updated Federal Enterprise Architecture (FEA) reference models. These models and their associated governance processes are significant for federal agencies. The models also contain concepts and content suitable for state and local governments. However, implementing the concepts and embedding them into agency architectures will be challenging. The White House Office of Management and Budget (OMB) is responsible for managing the FEA's development; federal agencies have provided considerable input as well. The FEA has been created to provide several benefits over time. The FEA and its associated governance processes are tools to promote IT and component reuse. As the introduction to the FEA Business Reference Model v.2.0 explains: "The FEA is a tool that enables the federal government to identify opportunities to leverage technology and alleviate redundancy or to highlight where agency overlap limits the value of IT investments. The FEA will facilitate horizontal (cross-federal) and vertical (federal, state and local governments) integration of IT resources, and establish the "line of sight" contribution of IT to mission and program performance. The outcome will be a more-citizen-centered, customer-focused government that maximizes technology investments to better achieve mission outcomes." The FEA will drive the following changes in and around the federal government? Federal agencies must show how their business functions, enterprise architectures and IT initiatives map to the FEA. Business case justifications known as Exhibit 300s will need to map to the FEA for fiscal year 2005 budget requests. The OMB will evaluate business cases for overlap and redundancies. According to the OMB, the FEA and business case processes are triggering more-collaborative cross-agency business case development. Vendors and integrators operating on behalf of the government will need to follow the business function and technical standards of the FEA. Gartner 2003 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

2 Here are the reference models of the FEA (see The Business Reference Model The Business Reference Model (BRM) is the federal government's high-level model that categorizes government business functions and subfunctions. The BRM's three main categories are Services for Citizens, Support Delivery of Services and Management of Government Resources. Individual agency business plans and architectures contributed directly to the creation of the BRM; however, the BRM does not directly reference department or agency names. For example, the Services for Citizens category includes a function for disaster management. Several federal agencies perform functions related to disaster management. BRM business functions are aligned with established government budget functions and codes as much as possible. When agencies submit business cases, OMB can use the budget codes and BRM functions submitted to categorize the request and look for redundancies. White House budget and performance initiatives were key influences in the FEA's development. The Service Component Reference Model The Service Component Reference Model (SRM) defines seven component domains and subdomain service categories that logically organize the components that can be used across government. They are not business-specific. Rather, they support multiple lines of business. For example, the Customer Services domain includes subdomains for customer preferences and customer-initiated assistance. The Process Automate Services Domain includes subdomains for tracking and workflow. The FEA Project Management Office (FEAPMO) has "envisioned" a component registry. Agencies would contribute their service components to the registry. Registered components would be searchable. The intent is for agencies that are developing architectures or initiatives to search the registry and determine whether required components exist, and if so, how well these components meet requirements. If a component exists in the registry and meets some, but not all requirements, the agency might enter into a servicelevel agreement with the component's creator for component enhancement. The Technical Reference Model The Technical Reference Model (TRM) outlines the standards, specifications, and technologies that collectively support the secure delivery, exchange and construction of business and application components (service components) that may be used and leveraged in a component-based or serviceoriented architecture. The main domains include Service Access and Delivery, Service Platform and Infrastructure, Component Framework, and Service Interface and Integration. The TRM provides agencies with a baseline set of standards and specifications to apply to their individual enterprise architectures. The FEAPMO is also working on two related reference models: The Performance Reference Model The Performance Reference Model (PRM), which is currently being drafted, will essentially be a reference for common performance outcome measures. It "articulates the linkage between internal business components and the achievement of business and customer-centric outcomes." Adherence to PLM metrics is intended to help agencies and the OMB determine their progress in meeting overall FEA objectives. The Data and Information Reference Model 28 July

3 The Data and Information Reference Model (DRM), another draft model, "will describe, at an aggregate level, the data and information that support program and business line operations. The model will aid in describing the types of interaction and exchanges that occur between the federal government and its various customers, constituencies and business partners. The DRM will categorize the government's information along general content areas and decompose 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, within the federal government and between the government and its external stakeholders." The FEA Management System Tool The FEAPMO has created the FEA Management System (FEAMS) tool, which "will store the FEA reference models. It will also include general information on agencies' IT initiatives. Initiative alignment to the BRM lines of business that they support, the service components and technology that these components leverage, and the performance metrics that they use in achieving performance objectives will be presented. It is OMB's goal that FEAMS will eventually include information on all of the capital assets in which federal agencies invest." How the FEA Relates to the Gartner Enterprise Architecture Framework How the FEA Affects Agency Enterprise Efforts: The Gartner Enterprise Architecture Framework was developed to be applicable to all clients, regardless of their industry. Here's how the framework relates to the FEA (for more information on the framework, see "Gartner Enterprise Architecture Framework for Government"). The FEA is a macro-level set of architecture models that is intended to eliminate redundancies and promote sharing. The FEA is not intended to completely fulfill the requirements for agency enterprise architectures. These models should be used by federal agencies to inform and complement their enterprise architectures. In turn, agency enterprise architecture and business case development will help develop future generations of the FEA. The Gartner Enterprise Architecture Framework can also be used to guide agency enterprise architecture development. The BRM answers the "what" question pertaining to business architecture. That is, the BRM describes the business functions across lines of business. The business architecture layers of the Gartner Enterprise Architecture Framework also answer "who?" and "why?" Why is government delivering a particular service, and to whom? The answers to these questions often lie in policy and law, and are a result of these and other environmental trends, such as those involving economy and security. These "who" and "why" answers should be found in agency business architectures. In the case of the FEA, the "who" and "why" answers contributed to the development of the BRM, but are not directly covered by the BRM. The Gartner Enterprise Architecture Framework supports the development of more-detailed agency business architectures and can also support the required summary mapping back to the FEA. The Gartner Enterprise Architecture Framework espouses the concept of business process styles. These styles help answer the question, "How are services delivered?" There are, for example, collaborative, analytical, real-time, transaction-oriented and utility processing styles. These processing styles often require different underlying logical and physical designs, even when delivering services to the same constituents within the same lines of business. The concept of styles is found in agency enterprise architectures not in the FEA reference models. 28 July

4 Design Patterns: The Gartner Enterprise Architecture Framework also includes the concepts of logical design patterns; these patterns are often associated with business process styles. For example, a storeand-forward application design pattern, such as the application design pattern used with , may be used for a reporting application, while an n-tier client-server application design pattern may be used for a query and transaction system. Again, these design patterns are part of agency enterprise architectures. The FEA is not intended to provide such functionality. Bricks: Bricks are the technical specifications, products and buy lists of the Gartner Enterprise Architecture Framework. Here, the TRM has loose mapping to the Gartner Enterprise Architecture Framework. The TRM includes standards and products for several categories. Here, the bricks portion of the Gartner model could be used to document adherence to the FEA TRM, while also identifying agencyspecific, technical architecture needs. Gartner research can also be used to help shape the standards contained in future versions of the TRM and agency enterprise architectures. What Federal, State and Local Government Organizations Should Do The FEA models and associated conformance requirements currently support the OMB's efforts to identify and reduce redundant functions and systems. Federal agencies are bound by law and administrative directives to align their enterprise architectures with the FEA. Although the models can guide agency architecture development, they do not comprise an enterprise architecture. Agencies will still need to develop architectures that more-discretely support their lines of business. The federal CIO council and its architectural working groups completed considerable work on the Federal Enterprise Architecture Framework (FEAF). Several agencies used this framework, along with its methodology, as a basis for their agency enterprise architectures. However, it is not clear whether work will continue on the FEAF. Federal agencies have achieved varying degrees of internal enterprise architecture development. Agencies with less-mature enterprise architectures can leverage the FEA's standardized business functions, service components and technical standards when developing their own enterprise architectures. However, these agencies will need to manage business architecture at a much more granular level. Agencies that are farther along the enterprise architecture maturity continuum are in a great position to help develop the next iterations of the FEA reference models. These agencies are also well-positioned to support vertical architectural alignment with state and local governments, particularly as it pertains to data models and the DRM. The data models found in the Justice Extensible Markup Language are an example of a federally coordinated set of data models and data dictionaries that have received input from state and local governments and could be used to support vertical-cross-tier justice and public safety applications. The SRM is intended to accomplish a similar goal for components. It identifies common areas for component development, regardless of line of business. It itemizes these areas and speaks to the development of a component registry in the near future. Creating a shared component registry and repository will be difficult. The more-granular a component is, and the easier it is to build, the more likely it will be that developers scattered across the vast domain of the federal government will develop their own. Fully developed, shared services, with published interfaces, are more likely to succeed. Such services perform functions that are visible and costly to duplicate. Many of the 24 federal e-government initiatives are culminating in services such as the Geospatial One-Stop (see "Geospatial One-Stop: A New National Resource"). State and local governments are also in various stages of enterprise architecture development. After reviewing published state enterprise architecture materials and speaking with state clients, we have 28 July

5 concluded that there is no state or local equivalent of the BRM. That is, business linkages for enterprise architectures are usually tied to general enterprise trends and goals, not rolled-up cross-government business requirements. We recommend that state and local governments: Use the FEA reference models to inform state and local enterprise architecture development. Communicate cross-jurisdictional and vertical integration needs to the federal government to help drive state and local requirements into the FEA Bottom Line: The Federal Enterprise Architecture is a set of reference models that focus on reducing redundant efforts and costs in the federal government. However, even when it is complete, the FEA will not fulfill all individual agency requirements for enterprise architectures. "Reference" is the key word. State and local governments should note that the FEA's emphasis is on the business, while the OMB's emphasis is on reducing duplication through its governance processes. Leverage as much of the FEA as possible, and help inform the FEA with state and local requirements. 28 July