48
1 Suggestions for the Federal Enterprise Architecture (FEA) Data and Information Reference Model (DRM) Brand Niemann Solution Architects Working Group and Chair, XML Web Services Working Group January 22, 2003/Updated January 27, 2003

Suggestions for the Federal Enterprise Architecture (FEA

  • Upload
    aamir97

  • View
    1.428

  • Download
    2

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Suggestions for the Federal Enterprise Architecture (FEA

1

Suggestions for the Federal Enterprise Architecture (FEA) Data and Information

Reference Model (DRM)

Brand NiemannSolution Architects Working Group and

Chair, XML Web Services Working GroupJanuary 22, 2003/Updated January 27, 2003

Page 2: Suggestions for the Federal Enterprise Architecture (FEA

2

Overview• 1. Some Background• 2. Suggested Structure for DRM• 3. BAH Discussion Document:

– a. The Federal Statistical System as a “best practice”.– b. Document Markup Languages (XML) and Community Vocabularies

(e.g. TaxXML) help with this problem.– c. The DRM is and is not..– d. The DRM Framework needs to articulate a proven process for

achieving business line/function integration and operational results.– e. Create Cognitive Topic Map Web Sites (CTW) that use XML

standards to render the information differently for different types of users.

– f. Relational Databases and XML Schema Can Work Well Together.– g. XML registries and repositories that integrate industry standards,

support distributed federation, and integrate with other tools and models will help transform E-Government.

– h. Successful pilot projects will contribute to the refinement and widespread adoption of the DRM.

Page 3: Suggestions for the Federal Enterprise Architecture (FEA

3

1. Some Background

• Federal Enterprise Architecture Data and Information Reference Model:– The Data and Information Reference Model (DRM) will describe,

at an aggregate level, the data and information that support program and business line operations. The model will aid in describing the types of interaction and exchanges that occur between the Federal Government and its various customers, constituencies, and business partners.

– The DRM will categorize the government's information along general content areas and decomposes those content areas into greater levels of detail. The DRM establishes a commonly understood classification for Federal data and leads to the identification of duplicative data resources. A common data model will streamline the processes associated with information exchange both within the Federal government between the government and its external stakeholders.

http://www.feapmo.gov/feaDrm.htm

Page 4: Suggestions for the Federal Enterprise Architecture (FEA

4

1. Some Background• The Federal Enterprise Architecture Program Management Office expects

to release drafts of two technology-related reference models early next year. The draft technical reference model (TRM) and service component reference model (SRM) will probably be launched together next month, acting program manager Robert Haycock said last week at the XML 2002 conference.

• SRM will describe software components that agencies can quickly assemble into applications, Haycock said. TRM will identify interoperability and reuse technologies—down to the product level in some cases.

• The working groups that are drafting the enterprise architecture models still have “a lot of conceptualizing” to do on a draft data reference model for the architecture, Haycock said. Current plans call for a DRM repository of XML schemas and metadata describing data common to multiple agencies’ business processes.

• “One thing we’re determined not to do is create our own standards,” Haycock said. “We want to use the commercial standards already out there.” The critical specifications are XML; Universal Discovery, Description and Integration; the Simple Object Access Protocol; and Web Services Description Language.

"Working group tests tools for Web services", Government Computer News, December 16, 2002,http://www.gcn.com/21_34/news/20656-1.html

Page 5: Suggestions for the Federal Enterprise Architecture (FEA

5

1. Some Background• Industry Advisory Council Enterprise Architecture SIG Papers (IAC

EA), with the goal of improving the Enterprise Architecture process and driving for government transformation, have been aligned with the CIO Council’s Federal Architecture and Infrastructure Committee's (AIC) three new Sub-Committees:– IAC EA SIG Paper in the AIC Components Sub-Committee: E-

government Information and Data Viewpoints - Federated Information Model Integrates Structured, Semi-Structured and Unstructured Information Sources:

• This paper presents an approach and a Federated Information Model that can be populated along government Business Lines and be used across Federal, State, Local and International e-government initiatives. The approach is based on both sound information and data base theory, a serious need, and an approach that correlates with standards organizations to create an open and extendable family of information models. These models can be one element of each organization's push for information integration and increased consistency, commonality, and visibility.

• IAC EA SIG POC/Authors:– Michael Lang, Metamatrix, Inc; [email protected]– John Dodd, CSC, [email protected]– R. Cardwell, Metamatrix, [email protected]

http://www.ichnet.org/IAC_EA.htm

Page 6: Suggestions for the Federal Enterprise Architecture (FEA

6

1. Some Background• Owen Ambur, 1/17/03: I believe the XML Registry should become the

embodiment of the DRM which should be built from the bottom up using as models the forms and the community of interest/practice to harmonize needless redundancies and inconsistencies. The “Eforms for E-Gov” incubator pilot project appears far more likely to add far more value sooner than all of the theoretically-oriented top-down FEA modeling efforts combined.

• John Dodd, 1/17/03: We think that we must go beyond a registry-even repository-to a Federated Data Management Center(s) and the competency of Information/Data Analysts that can both look at the data and information at the detailed level and produce “meta models” that can provide “virtual views” that are “useful and useable” today with an “emerging path” to a vision.

• Marion Royal, 1/22/03: I see documents within lines of business that contain reusable components that are registered/stored in a common library and that library provides the means for other lines of business to use those reusable components in their documents. However, I don’t see the Federal government adopting UBL (Universal Business Language) or populating the library with UBL-type content.

Page 7: Suggestions for the Federal Enterprise Architecture (FEA

7

1. Some Background

• Federal Enterprise Architecture Management System (FEAMS):– The FEA maintenance and upkeep process is greatly facilitated

through the use of an Internet-based automated EA repository and analysis tool - the Federal Enterprise Architecture Management System (FEAMS). In the future, agencies will be given access to FEAMS and use it in both capital planning and architecture development efforts.

– The Federal Enterprise Architecture reference models and related information are being stored in FEAMS. FEAMS currently includes general information on Agencies' major information technology (IT) initiatives, and aligns the initiatives to the BRM Lines of Business they support. It is OMB's goal that the FEAMS eventually include information on all of the capital assets in which Federal Agencies invest.

http://www.feapmo.gov/feaFEAMS.htm

Page 8: Suggestions for the Federal Enterprise Architecture (FEA

8

1. Some Background

• CIO Council’s Architecture and Infrastructure Subcommittee Charters (1/16/03 updates):– Enterprise Architecture Governance (EAG):

• Presumably store its deliverables in the FEAMS.

– Component (CS):• Component Registry, Product Directory, Common Metadata

and Tools Assessment Guide, Component-Based Architecture Information Knowledgebase Repository, etc.

– Leveraging/Emerging Technologies (LT/ET):• Registry of validated capabilities for FEA adoption from pilots

and other activities.

http://cio.gov/documents/architecture_subcommittee_charters.html

Page 9: Suggestions for the Federal Enterprise Architecture (FEA

9

2. Suggested Structure: Overall

AgencyNodes

E-Gov Initiatives Nodes

OMB/CIOC-AICNodes

The DRM Is:•Business-focused data standardization.•Cross-agency information exchanges.•Federated Registries and Repositories organized according to the Business Reference Model.•An agile framework for building new cross-agency applications and services.

The DRM Is Not:•A government-wide data model.•A government-wide markup language.•Complete!

“Internet Cloud of Web Services”

Federated Data Centers/Information/Data Analysts?

Page 10: Suggestions for the Federal Enterprise Architecture (FEA

10

2. Suggested Structure: Nodes

• XML Namespace (Line of Business, E-Gov Initiative, OMB/CIOC-AIC Activity, etc.):– Vocabularies/Semantics– Data Dictionaries– XML Artifacts– Topics Maps/Ontologies– Metadata Clearinghouses– Document Libraries– Registries/Repositories– Etc.

Page 11: Suggestions for the Federal Enterprise Architecture (FEA

11

2. Suggested Structure: Nodes

• XML Collaborator:– Administration Objects:

• Person• Organization• Group• Role• Activity

– Versioned Components:• Datatypes• Enumerations• Datapoints• Structures• Operations• Services• Documents

Page 12: Suggestions for the Federal Enterprise Architecture (FEA

12

3. BAH Discussion Document

• The Federal Government has limited means to share information across common business lines and functions.– a. The Federal Statistical System as a “best

practice”.• While similar in nomenclature, data and

information can support completely different business lines, processes, and functions.– b. Document Markup Languages (XML) and

Community Vocabularies (e.g. TaxXML) help with this problem.

Page 13: Suggestions for the Federal Enterprise Architecture (FEA

13

3. BAH Discussion Document(continued)

• The FEAPMO is creating the DRM to remove these barriers while facilitating the categorization of data across the Government:– c. The DRM is and is not..

• The DRM provides a consistent framework to categorize and describe data that supports the business lines and functions within the BRM:– d. The DRM Framework needs to articulate a proven

process for achieving business line/function integration and operational results.

Page 14: Suggestions for the Federal Enterprise Architecture (FEA

14

3. BAH Discussion Document(continued)

• The DRM is composed of four interrelated levels that independently classify data, and collectively comprise a Data Category:– e. Create Cognitive Topic Map Web Sites (CTW) that

use XML standards to render the information differently for different types of users.

• Each level within the DRM provides a foundation supporting the creation of XML Schema’s and Data Definition Libraries to support cross-agency interoperability and information sharing:– f. Relational Databases and XML Schema Can Work

Well Together.

Page 15: Suggestions for the Federal Enterprise Architecture (FEA

15

3. BAH Discussion Document(continued)

• The DRM can support the instantiation of cross-agency and cross-governmental Web Services for new and existing e-Gov initiatives:– g. XML registries and repositories that integrate

industry standards, support distributed federation, and integrate with other tools and models will help transform E-Government.

• There are five (5) major phases supporting the widespread rollout and adoption of the DRM:– h. Successful pilot projects will contribute to the

refinement and widespread adoption of the DRM.

Page 16: Suggestions for the Federal Enterprise Architecture (FEA

16

3a. The Federal Statistical System

• Framework:– OMB Statistical Policy Branch:

• Overall coordination for the Federal statistical system.– Federal Committee on Statistical Methodology:

• Policies on data collection and statistical analyses.– FedStats:

• “One-Stop Shopping” (about 70 agencies and 200 statistical programs).

– Major Data Integration Products:• Annual Statistical Abstract:

– About 30 topics and 1500 data tables.• USA Counties Database:

– About 5,000 parameters for the over 3000 counties.– Metadata Registries and Data Collection Design Tools:

• Census, Labor, etc.

Page 17: Suggestions for the Federal Enterprise Architecture (FEA

17

3a. The Federal Statistical Data Framework

• FedGov (formerly FedStats.Net) Content Network:– Repurposing good content to make it better with XML.– Relational databases delivered as XML and HTML.– Remote Web sites indexed and archived.– Local files indexed and searched.– Distributed Content Nodes.– Portals over Portals.

• Integration of content navigation and searching with XML:– Proprietary (Word, PDF, etc.) to XIL*.– Native XML to XIL.– Relational to XML and then XIL.– Unstructured (HTML, Text, etc.) to XIL.

*eXtensible Indexing Language – NXT 3 uses the SOAP standard to exchange and normalize information between local content directories, assembling meta-indexes (XIL based on XSLT) so that users can search or manipulate content transparently, regardless of physical location.

Page 18: Suggestions for the Federal Enterprise Architecture (FEA

18

3a. Example: FedGov Content NetworkIntegrating Documents, Metadata and Data Tables with XML

Annual Statistical Abstract

Page 19: Suggestions for the Federal Enterprise Architecture (FEA

19

3a. Example: FedGov Content NetworkCreating New Data Tables with XML

CIA Country Profiles

Page 20: Suggestions for the Federal Enterprise Architecture (FEA

20

3a. Example: FedGov Content NetworkTransforming Relational Databases to XML

USA Counties Database

Page 21: Suggestions for the Federal Enterprise Architecture (FEA

21

3b. Document Markup Languages and Community Vocabularies

• A Simple Example of the Benefits of XML-Searching for Information:– Most services are invoked by inputting data into HTML forms

and sending the data to the service, embedded within a URL string to match the given text strings to catalogued HTML pages:

• http://www.google.com/search?q=Skate+boots&btnG=Google+Search

– XML is a better way to send the data:• <SOAP-ENV:Body>• <s:SearchRequest xmlns:s=www.xmlbus.com/SearchService>• <p1>Skate</p1>• <p2>boots</p2>• <p3>size 7.5</p3>• </s:SearchRequest>• </SOAP-ENV:Body>

Eric Newcomer, 2002: Understanding Web Services, Addison-Wesley, pp. 4-5.

Page 22: Suggestions for the Federal Enterprise Architecture (FEA

22

3b. Document Markup Languages and Community Vocabularies

• CIO Council Vision, Karen Evans, Vice Chair, December 2002:– “We will consider publishing a taxonomy for government so we

can use the same language to describe the same concepts and will develop standards for XML data definitions so the information we create can be shared and accessed easily regardless of its origins.” (Sent endorsement on 12/16/02)

• E-Government Act of 2002, December 17, 2002:– Develop a taxonomy of subjects that organizes Government

information on the Internet according to subject matter (My Note: XML Topic Map Web Services).

– Address the integration of the data elements used in the electronic collection of information within databases, pilot projects that integrate data elements, and an inventory of major information systems and their interfaces between one another (My Note: The XML Collaborator and Registry Software Pilot).

Page 23: Suggestions for the Federal Enterprise Architecture (FEA

23

3b. Document Markup Languages and Community Vocabularies

• XML Standards Stack “Pyramid” (see next slide):– Community Vocabularies Layer:

• All the industry-specific implementations and problem-oriented specifications (where the “rubber meets the road”).

• How a specific user community plans to make use of XML and the specifics of data exchange, are often some of the first specifications to be developed.

• The number of community vocabularies is proliferating.

– Upside-down pyramid (relative numbers in each layer):

• From few (XML Base Architecture) to many (Community Vocabularies) specifications.

Page 24: Suggestions for the Federal Enterprise Architecture (FEA

24

3b. XML Standards Stack “Pyramid”

Community Vocabularies Community Vocabularies

XML Base Architecture

Document-OrientedSpecifications

Message-OrientedProtocols

Page 25: Suggestions for the Federal Enterprise Architecture (FEA

25

3c. The DRM Is and Is Not…

• Is:– Business-focused data standardization.– Cross-agency information exchanges.– Federated Registries and Repositories organized

according to the Business Reference Model.– An agile framework for building new cross-agency

applications and services.

• Is Not:– A government-wide data model.– A government-wide markup language.– Complete!

Page 26: Suggestions for the Federal Enterprise Architecture (FEA

26

3c. Example: Global XML Web Services Architecture (GXA)

• A protocol framework designed to provide a consistent model for building infrastructure-level protocols for Web services and applications. In addition to this underlying protocol framework, GXA defines a family of pluggable infrastructure protocols that provide applications with commonly needed services such as security, reliability, and multi-party agreement. GXA provides a set of common facilities that are needed by a wide number of Web services and applications, built on the foundation of XML and SOAP. Some of the specifications released to date include:

– WS-Security - Provides a security language for Web services; enhances SOAP messaging with credential exchange, message integrity, and message confidentiality.

– WS-Policy - A general-purpose specification describing how to expressenterprise security policies.

– WS-Routing - Describes mechanisms for routing SOAP messages withoutthe need to rely on underlying transport mechanisms.

– WS-Transaction - Adds transactional/coordination capabilities to Webservices.

– WS-Inspection - Provides a means for flexible discovery of Webservices, regardless of the mechanism used to describe them (WSDL, UDDI,etc.).

Source: Joseph Chiusano, Booz Allen Hamilton, proposed presentationat the XML Web Services Working Group, January 20, 2003.

Page 27: Suggestions for the Federal Enterprise Architecture (FEA

27

3d. The DRM Framework Process & Results

• The DRM Framework needs to articulate a proven process for achieving business line/function integration and operational results:– Not all data and information is ready, willing, and able

to be networked and integrated.– An umbrella organization is critical to mandate the

Facilitated Analysis Workshop (FAW) method lead by XML experts to develop XML Data Dictionaries and Schemas in a reasonable time.

– XML collaboration tools and registries/repositories are needed to facilitate the use and reuse of the XML Data Dictionaries and Schemas by a expanding sphere of business lines and participants.

Page 28: Suggestions for the Federal Enterprise Architecture (FEA

28

3d. Example: Global Justice Information Network

• The Global Advisory Committee (GAC) is a select group of key officials from local, state, tribal, federal, and other justice-related entities.

• Created to promote broad-scale sharing of pertinent justice information that supports the public safety.

• The GAC reports to the Assistant Attorney General, Office of Justice Programs (OJP), and the U.S. Attorney General in an advisory capacity.

• There are over 30 participating organizations!• They are overseeing the Justice XML Data Dictionary

and Schema Initiative (JXDDS 3.0).

Page 29: Suggestions for the Federal Enterprise Architecture (FEA

29

3d. Example: Sample Objects and Relationships

Person

Organization

Agency

Location (address, lat/long, …)

Contact Info (tel, fax, email, …)

Property

Weapon

Vehicle

Other

Incident

Accident

Case

Event

Conviction

Person Organization

Works_for

Affiliated_with

Supervised_by

member_of

leader_of

customer_of

Owns

Arrested_by

Convicted_by

incarcerated_by

booked_by

Person Person

Works_for

Affiliated_with

Supervised_by

leader_of

customer_of

Arrested_by

Convicted_by

incarcerated_by

booked_by

family (father_of)

work (works_for)

seen_with

victim_of

business_partner_of

committed_crime_with

Core Objects Relationships Relationships

Page 30: Suggestions for the Federal Enterprise Architecture (FEA

30

3d. Example: Justice XML Data Dictionary and Schema Initiative (JXDDS 3.0) Milestones

2002 2003Aug Sep Oct Nov Dec Jan

Feb 90 60 30Design and develop

Start 3.03.0.rfc

3.0.operation

Approved: JXDDS 2.0 JXDDS 2.1 The Plan

Identify other: Requirements Constraints Assumptions

Vet / RefineMigration tools

Validate

VetRefine

3.0.beta

Page 31: Suggestions for the Federal Enterprise Architecture (FEA

31

3e. Create Cognitive Topic Map Web Sites

• Cognitive Topic Map Web Sites (CTW) use XML standards to render the information differently for different types of users:– Initial IRS Pilot Project:

• 2002 Small Business Resource Guide CD-ROM (2,175 html/xml files -10.3 MB). Now available on the Web.

– Current IRS Pilot Project:• An integrated Topic Map application which contains over

8000 topics, all 95 Taxpayer Information Publications and over 800 FAQ with a search capability and an ontology of commonly used topics to be piloted internally at a couple of our taxpayer assistance call sites during the filing season.

Page 32: Suggestions for the Federal Enterprise Architecture (FEA

32

3e. Example: 2002 Small Business Resource Guide CD-ROM

• Welcome to our Topic Map Prototype. Topic Maps is an international standard (ISO 13250) for identifying topics and managing both their relationships and occurrences within a document set. Topic maps provide new methods for finding information on the Web such as on-line cross publication index below.

• This prototype consists of the following subset of small business publications. We will make a decision to expand the prototype to the full set of business publications based on your feedback.

• The following publications are included in the topic map prototype:– Publication 15: Circular E, Employer's Tax Guide– Publication 334: Tax Guide for Small Business– Publication 533: Self- Employment Tax– Publication 535: Business Expenses– Publication 541: Partnerships – Publication 542: Corporations– Publication 544: Sales and Other Dispositions of Assets– Publication 583: Starting a Business and Keeping Records

Page 33: Suggestions for the Federal Enterprise Architecture (FEA

33

3e. Example: 2002 Small Business Resource Guide CD-ROM

http://www.sdi.gov/irscd/web/index.htm

Page 34: Suggestions for the Federal Enterprise Architecture (FEA

34

3f. Relational Databases and XML Schema Can Work Well Together

• Relational databases are the dominant mechanism for storing and managing structured data.

• All of the major vendors have improved on an already available method of storing large chunks of data as a means of better supporting XML.

• Because XML documents do not fit neatly into rows and columns, relational databases are being extended and native XML data stores (NXD) are being developed to support SQLXML and XQuery.

• Relational database technology works well with XML tools (e.g. XML Spy) to automate the production of XML Schemas which are used so far for:– Data Validation (XSD)– Forms (XForms)– Messaging (SOAP)– Web Services Description (WSDL)– Application and Information Integration (MOF)

Page 35: Suggestions for the Federal Enterprise Architecture (FEA

35

3f. Example: XML and Databases

• Most data is in relational databases so need to XML-enable them:– Main players: Oracle, SQL Server, DB2, Sybase, Access,

Objectivity, FileMaker, and FoxPro.• Native XML databases are beginning to come on strong:

– Main players: eXcelon and Tamino (commercial) and Xindice, eXist, 4Suite, and ozone (Open Source).

• Also middleware products that transfer to/from relational databases:– Main players: JAXB, .NET, Delphi, and WebSphere

(commercial) and Castor, JXQuick, Zeus, and Zope (Open Source).

Source: Ronald Bourret, XML and Databases, XML 2002 ConferenceTutorial, December 9th. http://www.rpbourret.com

Page 36: Suggestions for the Federal Enterprise Architecture (FEA

36

3f. Example: Transforming E-Government

• The Data Model is the Key!:– Application integration is only part of the problem -

fundamental data analysis and modeling needs to be done to integrate mixed data types - unstructured and structured; relational and non-relational (e.g. native XML databases).

– The real challenge is to develop a more unified and comprehensive data model that includes a new and complex dimension on an existing problem, namely XML.

– See 8. Pilot Projects are the Key to DRM Success.

Page 37: Suggestions for the Federal Enterprise Architecture (FEA

37

3g. Use XML Registries & Repositories Everywhere

• XML registries and repositories that integrate industry standards, support distributed federation, and integrate with other tools and models will help transform E-Government:– Namespace Management– Security– Distributed/Federated Capabilities– Granularity– Classification/Taxonomy Support– "Core Component Enablement" (when fully matured under

UN/CEFACT and OASIS)

Source: Joseph Chiusano, Booz Allen Hamilton, Member OASIS ebXML XML Registry TC, “XML Registry Top 6 Features”, January 16, 2003.

Page 38: Suggestions for the Federal Enterprise Architecture (FEA

38

3g. Example: Web Services and More: Integrating Business Processes and Information Across Agencies-David Booth,

W3C Fellow, FedWeb, October 29,2002Representing Semantics

•Owners of Client and Service must agree on semantics•Can be verbal or written (preferably)•Can be human-oriented (e.g., English) or machine-processable (e.g., RDF)

•Ideally, Web Service Description should point to semantics•E.g. "targetNamespace" URL

My recommendation: Web Service Description should reference its semantics

Page 39: Suggestions for the Federal Enterprise Architecture (FEA

39

3g. Example: XML Collaborator

• Blue Oxide’s XML Collaborator has been selected as one of the six initial incubator pilot projects to “accelerate the effective and appropriate implementation of XML Web services technology in the federal government” and to help the E-Gov Initiatives gain experience with the emerging “publish, find, bind” paradigm associated with the service-oriented architecture of XML Web services.

• Designed to conform to ISO/IEC 11179, the ebXML registry standard, and UDDI and to make an integrated distributed registry possible.

• Supports the XML Working Group XML Registry and participates in the Registry/Repository Team.

Page 40: Suggestions for the Federal Enterprise Architecture (FEA

40

3g. Example: XML Collaborator

See http://www.blueoxide.com for White Paper and forthcoming online version.

A Distributed Web Service to Build Distributed Web Services

Page 41: Suggestions for the Federal Enterprise Architecture (FEA

41

3h. Pilot Projects are the Key to DRM Success

• Successful pilot projects will contribute to the refinement and widespread adoption of the DRM:– DOJ “Operationalization” of the XML Collaborator for

the Global Justice Information Network– “Military Pilots”– Electronic Standards Work Group (E-Grants)– Business Compliance One-Stop– MetaMatrix and XML Collaborator (Department of

Homeland Security)

Page 42: Suggestions for the Federal Enterprise Architecture (FEA

42

3h. Example: DOJ “Operationalization” of the XML Collaborator in the Global Justice Information Network

• XML Collaborator Pilot Stages:– a. White Paper - distributed last November– b. Live Demo with Selected Content - XML 2002 Conference,

December 10– c. Industry Standards Interoperability (e.g. UBL) - January 14

and 15 demos– d. Implement Distributed Nodes for DOJ, etc. – soon– e. Support for the eForms and DRM pilots - in process with OMB

and IAC• XML Collaborator Architecture in Support of the FEA-

PMO Enterprise Architecture:– a. Integration across multiple standards– b. Integration across multiple distributed nodes– c. Integration with other tools and models

Page 43: Suggestions for the Federal Enterprise Architecture (FEA

43

3h. Example: “Military Pilots”

• I am going to propose at the MITRE Conference kickoff presentation next week (see posted at http://web-services.gov) that one of the "Military Pilots" be the repurposing of the DoD/DISA and DLA/DLIS registries into XML Web Services using the XML Collaborator to demonstrate that the three separate DLA/DLIS registries (metadata, 11179 and XML) can become one integrated registry and that both can be "virtually" integrated as XML Web Services. You may recall that Kevin Williams demonstrated repurposing of a DoD/DISA Registry DTD into XML Collaborator and creation of a Web Service call to the XML Collaborator at the last Registry/Repository Team Meeting on January 15th. While this may be "disruptive" to some, I think it is the faster, cheaper, and better way to go with making "legacy registries" interoperable with the new distributed registries that will start to proliferate for Web Services.

Page 44: Suggestions for the Federal Enterprise Architecture (FEA

44

3h. Example: Electronic Standards Work Group (E-Grants)

• According to David Rostker of OMB/OIRA--there are approximately 7500 OMB-approved forms with current approval. About 3000 of them may relate to collection of information about grants and grant programs. We have a strategy in the E-Grants PMO that will involve the definition of a "Core" grant application data using data on the SF-424 plus the Universal Federal Identifier(DUNS)(http://www.whitehouse.gov/omb/grants/grants_forms.html)

• We also have an emerging strategy that will allow us to support agency and program-specific data collection by defining collection of "Non-Core Grant Application Line Item" possibly using an XML tag and a flexible code table to support many elements. Over time, some of these "non-Core" elements will move to Cross-agency elements and get their own XML tag as they are properly defined and vetted through X12, ANSI, EDI, FEA, GSA-XML workgroups, etc.

• As a member of the IAEGC Electronic Standards Workgroup, you will be a participant in this process. I would like to suggest that the SF-424, its related components and this "non-core" strategy be part of the set of forms that your workgroup is evaluating. We can probably have further discussions about this after the January 29th kickoff meeting of the ESWG.

• You can see some of the "strategies" for government-wide grant application data on our website http://www.grant.gov under the E-Grants PMO "Application Data Strategies".

Source: Diana King, HHS, Inter-Agency Electronic Grants Committee (IAEGC)

Page 45: Suggestions for the Federal Enterprise Architecture (FEA

45

3h. Example: Business Compliance One-Stop

• Apply XML Web Services to their content:– Digital Talking Book– VoiceXML– XForms– Distributed Content Authoring, Management, and Dissemination– Topic Maps– Collaboration and Registry– Open Web Mapping Services

• Present at the “Architecting and Piloting the e-Gov Business Compliance One Stop with XML Web Services” Track at the Open Source for Federal and State eGovernment Programs Conference, Washington, DC, March 17-19, 2003.

Page 46: Suggestions for the Federal Enterprise Architecture (FEA

46

3h. Example: MetaMatrix System• MetaMatrix provides a model-driven information integration solution

that combines an enterprise metadata management system, MetaBase, with a scalable data integration technology, the MetaMatrix Server.– The MetaMatrix Server provides a standard interface to disparate

information sources. Legacy, structured, and unstructured data sources are all seamlessly integrated in a virtual database without moving any data. Using Structured Query Language (SQL), enterprise applications and Web Services gain real-time access to disparate information sources through the MetaMatrix Server's SOAP, JDBC/ODBC, and Java interfaces.

• Supported Standards:– Object Management Groups (OMG):

• XMI • MOF • UML (eXtensible Metadata Index, Meta Object Facility, and Universal Modeling Language)

– World Wide Web Consortium (W3C):• XML • XSLT • XML Schema: Simple Datatypes

– Java:• J2EE • JDK 1.3 • JNDI • JMS • EJB • RMI

Page 47: Suggestions for the Federal Enterprise Architecture (FEA

47

3h. Example: MetaMatrix System

http://www.metamatrix.com

Page 48: Suggestions for the Federal Enterprise Architecture (FEA

48

3h. Example: MetaMatrix System