# Presentation: 139400

## Business Case for the XML.gov Registry 

- Washington, DC
- August 14, 2002

**Status Briefing**

**Business Case for the XML.gov Registry **

*This document is confidential and is intended solely for the use and information of the client to whom it is addressed.*

## Agenda

- Perform a document walkthrough
- Develop an understanding of level of detail within the document
- Gain a baseline understanding and concurrence on key areas
- Customers and Stakeholders
- Technology Architecture
- Requirements and Use Cases
- Governance & Management Model
- Defined and Recommended Alternatives
- Cost Structures
- Benefits Structure and Scoring
- Discuss Next Steps for the Business Case Analysis
- Length of comment period and participants (is a “road show” required?)
- Implementation Plan
- Approval Process and OMB Target Individuals

## A federal registry/repository satisfies various stakeholders and needs based on governmentwide consensus

- Coordinates and enhances currently fragmented activities being undertaken by federal agencies across government to build and populate XML registries
- Promotes a variety of government initiatives and missions including e-Government and Homeland Security initiatives
- Provides a clearinghouse for XML Schemas and related artifacts to improve semantic and technical interoperability
- Ensures cross-government coordination and maximum reuse of artifacts associated with government-unique requirements by all types of federal business partners
- Supports more efficient electronic business within the federal government
- Cooperatively supports business processes surrounding the registration of Web services

## The purpose of this Business Case Analysis (BCA) is to provide the justification for the XML.gov Registry/Repository based on  cost, value and risk 

- This business case considers whether the Government should invest in a common XML registry/repository
- This investment would provide substantial foundational and operational value to the Government, and help to ensure cross-government coordination with government-unique requirements by all types of federal business partners
- This Business Case Analysis (BCA) includes the following:
- Outlines the need for a Federal XML Registry
- Analyzes the status quo and proposed alternatives
- Makes a recommendation for a ‘preferred alternative’ that will maximize cost effectiveness and further the missions of the Federal government
- This document is not intended to provide a detailed design for a registry/repository capability, nor does it provide comprehensive details needed for implementation

## The business case analysis compared three alternatives

- Alternative 1: Base Case (Status Quo)
- No coordination activities to ensure the interoperability of government-sponsored registry/repositories
- Any agency can build and maintain XML registries
- Assumes individual agency registry will proliferate over time
- Alternative 2: Federated Registry/Repositories
- A primary governmentwide federal registry/repository is create to act as 1) a hub to facilitate exchange between federal registries and 2) a XML reg/rep for agencies that do not build their own registry/repositories.
- Each agency can build a registry/repository which can interface with all registries in the federation through the primary registry
- Alternative 3: Centralized Registry/Repository
- A centralized federal registry/repository is built that lists and stores all XML artifacts published by federal agencies.
- All federal agencies wishing to publish XML artifacts are required dto use this central registry/repository
- Requires the eventual termination of all current XML registry activities in agencies

## Alternative 1: Status quo registry/repository logical architecture

- Multiple and distinct federal XML registry/repositories that facilitate management and distribution of XML artifacts
- Progress occurring in the accumulation of federal XML artifacts
- Highly proprietary functionality in the process of developing a customized software solution
- Lack of consistent ebXML implementations and a mix of highly customized registries exist that are only semi-compliant to ebXML 2.0 specifications

## Alternative 2: Preliminary federated registry/repository logical architecture 

- Initial lifecycle deployment of the federated XML registry/repository model to support rapid and standardized accumulation of XML artifacts
- Establishes technical and operational foundations to support a unified federal registry solution later in the lifecycle
- Preliminary ramp up and standardization to align existing registry architectures with the primary federal XML registry/repository architecture
- Enables the government to immediately proceed with semantic standardization efforts before approaching the complexities of registry/repository interoperability

## Alternative 2: Mature federated registry/repository logical architecture

- Complete lifecycle deployment of the federated XML registry/repository model
- A series of distributed services utilizing registry nodes built on peer-to-peer architecture foundation
- Transparently negotiates and exchanges information with other registries within the federation based on synchronization and interoperability capabilities
- Supports visibility into inter-agency XML initiatives while mandating a minimum set of implementation specifications to participate in the registry/repository landscape
- Each registry operates as a de facto “meta registry” to enable interactions across other registries

