Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Washington, DC June 19, 2002 Briefing to XML Working Group 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.
  2. 2. Agenda <ul><li>Task Overview </li></ul><ul><li>Business Case Outline </li></ul><ul><li>A Snapshot of Preliminary Findings </li></ul><ul><li>Next Steps </li></ul>
  3. 3. Project Staff <ul><li>Gene Zapfel: eCommerce and eBusiness strategies </li></ul><ul><li>Terry Bjornsen: eBusiness strategy, data and messaging standards [EDI and XML], supply chain management </li></ul><ul><li>John McGady: eGovernment business strategy development </li></ul><ul><li>Mark Miller: XML technology expertise </li></ul><ul><li>Misty Jordan: XML technology expertise </li></ul><ul><li>Michelle Quadt: IT capital planning and business case development </li></ul>
  4. 4. Project Objective: develop the business case and strategy for future direction of the XML Registry <ul><li>Draft and Final OMB Form 300 and Business Case </li></ul>Primary Deliverables <ul><li>Overview of Federal XML Environment </li></ul><ul><li>XML Registry Requirements and Use Cases </li></ul><ul><li>Alternative Registry Strategies </li></ul><ul><li>Financial Analysis </li></ul><ul><li>Final Registry Strategy </li></ul>Supporting Analyses
  5. 5. Activities thus far… <ul><li>Kickoff meeting May 23 </li></ul><ul><li>Background research </li></ul><ul><li>Discussions with XML Reg/Rep team members </li></ul><ul><li>Thursday status meetings </li></ul><ul><li>Interviews with broader XML WG membership </li></ul>
  6. 6. Business Case Outline <ul><li>Executive Summary </li></ul><ul><li>Background </li></ul><ul><li>Business Case Methodology </li></ul><ul><li>Registry/Repository Strategy </li></ul><ul><ul><li>Role of the Registry/Repository </li></ul></ul><ul><ul><li>Customers and Value Proposition </li></ul></ul><ul><ul><li>Governance Model </li></ul></ul><ul><ul><li>External Relationships (e.g., other registries, standards bodies and eGov initiatives) </li></ul></ul><ul><ul><li>Accommodation for evolving technology standards </li></ul></ul><ul><li>Solution Architecture and Use Cases </li></ul><ul><li>Strategic Alternatives and Cost/Benefit Analysis </li></ul><ul><li>OMB Form 300 preparation </li></ul>
  7. 7. Snapshot of key data points and issues <ul><li>An XML registry should support human to registry interactions as well as system to registry interactions. Thus, a subjective human element exists in which a person must first establish and refine understanding of what definitions exist in the registry and how they can be used, before they are incorporated into an XML technology solution for system to system use. </li></ul><ul><li>Registries describing and pointing to business services (i.e., web services) offer higher value than registries that provide only XML definitions and classifications (i.e., XML schemas) </li></ul><ul><li>The notion of having a single, federal XML registry is not clear in the mind of the respondents, but sounds desirable given the substantial benefits of being able to collect and centralize descriptions and elements on a holistic level. </li></ul><ul><ul><li>Interoperability between XML registries run by different agencies is imperative. </li></ul></ul><ul><ul><li>Certain levels of interoperability between organizations are difficult to attain even when a common element definition exists </li></ul></ul><ul><ul><li>Moving forward one registry does not necessarily seam feasible as opposed to multiple, distributed registries interoperating </li></ul></ul><ul><li>The governance and operational model for the registry and its contents has not yet been addressed. </li></ul>
  8. 8. Snapshot of key data points and issues (cont…) <ul><li>The strengths and limitations of using ebXML in an XML registry appear well known, while the strengths and limitations of using emerging specifications such as UDDI and WSDL appear very unclear. </li></ul><ul><li>Given so many systems already exist, newly agreed upon XML definitions that would exist in the XML registry may not be able to be efficiently imposed on other agencies. The question arises as to whether imposing standard element descriptions on different agencies is either possible or desirable. </li></ul><ul><li>ebXML possesses positive and negative aspects </li></ul><ul><ul><li>Interoperability functionality in ebXML is still in its infancy, not extremely flexible, and lacks substantial industry product support </li></ul></ul><ul><ul><li>ebXML’s assumed security model incorporating digital signatures may be too strong for widespread deployment and usage </li></ul></ul><ul><ul><li>ebXML provides strong relationships between documents (associations of objects and packages of objects); more granular data elements require more robust relationships and associations as prescribed by ebXML </li></ul></ul><ul><ul><li>exXML provides strong capabilities in document lifecycle management and classification schemes that evolving specifications do not </li></ul></ul>
  9. 9. Snapshot purpose of an XML registry/repository <ul><li>Provide a mechanism to define classification schemes </li></ul><ul><ul><li>Administrative capability where a registry “owner” or a “sub-classification owner” would add new categories and classification hierarchy to the registry </li></ul></ul><ul><li>Provide a mechanism for navigating/searching a classification scheme </li></ul><ul><ul><li>How schemas are organized in a registry for use by humans or systems </li></ul></ul><ul><li>Provide a mechanism for adding items to a classification scheme as well as managing newly added items </li></ul><ul><ul><li>Uploading XML schemas to the registry/repository for centralized distribution and consumption </li></ul></ul><ul><li>Store metadata about data definitions such as XML schemas, DTDs, etc. </li></ul><ul><li>Store metadata about web services (i.e., references, address, descriptions) </li></ul><ul><li>Store actual XML data definitions (e.g., XML schemas, DTDs, etc.) </li></ul><ul><li>Store and describe actual data/reports described in XML (e.g., agencies could publish quarterly reports in XML and centrally distribute those reports as XML files on the registry) </li></ul>
  10. 10. Snapshot purpose of an XML registry/repository (cont…) <ul><li>Support real-time XML validation of XML content against XML data definitions </li></ul><ul><ul><li>For example, states would be have computer software automatically validate state water quality XML files against a centrally stored EPA water quality XML schema stored in the federal XML registry/repository </li></ul></ul><ul><li>Support interoperability between different XML registries </li></ul><ul><ul><li>The federal XML registry should be able to negotiate and exchange information with agency specific registries </li></ul></ul><ul><ul><li>The federal XML registry should be able to cross-search other registry indexes for relevant information </li></ul></ul><ul><li>Software and application developers/integrators in federal agencies are the primary users </li></ul>
  11. 11. Snapshot value proposition of an XML registry/repository <ul><li>Multiple agencies using common XML definitions and objects creates synergy </li></ul><ul><ul><li>Increased awareness of what XML objects are available allows people to refine current implementations and apply higher-traction, more widely used XML definitions to future initiatives </li></ul></ul><ul><li>Stronger descriptions and classifications of functional lines and definitions in the federal government improve overall government efficiency </li></ul><ul><ul><li>Organizations can recognize more value from the registry if the XML registry provides business process classification schemes and the ability to navigate business domains based on required content </li></ul></ul><ul><ul><li>Functional overlaps can be identified in the federal government for improved efficiencies </li></ul></ul><ul><li>Creation of policies and procedures allowing registries to interoperate enable distributed, collaborative registries that support agencies working together with more agility and flexibility rather than reinventing the wheel each time data is exchanged </li></ul><ul><ul><li>Need to represent agile information and interoperability spanning non-traditional organization boundaries </li></ul></ul><ul><ul><li>Downstream usage of an XML schema or XML business service may not be known until it becomes available in a registry and promoted to many organizations </li></ul></ul><ul><li>A registry allows the federal government to synthesize and consolidate government-wide XML initiatives: </li></ul><ul><ul><li>Govt can also identify preexisting standards from industry consortia efforts, authorize, and recommend these as federally supported definitions </li></ul></ul>
  12. 12. Next Steps <ul><li>Complete information gathering research activities </li></ul><ul><li>Synthesize information vet key themes and scoping </li></ul><ul><li>Continue to align activities with identified relevant efforts (eGov, ebXML) </li></ul><ul><li>Commence preliminary deliverable development </li></ul><ul><li>Interviews with broader XML WG membership </li></ul>