The definitions provided below describe some of the global terms and expressions used throughout this document to refer to key areas or functions associated with XML registries.

Abbreviations

XML Extensible Markup Language

DTD document type definition

UDDI Universal Description, Discovery, and Integration

Definitions

XML Artifacts: The term “XML artifacts” in this document refers to and includes XML schemas, document type definitions, XML documents, etc individually or as a group. The term also encompasses data definitions.

Related Artifacts: The term “related artifacts” refers to any supplementary documents, XML files, design documents, or any other files that support XML artifacts themselves and convey more precise information about those particular XML artifacts.

Web Services: The term “Web services” refers to metadata (descriptive information) about a web service, wherein the registry/repository references the location and information about web services that are available on another system (similar to a UDDI capability), but does not physically host the web service itself.

Registry/Repository: Throughout this document, the term “registry/repository” is used interchangeably with the term “registry.” Both terms are used to refer to electronic listings of specifications (schemas, DTDs, etc) as well as the locations where the schemas, DTDs, metadata, etc reside.

Executive Summary

Statement of Purpose

The purpose of this Business Case Analysis (BCA) is to provide the justification for the XML.gov Registry/Repository, based on an analysis of its cost, value and risk. The primary business driver for the BCA is to address the need for the coordination and interoperability of Extensible Markup Language (XML) registry/repositories sponsored by federal agencies.

The government-wide XML.gov Registry/Repository initiative aims to coordinate the currently fragmented activities being undertaken by federal across government to build and populate XML registries. This business case considers whether the Government should invest in a common XML registry/repository —“ primary federal registry/repository” — that will unify and interoperate with current and future individual registries operated by different federal agencies, as well as serve as a central portal linking to all (federal) agency registry/repositories and providing a central publishing forum for agencies not electing to build individual registries. In the current federal environment, XML activities and registries are disjointed, non-interoperable, and there is limited awareness of their content and potential applicability to federal IT initiatives. In addition, the technological specifications upon which these different registries were built vary from registry to registry. An investment in a central federal registry/repository would not only provide a central portal to retrieve artifacts in registries across the federal government, it would also enable federal agencies without their own stand-alone registries to publish artifacts. This investment would provide substantial foundational and operational value to the Government, and would help to ensure cross-government coordination and maximum reuse of artifacts associated with government-unique requirements by all types of federal business partners.

This XML.gov Registry/Repository BCA was prepared using the Value Measuring Methodology (VMM). VMM – an analytical framework developed as part of a January 2002 study conducted by Booz Allen Hamilton for GSA and the Social Security Administration (SSA), entitled Measuring the Value of e-Services – provides a structure in which a broader range of benefits than those considered in a traditional cost-benefit analysis are captured and quantified. This approach is compliant with guidance from the Office of Management and Budget (OMB) and incorporates both public and private sector analytical best practices.

Accordingly, this business case documents the analysis, and comparison of the costs, value (benefits), and risks of initiative alternatives analyzed using VMM.

Summary Project Description

The eXtensible Markup Language (XML) has emerged as a key technology to assist commercial and government organizations in exchanging information and conducting business over the Internet. Groups of public and private organizations are using XML today to define standard data components and business processes that can be built into web applications, enabling them to use the Internet in innovative ways. As communities of interest define XML elements to be used in their business transactions, other business partners seeking to implement XML solutions— either within these particular communities or for their own internal use—can access the results of these standardization efforts. These XML definitions can be published via XML registries, which are data stores created according to industry standards to facilitate the sharing and reuse of XML artifacts. Several such registries have been and are currently being established by agencies of the federal government to support the use of XML technology in IT projects.

The current federal XML environment is characterized by a patchwork of initiatives with varying goals. There is no common definition of what a government-sponsored XML registry or repository should contain. Often, there is little XML centralization even within an individual agency. This fragmented environment is attributable both to the absence of a central federal coordinating body or policy function and to the relative lack of commercially available IT products to support an XML registry. As a result of these conditions, highly customized registries within individual agencies have been the norm.

A key challenge facing the federal government in this arena is the development of a means to enable existing federal registries to interoperate, while providing a clear definition of the use and purpose of each registry. For example, some agencies may have an immediate need to define business processes, whereas other agencies may need to provide data element definition specific to the content of their repositories. A consistent and well-developed approach to and determination of the registries’ uses will facilitate the discovery of artifacts and their reuse. Without the definition and establishment of the purposes of all of the individual agency registries, the proliferation of discrete XML registries would continue and, therefore, redundant XML definitions would also proliferate.

The XML.gov Registry/Repository initiative will provide a consolidated government-wide approach to XML definition, storage, and reuse among all federal agencies and their partners. By providing a means of electronic information-sharing and enabling e-Government transactions, the initiative will yield efficiencies and directly benefit customers and stakeholders, including federal, state, and local government entities; private industry; the scientific community; and the public.

All agencies will need to share information with one another and with external business partners. Therefore, the XML.gov Registry/Repository is designed to be a crosscutting, multi-agency initiative. Federal agencies, their business partners, as well as a number of communities of interest will be involved in the on-going development of the initiative and the registry landscape that it will support. The XML.gov Registry Initiative will have an impact on all federal agencies that are included within the scope of 24 major cross-agency Presidential e-Government initiatives and, potentially, on future e-Government projects.

Once implemented, the XML.gov Registry/Repository initiative will enable suppliers of goods, services and IT to the federal government to share information seamlessly with their government customers. Both application owners (AOs) in agencies and their user communities will benefit from the transactional, technological, and communications efficiencies that a coordinated Federal XML effort would deliver.

Importance and Impact of Investment

The Paperwork Reduction Act of 1995 and the Government Paperwork Elimination Act of 1998 both reflect the government’s goal to use information technology to make business processes more effective and more efficient. Magnified by the private sector’s use of e-commerce and e-business, as well as the changing expectations of citizens, federal agencies have been developing and implementing IT solutions. As agency systems proliferate, having a reference point for core components would eliminate redundant data description and promote government-wide knowledge sharing. Depending on the level and type of XML artifact stored in a primary federal registry, this registry could leverage or link existing registries and ensure the interoperability of existing Federal registries. Current registries will no longer need to function independently.

There are multiple, disparate registries currently in use or in development across the federal government. Because these registries have been developed in isolation – either at the agency or project level - their creators and users are not able to leverage work performed by other organizations or benefit from lessons learned. This level of isolation has resulted in redundant development efforts, in which each must begin from square one. The cost to develop discrete XML registries has, therefore, acted as a barrier to entry for some of the smaller agencies and resulted in redundant Government spending, which translates into increased costs for citizens. By consolidating the development of XML registries, costs –including those incurred for acquiring specialized skill sets - could be spread across multiple agencies, breaking down cost barriers and reducing the level of resources expended government-wide.

A primary federal XML registry would help promote a variety of government initiatives and missions, including, but not limited to, e-Government and Homeland Security initiatives. Due to the potentially segmented security restrictions or federal agency-specific data, no private sector XML registry exists that can support full use by the federal government. The preferred alternative of a “registry of registries operated in a federated model, linked by a primary (or flagship) federal registry” (referred to as the “federated registry/repository model”) would provide a non-intrusive way for existing registries to co-exist and be used by all agencies without significant additional effort and resource allocation on their part.

Summary of Investment Costs

The overall investment requirements for the preferred alternative, the federated registry/repository model, with a primary federal registry, are outlined in the table below. Table 1 reflects the costs to the federal government as a whole (ten year lifecycle) for this alternative. These costs include: the costs of establishing and operating a primary federal registry/repository that will link all individual registries, the costs of the individual agency registries that are assumed to exist, and costs associated with new registries that will be created between 2004 and 2013.

Table 1: Summary of Investment Costs

Based on the analysis conducted to date, the expected total investment cost associated with a federated model of government-sponsored registries, linked and governed by a primary registry/repository—XML.gov—is $7.7 million, with a total life-cycle cost (FY 2004-FY 2013) of $59.4 million.

A sensitivity analysis was conducted to account for uncertainty associated with the initiative and an expected range of costs was generated. The expected range for investment is $7.4 million to $8.0 million and the expected range for the total life-cycle cost is $58.2 million to $61.0 million.

Barriers to Success in Current Environment

There are two major barriers to the successful implementation of a federated model of registry/repositories that will affect the XML.gov Registry/Repository initiative:

· Technical Risk: The commercial software products and appropriate interoperability standards to support a federation of registries are not expected to be in place until December 2002. In addition, it is likely that there are government-sponsored registries currently in place that will need to be retrofitted in order to participate in the federated model.

· Stakeholder Resistance: Stakeholders across government and industry may be unwilling or slow to work collaboratively on data sharing agreements that leverage XML artifacts or provide a sharing capability to the XML artifacts that they have constructed.

Introduction

This Business Case Analysis (BCA) outlines the need for a coordinated federal XML registry/repository capability, analyzes the status quo and proposed alternatives, and makes a recommendation for a ‘preferred alternative’ that will maximize cost effectiveness and support the missions and service delivery of individual agencies across the federal government. More and more, it is becoming necessary for entities within industries to communicate with each other electronically in order to facilitate their daily business transactions. The federal government is no exception. The government must communicate effectively within itself, with the citizens it supports, and with entities with which it conducts business. When information is shared electronically, it must not only be exchanged, it must also be manipulated and interpreted. The eXtensible Markup Language (XML) has been a tremendous enabler for the sharing of electronic information because it provides a flexible, non-proprietary way to annotate or ‘tag’ information so that it can be exchanged and interpreted by disparate computer systems. However, the need within the federal government to use XML emerged in advance of the development of standards. This created a situation in which programmers were free to create their own XML elements in isolation. In the absence of standards and without a central storehouse and clearinghouse of XML elements, it is likely that many programmers engaged in redundant efforts to develop XML elements that already existed. As a result, current federally sponsored XML efforts are very fragmented and the government is not achieving the level of efficiency that would not only greatly improve collaboration among government entities, but also reduce software development cycles and costs.

This business case considers whether a central, primary federal XML registry/repository should be established in order to eliminate some of the registry redundancies that exist today, and provide the government with a flexible and scalable means of leveraging future technological advances, and coordinating current and future federal XML efforts.

The XML.gov Registry/Repository initiative would provide a consolidated approach to XML definition and storage and reuse among all federal agencies and their partners. Moreover, by providing a means of electronic information sharing that will enable other e-Government transactions, the initiative would directly benefit customers and stakeholders, including Federal, state, and local government entities; private industry; the scientific community; and the public.

This BCA has been prepared in accordance with guidance from the Office of Management and Budget (OMB), the General Services Administration (GSA), and government and commercial best practices. It incorporates a full comparison of viable alternatives using the Value Measuring Methodology (VMM). VMM incorporates the definition, estimation, normalization, and comparison of the costs, benefits, and risks of alternatives that extends beyond traditional cost-benefit analyses.

Current Environment and Background

The current federal XML environment is extremely fragmented and the goals of the assorted XML initiatives vary from agency to agency. There are no standards and, therefore, no common definition of what a registry or repository should contain or the technological platform on which it should be built. Often, there is little XML centralization even within one agency. Adding to the fragmentation of the current environment is the relative lack of commercially available products to support an XML registry, which has resulted in custom registries becoming the norm.

Due to the current state of the federal XML environment, a major challenge facing the federal government is the development of some means of allowing existing Federal registries to interoperate with one another and provide a clear definition of the use for each registry. For example, some agencies may have an immediate need to define business processes whereas other agencies may need to provide data element definition. A consistent and well-developed approach to the registries should be used to facilitate easy discovery of artifacts, thus enabling reuse. Without this definition, the proliferation of discrete and non-interoperable federal XML registries would continue, as would redundant XML definitions.

The XML.gov Registry/Repository initiative responds directly to the CIO Council’s XML Working Group agenda as it relates to e-Government. It also addresses requirements associated with the 24 cross-agency e-Government initiatives identified by the President’s e-Government Task Force and creates a foundation that may be leveraged by federal agencies as they begin to move forward in development of other e-Government and IT initiatives. Additionally, the development and use of a primary government-wide federal XML repository will benefit the individual communities of interest related to specific agencies. Because these communities of interest are specific to the mission of the agency to which they are affiliated, they vary widely from agency to agency. For example, the Department of Justice may need to share information with state and local justice systems, state and local criminal agencies, and federal criminal agencies. Each agency—even those that have not defined an official XML initiative—uses XML in many of its current IT projects. As a result, having an accessible XML registry that supports both artifact and business process storage could benefit all agencies regardless of whether an official XML registry has been identified. Finally, the XML.gov Registry/Repository initiative will also benefit federal business partners and commercial suppliers, enabling them to share information seamlessly with the government.

As a crosscutting, multi-agency initiative, the development of the XML.gov Registry/Repository would involve the collaboration of multiple federal organizations and communities of interest, specifically agencies that have XML initiatives that are in an advanced stage of development, including but not limited to:

• Environmental Protection Agency – Currently using the National Institute of Standards and Technology (NIST) registry

• Department of Defense – Disa.mil XML registry

• Navy – Currently creating a registry business case to determine the value of creating a Navy-specific registry versus using the existing Department of Defense registry

• Department of Justice – Currently defining meta-data elements to be shared with state government business partners and establishing a repository.

Due primarily to the fact that all federal agencies need to share some level of information with business partners, the XLM.gov Registry/Repository Initiative will require the involvement of federal agencies and communities of interest in addition to those listed above. These agencies will include:

• General Services Administration (GSA)

• Office of Management and Budget (OMB)

• Homeland security organizations

Some examples of communities of interest that may be involved in the XML.gov Registry/Repository initiative include:

• State government agencies

• Local government agencies

• OASIS

• Federal working groups

• XML Working Group of the CIO Council

• Solutions Architecture Working Group (SAWG) of the Federal Enterprise Architecture initiative

• NIST

• Related industry business partners

• Related interest groups (e.g. xml.org, uddi.org)

• Related standards bodies

Why is this Investment Important?

Three main factors drive the importance of an investment in the XML.gov Registry/Repository Initiative: the business requirement to share information; the widespread use of XML as an information tagging mechanism; and the need for efficiency.