## Alternative 3: Centralized registry/repository logical architecture 

- A third alternative for standardizing XML artifact collection and distribution across the federal government
- A single and uniform registry/repository platform for capturing and storing all XML artifacts within the federal government
- All existing federal XML registries would effectively shut down and migrate any existing XML artifacts to the centralized registry

## There Are Three Categories in the Standard Cost Element Structure

- _Development and Planning_: includes personnel costs associated with the studies, planning, documentation, and analysis required for the project along with any personnel, hardware and software necessary for a testing environment of new systems or applications
- _Acquisition and Implementation_: includes the acquisition of the actual project hardware and software, as well as the personnel required to accomplish implementation
- _Maintenance and Operations_: includes upgrades, maintenance, and recurring training

## The Alternatives Analysis applies three analytical frameworks to each alternative

- _Cost Analysis_: A cost element structure is developed and populated for each alternative
- _Value Analysis_: Score based on a weighted composite of the alternative’s likely performance on each of the benefits in the value framework
- _Risk Analysis_: Composite score based on the probability of occurrence of the risks and the likely impact on cost and value for each alternative

## The Overall Value Of An Alternative Is Determined By Estimating And Weighting Benefits In Five Categories 

## Each Benefit is Assigned a Metric that is Used to Develop the Value Estimate and Score of Each Alternative

***Illustrative***

**Metric**

**Benefit**

**Description of Benefit**

**Value Factor**

## Alternatives Analysis: Risk Methodology

- A total of 24 risks were identified and then scored, by alternative, based on probability of occurrence and the expected severity of the impact.  These scores were based on assigned risk levels– High, Medium, and Low– for probability and impact
- Probabilities of risk occurrence and impact of risk were determined on an alternative-by-alternative basis
- Risks associated with Program Management and Planning could be mitigated by comprehensive project planning and program management controls
- Risks associated with the immaturity of XML, lack of awareness of XML at a Federal level, and lack of agency expertise could be mitigated by education, awareness, and training
- Risks driven by lack of standards, policy, and or operational procedures for maintaining an XML registry in a Federal environment could be mitigated by establishing a fully staffed PMO with the appropriate authority to develop governmentwide policy and standards

## Identified Risks

**Identified Risks**

## Identified Risks (continued)

**Identified Risks (continued)**

## Alternative 1— The Base Case (Status Quo): Assumptions

- Four government-sponsored registry/repositories currently exist and are in operation
- In addition to the four registries currently in existence and their 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

## Alternative 1— The Base Case (Status Quo): 10-Year Lifecycle Cost

- Investment Cost (Planning + Acquisition)= $20.8 Million
- Total 10-Yr. Lifecycle (All Categories)= $125.7 Million

## Value Score for Alternative 1 – Base Case (Status Quo) Scores for Direct User and Government Operational Value Factors

## Value Score for Alternative 1 – Base Case (Status Quo) Scores for Strategic, Financial, Social Value Factors and Total Alt 1 Value Score

## Alternative 2— The Federated Registry: Assumptions

**Alternative 2— The Federated Registry: 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 8, excluding the primary registry
- Fewer (approximately half relative to the Status Quo) agencies will establish their own registries, electing instead to publish artifacts in the primary registry/repository
- Transition and integration costs associated with linking the four existing registries into the primary registry are not included

## Alternative 2— The Federated Registry: 10-Year Lifecycle Cost

- Investment Cost (Planning + Acquisition) = $7.7 Million
- Total 10-Yr. Lifecycle (All Categories) = $59.4 Million
- Ten Year Lifecycle Cost for XML PMO (includes Primary Registry) = $16.7 Million

## Alternative 2— The Federated Registry: 10-Year Lifecycle CostXML Program Management Office Costs 

**PMO Costs Include  ****Primary Registry Operations, Program Management and Governmentwide Policy Coordination and Oversight**

- XML PMO Investment Cost (Planning + Acquisition) = $3.6 Million
- Ten Year Lifecycle Cost for XML PMO (includes Primary Registry) = $16.7 Million