The government must share information with all its stakeholders, citizens, and interested parties. Sharing information electronically is critical to the government operations. The first step in enabling information sharing is by providing a centralized, coordinated approach to a federal XML registry/repository capability. In creating a primary federal registry/repository, the government is directly enabling the fulfillment of the Presidents e-Government and Homeland Security agendas.

There are currently multiple, disparate federal registries currently in use or in development. Because these are developed in siloed environments, the builders and users of these registries are not able to leverage work performed by other agencies. Additionally, these agencies have developed their registries from scratch. The cost of doing that presents a barrier to entry for some of the smaller agencies. The cost to the government, and therefore the citizen, is increased. IT bandwidth, particularly for the specialized skill set required for the development of XML registries, could be spread across multiple agencies and development costs could be reduced.

The Clinger Cohen Act (formerly referred to as the Information Technology Reform Act of 1996 or ITMRA) defined general information management policies for federal agencies. It focuses on the management of IT in government and effectively decentralized the management of IT resources to the individual agencies. The Clinger Cohen Act and associated OMB guidance acted as a catalyst for agencies to ask and answer three critical questions when considering an investment in an IT system: 1) Does this investment support the core mission functions that need to be performed by the federal government?, 2) Does the initiative need to be undertaken because no other private sector or government source can support the function?, and 3) Does the investment support work processes that have been simplified or otherwise redesigned to reduce costs, improve effectiveness and make use of commercial, off-the-shelf products?

A primary government-wide federal XML registry, that (1) acts as a repository for agencies not establishing individual registries and (2) links all current and future registries to one another and ensures interoperability, would support these legislative mandates on two levels. The primary registry, and the Governmentwide interoperability and coordination activities that accompany it, would help promote a variety of government initiatives and missions, including, but not limited to, the expansion of e-Government and homeland security coordination. Due to the potentially segmented security restrictions or federal agency specific data, no private sector XML Registry currently exists that could support use by the federal government. The government registries previously listed could be adapted to be used by the federal government as a whole but would require extensive adaptation and development of protocols for maintenance and use. The ‘preferred alternative’ of a ‘registry of registries’ would provide a non-intrusive way for existing registries to coexist, interoperate, and be used by all agencies without significant additional effort and resource allocation on their part.

The e-Government initiatives provide a way for the government to become web-enabled and, as a result, to provide more information to its core customers. These initiatives are divided into four categories or focus areas, government to government (G2G), government to business (G2B), government to citizen (G2C), and internal efficiency and effectiveness (IEE). Additionally, there are some foundational initiatives that cut across all of the focus areas.

XML is currently the ‘glue’ that promotes interoperability. It will allow the systems being developed for these initiatives to communicate with each other and paves the way for future or expanded collaboration between agencies. A primary federal XML registry/repository that links all individual federal registries and ensures interoperability, if made available to IT developers across the federal government, would facilitate the design and implementation of current and future e-Government initiatives.

XML lays the technological foundation that supports interoperability. The XML.gov registry, depending on its use, could support a common language and act as a catalyst in the definition of common processes across government. Some examples of common processes that are cross-agency are workflow, messaging or purchasing transactions. Though the details may vary slightly from agency to agency, the common components are the same. Thus, providing a registry or a registry of registries of common components would support their reuse, effectively enhancing efficiency and reducing redundant development efforts and spending. Over the long-term, this would provide government agencies with architectural standardization and support the President’s e-Government Component Based Architecture strategy currently in development by the Solutions Architecture Working Group.

An XML registry/repository is the foundation upon which data transmission between disparate systems is built. It also provides a common taxonomy for systems, which allows them not only to share information but also to translate information that is received. It is for this reason that a primary government-wide federal XML repository would be a key enabler of current and future homeland security coordination.

What is the Potential Impact?

The primary benefit of XML is that it is extensible and can be used to describe both low-level elements and business processes. This is also one of the primary detriments. Because it is so easy to use and can be used to ‘glue’ so many things together - for example, it can glue legacy system information to web-based application information - an overabundance of XML elements, schemas, or other components have been developed. As a result, the industry is already flooded with ‘legacy’ XML elements even though XML is relatively new. This presents a burden to the developer, IT manager, or system that is trying to use a given registry.

The first building block in defining an XML vision is to define a common language. From that language, common actions or business processes can be developed. Upon common actions or business processes, common services can be developed. Creating a primary, “umbrella” federal XML registry/repository is the first step in the process of defining a common language or taxonomy. Once an agency has determined a common language within itself (or has reused pieces of a common taxonomy already defined by one of the other agencies), it can then start developing a common language for those transactions that are specific to its mission. For example, the Department of Housing and Urban Development (HUD) may have a requirement to define a mortgage lender in a new application. The developers of the HUD solution could refer to the XML.gov Registry/Repository and find that other government agencies have already developed a common language for describing a lender (whether a business entity or person). HUD could begin to shift their focus from defining an element (through re-using the existing artifact) to one of adapting a current taxonomy to meet their needs.

For some of the smaller agencies, the ability to access and use the resources of the primary Federal XML registry would enable them to overcome budget barriers that have in the past prevented them from engaging in their own XML initiatives. It would provide those organizations with the opportunity to reap the benefits of the Presidents e-Gov initiatives, effectively taking advantage of the work performed by larger agencies with larger IT budgets. Ultimately, this ability would enable all agencies to reach the =the same level of technical capability.

There are many external providers who likely have the capability to host and operate a Federal XML registry/repository. The primary reasons for not selecting an external provider for this service are centered on data sensitivity and the need to leverage and promote the use of the registry to foster reuse and innovation. This issue is further discussed in Project Description section of this document.

Project Description

The XML.gov Registry/Repository initiative will establish a primary government-wide federal registry/repository for XML artifacts that are generated and maintained by federal government entities. It will be operated in a federated fashion in order to balance specific agency needs and the requirements of standardization, interoperability, and reuse. The federated model consists of a primary registry—XML.gov— and government-wide coordination function that links all individual agency registries and ensures their interoperability with one another and the primary registry. This primary registry would also serves as the registry/repository for agencies without individual registries.

Concept of Operations

Projects and programs will come to the XML.gov Registry/Repository during their early planning activities, in order to determine if an artifact (e.g., an XML schema) has been developed that could be leveraged to satisfy their needs. If no artifact exists, the project would develop a new series of XML artifacts. These artifacts will undergo a series of validity checks to ensure that they comply with minimum technical and other standards, and will then be placed in the primary registry/repository for management and future reuse by other projects and programs as appropriate.

The federal government is increasingly interdependent upon other governmental entities, businesses and citizens in successfully enacting business processes operating among many communities of interest. Therefore, the concept of operations for the XML.gov Registry/Repository initiative is based upon a set of current operating practices that exist within the federal government and industry regarding the creation, storage and management of XML based artifacts. The initiative will create a means to better facilitate interaction among and across communities of interest through the publishing, sharing, and reuse of standard XML artifacts.

Customers and Stakeholders

The customers and stakeholders for this initiative are as follows:

Federal Systems and Application Developers – Those who are developing IT applications and software for use by the federal government. As direct users of the federal registry/repository, they will ensure that XML artifacts are leveraged within custom-built software.

Systems Architects – Those who are designing systems and work processes for the federal government. These individuals will need to alter their design approaches based on the appropriate XML artifacts and to accommodate technical interoperability with the XML.gov Registry/Repository.

Repository and Records Managers – Those charged with the compilation, retention, and stewardship of federal records. The format in which data is retained and retrieved must conform to federal standards and mandates. The artifacts within the repository will support these formats.

Program Managers – Those managing Federal programs in support various agencies’ missions. The business process and standard policies must be reflected in the reusable XML artifacts housed in the repository.

Suppliers to the Federal Government – Those organizations that provide products and services to the federal government. The standardization of data interfaces through the use of XML will enable suppliers to transact electronically with the federal government.

Federal Agencies – All federal agencies must conduct business – whether transactional or the dissemination of information – through electronic channels. The XML is a foundational element of that requirement.

State Governments – Those organizations within state governments that require close collaboration with the federal government and that report to the federal government. XML artifacts will enable efficient, consistent and standardized reporting, as data definitions for individual reporting transactions and technical specifications will be prescribed by and stored in the XML.gov Registry/Repository.

Local Governments – Those organizations within local governments that require close coordination with the federal government. For example, organizations associated with parks and recreation coordination and those that satisfy rapid response/law enforcement needs.

Technology Providers – Those who produce COTS products for use by the federal government. The development of these products will leverage the XML artifacts in the repository and exploit the services of the registry as it evolves.

Key Assumptions

A number of programmatic, technology, and cost assumptions have been made about the Registry/Repository for the purposes of conducting this analysis. The assumptions most critical to the overall business case analysis are presented below:

· The use of XML and XML artifacts by all stakeholders and COTS vendors is an established practice that will increase over time.

· Standards bodies involved in the development of the XML language (e.g., the World Wide Web Consortium or W3C), as well as the usage of XML within business and technical contexts (e.g., Electronic Business XML [ebXML], Universal Description, Discovery, and Integration [UDDI]), are converging in areas, which will promote rapid growth of XML and web services usage.

· XML artifacts can be leveraged within and across communities of interest that traverse organizational boundaries. The value of the registry/repository is fully realized when XML artifacts are leveraged within communities of interest as well as across communities of interest.

· The target technology environment will be ebXML standards-based to the extent possible and to the extent that standards are suitably represented in COTS products. The technology environment may not necessarily utilize ebXML compliant specifications in totality.

· The target technology environment aims to satisfy civilian government use for non-intelligence oriented XML activities.

· A security plan will be incorporated into the implemented Governmentwide registry solution.

· The target technology environment will be comprised of scaleable hardware and software to accommodate unplanned and potentially unforeseen periods of peak processing.

· There is sufficient and available network capacity to support anticipated transaction volumes.

· The agencies have adequately skilled staff and training programs or can acquire needed resources to support interactions with the registry/repository.

· All permanent staff supporting the Program Management Office for the XML.gov registry are government staff.

· The discount rate for determining present values of cash flows is 5.4%; the inflation rate is 2.13%.

· The XML.gov government-wide registry/repository will be established as an inter-agency IT initiative, with a managing partner agency designated to manage operations.

· The managing partner agency will establish a Program Management Office to manage implementation and operation of the overall program and to coordinate policy, government-wide outreach, and ensure technical interoperability across all federally sponsored registries.

Key Risks

Lack of Awareness: Developers and stakeholders may not be aware of the existence of the registry/repository and will therefore not contribute to or reuse its content. This risk will be mitigated through the establishment of an XML.gov Registry/Repository initiative outreach campaign and the inclusion of the federal registry/repository within the FirstGov environment.

Lack of Executive Support: Federal executive leadership may not fully support the need to share and collaborate across and among communities of interest or ensure that their individual local registries operate in a federated fashion, i.e. interoperate with the flagship or primary federal registry/repository (XML.gov). This risk can be mitigated through committed leadership support of and outreach by the XML.gov Registry/Repository initiative from OMB and the CIO Council.

Lack of Enforcement: Standards may be ignored in favor of local requirements and developer preferences. This will be mitigated through the use of a governance model that will invite participation from registry owners and communities of interest.

COTS Alignment: COTS vendors may not embrace XML nor have the flexibility to accommodate XML Schemas in their products. The mitigation strategy for this risk includes the incorporation of rapidly growing solutions that support XML. Additionally, XML support should be added to the purchase criteria for all federal COTS purchases. This requirement should be similar to the “web based” requirements that exist in most federal COTS purchases.

Cultural Resistance to Interdependence: Many federal agencies and programs have an ingrained culture that resists dependency on outside contributors and managers to complete their mission. This risk will be mitigated through an open and participatory governance process, well-documented standards, and the building of an awareness of strong benefits associated with the sharing of information through the use of a central primary XML registry/repository.

Poor Security Controls: The existence of a primary federal registry/repository will create greater visibility to XML schemas and artifacts across a wide user population, potentially putting the security of sensitive information at risk. This risk will be mitigated through the use of security controls on the specific data in the registry/repository (e.g., authentication) and by the employment of the federated model, which will enable individual registries to keep sensitive information localized.

What are Barriers to Success?

There are two major barriers to the successful implementation of a federated model of registry/repositories that will affect the XML.gov Registry/Repository initiative:

How Much of an Investment is Required?

This section identifies the required budgetary resources for the preferred alternative to appropriately fund, across the government, the deployment of the federated model of registry/repositories, with a primary government-wide XML registry/repository acting as a hub. Funding needs are organized into three stages of the initiative and its deployment—planning, full acquisition, and operations and maintenance—as required by the OMB business case process.

Typically, planning money is used to identify strategies and alternatives for solving a program’s problems. This and the full acquisition money constitute the investment. Operations and maintenance (maintenance) money funds recurring expenses and system and program maintenance. In addition, within each project stage are two subcategories: budgetary resources and outlays. The budgetary resources category indicates how much funding is required for a particular program. Outlays show when the money is spent. For this analysis, we assumed that the money is spent by the end of the year for which it is authorized; therefore, budgetary resources and outlays are the same.

The overall investment requirements for the, the federated registry/repository model, with a primary government-wide federal registry, are outlined in the table below. Table 2 reflects the costs to the federal government as a whole (ten year lifecycle) for this alternative. These costs include: the costs of establishing and operating a primary federal registry/repository that will link all individual registries, the costs of the individual agency registries that are assumed to exist, and costs associated with new registries that will be created between 2004 and 2013.

Table 2: Required Investment

Link to Mission and President’s Management Agenda (PMA)

How does this investment support the requesting agency's mission and strategic goals and objectives?

The XML.gov Registry/Repository initiative is a foundational, government-wide effort that will provide capabilities that may be leveraged across all federal agencies and programs. It is one the building block of technological capabilities required to enable the more efficient and effective communications and transactions across federal agencies. The initiative addresses a variety of government-wide strategic and legislative goals, including all of the cross-agency e-Government goals identified by the President’s e-Government Task Force and the Government Paperwork Elimination Act. The existence of a Federal XML registry/repository will enable many of the goals articulated in the President’s Management Agenda (see below) including: closer coordination among agencies; information sharing across all levels of government; more transparent supply chains and acquisition processes; standardized reporting; and digital correspondence.

How does the investment support the strategic goals from the President's Management Agenda?

The President has called for "active, but limited" Government: one that empowers states, localities, and citizens to make decisions; ensures results through accountability; and promotes innovation through competition. According to the President’s Blueprint for New Beginnings, if reform is to help the federal government adapt to a rapidly changing world, its primary objectives must be a Government that is citizen-centered, results-oriented and market-based.

Funding of the XML.gov Initiative is justified by its support of one of the five key elements in the President’s Management Agenda – Expanded Electronic Government. As articulated by OMB, “the vision of e-Government is an order of magnitude improvement in the federal government’s value to citizen.” To enable this vision, the President’s e-Government Taskforce identified initiatives in four categories:

• Government to Citizen - focused on “building easy to find one-stop shops for citizens to create single points of easy entry to access high quality of governmental services.”

• Government to Business - focused on “reducing the burden on businesses by using Internet protocols and consolidating the myriad of redundant reporting requirements.”

• Government to Government - focused on making “it easier for States to meet reporting requirements, while enabling better performance measurement and results.”

• Internal efficiency and effectiveness – focused on the need to “improve the performance and reduce costs of federal government administration by using best practices in areas such as supply chain management, financial management, and knowledge management.”

The XML.gov Registry/Repository, being a foundational, government-wide capability, addresses all four of these areas.

Table 3: PMA Support

PMA Goal: Expanding e-Government		XML.gov Initiative Characteristics
Citizen – Centered	Government-to-Citizens (G2C); Create easy-to-find single points of access to government services for individuals	§ The XML.gov Registry/Repository will support the 24 government-wide e-Gov Initiatives through the facilitation of standardized XML-based data that can be leveraged by all government web sites in a consistent manner. Further definitions of XML components will lead to additional data being made available in formats that can be easily accessed and displayed by current web sites. § Businesses will have reduced reporting and regulatory burdens through the electronic searching of federal regulations and the electronic filing of reports and inquiry responses. The data standards to support these electronic processes will be XML based and housed in the federal registry/repositories and accessible through individual agency registries as well as the primary registry. § Governments will be able to create seamless processes by linking systems and standardizing data formats through the use of XML schemas, which will be housed in the federal registry/repositories.
	Government-to-Business (G2B); Reduce the reporting burden on businesses —businesses should not have to file the same information over and over because government fails to reuse the data appropriately or fails to take advantage of commercial electronic transaction Protocols
	Government-to-Government (G2G); Share information more quickly and conveniently between the federal and state, local, and tribal governments.
Results-Oriented	Internal Efficiency and Effectiveness (IEE); Make better use of modern technology to reduce costs and improve quality of federal government agency administration, by using industry best practices in areas such as supply-chain management, financial management and knowledge management.	§ The existence of common XML artifacts will foster reuse among Federal developers and integrators and create a vehicle for standardized information exchange within and between agencies. This will provide an improvement in the cost effectiveness of the government considering that the development of a single XML Schema can cost over $1M. Also, XML artifacts will be used as one of the core “building blocks” in instituting industry best practices (supply chain management, knowledge management, etc.) in that data can be tagged and described in XML and schemas and components can be shared via the primary registry/repository (a common practice in industry).

Sources: President’s Management Agenda, President’s Blueprint for New Beginnings.

Are there any alternative sources in the public or private sectors that could perform this function?

Many XML registries currently exist in many different private sector industries. However, these registries cannot fully satisfy the needs and requirements for a federation of government-sponsored XML registries. Government business processes, while they may be composed of many of the same elements that exist in private industry, there are more than likely an equal number of elements that will be of no value in private industry and therefore do not exist in their registries. The factors that contribute to the inherently governmental nature of the XML.gov registry include:

· Security requirements will vary far more widely and be more regimented than in private industry.

· The reporting and information collection needs of the federal government are unique.

· The federal government has a greater need to make information publicly available to the citizens than is needed in private industry.

Technical Description and Plans: Technology and Architecture

The purpose of the Federal CIO Council XML Working Group is to accelerate, facilitate, and catalyze the effective and appropriate implementation of XML technology in the information systems and planning of the federal government. The XML working group intends to define an XML registry/repository technical solution and architecture that supports data interoperability and minimization of data overhead within the federal government. This data harmonization effort aims to promote a citizen-centered approach to government, establish data conformity and standardization, promote interoperability between disparate systems, improve the efficiency of agencies government-wide, and facilitate standardization of XML based entities and definitions across the federal government.

The XML Working Group defines a registry/repository on their web site as follows:

“A registry/repository is a mechanism used to discover and retrieve documents, templates, and software (i.e., objects and resources) over the Internet. A registry is the mechanism used to discover the object. The registry provides information about the object, including the location of the object. A repository is where the object resides. A user retrieves an object from a repository.”

In its May 2001 report entitled “Requirements for an XML Registry,” the Logistics Management Institute defined a registry/repository as follows:

“An XML registry is an integrated software system that consists of two distinct components, a registry and a repository. A registry is a facility that stores relevant descriptive information (known as metadata) about registered objects, and allows the metadata to be operated on in various ways. A repository is a storage facility for registered objects with an access method that enables retrieving individual objects, perhaps with an additional authentication and permission layer.”

The intention of the registry/repository solution is to provide a clearinghouse for federal XML Schemas and related artifacts. XML artifacts include metadata, XML transformations, DTDs, XML instance documents, or PDF files describing the use and modeling of the XML Schema. The registry naturally amplifies artifacts associated with XML Schemas through logical associations. The overarching goal of the registry/repository solution is to create a federal directory of XML related artifacts. The ultimate purpose of a primary federal XML registry/repository is to support more efficient electronic business within the federal government.

Varying terminology is often used in reports and discussions surrounding the context of an XML registry/repository to help clarify technical architectural details. The architecture specifies foundation terminology to clearly articulate and distinguish the architecture recommendation from pre-existing technical documents in the registry/repository arena, XML specifications, and other reports about XML that do not necessarily share consistent meanings of certain technical terms. For the purposes of this document, core architecture terminology includes the following:

· Extensible Markup Language (XML) is a tagging language used to describe and annotate data so it can be consumed by human and system interactions. XML is typically arranged hierarchically using XML elements and attributes. It also uses semantically rich labels to describe elements and attributes to enable meaningful comprehension. An example of XML data describing an element named “Person” appears as follows:

</Person>

· XML Schema Definition (XSD) is a W3C specification that defines how to formally describe XML elements within an XML document. XSD descriptions enable a system to verify that all XML data adheres to the element description rules within the XML document. An XML Schema represents an abstract characterization of XML elements that indicates an object’s relationship to other objects in the XML document. A system considers an XML document valid when it conforms to the specifications in an XML Schema.

· Metadata is descriptive information about other data. When applied to an XML context, metadata typically conveys information relating to XML structure, context, and use so as to help further describe an XML artifact.

· Electronic business XML (ebXML) is a joint consortium between OASIS and UN/CEFACT. OASIS typically has a commercial focus as it sets objectives per the direction of its predominantly industry-based members, whereas UN/CEFACT acquires direction from bodies represented in international governments as found in the United Nations. Relevant ebXML specifications for the federal XML registry/repository initiative provide business process collaboration, exchange of XML business semantic knowledge (i.e., XML registries), messaging protocols, and trading profile management and discovery.

Overall, ebXML specifies methodologies and specifications for describing business processes and organizing XML artifacts in a registry to facilitate their use with business processes. ebXML registry/repository products specify a semantic registry. A semantic registry primarily stores meaningful XML-based semantic content (e.g., metadata information about elements), as well as classifications and associations of that semantic content. ebXML provides specifications for ebXML messaging service capability, establishing a more sophisticated specification for XML based Web services that aims to solve a similar problem as competing Web services specifications. Although no formal ebXML product certification is currently available, product companies are able to build products based on the interpretation of specifications. Moreover, NIST is in the process of establishing an ebXML compliance and conformance standard to verify validation points of ebXML compliant registry software.

· Web services are self-describing, self-contained, modular units of software application logic that provide defined business functionality. Web services are consumable software services typically including some combination of programming and data. They may also include human resources made available from an organization’s UDDI server for Web users or other web connected software. Web services can be aggregated with one another to establish a larger workflow or business transaction. Inherently, the architectural components of Web services support messaging, service descriptions, registries, and loosely coupled interoperability.

· Universal Description, Discovery, and Integration (UDDI) is an OASIS specification that defines an XML-based registry for organizations to list and describe their Web services on a network. UDDI enables organizations to find beneficial software capabilities on the Web and interoperate with those systems for data exchange and commerce. UDDI is often compared to a telephone book's white, yellow, and green pages; it allows businesses to be listed by name, product, location, or the Web services they offer. UDDI is intended to operate as a general registry for Web services, as well as XML artifacts and schemas specifically associated with those services.

· Simple Object Access Protocol (SOAP) is a means for a program running on one kind of software platform to communicate with a program on the same or different kind of platform using standards based HTTP and XML as the mechanisms for information exchange. SOAP specifies how to encode an HTTP header and an XML file so that a program on one system can call a program on another system and pass it information. SOAP also specifies how the called program can return a response, thus making it an overall data exchange governance standard.

· The Web Services Description Language (WSDL) is an XML-based language used to describe the services offered by an organization and provide a way for individuals and organizations to access and search those services electronically. WSDL language describes services listed on a UDDI directory and is, therefore, a cornerstone of the UDDI initiative.

Enterprise Architecture: Applications and Technology

The strategic XML registry/repository architecture topology provides insight into an architectural roadmap for the future of a federal XML registry/repository system (federation) in FY2004 and beyond. This specification encapsulates critical functionality identified by members of the Federal CIO Council XML Working Group, as well as any outstanding future requirements for extending core functionality as XML-based technology evolves. The three architectures considered include the status quo architecture, the centralized registry/repository architecture, and the federated registry/repository model.

Figure 1 depicts the federal government’s current (status quo) XML. There are currently several federal XML registry/repositories that facilitate the management of XML artifacts. One of the key distinctions of the configuration of current environment is that there is progress in the accumulation of federal XML artifacts, however there is minimal to no coordination.

Figure 1: Status Quo Registry/Repository Logical Architecture

Conceptually, the status quo architecture indicates the federal government’s positive momentum toward increasing the use of XML technology. However, the notion of the architecture scaling across many agencies in the future creates a scenario in which there may be limited opportunities for knowledge sharing. For example, knowledge-sharing may only occur through word-of-mouth ,or among individuals residing in agencies that are more aware of the benefits of sharing XML elements and the activities of others in this area. In the status quo architecture, ebXML standards have sufficient sanction, but lack consistent implementation: the current architecture is a mix of highly customized registries considered to be only semi-compliant to ebXML 2.0 specifications. Many of these registries are high budget, homegrown solutions giving credence to ebXML 1.0 and 2.0 specifications as core requirements. However, these customized software solution development efforts are often burdened with highly proprietary functionality incorporated during development process. This approach inherently leads to costly inefficiencies that will be realized as new ebXML standards emerge and the government fails to take advantage of anticipated innovations of COTS registry/repository solutions.

The centralized architecture shown in Figure 2, below, illustrates a single centralized federal registry/repository for capturing all XML artifacts within the federal government. In this scenario, all existing federal XML registries would effectively shut down and all XML artifacts would be migrated into the centralized registry.

Figure 2: Centralized Registry/Repository Logical Architecture

Figure 3 depicts a “federated registry/repository model.” The architecture of this model operates as a series of distributed services utilizing registry nodes built on a foundation of a peer-to-peer network. From this perspective, each registry operates as a de facto “meta registry” and has the ability to enable interactions across other registries in the federal government, existing in accordance with the interoperability standards specified in the architecture. The federated registry/repository model supports visibility into inter-agency XML initiatives and mandates a minimum set of implementation specifications to participate in the registry/repository landscape. In this model, the landscape is governed by the primary or flagship government-wide registry/repository that acts as a hub linked to all individual agency registries.

Figure 3: Mature Federated Registry/Repository Logical Architecture

The federated registry/repository model recognizes that a single centralized approach will not work well for all systems and agencies government-wide. Even with the advent of UDDI based registries for Web services, many organizations foresee that intra-organizational registries will be far more common than inter-organization registries. However, collaborative vertical agency registry silos can be quite useful if they are developed on common ebXML standards.

This model functions on a hypothesis that some adoption of registry standards in a distributed fashion is better than the alternative of no standards adoption and the resulting disparities between registry/repository solutions that is seen in the status quo environment. (?) Inherent conformance pressures from organizations wanting to collaborate with non-conforming agencies will aid in creating positive momentum government-wide. The model is essentially a lightweight, general-purpose architecture built on ebXML standards that enables adoption of emerging XML standards to increase registries’ future value.

Any individual registry/repository within the federated registry/repository model architecture is able to negotiate and exchange information with other registries within the federation. Additionally, a federated registry model can facilitate cross-searches of other registry indexes for relevant information and provide pointers to relevant XML artifacts for either human or system consumption. As the propagation of new XML registries will inevitably continue within the federal government and at other levels of government, registry synchronization and interoperability goals become increasingly imperative. Enterprise reuse and establishing a distributable technology architecture that different agencies can leverage is critical within the federated registry/repository model.

The federated registry/repository model also supports the unencumbered innovation and customization of independent registry/repository capabilities above and beyond core registry/repository specifications (provided core compliant capabilities exist as prescribed by the relevant standard). This model equally supports multiple, distributed registrars that perform registration activities on behalf of other organizations at either an agency or aggregate agency level depending on the functional classification.