## Value Score for Alternative 2 – Federated Registries Scores for Direct User and Government Operational Value Factors

**Value Score for Alternative 2 – Federated Registries Scores for Direct User and Government Operational Value Factors**

## Value Score for Alternative 2 – Federated Registries Scores for Strategic, Financial, Social Value Factors and Total Alt 2 Value Score

## Alternative 3— Centralized Registry: Assumptions

- 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
- Scope, capacity and level of effort estimated for the centralized registry are 33% greater than those estimated for the primary registry in the federated model
- Transition and integration costs associated with migrating the four currently operating (pre-existing) registries to the centralized are not included

## Alternative 3— Centralized Registry: 10-Year Lifecycle Cost

- Investment Cost (Planning + Acquisition)= $5.0 Million
- Total 10-Yr. Lifecycle (All Categories)= $23.1 Million

## Value Score for Alternative 3 – Centralized Registry Scores for Direct User and Government Operational Value Factors

**Value Score for Alternative 3 – Centralized Registry Scores for Direct User and Government Operational Value Factors**

## Value Score for Alternative 3 – Centralized Registry Scores for Strategic, Financial, Social Value Factors and Total Alt 3 Value Score

## Alternative 2 is recommended as it exceeds other alternatives in overall scoring and stakeholder value

- Possesses a stronger value score and risk-adjusted value score for government-sponsored XML registry/repositories
- Fulfills the requirements of and provides value to the governmentwide e-Government stakeholders, customers, agency leaders, program managers, and others affected by XML technologies significantly better than Alternative 1 and notably better than Alternative 3 (centralized)
- Operates as a key enabler of interoperability among agency systems and XML registries and provides the foundation for a federal XML infrastructure
- Provides agencies the flexibility to manage and maintain their own repositories of artifacts
- Delivers greater value in individual benefits and in aggregate Value Factors (excluding Government Financial Value)

## Governance and Maintenance Model Overview

- Regardless of type of registry used, maintenance and operational procedures must be in place to ensure effective use.
- Governance and maintenance defines the administration and use of the registry.  As such, both the registry functionality and business processes will be affected.
- This defines Federal registry governance and maintenance.  Local, or agency, registries will be governed and maintained independently.
- Change will be effected from multiple levels:
- Top-down changes will include Executive mandate, legislation, etc.
- Bottom-up changes will include changes prompted by Agency or Community innovation

**Governance and Maintenance Model Overview**

## Governance Model

- 3-tiered approach consisting of Operations, Standards, and Demand.  It will have a dotted-line relationship with Policy
- Will support the functions of the registry without overburdening any one Federal agency.
- Operations includes the day-to-day maintenance of the registry, management of artifacts, etc.  The logical home is GSA.
- Demand includes representing requirements and needs of the registry users.  This would be an extension of functions of current Working Groups.
- Standards includes operational and use procedures, etc.  The logical body for this function is NITS.
- Policy would be driven by a combination of forces including OMB, CIOC, and the OHS.

## Maintenance Model

- Federal registry is maintained at the Federal level by the Operations group depicted in the Governance Model.
- Each agency maintains its own local registry, if one exists.
- Maintenance roles are:
- Executive Agent (Operations function defined under Governance Model)
- Program Manager (Agency representative interacting with the Federal registry)
- Community Managers ( groups of interest, end-users of the registry, interested standards bodies, etc.)
- Smaller agencies not wishing or able to maintain a local registry could use the central registry for storage of XML artifacts
- Working groups have relationships with all 3 Maintenance roles

## Next Steps

- Incorporate feedback on Business Case Analysis
- Develop Implementation Framework
- Review/refine alternative value and risk analyses
- Develop Final Business Case Analysis, OMB Form 300

## BACKUP SLIDES

## Customers and Stakeholders

- The customers and stakeholders for this initiative are as follows:
- Federal Systems and Application Developers
- Systems Architects
- Repository and Records Managers
- Program Managers
- Suppliers to the Federal government
- Federal Agencies
- State Governments
- Local Governments
- Technology Providers

## VMM Decision Framework Development - Overview

## Standard Cost Element Structure: System Planning and Development

**Standard Cost Element Structure: System Planning and Development**

## Standard Cost Element Structure:  System Acquisition and Implementation