The mature federated registry/repository model shown in Figure 3 provides automatic and transparent synchronization between all registries in the federation. Essentially, all servers are created on a common registry/repository platform to afford synchronization, interoperability, and minimize future refactoring. The synchronization capabilities are crucial to satisfy the federal government’s goal of supporting independent registries at an agency level, while providing access to various XML artifacts government-wide. For example, a user of the primary government-wide XML registry/repository can search for registered XML Schemas at any single registry within the federation without manually spanning and interacting with several different registries—a one-stop shopping capability enabled by the primary registry. This enables a user to use the registry of their choice. Following the logic of a UDDI Web services registry, any federated XML registry/repository node replicates any XML artifact registrations defined as “publicly distributable” across all nodes, resulting in a complete set of registered records available to all peer nodes. The node operators all support common registry capabilities to ensure the integrity and availability of provided information. The federated registry/repository model also assumes synchronization of registry classification schemes following a similar model as UDDI, where replication of certain data occurs as necessary to support classification interoperability between registries.

During the initial lifecycle deployment of the federated registry/repository model— preliminary ramp-up and standardization coalescence— existing registry efforts would plan to align their registry architectures with the primary federal XML registry/repository architecture. After aligning technology plans and moving forward with architectural changes in the federation, registry/repository synchronization can then be implemented as specifications are released that provide guidance on enabling synchronization between registries. The federated registry/repository architecture model reasonably assumes that within two years from the initiation of the registry/repository effort, specifications will exist from either ebXML or another standards body that provide guidance in synchronizing registries. Various stakeholders within the ebXML community have noted that such synchronization is already identified as a key future specification intended for availability in upcoming ebXML specification documents. In the event that ebXML fails to put forth appropriate synchronization specifications, the federated registry/repository model will support a workable concept of synchronizing registries through the use of peer Web services existing on each registry/repository in the federation.

Figure 4: Preliminary Federated Registry/Repository Logical Architecture

The interim federated registry/repository model in Figure 4 captures a multitude of XML related items in an ebXML compliant registry/repository potentially residing (initially) at FirstGov. The architecture enables rapid, government-wide collection and access to the increasing number of federal XML artifacts from agencies with or without an XML registry/repository. The preliminary approach also enables the government to immediately proceed with semantic standardization efforts before approaching the complexities of registry/repository standardization and interoperability issues. In summary, the complete federated model establishes a distributed XML knowledge management system for creating government wide efficiencies in leveraging XML artifacts and more effectively incorporating XML into electronic business processes.

XML Registries and Web Services

The federal government and industry will progressively move in a direction of supporting open market Web services based on the standards UDDI, SOAP, and WSDL. In discussing ebXML Web services in relation to open market Web services, it is essential to note that non-ebXML (i.e., open market) Web services typically have inherent technical interoperability. Non-ebXML Web services as implemented by IBM, Microsoft, BEA, and other software vendors provide easily implementable capabilities that do not impose restrictive business processes on the organization leveraging the Web service.

The concept of industry-embraced Web services should not be thought of as a W3C owned and controlled set of specifications. OASIS is actively working on many critical specifications surrounding non-ebXML Web services including WS-Security, UDDI, and other specifications beyond the work of the W3C. Thus, it is not necessarily valid to say that the W3C standards are the only foundation “XML Family of Standards” as the Gartner Group occasionally points out in respective reports. Standards from various organizations such as OASIS must be examined in tandem with the W3C standards when making forward thinking decisions for federal government architectural initiatives. This concept further lends credibility to OASIS sponsored ebXML specifications.

Non-ebXML Web services are known for being loosely coupled request/response processes with limited business process semantics. As such, semantic interoperability between Web services cannot be guaranteed given that current specifications do not prescribe a solution beyond providing narrative information within the WSDL file or associated XML Schema. Non-ebXML Web services also do not require an agreement between the requester and the provider to ensure semantic interoperability. Utilizing the federated registry/repository model for such purposes, agencies will then able to hone in on the goal of a zero latency enterprise by conducting business without the prior establishment of formal relationships for data exchange purposes. This loosely coupled model based on a stateless request/response architecture facilitates rapid data exchange solutions with lower recurring maintenance costs, as a result of easily consumable changes. Whereas ebXML typically concentrates on a document centric semantic integration mechanism, non-ebXML Web services incorporate a non-semantic and semi-agnostic data services integration approach anticipating that the Web service’s lightweight WSDL file sufficiently describes the action of the Web service.

As open market web services are much less rigid, ebXML provides what many consider to be higher-end and semantically rich Messaging/Web Services specifications. Additionally, ebXML provides more robust ties between ebXML compliant artifact registries and ebXML-based Web services. Nevertheless, an ebXML Web services implementation requires more significant interactions between trading partners. A trading partner desiring to engage a service provide in an ebXML-compliant transaction must perform the following activities:

• Download a copy of the ebXML specifications.

• Download the core library and business library.

• Request service provider’s business process information for analysis and review.

• Submit its business process information to an ebXML-compliant registry.

Both ebXML and Web services initiatives are characterized as enabling systems in different organizations with distinct sizes and locations to discover one another, conduct automated data integration processes with one another, and subsequently do more business with one another in the future. The ideal integration scenario involves companies being able to negotiate business transactions easily and efficiently with minimal non-automated interaction. ebXML Web services primarily differentiate themselves from non-ebXML Web services by channeling integrated Web services into pre-defined and highly structured business process specifications by which trading partners abide. This level of semantic integration helps minimize invalid uses of Web services messaging, whereas non-ebXML Web services allow an organization to interact with trading partners using limited semantic understanding and highly flexible downstream integration options.

No formal relationship currently exists between UDDI and ebXML specifications. However, UDDI and ebXML exist as complementary technologies such that organizations using ebXML Web services can register their business and Web services in a UDDI registry. Subsequently, UDDI Web services, service types, and specification pointers have the agility to point to an ebXML registry/repository for business and technical descriptions of the services. Moreover, organizations that register XML artifacts such as XML Schemas or XML Style Sheets in an ebXML compliant registry/repository can also register the existence of these artifacts via a URL as “service types” in a UDDI registry. This enables UDDI Model specification entries to point to these remote XML artifacts that actually reside in the ebXML registry/repository. The only UDDI requirement for an XML artifact storage mechanism is that it makes the resource available via HTTP GET.

Ideally, federal organizations involved in data exchange are able to leverage XML Schemas and Web services without negotiating formal relationships with the content originator or necessarily being legally compliant with any sponsoring organization (i.e., an authorized ebXML trading partner). This just-in-time data integration model seeks to reflect modern aspects to data interchange and support rapid consumption of business definitions and services. The federated registry/repository architecture further supports the notion of non-ebXML compliant applications leveraging the registry’s resources. Essentially, a trading partner, or user of the registry, is able to leverage registry resources without being ebXML compliant themselves or specifically having an ebXML collaboration protocol profile (CPP). This approach promotes the efficient and effective use of XML, in line with the vision of the Federal CIO XML Working Group, while not overtly restricting partner organizations to precisely comply with ebXML standards. Moreover, the architecture reflects the concept that not all users, agencies, and trading partner organizations that can benefit from the registry will retain the technology sophistication or comprehension required to use or contribute to the registry under ebXML conformity.

The federated registry/repository model implies that government should follow ebXML specifications to the extent possible for registry/repository implementation, but proceed more slowly in embracing ebXML Messaging and ebXML Web service specifications as they appear to be losing traction even in the midst of higher sanction by some standards bodies. ebXML 2.0 registry/repository specifications do not preclude the federal government from moving forward with the federated XML registry/repository approach, even if future registry/repository customizations must be to spearhead XML adoption and collaboration government-wide. Inevitably, over the course of the ten-year lifecycle of the XML.gov initiative, the federal government will need to move beyond ebXML registries to more robust industry standards with product backing and tangible vendor momentum. Industry momentum and market adoption are helping to make Web services architectures leveraging specifications such as UDDI, SOAP, and WSDL key foundations in modern enterprise architectures. Although ebXML provides certain specifications for Web services as well, the ebXML Web services standards are viewed by various stakeholders as far more complex than the aforementioned standards (i.e., UDDI, SOAP, etc.); overly bound to complex business processes; and lacking sufficient market adoption and product traction.

Enterprise Architecture: Data

The XML.gov Federal Registry/Repository Initiative’s implementation consists of technologies that accommodate citizen, user, and customer activities relating to XML artifacts, most notably XML Schemas. The initiative’s implementation consists of a distributed environment with some or all of the supporting technologies being housed in separate facilities from the users. It can be developed utilizing COTS products, and designed and implemented following hardened industry and federal standards and best practices. Moving forward with the federated model, it will be necessary for multiple vendors to provide consistent and reliable interoperability between their technologies to ensure more robust data architecture across registries. Existing data architecture benefits of ebXML 2.0 include the following: 1) strong relationships between XML artifacts such as well as associations of XML artifacts; 2) support for more granular data elements and robust associations between those elements; 3) strong capabilities in document lifecycle management; and 4) generation and management of rigorous classification schemes.

Consistent data architecture and interoperability between XML registries operated by different federal agencies is imperative to success of the federated XML registry architecture. Given that multiple XML registries are already operational in the federal landscape (e.g., DOD XML Registry, EPA Environmental Data Registry (EDR), DOJ Registry, etc.), it will be necessary to review the architecture of these existing registries to ensure compliance with the forthcoming federated XML registry standard.

GAO defines interoperability as follows:

“Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged.”

The GAO definition implies both technical interoperability and semantic interoperability. Technical interoperability means that the architecture must work with lower level technical details such as protocols (e.g., HTTP), languages (e.g., XML), and potentially even traverse systems such as firewalls that may explicitly prohibit interoperability by limiting data exchange. In contrast, semantic interoperability implies that the architecture supports systems’ use of the exchange information based on a shared comprehension and agreement on the meaning of that data. Two systems may be able to technically interoperate with one another successfully, but one system may have a significantly divergent interpretation of the data being exchanged if the semantic meaning of that data was not understood or delineated within the data exchange process.

Overall, well-defined interoperability facilitates system collaboration between a heterogeneous set of platforms, applications, and programming languages by transparently supporting XML data negotiations between systems. ebXML specifications state that the primary reason for conforming to ebXML is to increase the probability of the interoperability between XML registry implementations being successful. Ideally, registry/repository specifications from standards bodies must be integrated to ensure traction and the ability for software product vendors to develop consistent software models that map to clearly understood specifications with minimal to nonexistent overlap. Registry interoperability must be dealt with at a level beyond specification-by-specification software patches. The government needs to expect that ebXML interoperability standards will show longer term, clearly defined vision. Without such well-defined interoperability even the most sophisticated ebXML registry/repository specification will inevitably lack market traction.

A government-wide XML syntactical and semantic vocabulary and artifact classification is continually evolving as federal business processes and requirements evolve. It is impractical to suggest that once the government adds all XML Schemas for all business processes to the registry, a final and complete vocabulary would exist. The goal of the federated registry/repository is to disambiguate elements using useful, logical, and relevant XML namespaces that are closely mapped to functional communities of interest. Utilizing registry interoperability standards such as ebXML, classification interoperability between registries is likely to be more attainable. Leveraging ebXML enables the federal registries to work together efficiently with classification taxonomies, while still operating semi-independently. Additionally, proper classification of XML artifacts by communities of interest ensures the utility of the registry federation. There is an implicit benefit in being able to leverage progress and historical lessons learned, while simultaneously sharing benefits in current XML initiatives based on existing definitions. One can assume that inherent synergies will occur between organizations working with similar XML vocabularies, and natural consolidation processes will occur at both intra and inter-organization levels.

The overarching goal of the federated registry/repository data architecture is to foster standardization of data definitions, data exchange business processes, and data sharing. The inefficiencies existing in federal systems constantly exchanging data with different systems and using disparate XML and non-XML vocabularies provides implicit momentum to move forward with XML registries and directories leading to naturally evolving XML-based Web services. During the preliminary lifecycle of the federated architecture model, a substantial number of XML-based artifacts will likely be added to the primary registry/repository. The preliminary phase of the federated registry lifecycle avoids being overly ambitious in demanding common standards for XML Schemas across the government, while accepting that multiple XML definitions will exist. As agencies recognize parallel efforts within their own organization as well as external organizations, the XML data harmonization of a small number of XML Schemas leads to a proliferation of high traction and highly reusable XML Schema core components. These core components benefit future initiatives between current trading partners as well as efforts with yet-to-be-identified trading partners. Community of interest leaders will then be responsible for evangelizing XML Schemas, thereby identifying and advocating the benefits and merits of competing XML definitions to build federal awareness. The registry federation also supports the process of XML Schema creation at various points of its lifecycle by providing useful pre-existing schemas and elements, as well as non-XML artifacts surrounding those schemas. Additionally, refined metadata capture increases the value and propagation of XML Schema standards government-wide, improving semantic meaning. Overall, the collective data architecture activities surrounding XML artifacts in the registry federation enable improvement in efficiencies within data exchange and data semantics between organizations.

Security and Privacy Plan

Although this business case does not propose the complete details of system architecture, privacy and security considerations are an integral component of the development of the primary XML registry/ repository and those registries linked to it. In the implementation of the XML.gov Registry/ Repository Initiative, a variety of mechanisms will be employed throughout its architecture to ensure the privacy and security of services to all of its customers and stakeholders. GSA will identify information exchanges made between federal employees and the registry/repository to determine which of these are or potentially could be subject to any applicable guidance (e.g., the Privacy Act, the Trade Secrets Act, E-SIGN) from appropriate sources (e.g., Laws, Executive Orders, Presidential Directives and Memorandums, OMB Circulars and Memorandums). Relevant requirements will be incorporated into the designs of the initiative’s processes and systems.

As the development of the XML.gov Registry/Repository initiative and associated IT designs advance, a detailed privacy and security plan will be implemented. The plan will summarize what is required of all systems and applications that support the modernized business processes; describe the controls in place or planned; and delineate responsibilities of all individuals who access the system. A certification and accreditation program that must approve both the plan and the implementation of the plan in the production environment will be approved through a certification and accreditation program. A periodical renewal of the certification and accreditation will be performed according to the plan’s specification (e.g., every three years).

Figure 5 illustrates the key components of an IT system security life cycle.

Figure 5: Security Life Cycle

Security Risk Management and Assessment

Risk assessments of privacy, information security, or other types of risk give decision makers the information required to understand factors that can negatively influence operations and outcomes and to make informed decisions regarding how those risks may be mitigated. The XML.gov Registry/Repository initiative will use a risk-based approach to define adequate security. It will take into account such major risk factors as the value of each system, application, and information; threats and vulnerabilities; and the effectiveness of current or proposed safeguards. As part of its security plan for the proposed business transformation, the XML.gov Registry/Repository initiative will:

· Identify threats that could adversely affect critical operations and assets, such as intruders, criminals, disgruntled employees, terrorists, and natural disasters

· Estimate the likelihood of such threats based on historical information and the judgment of knowledgeable individuals

· Identify and rank the value, sensitivity, and criticality of the operations, data and assets associated with the federation of registries

· Estimate the potential costs associated with the impact on the most critical and sensitive assets and operations if a threat should materialize, including recovery costs

· Identify cost-effective actions to mitigate or reduce risk, which might include new organizational policies and procedures, as well as technical or physical controls

· Document the results of the risk assessment and draft an action and risk management plan.

Security Risk Mitigation

Risk mitigation is the selection and installation of privacy and security controls to reduce risk to an acceptable level. The XML.gov Initiative risk mitigation process is depicted in Figure 6.

Figure 6: Security Risk Management

The risk mitigation process consists of the following measures:

1. Select Safeguards: The identification of controls is a primary function of computer security risk management. In selecting controls, the XML.gov Registry/Repository initiative will consider the following factors:

• Organizational policy, legislation, and regulation

• Safety, reliability, and quality

• System performance requirements

• Timeliness, accuracy, and completeness requirements

• Life cycle costs of security measures

• Technical requirements

• Cultural constraints

2. Accept Residual Risk: The XML.gov Registry/Repository Initiative Program Management Office (PMO) will decide if the proposed IT solutions are acceptable, given the type and severity of the residual risks. Acceptance of residual risk will be closely linked with the authorization to place proposed IT solutions into production. The (PMO) will provide for the accreditation and formal approval of proposed IT solutions once a decision on the acceptable level of residual risk has been made.

3. Implement Controls and Monitor Effectiveness: Security risk management must be a continuing process if it is to remain effective. Consequently, the XML.gov PMO will periodically identify, assess and mitigate emerging risks.

Alternatives Analysis

Methodology: Business Case Process Using the Value Measuring Methodology (VMM)

The purpose of preparing a business case is to capture how the value that would be gained from an investment weighs against its costs, taking into account project risks or uncertainty. By capturing this information, the business case facilitates more informed and productive decision-making, and serves as the justification for worthy investments.

This business case was prepared using the Value Measuring Methodology (VMM), an analytical framework compliant with guidance from OMB, which incorporates best practices from both the private and public sectors. The methodology’s framework provides a structured and comprehensive assessment mechanism that extends the boundaries of traditional business case analysis. Utilizing VMM, the cost of the investment is captured and quantified, as is the full range of value it will provide to direct users, stakeholders, and the government itself. This approach also provides the framework for considering and understanding project risks that might decrease its effectiveness and the uncertainties that might blur standard analysis. The completeness of this approach provides decision makers with the information required to explore, understand, and make decisions based upon the relationships between value (benefits), risk, and cost.

The remainder of this section outlines in greater detail the Value Measuring Methodology and its application during the development of the XML.gov Registry/Repository business case.

The Value Measuring Methodology (VMM)

Step 1: Develop the Decision Framework.

The decision framework is the cornerstone of the VMM methodology. It is comprised of three structures:

The Value Structure: Describes and prioritizes value (or benefits) in two layers. Within the first layer are the five Value Factors or major categories of value (Direct User/Customer Value, Social Value, Government Financial Value, Government Operational and Foundational Value, and Strategic/Political Value) that must be addressed when considering the full value of an initiative. Direct User/Customer Value captures value associated with customer or end-user needs and requirements. This Value Factor answers the question: What do users and customers want? Social Value captures benefits realized by individuals or organizations that are neither direct users of the service nor the service provider or initiative leader. The Social Value Factor refers to benefits that accrue to society or taxpayers at large. Government Financial Value captures benefits that have a direct impact on the government service provider and other federal government budgets. In brief, it captures cost savings and cost avoidance to the government as a whole. Government Operational/Foundational Value captures benefits that may be achieved in the operations of both current services (operational) and in preparation for future demand (foundational), e.g. improvements in efficiency and effectiveness of processes and operations. Finally, Strategic/Political Value captures benefits that move an organization— and/or the Government as a whole—towards fulfilling broader mission or strategic goals.

Prioritization of the five Value Factors is done by senior-level government staff representing the priorities and objectives of e-government as defined by the Executive Office of the President. This process is facilitated by the use of an Analytical Hierarchy Process (AHP) tool, Expert Choice, at a moderated session attended by these senior staff members. For the purposes of this business case, data on the prioritization of the Value Factors was taken from a July 2002 moderated session with e-government stakeholders and officials from OMB and GSA.

Within the second layer of the value structure, project or initiative level staff and analysts work with representatives of user communities and partner agencies to identify and prioritize measures that specifically define value (benefits) within each of the five Value Factors. The definition of each measure includes the identification of a metric, a target, and a normalized scale. By identifying a metric for each identified value measure, it is possible to measure and determine whether an initiative has delivered the desired benefits. By translating (or normalizing) performance measurements onto a single scale, it is possible to compare both objective and subjective measures of value. (The normalized scale used in this business case ranged from 0 to 100, where 100 is the best possible score.)

For this business case, analysts, with input from representatives from the user and partner communities, prioritized the benefits within the Value Factors, assigning each with a “weight,” and developed corresponding metrics.

The Risk Structure: The Risk Structure articulates the risks associated with the initiative, including those that impact costs (risks associated with cost overruns) and value (risks that may jeopardize the realization of the benefits).

The Cost Structure: The purpose of the Cost Structure is to define a hierarchy of cost elements to be used for estimating costs and developing the foundational basis of estimate. The project-specific cost element structure (CES) is based on a standard CES developed by Booz Allen Hamilton for IT projects and initiatives, and is tailored to incorporate the specific requirements of the initiative being developed (in this case the XML.gov Registry/Repository initiative). The foundational basis of estimate captures global assumptions (e.g., economic factors such as the discount and inflation rates) as well as project-specific drivers and assumptions (e.g. assumptions about the number of users of a system) derived from developing the Value Structure and articulating the associated project-specific benefits and performance metrics.

Step 2: Conduct an Alternatives Analysis.

During this step, decision makers, analysts, technologists, policy makers, and others collaborate to define and assess alternative solutions for a particular initiative. The alternatives analysis consists of considering alternative means, methods or solutions for providing the functionality that the initiative under analysis aims to provide. For every initiative under consideration the base case, or status quo, is one of the alternatives. The base case alternative captures the impact on both value and costs over time if no initiative is implemented. Each alternative, including the base case, is analyzed against the parameters of the decision framework created in Step 1: performance for each value measure is predicted and scored on the normalized scale; cost are estimated for each cost element; and the risk profile of each alternative is defined. Finally, a basis of estimate for costs is tailored and documented to identify specific cost drivers and assumptions associated with each alternative.

Using statistical simulation software tools, both estimated ranges of cost and value are analyzed to determine the expected or “most likely” costs and value (benefits). Using this approach, in lieu of developing point estimates, is required in order to account for the uncertainty associated with cross-agency e-government initiatives. Finally, risk analyses are conducted to determine the impact and probability associated with each identified risk.

Step 3: Pull Together the Information.

Using outputs of the analyses conducted during Step 2, analysts aggregate the total cost, value (value score) and risk (risk score) for each alternative. Using this information, the effect of risk (risk score) on both cost and value are determined. In addition, this information provides the data necessary to develop two decision metrics for each alternative: the return on investment (ROI) and an index reflecting the level of benefits, or value, achieved for each alternative.

The calculation used to develop the index for comparing the value associated with each alternative in the context of its cost is a simple division problem: the value score of an alternative is divided by the investment cost of the alternative. Decision-makers may use this index to perform an “apples-to-apples” comparison of alternatives to determine which will provide the greatest amount of value “bang-for-the-buck.” This is possible because each alternative was analyzed against the same decision framework in which all value was translated onto a single scale.

Description of the Alternatives

Alternative Selection and Development

As part of this business case analysis (BCA) process, the project team attended stakeholder meetings that included partnering agency representatives from the CIO Council XML Working Group. During these meetings, the objectives and intended parameters of the XML.gov Registry/Repository initiative were discussed. Stakeholders articulated the value proposition and a range of high-level concept of operations. The result of these discussions established a clear vision of a desired end-state: 1) streamlined, simplified and rapid access to XML artifacts related to government transactions; and 2) the accessibility of government-unique requirements for business partners through an authoritative source of XML artifacts that support business processes and transactions between the federal government and citizens, businesses and state and local governments. This specified vision formed the basis for developing three alternatives briefly described in Table 4.

Table 4: Summary Description Of Alternatives

Alternative	Description
Alternative 1: Base Case (or Status Quo)	Undertaking no coordination activities to ensure the interoperability of all government-sponsored registry/repositories and to facilitate the retrieval of government related artifacts. Any and all agencies could build, operate, and maintain any number of registries with any variation of underlying technologies and specifications.
Alternative 2: Federated Registry/Repositories	Building a primary government-wide federal registry/repository that acts as both an interoperable portal to facilitate communications between all other existing federal registries and as a repository of artifacts associated with agencies that elect not to build their own registry/repositories. Each agency or federal entity may stand up its own registry/repository so long as it is in accordance with the technical specifications published by the primary registry managers and policy officials to ensure interoperability with all registries in the federation.
Alternative 3: Centralized Registry/Repository	Building a centralized federal registry/repository that lists and stores all artifacts published by federal agencies. The centralized model, or centralized registry, requires that every federal agency wishing to publish schemas or artifacts provide submissions to the central registry/repository for review and approval. This alternative requires the eventual termination of all current XML registry activities in agencies (e.g., EPA, DoD, etc.) and would require existing registries to be subsumed by the new centralized registry/repository.

After the articulation of the initial concept and value proposition, additional refinement occurred. VMM was used to enhance, clarify and measure the value proposition of a coordinated government-wide capability for the publication and retrieval of XML artifacts related to government operations, business needs, and business transactions. The selected alternative, the federated model registry/repositories, was selected based on its ability to provide the types and breadth of value articulated by representatives of user communities and partner agencies, as compared to the base case and the establishment of a centralized federal registry/repository.

The sections below provide a more detailed description of the three alternatives considered.

Alternative 1: The Base Case

The current environment is characterized by a lack of standardization, coordination, and interoperability of government-sponsored XML registry/repositories. No centralized policy group is in place to create and enforce technical standards to ensure the interoperability of the disparate registries and facilitate the reuse and retrieval of their respective artifacts. The technology platforms on which existing registries have been built differ widely, as do the use of COTS products and customized applications. The fragmentation of current XML efforts increases the likelihood that communication within communities of interest will be ineffective. Additionally, redundant, non-standardized XML artifacts are likely to proliferate, eroding one of the key benefits of using XML technologies.

In the current environment, registries are expected to proliferate across government, but are less likely to be interoperable due to the absence of a central, federal, standards-setting body for XML artifacts and registry repositories. In response to the needs of their individual communities of interest, select business partners and internal needs, federal agencies have and will continue to establish XML registry/repositories in a stovepiped manner.

There are currently no less than four functional and production-use registry/repositories in the federal government, but many more are likely to be established in subsequent years as the awareness of the use of XML technologies continues to grow and commercial products that facilitate the development of registries mature. Due to the absence of a coordinating body, the reuse and interoperability of artifacts and registries, respectively, is likely to be minimal. Since the main value of XML technologies lies in the reuse and standardization of artifacts and schemas, the value delivered in the base case alternative is extremely limited.

Alternative 2: Federated Model of Government-Sponsored Registry/Repositories

Because it provides a structure to realize the full efficiency benefits associated with XML, the federated alternative has a significant impact on the value provided to all users of XML technologies and to e-Government stakeholders and leaders. Alternative 2 maximizes the reuse of artifacts and the interoperability of government-sponsored registry/repositories, while enabling Federal Agencies with different business partners to establish, populate, and maintain their respective registry/repositories.

The federated model consists of a primary government-wide federal registry/repository that acts as central portal and interoperable hub to facilitate communications between all other existing and new federal registries and as a repository of artifacts generated by agencies that elected not to build their own registry/repositories. Agencies may stand up individual registry/repositories; however, the managers of the primary federated registry act as a policy body and establish, coordinate, and monitor technical and interoperability standards. A Program Management Office (PMO) is established to provide overall management of the primary registry, management of the federal XML landscape, develop policies, set standards, and monitor interoperability compliance of individual federal agency registries with the primary registry. This operational model ensures that artifacts from any federal registry can be accessed and retrieved regardless of the government-sponsored “point-of-entry” registry. In addition, for those federal agencies electing not to build their own registry/repositories, the primary registry acts as their “home” registry/repository for publishing and leveraging XML artifacts.

The integrated approach provides for a strong government-wide coordination and a centralized management function, while providing individual agencies the autonomy to publish artifacts and operate registries independently according to the specific needs of their communities of interest. As a result, the federated model delivers a number of key benefits to XML users, government business partners, and the federal government as a whole including:

• Simple and rapid access to XML artifacts related to government-unique requirements for all federal business partners

• Improved coordination, communications, and collaboration between federal agencies, as well as federal and state and local entities

• Streamlining of intergovernmental data collection and data sharing

• Reduced administrative burdens

• Improved federal agency information technology performance.

Alternative 3: Centralized Federal Registry/Repository