**Standard Cost Element Structure:  System Acquisition and Implementation**

## Standard Cost Element Structure:  System Maintenance and Operation

**Standard Cost Element Structure:  System Maintenance and Operation**

- Cost Element Structure

## The registry/repository encompasses core functional capabilities and requirements 

- Add, edit, and delete a hierarchical classification scheme and its related classification branches that support systematically organizing registered XML artifacts
- Navigate and view all content of the hierarchical classification scheme.  Viewable content includes an XML artifact, related artifacts, classification schemes an XML artifact belongs to, and metadata about the XML artifact
- Search the classification scheme by branches, XML artifacts within the scheme, contents of XML artifacts, or metadata about an XML artifact.  The search should support using human to system search interfaces or system to system search interfaces
- Add, edit, and delete an XML artifact within one or more classification branches
- Add, edit, and delete one or more of the metadata attributes of an existing XML artifact within the classification scheme
- Add, edit, and delete artifacts that supplement an XML artifact with useful information such as XML instance documents and PDF documents about the XML artifact

## The registry/repository encompasses core functional capabilities and requirements (cont...)

- Review and validate XML artifacts added to the system
- View, add, edit, and delete groupings of related XML artifacts
- Version control for XML artifacts and metadata attributes
- Selective security and access control capabilities for the following items: the registry/repository itself, classification scheme branches, XML artifacts and their related artifacts
- Organize registry/repository users within roles containing specified privileges so as to manage content and capabilities within the registry/repository
- View, add, edit, and delete actual data files in XML (e.g., agencies may publish quarterly reports in XML and centrally distribute those reports as XML files on the registry)

## The registry/repository encompasses core functional capabilities and requirements (cont...)

- Support run-time XML validation via the HTTP protocol of XML content against XML artifacts that exist in the registry/repository (e.g., state governments have state water quality XML data files that must be validated against an EPA water quality XML Schema stored in the registry/repository)
- Basic XML artifact collaboration to capture feedback and ideas about specific XML artifacts from those leveraging the XML artifact itself
- Support for multiple registries to synchronize registry metadata information from one registry to another in order to facilitate interoperability

## High level use cases specify anticipated possibilities for how users and systems would interact with the registry/repository 

- A user uploads a new XML Schema
- The users logs in, identifies a relevant classification scheme, uploads the XML schema file, has the XML schema automatically validated for correctness by the registry, receives upload confirmation, and waits several days for e-mail review and acceptance by the community of interest
- A user performs a text search for an XML Schema
- The user navigates to the registry, types in search criteria, receives a list of XML Schemas with schema text matching search criteria, selects a desired XML Schema from the list, then views the detailed XML schema contents and metadata to determine applicability to their technology initiative
- A user performs a metadata search for an XML Schema
- The user navigates to the registry, selects an option for a metadata search, views a list of standard metadata fields for searching, enters metadata search criteria, then views resulting XML Schemas that match the metadata search criteria

## High level use cases specify anticipated possibilities for how users and systems would interact with the registry/repository (cont...)

- A system different from the federal registry/repository references an XML schema in the registry/repository
- System A uses a SOAP-based message over HTTP to consume a Web service on System B.  System B responds that the Web service requires XML compliance to an XML Schema located in System C’s registry/repository.  When receiving the SOAP-based message from System A, System B consumes the XML Schema from System C using HTTP, validates System A’s message, and responds with XML data using the Web service
- A developer uses an XML software development tool to validate an XML instance file against an XML Schema residing in the registry/repository
- Developer loads an XML instance file into the development tool, adds the registry’s URL for the referenced XML Schema within the XML instance file, selects an option in the development tool to validate the XML file, the development tool references the XML Schema in the registry/repository, then the tool identifies the XML instance file as either valid or invalid
- A community of interest administrator approves an XML Schema submitted by a federal user
- A community of interest administrator logs into the registry, selects an option to view submitted, unapproved XML Schemas, views a list of submitted XML Schemas, selects a schema from the list, views the schema details and related metadata, and approves the XML Schema assuming it correlates into the community of interest classification scheme.  An e-mail message is then automatically sent by the registry to the submitter with the notice of approval