The centralized registry/repository alternative provides some of the value associated with a federated XML registry/repository in terms of policy coordination and interoperability standards (noting that interoperability is a marginal concern if only one registry exists). However, due to the size and complexity of the federal government and the bottleneck that would likely be created by mandating that any artifact published by a federal entity go through a single registry, the centralized registry alternative inevitably creates inefficiencies and stifles the artifact submission and publication process. Moreover, the centralized registry model is likely to discourage submissions over time due to both the real and perceived onerousness of the submissions process. This decline in submissions may potentially result in a decrease in activity among communities of interest to develop standard artifacts associated with those communities’ respective ranges of business processes, transactions, and systems. As with any initiative, the ability to deliver value is directly correlated to its use. Therefore, the lower the participation in the registry/repository, the lower the level of value it will deliver.

The centralized model, or centralized registry, requires that every federal agency desiring to publish schemas or other XML artifacts provide submissions to the central registry/repository for review and approval. The value of this alternative is lower than that of the federated model in large part because it requires the eventual termination of all current agency-specific XML registry activities (EPA, DoD, etc), requiring that existing registries be subsumed by the new centralized registry/repository and no new individual agency registries be created. This absence of autonomy and independent mechanisms for the publication of XML artifacts would act as a disincentive for agencies to engage in the artifact standardization development and publication activities that would likely take place if agencies could collectively manage their individual XML spaces with other agencies.

The reduction of activities and limitations that the centralized alternative creates with respect to the number of published artifacts and their prospective reuse, erode one of the key value propositions of XML technologies: increased communications among communities of interest and more efficient and effective communications while developing XML artifacts relevant to those communities’ business transactions and needs.

Cost Analysis

Methodology

Once the alternatives were defined, the business analysis team allocated costs to useful and understandable categories defined in the decision framework (listed and described in detail in Appendix A: Cost Element Structure). They then reviewed documentation from similar existing programs and used professional and engineering judgments to populate the cost element structure. This included a consideration of certain standard cost elements developed by the business analysis team to estimate the cost of information technology projects. The first task was to identify costs associated with the status quo, creating a baseline. Primary sources for baseline data were current spending plans for existing XML registries and data gathered from industry on software and hardware costs. In many instances data were not available or were imprecise, therefore sufficient justification for professional and engineering judgments were documented. Additionally, low and high cost ranges were assigned and analyses were conducted to determine the statistical (simulated) expected value –or most likely— cost.

General Assumptions

For budgetary purposes, costs were provided in inflated dollars to determine the total amount that must be set aside for the alternative in question. For comparative purposes, discounted costs were provided to represent future outflows in today's dollars, in consideration of the time value of money. The estimates for this project were based on the following general assumptions:

• While costs will continue indefinitely, changes in equipment costs, workload and other environmental factors are likely at some point in the future. These environmental factors were not built into the cost estimates. A standard ten-year lifecycle was chosen for quantifying each of the alternatives (FY 2004-FY 2013).

• OMB Circular A-94 inflation factors (1.94% for budgetary purposes) and nominal discount rate (5.1% to compare alternatives and costs in current dollars) were applied.

• All contractor rates were loaded with overhead and benefits and were based on GSA’s Multiple Award Schedules IT schedule price list. A work year was assumed to consist of 2087 work hours based on OMB Circular A-76 guidance.

• Government labor rates were based on 2003 rates for step 9 at all specified GS levels. Benefit and Overhead rates of 32.45% and 12% were applied to government salaries based on OMB Circular A-76 guidance.

• Sunk or prior year costs are not included in the estimates.

• Four government-sponsored registry/repositories currently exist and costs have been estimated for those four registries.

• All IT systems and software integration work is assumed to be performed by contractor personnel at contractor labor rates.

• Recurring annual maintenance costs for hardware and software were assumed to total 20% of the initial price of the hardware and software.

• The lifecycle costs for all alternatives reflect the costs associated with the replacement of all hardware every four years.

• The main cost driver for these XML alternatives is personnel, both contractor and government labor.

• All lifecycle cost estimates represent costs to the federal government as a whole.

Alternative 1: The Base Case – Assumptions and Results

The base case alternative assumes the maintenance of currently operating government-sponsored registry/repositories and also assumes that new registries will be established by individual federal departments and agencies over the ten-year lifecycle. The base case estimate reflects the combined government-wide lifecycle costs of all of the registries that are projected to be in operation between
FY 2004 and FY 2013. In addition to the general assumptions discussed in the section above, the status quo cost estimate was based on the following assumptions:

• In addition to the four registries currently in existence and their associated recurring operation and maintenance costs, five additional registries per year will be established between FY 2004 and FY 2007.

• The total number of registries in operation by the end of the ten-year lifecycle is 24, based on the assumption that all major departments will have a registry and that a number of the major independent agencies will also establish registries.

Table 5: Base Case Lifecycle Costs

Based on the analysis conducted to date, the expected total investment cost associated with Alternative 1: the Base Case is $20.8 million, with a total life-cycle cost (FY 2004-FY 2013) of $125.7 million. The expected range for investment is $20.2 million to $21.5 million and the expected range for the total life-cycle cost is $123.4 million to $128.6 million.

Alternative 2: Federated Registry/Repositories – Assumptions and Results

The federated model assumes that a Program Management Office (PMO) for the XML.gov Registry/Repository initiative will be established and that the PMO will act both as an operational entity, building and maintaining the primary federal registry/repository, and as a policy office issuing, monitoring and enforcing interoperability standards for federal agencies’ individual registries. The PMO also serves the function of building awareness across the federal government of the uses of XML artifacts and technologies and their applicability to government business processes. In addition to the PMO, this alternative assumes that select agencies will establish registries individually and link them to the primary registry, while other agencies will use the primary registry to post any artifacts they wish to publish. As previously explained, the cost estimate for this alternative reflects the total cost to the federal government, which is the sum of the PMO costs and the combined costs of all the individual registries that are projected to be established over the ten year lifecycle. In addition to the general assumptions, the federated model cost estimate was based on the following assumptions:

• In addition to the four registries currently in existence and their associated recurring operation and maintenance costs, one additional registry per year will be established between FY 2004 and FY 2007.

• The total number of individual registries in operation by the end of the ten-year lifecycle is eight, excluding the primary registry, whose costs are included in the PMO costs. This is based on the assumption that fewer (approximately half) agencies will establish their own registries, electing instead to publish artifacts in the primary registry/repository.

• The transition and integration costs associated with either linking the four existing registries into the primary registry or subsuming them into the primary registry are not included.

Table 6: Federated Model Lifecycle Costs

Based on the analysis conducted to date, the expected total investment cost associated with Alternative 2: the Federated Model is $7.7 million, with a total life-cycle cost (FY 2004-FY 2013) of $59.4 million. The expected range for investment is $7.4 million to $8.0 million and the expected range for the total life-cycle cost is $58.2 million to $61.0 million.

Although the total costs to the Government include the cost of the XML Program Management Office, the cost of the central registry/repository, and the costs associated with agencies building individual registries—the PMO costs, exclusive of the costs borne by individual agencies projected to establish their own registries— are broken out below, for illustrative purposes.

XML Program Management Office Costs

Table 7: XML PMO Costs (Primary Registry Operations plus Program Mgmt and Policy Oversight)

Based on the analysis conducted to date, the expected total investment cost associated with the XML.gov PMO in the federated model is $3.5 million, with a total life-cycle cost (FY 2004-FY 2013) of $16.7 million. The expected range for investment is $3.4 million to $3.7 million and the expected range for the total life-cycle cost is $16.2 million to $17.4 million.

Alternative 3: Centralized Registry/Repository - Assumptions and Results

The centralized model assumes that a centralized registry will be established for the entire federal government. A PMO for the XML.gov Registry/Repository initiative will be established and will act both as an operational entity, building and maintaining the centralized federal registry/repository, and as a policy office issuing standards for artifacts and conducting outreach. The PMO serves the function of building awareness across the federal government of the uses of XML artifacts and technologies and their applicability to government business processes. This alternative’s cost estimate includes the operational costs associated with building and maintaining the centralized registry and the management, policy and oversight costs associated with the policy and outreach responsibilities of the XML initiative. In addition to the general assumptions, the centralized registry/repository cost estimate was based on the following assumptions:

• Since no new individual registries will be established outside of the centralized registry, the centralized registry/repository will support greater activity and require more capacity than the primary registry in the federated model. The scope, capacity, and level of effort estimated for the centralized registry is 33% greater than those estimated for the primary registry in the federated model.

• The transition and integration costs associated with subsuming the four currently operating (pre-existing) registries are not included.

Table 8: Centralized Registry/Repository Lifecycle Costs

Based on the analysis conducted to date, the expected total investment cost associated with Alternative 3: the Centralized Model is $5.0 million, with a total life-cycle cost (FY 2004-FY 2013) of $23.1 million. The expected range for investment is $4.7 million to $5.3 million and the expected range for the total life-cycle cost is $22.3 million to $24.2 million.

Value/Benefit Analysis

Methodology

The decision framework tailored for the XML.gov Registry/Repository initiative – specifically the Value Structure comprised of the five Value Factors - provided the roadmap for predicting the value outcomes for the Base Case and Alternatives 2 and 3 (the federated and centralized models, respectively).

To tailor this portion of the decision framework, the five Value Factors (Direct User, Social, Government Operational/Foundational, Government Financial and Strategic/Political) were prioritized during a working group session attended by senior staff from both GSA and OMB, as explained in the VMM process summary.

Working with stakeholders of the XML.gov Registry/Repository initiative, representatives of user communities and partner agencies, and the XML Working Group of the Federal CIO Council, value (benefit) measures in four of the Value factors (all but financial value) were defined and - through group discussion- refined. Performance metrics and targets associated with each of the value measures were then identified. Based on commercial benchmarks and stakeholder input, these comprehensive metrics were used to determine the projected value that would be gained under each alternative.

For the fifth Value factor, Government Financial Value, two standard measures – cost savings and cost avoidance for all federal agencies – were defined by the project team.

As a result of both the senior level and project-level input and prioritization sessions the five Value Factors and XML.gov Registry/Repository initiative-specific value measures were assigned weights. These weights are listed in the table below. The aggregate weights of the five Value Factors equal 100%. Within each of the Value Factors, the aggregate weights of the identified value measures also total 100%.

Table 9: Value/Benefit Weights

The above table provides abbreviated titles for all of the benefits. The Value Analysis Methodology and Basis of Estimate (Appendix C) provide complete definitions for all measure value measures, including their associated metrics and normalized scores. The assumptions and results of the value analysis conducted for each alternative is discussed in the following three sections.

Alternative 1: The Base Case – Assumptions and Results

The current environment is characterized by a lack of consistency and coordination in the administration and management of government-sponsored XML registry/repositories and activities, both across and within federal agencies. Its very nature is in direct opposition to achieving the fundamental benefit associated with the use of XML technologies, specifically: efficiency benefits that arise out of the standardization of artifacts; the interoperability of registry/repositories and the reuse of artifacts to standardizes communications and transactions between business partners. In the status quo environment, not only do four functional and production-use registry/repositories exist, but many more are likely to be established in subsequent years, with a multiplicative degradation in value, as more non-interoperable registries proliferate—decreasing the likelihood of artifact reuse and data standardization and their associated value/benefits.

Table 10: Base Case Value Analysis

Value scores were calculated on a scale of 0 to 100 as described in Appendix C: Value Analysis and Basis of Estimate. The status quo scored the lowest for the Direct User Value, Social Value, and Government Financial Value factors and, on a relative basis, scored higher for Strategic and Operational Value. The low composite weighted scores for Direct User Value and Social Value were expected given the fragmented nature of the federal XML environment in the base case. In this environment individual agency registries are not currently and are unlikely in the future to be linked or interoperable, therefore users do not have:

· A single authoritative source for XML artifacts related to inherently governmental functions

· Adequate access to efficient search and retrieval capabilities across government sponsored registries

· Sufficient knowledge-sharing capabilities

· The ability to realize the value associated with time savings and efficient communications associated with coordinated and linked government registries

As was also expected, this alternative provides no value in the Government Financial Value Factor (zero value score) due to the fact that no consolidation or coordination of registries takes place and no associated cost savings are realized. Also, there can be no cost avoidance for this alternative because each individual agency or registry bears the full maintenance and operational costs of a stand-alone registry/repository, which are multiplied by the total number of registries.

Finally, the status quo also provided low social value. This was also expected, as the Social Value Factor captures benefits to society as a whole, which in this case would include more efficient use of tax dollars and the coordination of intergovernmental data collection and sharing. No efficiencies resulting from coordination and streamlining are realized in the current environment because each stand-alone agency registry operates in a stovepiped fashion, according to unique technical specifications and data standards.

For the Base Case alternative, on a scale 0 to 100, the resulting total expected value score was 22.6, with a range of 13.5 to 31.6.

Alternative 2: Federated Model of Registry/Repositories

As with Alternatives 1 and 3, value scores for the federated model of government-sponsored registry/repositories were calculated on a scale of 0 to 100. The individual benefits with highest scores were those associated with the ease of use of federated registry/repositories for direct users; operational efficiencies due to the interoperability and coordination of government-sponsored registries; and the improved coordination, communications and knowledge and data sharing between government entities facilitated by interoperable federal registries with standardized artifacts.

It therefore follows that this alternative would be the selected alternative and that it will provide high value in key benefits areas. Since the XML Initiative is, by definition and design, a foundational effort to improve the efficiency and effectiveness of “back office” communications and transactions, it also follows that this alternative would have a composite value score for the Government Foundational/Operational Value that exceeds the composite scores for the four other Value Factors. The federated model delivers the most value to direct users by maximizing the ease of use of XML resources and information and by providing a single authoritative source for definitions of XML artifacts for government-unique requirements. This alternative delivers the most foundational value by enhancing the IT performance of federal agencies, increasing productivity and efficiency in government operations, facilitating information-sharing among disparate systems and agencies, and improving federal interagency collaboration. This alternative was also scored very high for its ability to fulfill strategic goals related to supporting the President’s e-Government agenda and facilitating the building block for homeland security coordination. Finally, the federated model also performed well in the area of social value, particularly when considering the value associated with government-wide coordination and data sharing, and increased efficiency in the allocation of tax dollars.

Table 11: Federated Model Value Analysis

Although the federated model alternative performed well and achieved high scores in four of the five Value Factors, in relative terms, its score for Government Financial Value (cost avoidance and savings) was much lower. This is due to the assumption within the federated model that a primary federal registry would be established and operated in addition to and in tandem with individual registries established by different agencies across the government with which it is linked. Since all of the alternatives in this business case reflect the total costs to the federal government as a whole, the costs of the federated model include those associated with individual agency registries that are projected to proliferate over the lifecycle of the XML.gov Registry/Repository initiative. It is therefore not surprising that the relative performance of this alternative in terms of cost avoidance is not maximized. Some level of cost avoidance will be realized if this alternative is implemented, however they are projected to be lower than those associated with user value, operational efficiencies, strategic value and interagency collaboration.

For the Federated Model alternative, on a scale 0 to 100, the resulting total expected value score was 58.5, with a range of 35.6 to 74.3.

Alternative 3: Centralized Registry/Repository

For the centralized registry/repository, the individual benefits with highest scores were those associated with the availability of XML artifacts through system “up time”; improved search and retrieval capabilities for direct users; operational efficiencies due to facilitation of data sharing among disparate agencies; and the strategic benefits of supporting the Federal Enterprise Architecture Initiative and facilitating the building blocks for homeland security coordination.

This alternative has a composite value score for the Strategic/Political Value Factor that exceeds the composite scores for the four other Value Factors. This is most likely due to the fact that a single custom-built, new registry/repository would be much easier to align with the Federal Enterprise Architecture Business Reference Model than a network of distinct registries managed by individual agencies or entities. In addition, a new centralized registry would be much easier to tailor to emerging coordination and communications needs in the homeland security arena. This alternative also scores relatively highly in the Government Financial Value, particularly for the measure associated with government-wide cost avoidance. This is because, under this alternative, no federally sponsored registry/repositories would exist outside of the centralized registry. The operational and start up costs associated with agencies establishing individual registries are, therefore, avoided.

In general, this alternative was scored poorly for direct user value; mixed outcomes with respect to government operational/foundational value; and moderate or mixed results for social value in which it scored very poorly in its efficient use of tax dollars.

Table 12: Centralized Registry/Repository Value Analysis

For the Centralized Registry/Repository alternative, on a scale 0 to 100, the resulting total expected value score was 49.8, with a range of 31.1 to 63.5.

Risk Analysis

Risk Analysis Summary

The purpose of a risk analysis is to evaluate the alternatives with respect to identified risk factors in order to estimate the likelihood of achieving anticipated value (benefits) and the accuracy and completeness of estimated costs. The previous sections discussed the projected value and estimated costs associated with the alternatives. This section identifies and assesses the risks against both the estimated costs and value of each alternative under consideration.

Methodology

The potential impacts of risks associated with all of the XML alternatives were calculated using a two-tiered risk framework. With client and stakeholder input, as well as best practices in risk assessment, risks associated with the XML initiative were identified, then evaluated to determine whether they had a low, medium, or high likelihood of occurrence and whether they would result in a low, medium, or high impact on costs and value if they materialized. Numerical probabilities and cost slippage/degradation in value performance were then defined for each level of risk and degree of risk impact, respectively. These numerical factors (or risk impact and probability scores) were applied to the appropriate individual cost elements and benefits.

This process produced risk-adjusted scores for the three alternatives. The results of this analysis are summarized below. For a more detailed explanation of the risk methodology and results, see Appendix B: Risk Methodology and Basis of Estimate.

Alternative 1: The Base Case – Assumptions and Results

The Alternative 1 risk probability and impact scores were applied to the costs and expected value of the base case according to its risk profile. The results of this analysis indicated a potential 31% decrease in the value (or benefits) and a potential 157% increase (more than double) the estimated investment costs. These results are summarized in the following table.

Table 13: Base Case Risk Analysis Results

Alternative 2: Federated Registry/Repositories – Assumptions and Results

The Alternative 2 risk probability and impact scores were applied to the costs and value of the federated model of registry/repositories alternative according to its risk profile. The results of this analysis indicated a potential 24% decrease in value (benefits) and a potential 112% increase in investment costs, for this alternative. The following table summarizes the results of the risk analysis for Alternative 2.

Table 14: Federated Model Risk Analysis Results

Alternative 3: Centralized Registry/Repository – Assumptions and Results

The Alternative 3 risk probability and impact scores were applied to the costs and expected value of the centralized registry/repository alternative according to its risk profile. The results of this analysis indicated a potential 20% decrease in the value (or benefits) and a potential 137% increase in investment costs, according to the risk profile of this alternative. The following table summarizes the results of the risk analysis for Alternative 3.

Table 15: Centralized Registry/Repository Risk Analysis Results

Comparing the Alternatives

Alternative 2, the Federated Model –defined as a primary federal XML registry/repository interoperating with individual government-sponsored registries— will maximize the value associated with the federal government’s adoption of XML technologies and avoid substantial costs, even after the application of risks to all three alternatives’ total value scores. A federation of (federal) interoperable government-sponsored registry/repositories, with a primary registry in place as a central portal, will yield far greater user, social, operational and strategic value than either a single centralized federal registry or the status quo (Alternatives 3 and 1, respectively).

The table below summarizes the difference in value, cost, and return on investment (ROI) associated with the three alternatives considered during this analysis.

Table 16 : Summary Comparison of Alternatives – Unadjusted Value and RO
I

The table demonstrates that- irrespective of social, strategic, operational and user value- the highest return on investment is associated with the Centralized Model. No return on investment (no cost avoidance) is realized in the base case. Despite the higher return on investment associated with the Centralized Model, it is critical to consider the Alternative 2 (federated) vs. Alternative 3 (centralized) costs in context.

In Table 16 and throughout this business case, Alternative 2— the Federated Model— captures the total costs to the Government, including (1) the cost of the XML PMO and the central registry/repository and (2) the costs associated with agencies building individual registries. The investment costs of the primary registry in Alternative 2 are a subset of the Alternative 2 PMO costs, which total $3.5 million. The lifecycle costs of the Alternative 2 PMO (i.e. costs exclusive of the costs borne by the sum of individual agencies projected to establish their own registries through the end of the ten-year horizon) total $16.7 million. Although lower than that of the Centralized Model, taken alone, the Alternative 2 (federated) ROI of 544% is nevertheless compelling.

Due of the foundational nature of the use of XML technologies- their main uses apply to making improvements in the efficiency and effectiveness of “back office” communications, transactions and systems- and the relative immaturity of related implementation efforts in the federal government, it is essential to consider the value proposition of the XML alternatives more heavily than the pure ROI metrics. This was the key reason for using the VMM and measuring those values not captured in return-on-investment calculations. It therefore follows that the Federated Model would be the selected alternative because, in the aggregate, it delivers more than twice the value (higher value score) than the status quo does and almost 20% more value than the Centralized Registry Alternative. Even after having adjusted all value scores for risk, that achieved by the Federated Model remains higher than those of the remaining two alternatives.

Alternative 1, the Base Case, is not recommended from any standpoint, whether from a pure cost/ROI perspective or from a value perspective. The Base Case ROI is zero; indicating that the Government will receive no financial benefits by maintaining the status quo. Perhaps most notable is the fact that when analyzed against the same decision framework as the other two alternatives, the Base Case had the highest estimated investment costs and the lowest aggregate value score.

The substantial cost avoidance under Alternative 3 (which drives the ROI of 1343%) is a result of the absence of independent XML activity and registry proliferation in the federal space, including the associated aggregate costs of all agency operations and maintenance. There is only a single, centrally managed and operated registry/repository under Alternative 3, therefore recurring costs over a ten year life cycle accrue and are incurred only for one registry, rather than for multiple registries that are either part of a registry federation or simply part of a fragmented group of registries.

With respect to Government Operational and Foundational and Direct User Value, the Federated Model of registry/repositories provides for an efficient and robust, interoperable network of registries that will encourage the use (and reuse) of XML artifacts, but also lays the foundation for the initiation of data standardization efforts across government.

Recommended Alternative

The value score and risk-adjusted value score for the federated model (Alternative 2) for government-sponsored XML registry/repositories suggest that this alternative would fulfill the requirements of, meet the needs of, and provide value to the government-wide e-Government stakeholders, customers, agency leaders, program managers, and others affected by XML technologies significantly better than the base case (Alternative 1) and notably better than the centralized model (Alternative 3). The Federated Model, with a PMO and an associated operational primary registry accomplishes the following: acts as a key enabler of interoperability among agency systems and XML registries; provides the foundation for a federal XML infrastructure; and provides agencies the flexibility to manage and maintain their own repositories of artifacts. In so doing, the risks of resistance are lower than in a mandatory centralized model, resulting in better performance in the area of reuse of XML artifacts (increased efficiencies) and a higher risk-adjusted value score. Alternative 2 delivers greater value in almost all of the individual value measures and also for Value Factors in the aggregate (with the exclusion of Government Financial Value).

Table 17: Federated Model (Preferred Alternative) Results

Implementation and Management Strategy

Governance Model: Leadership and Structure

Overview

Appropriate mechanisms for registration and storage of XML artifacts are critical components of an agency’s business, security, and IT architectures. Implementing common registration and repository mechanisms across government agencies will leverage the government’s investment in the business architecture. The systematic implementation of the federated architecture also significantly reduces delivery time for new systems and improves interoperability potential with existing systems. Redundant costs for individual agencies developing such infrastructure will be mostly eliminated by smaller agencies that do not need to establish their own registry/repository within the federated architecture. Additionally, deployment time for related e-Government infrastructure could be significantly reduced by agencies leveraging artifacts and resources available within a federated registry/repository. Furthermore, the federated architecture initiative facilitates the integration of mechanisms for registration and storage of XML artifacts into individual agency’s business, security, and IT architecture planning and development.

Business architecture implications for the deployment of the federated registry/repository initiative will be the streamlining of business practices, as well as the integration of a shared, consistent data vocabulary within a wide array of business processes. Depending on the specific business practice, these implications could result in significant monetary savings through the elimination of redundant processes. Figure 7 represents the change model that occurs in the business architecture of the federal registry/repository landscape, independent of the selected technology architecture. As the federal XML registry/repository landscape is apt to experience change as technology matures and the XML landscape modernizes across industry and government, an appropriate balance of federal leadership and grass roots innovation from various federal agencies should govern the registry/repository system. This tractable solution architecture enables bottom up innovation and top down leadership within the repository, while supporting XML knowledge and intelligence storage across organizational boundaries.

Regardless of the type of individual agency registries being created, maintenance and operational procedures must be in place to ensure effective use of all registries in the federation. Using the federated registries approach, each agency would maintain its own registry/registries (hereafter called local registries). However, local registry maintenance bodies would also be responsible for registering, to a defined extent, with the primary federal registry—XML.gov. The local registries would be governed and maintained according to their own current processes. This section focuses on the governance and maintenance of the primary federal registry and describes interaction with local registries as needed.

The requirements, policies and procedures for the XML.gov primary registry will be influenced both from above and below (see Figure 7 below for the Business Architecture Change Model). Federal Leadership will influence it from above. This might mean Congressional legislation, executive mandates, or directives from OMB, etc. Agency level needs and requirements will impact the primary registry from below. Each Federal Agency will have unique needs and their technical environment will be continually evolving. Due to the fluidity of this environment, the primary registry/repository will need to be flexible.

Figure 7. Business Change Model

The prescribed change model shown in Figure 7 ensures that agencies are working collaboratively to improve the federal XML registry/repository landscape as well as the primary registry, while being unified and receiving direction from federal leadership.

Architecture configuration management is an imperative aspect of governing the primary registry/repository and the entire federal XML landscape and managing innovation. The federated model assumes that organizations will inevitably need to innovate and extend beyond the baseline federated model functionality based on ebXML specifications. Evaluation and analysis of capability necessity must be employed on each enhancement to core ebXML capabilities. The federated solution model recommends a Change Control Board (CCB) to manage future plans for the federated community of registry/repositories. A CCB manages change in the federated architecture model regarding processes, prioritization of objectives, and high-level scope activities. Essentially, the CCB works with core leadership in the registry/repository community to ensure that any non-ebXML, custom registry/repository requirements can be synchronized across all organizations in the federation to minimize stovepiped efforts.

Overall, the following guiding business architecture principles exist for ensuring the success of the XML.gov registry/repository initiative:

• The primary federal XML registry/repository and the XML.gov PMO should aspire to disintermediate complexity and over-imposing standards that do not support organizations’ quick, easy, and dynamic discovery of useful XML artifacts that support the exchange of data and semantic meaning between federal agencies and their business partners.

• Standardizing XML data definitions for data exchange efforts is easily feasible. However, standardizing XML business processes is highly complex and not as practicable given the implicit disparities that exist between government organizations using COTS and custom software applications. The standardization of XML business processes across the federal government will require a significantly greater level of effort that the standardization of XML data definitions.

• Registries describing and pointing to Web services (i.e., software processes that enable fetching, adding, editing, or deleting data) offer higher value than registries only describing or defining XML entities such as XML Schemas. This is because Web services are inherently tied to an operational business process interconnected with a functioning software system, whereas XML Schemas by themselves may exist independent of any operational system and may only provide semantic understanding and compliance of data. The registry should support the goal for federal organizations to programmatically and systematically describe their Web services and specify how they prefer to conduct business so that partner organizations can quickly, easily, and efficiently integrate with those organizations. A future implementation of a federated UDDI registry at a later point in the federated model can simplify the effort of integrating disparate federal business processes.

• Conformance to ebXML specifications by itself is not a sufficient condition to achieve interoperability between federal agencies, as ebXML requires dependence on data exchange implementations to conform to the requirements in various ebXML specifications to guarantee interoperability. Moreover, anticipated users of registries in the federated model may lack adequate technology sophistication or comprehension of ebXML specifications in order to ensure compliant implementations.

Maintenance Model

Three primary roles have been identified in the maintenance of the primary federal XML registry/repository. In the federated registry environment, roles at the agency and community of interest level could overlap with those needed for the support of a local agency XML registry, if one exists.

• Registration Authority (RA), sometimes referred to as Executive Agent (EA)

• Program Manager (PM), also known as Responsible Organization (RO)

• Community Managers (CM), also known as Submitting Organization (SO)

Figure 8: Maintenance Model

The Registration Executive Agent (EA) or Registration Authority (RA) serves as the ‘owner’ of the primary federal registry/repository. The EA, represented by the XML.gov PMO in this business case, can be composed of persons from multiple organizations.

RA responsibilities include:

• Coordinate and implement registry functionality

• Insure interoperability with local or other pre-existing federal XML registries

• Determine federal XML registry standards

• Maintain relationships and ensure coordination and convergence with related federal bodies:

• CIO Council

• Solutions Architecture Working Group

• XML Working Group

• Determine policy and procedures regarding submission to the registry

• Coordinate XML education and outreach

• Determine levels of conformance

• Define legal liability

• Review and approve new entries to the primary federal registry

• Review and approve new agencies’ connection to and use of the primary federal registry

• Function as a Program Manager (see functions below) for those agencies who cannot support a local registry but wish to use the primary federal registry.

The Program Manager (PM) is the person or group at each agency who maintains the local agency XML registry, if one exists, and provides the link between the local and federal registries. Maintenance of submissions to the primary federal registry would be an extension of their current functions of providing oversight for their local registry.

Responsibilities of local registry Program Managers include:

• Maintain local registry

• Make submissions to the primary federal XML registry RA

• Coordinate efforts between the local registry and the primary registry

• Search primary registry for objects for reuse

• Register new XML artifacts into primary registry if necessary artifacts not found in primary registry and link new artifacts to local registry

• Manage artifact life cycle

• Maintain artifact stability

• Manage version control

• Manage audit trail

• Maintain quality control

The Community Managers (CMs) are the primary end-users of the registry. This group might include developers, data modelers, integrators, database administrators, business process managers, etc. This group could also include people from related Communities of Interest, which may have representation from private industry, standards bodies, working groups, subcommittees, etc.

Responsibilities of the CMs include:

• Represent Communities of Interest

• Represent local working groups

• Review submissions for conflict with entries in the primary federal registry

• Verify appropriateness of proposed submissions

Governance Model

The Registration Authority, in this case the XML.gov PMO, provides governance for the primary federal XML registry and for the federated XML registry landscape overall. Since the primary registry is intended for government-wide use, a three-pronged governance model is proposed, as represented in Figure 9.

Figure 9: Governance model

The broad categories of roles in this governance model include:

• Operations: Day-to-day maintenance and operations of the primary/flagship federal XML registry/repository. The logical home for the primary registry, at least initially, is with the FirstGov initiative at the GSA.

• Demand: Functional and standards guidance. This would be the logical extension of the functions of several existing working groups, (e.g., the CIO Council XML Working Group).

• Standards: Standards-setting for the primary registry/repository. NIST is the logical candidate to perform this function.

• Policy: Policy setting, coordination, and strategic directives. This function overlaps with several coexisting bodies including OMB, the CIO Council and the Office of Homeland Security. The relevant bodies for this function may change over time due to legislation or other external factors.

Risk Level	Probability	Cost Impact	Value Impact
High	50%	25%	-25%
Medium	30%	15%	-15%
Low	10%	5%	-5%

Risk Input	Alt 1 Probability	Alt 2 Probability	Alt 3 Probability
Cost Overruns	Low	Medium	High
Lost Information and Data	Low	Low	Medium
Hardware/Software Failure & Replacement	Medium	Medium	Low
Project Size Misestimation	High	Medium	High
Project Team and Oversight/Management Planning Not Structured Properly	Low	High	High
Security Needs of Agencies May Not Be Fully Addressed by the Registry/Repository Structure	High	Medium	High
Inadequate Allocation of PMO Staff & Time Requirements	Low	Medium	High
Inadequate Expertise of Agency Staff	Low	Low	Medium
Inadequate Estimation of Implementation Time	Low	Low	Medium
Poor Monitoring of Execution & Critical Path	Low	Medium	High
Absence of Federal Policy and Technological Standards for Artifacts and Registry/Repositories	High	Medium	Low
Lack of Awareness of XML Technologies Government-wide	High	Low	Medium
Lack of Agency Executive Support and Long Term Leadership Due to Foundational Nature of Initiative	Medium	Medium	Medium
Agency Continuance of Stovepiped Individual XML Registry Efforts and Low Resultant Reuse of Artifacts	High	Medium	Low
COTS Products in Use by Agencies Developed without Access to Federal XML Standards	Medium	Low	Medium
Organizational Culture in Agencies is Resistant to Adoption of Federal Specifications, Standards and Wider Adoption of XML	High	Medium	High
Current XML Technology Not Yet Mature Enough to Accommodate Needs and Complexity of Implementing Primary and Common Federal Government-wide Registry: Risk of Non-Interoperability	High	High	Medium
Absence of Authoritative Federal Governance Body to Oversee and Manage XML Efforts and Coordination Across the Federal Government	High	Medium	Low
Registry/Repository Architecture May Not be Scalable to Support Future Interoperable Technologies	High	High	High
Efficiency Gains Realized Only if Registries Accompanied by Standards-Setting for Data Elements and Registry Architectures	High	Medium	Low
Uncertain Long Term Funding Needed for Upgrades and to Support Standardization and Coordination Efforts	High	Medium	High
Cross-Agency Nature of Efforts Will Complicate Consensus-Building on Technical Specifications and Overall Coordination of Registry Activities	High	High	High
Sustainable Configuration Management	High	Medium	Low
Base Peer Registry Cannot Interoperate w. Pre-Existing Registries	High	Low	Low

DIRECT USER VALUE	PERFORMANCE MEASURE/METRIC
I. Ease of Use of XML Resources and Information
Flexible posting and retrieval procedures; scalable architecture, which can support evolving XML and registry technologies; limited/no mandatory contribution requirements; low costs of entry and participation, access and connectivity to additional resources beyond federal government	· Average annual % increase in the number of artifacts in (federal) government-sponsored registry/repositories
II. Single Authoritative Source for Agreed Upon Definitions for XML Artifacts for Inherently Governmental Data/Government-Unique Requirements
Primary registry is a flagship registry, recognized as a single point of entry and portal to government artifacts	· % of survey respondents indicating that they use artifacts in government-sponsored registry/repositories as the primary means of conducting or implementing electronic business transactions with the federal government
III. Improved Search, Discovery, Access and Analysis Capabilities for Functional Users/Communities of Interest
Facilitation of search/queries, retrieval, and analysis of artifacts due to standardized tagging	· Average number of clicks per search/query to find and retrieve desired artifacts in government-sponsored registry/repositories
IV. Ease of Submission for Publishing XML Artifacts in Government-Sponsored XML Registry/Repositories
	· Cycle time in business days from logon to notification of acceptance/rejection of artifact submission
V. Broad Knowledge-Sharing Capabilities
Rapid access to government-wide XML knowledge, solutions, innovations, and standards through a self-service registry usage model; rapid access to and communications for functional/subject matter knowledge and standards for communities of interest	· Annual % increase in the number of users of government-sponsored registry/repositories
VI. Improved Availability of XML Artifacts for Communities of Interest
Federated registries enable fast, easy, consistent, reliable access to federal XML artifacts; artifacts available through highly accessible web portal without custom software applications	· Average “up time” of government-sponsored registry/repositories in %
VII. Time Savings Due to Efficient and Effective Communications among Communities of Interest/Business Partners
Interoperability of many disparate systems; agencies/vendors can more rapidly and effectively communicate with one another.	· % of users indicating that the use of XML artifacts from federally sponsored registries reduced the time to implement XML based transactions
SOCIAL (NON-USER or PUBLIC) VALUE	PERFORMANCE MEASURE/METRIC(S)
I. Coordination and Streamlining of Intergovernmental Data Collection and Sharing
Government-wide XML artifacts become more deeply socialized over present day activities with State and Local governments and foster more efficient collaboration on data integration initiatives with the federal government; facilitation of the eventual reduction of reporting burdens/requirements on businesses and individuals and elimination/reduction of redundant collections	· Number of major intergovernmental projects that involve electronic communications/ transactions using artifacts from government-sponsored registries
II. More Efficient Use of Taxpayer Dollars
The more retrieval and reuse of artifacts, the greater the efficiency f the transactions between the associated parties; level of use of government-sponsored registry/repositories, measured by the number of downloads, is being used as a proxy for efficiency; greater efficiencies are realized in government transactions as the adoption of standard data elements and Web services increase	· Average annual % increase in the number of downloads of artifacts from government-sponsored registry/repositories
OPERATIONAL/FOUNDATIONAL VALUE	PERFORMANCE MEASURE/METRIC(S)
I. Improved Federal Interagency Collaboration (Current and Foundation for Future Collaboration)
Improved collaboration and information-sharing among federal government entities	· Number of major federal cross-agency projects that involve electronic communications/ transactions using artifacts from government-sponsored registry/repositories
II. Increase in Productivity and Efficiency of Government Operations
More Rapid Software Development Cycles; faster software development cycles by leveraging pre-existing XML artifacts and work products (i.e., existing XML Schemas, Web services providing existing data)	· Increases in productivity are a function of positive movement, meeting minimum levels of performance on an annual basis, for 5 key indicators. All of the following must occur in order to achieve productivity gains: average annual % increase in the number of artifacts in government-sponsored registry/ repositories ³ 15, % of users indicating that government-sponsored registry/ repositories reduced the time to ³ 50, number of major intergovernmental projects that involve electronic communications/ transactions using artifacts from government-sponsored registry/ repositories ³ 5, number of major federal cross-agency projects that involve electronic communications/transactions using artifacts from government-sponsored registry/ repositories ³ 5, average annual % increase in the number of downloads of artifacts government-sponsored registry/repositories ³ 15.
III. Efficient Reuse and Adaptation of Existing XML Efforts and Consolidation of Currently Fragmented Federal XML Efforts
	· Ratio of submissions to retrievals of artifacts in government-sponsored registry/ repositories
IV. Minimization of Administrative Burdens Associated with Publishing and Creating XML Artifacts in Government-Sponsored Registry/Repositories
	· % of agency managers indicating that the administrative burden is minimal in publishing/creating XML artifacts in government-sponsored registries
V. Facilitation of Data and Information-Sharing Among Disparate Systems and Entities (within and outside of Government)/ Intergovernmental Interoperability
Interoperability of Agency and Business Partner systems and across e-Gov initiatives; interoperability across registry/repository initiatives opens opportunity for greater collaboration between agencies	· Number of major intergovernmental projects that involve electronic communications/transactions using artifacts from government-sponsored registry/ repositories
VI. Enhanced IT Performance of Federal Agencies
	· % of agency IT managers positively responding that government-sponsored registries have effectively supported their use of XML technology to support agency business needs and systems and improved IT performance in their agency
GOVERNMENT FINANCIAL VALUE Note: Below are the types of financial benefits that were used to calculate ROI and do not represent benefits with individual value scores.
Information Technology Cost Avoidance
Reduction in recurring hardware and software costs
Reduction in System Maintenance Costs
Elimination of maintenance costs associated with multiple and disparate systems
Administrative Cost Savings
Reduction in recurring staffing costs associated with multiple registry maintenance
Reduced Government-wide Training Costs
STRATEGIC/POLITICAL VALUE	PERFORMANCE MEASURE/METRIC(S)
I. Support for Federal (OMB) e-Gov Initiatives and President’s e-Gov Strategy
Availability in near term for early efforts; low cost of entry and participation; facilitates all 24 government-wide e-Gov initiatives; enables XML activities to support communities of interest along Federal Enterprise Architecture (FEA) Initiative lines of business	· Number of Quicksilver initiatives making use of XML artifacts from government-sponsored registry/repositories
II. Closer Working relationships with Partnering Departments and State and Local Governments
	· Number of state and local government initiatives making use of XML artifacts from government sponsored registry/repositories.
III. Facilitation of and Support for Federal Enterprise Architecture Initiative
Augments OMB FEA Business Reference Model framework; enables XML activities to support communities of interest along functional lines of business.	· OMB feedback on the degree of alignment between government-sponsored registries’ classification schemes & FEA business framework Maximum extent possible= 4, Strong=3, Moderate=2, Minimal=1, No alignment=0
IV. Building Blocks for Homeland Security Coordination
Registry/repository provides building blocks for future homeland security initiatives by contributing key components for XML collaboration and data exchange between agencies.	§ Is the number of homeland security related artifacts submitted to federally sponsored registries increasing?

Abbreviations

Definitions

Methodology: Business Case Process Using the Value Measuring Methodology (VMM)

The Value Measuring Methodology (VMM)

Step 1: Develop the Decision Framework.

Step 2: Conduct an Alternatives Analysis.

Step 3: Pull Together the Information.

Description of the Alternatives

Alternative Selection and Development

Alternative 1: The Base Case

Alternative 2: Federated Model of Government-Sponsored Registry/Repositories

Alternative 3: Centralized Federal Registry/Repository

Methodology

General Assumptions

Alternative 1: The Base Case – Assumptions and Results

Alternative 2: Federated Registry/Repositories – Assumptions and Results

Alternative 3: Centralized Registry/Repository - Assumptions and Results

Alternative 1: The Base Case – Assumptions and Results

Alternative 2: Federated Model of Registry/Repositories

Alternative 3: Centralized Registry/Repository

Risk Analysis Summary

Methodology

Alternative 1: The Base Case – Assumptions and Results

Alternative 2: Federated Registry/Repositories – Assumptions and Results

Alternative 3: Centralized Registry/Repository – Assumptions and Results

Overview

Maintenance Model

Governance Model

Development Hardware

Development Software

Development Support: Government and Contractor

Studies

Procurement

Personnel: Government and Contractor

Training

Hardware Maintenance, Upgrades and Lifecycle Replacement

Software Maintenance, Upgrades and Lifecycle Replacement

Operations and Maintenance (O&M) Support: Government and Contractor

Recurring Training

Other Operations and Maintenance: Help Desk, Transition/Parallel System Operations, More

Methodology Overview