Logistics Management Institute
2000 Corporate Ridge
McLean Virginia 22102
Please send all
comments or corrections to these minutes to Glenn Little at glittle@lmi.org.
Mr. Owen Ambur welcomed the participants and introduced Mr. David McClure, Director, Information Technology Management Issues for the U.S. General Accounting Office (GAO).
Mr.
Ambur:
OK, we’re going to start off with the GAO briefing. We have Dave McClure, Director of IT Management Issues at GAO, and Dave has two guests accompanying him—John Ferrari and Steve Law. We’ll have about an hour for the GAO presentation and then we’ll have a brainstorming session to follow up. During the brainstorming session, we’d like to get as many ideas out as possible and limit the debate. Following the brainstorming, we’ll have a consensus building session led by Don Egan of LMI.
In light of the number of people today, we’ll dispense with our normal procedure of introducing ourselves and go ahead with the presentation.
With that—Dave?
Good morning. Thank you for having us here to talk about this report put out almost a month ago. We did this report at the request of Senator Joe Lieberman. As many of you know he’s engaged in recrafting the E-Government Act for 2002. The bill addresses XML and SOPs [Standard Operating Procedures] for data sharing in government. We were approached last year to do the report—on “What is XML?” and “What is its future?”
The report is not an advocacy or critique, but rather a “where we were at this moment” in XML’s evolution. This is a moving target. We’re already out of date, depending upon what’s on the wire service or xml.com. We must realize that. We would like to share an overview of this report. It was widely reported in the press. The headlines were from A to Z as usual—all the way from calling for the end of XML, to it’s being the savior for the government. We’d like to share what it says, and have a dialogue about where we should go.
There are some recommendations in the back of the report that are worth looking at in terms of next steps. With that, I’d like to turn it over to John Ferrari, my Assistant Director. He and Steve Law are really responsible for it. He’ll answer all your in-depth questions. John?
Mr. John Ferrari:
Thanks, Dave.
Slide 2: [Agenda]
Good morning. I’m glad to be here to explain what we’re trying to say in our report. I’d like to start off by talking a little about the context of the report, and what feedback we’ve heard so far. I’ll spend time on specific scope and objectives of the report, as well as the method, to help you understand what we were and were not trying to do with this report. I’ll concentrate on the main issues we saw emerging, and our recommendations.
Slide 3: [Context] The press stories that came out—the first two came out the same day the report came out. [Mr. Ferrari read the selection of headlines on the slide to the audience.]
1. Computerworld (April 5): “GAO says XML not ready for extensive government use.”
2. GovExec.com (April 5): “GAO urges government to adopt XML programming language.”
3. GCN.com (April 5): “General Accounting Office warns of XML pitfalls.”
4. Federal Computer Week (April 8): “XML efforts need focus, GAO says.”
5. Washington Technology (April 10): “Lieberman: Government needs plan for adopting XML.”
As you can see, the first two are almost the opposite of each other. Neither captures what we’re trying to do with the report. The third one has a foreboding tone, which isn’t what the whole report was about. We did warn of some of the pitfalls, but it was only one part of it. The last two were closer to what we were trying to do. The one that says XML efforts need focus is closer to what we thought. The last one—the quote from Senator Lieberman—is one of our recommendations.
Mr. Marion Royal: There was one about our group—attributed to Owen and me—that was misleading, because we did not challenge the report.
Yes. We got a single negative comment from HR-XML because they wanted their slice of pie covered better than it was. Other than that, we didn’t get any other negative comments.
Mr. Ambur: I agree with Marion’s point, but whether or not we liked what’s written, these comments are a measure of where we are. These reporters know a little more about the development of XML than the general public, so it’s an interpretation of what we’re facing.
Slide 4: [Scope and objectives] The scope and objectives narrow in on what we’re trying to do. GAO is a congressional agency. Almost all of our assignments and reviews are done at the request of congress—usually at the behest of the head of a committee or subcommittee. This one was performed for the Senate Committee on Governmental Affairs, specifically Senator Lieberman. It focuses on broad federal adoption of XML. We looked at the Federal Government in general.
Our tasking was to look at the big picture across government. We had two major taskings:
1. Look at the status of XML standards first, because there are so many (like all standards). Where are they in terms of providing a foundation for broad government use, and
2. What are the challenges government faces, specifically the challenges in fulfilling the promise of broad interoperability? So it was looking at the toughest nut to crack in this whole process.
We tried to collect as much information as possible in this area, and analyze and distill it. We looked at the major standardization activities and the documentation that was out there.
Slide 5: [Methodology] [In addition to the methodology, the slide lists the names of government agencies, private sector representatives, and consortia with whom GAO held discussions—XML Working Group, OMB, GSA, NIST, DoD, EPA, NARA, SEC, OPM, Amtrak, Microsoft, XBRL.] Here is a list of some of the people with whom we spoke. You can see that the concentration was on the government, as is the focus of the report.
This was conducted from April 2001 to January 2002. It goes back to the point that this is a moving target. I know some of the facts are out of date now, but that’s unavoidable. The last point I’ll make is that the heart of what we were doing was to be an ear and listen to what you had to say about XML, and come back and report on that. It wasn’t to sit in an ivory tower and decide what should be done—but rather to hear, distill, and report on it.
Slide 6: [Principal findings] The first chart is some of the progress that’s been made so far. XML is clearly being implemented in many ways—both commercially and in the Federal Government—so headlines saying it’s not ready to be used are clearly out of touch, since it’s already out there. In the first chapter, we listed many examples of federal agencies that are implementing XML. It’s not a scientific or statistical study, just few examples. It’s not meant to include everything, but just a few good cases.
The SEC is an example of a very targeted use of XML. They realized savings in software development. It was very effective, and very specific. The AMTRAK example was successful along the same lines. Others come to mind. [The Department of] Justice and DoD works with XML where people move beyond specialized systems and pull together a community to agree on data structures. EPA is getting States to agree to submit their environmental reporting data in XML.
There’s a range of sophistication of uses. We have no issues or criticism of the use of XML to date
The XML Working Group—lately the group has taken up the drafting of a developer’s guide, a discussion of guidelines for usage, etc. It’s definitely getting toward the line of some of our recommendations. That’s what I’ll get to.
Mr. Ambur: By the way, our current charter lapses at the end of this fiscal year. One of our decisions at the CIO Council will be to recommend whether our work continues, and if so in what context.
Slide 7: [Findings, continued] Remember, we looked at taskings, methods, and challenges. In the first arena, the overall message is that the basic technical framework is there and well established. It does not pose a problem in making decisions in the government.
The arena of business standards is less well-established. It requires maybe caution or care at implementation. I’ll get into that more in a minute.
On challenges, we noted that implementing XML presents pitfalls. That was picked up in the press. The main reason that’s one of our major findings is to make the point that XML isn’t a silver bullet that can be easily implemented and solve all problems of interoperability. It must be implemented with care to reap the long-term benefits.
Another point—federal input to standards bodies hasn’t been consolidated. It’s been catch as catch can. We think interoperability depends upon an effective cross-agency registry, and lastly, we think that implementation is more effective in terms of an architecture.
Slide 8: [Standards] OK, let’s talk about standards a little. The technical standards are well established. The key factor is that technical standards emanate from the W3C. Everybody agrees they’re in charge. It makes things convenient—they’re a source of authority.
Business standards don’t have the basic agreed-upon authority. They come from many different places, so there’s not the same agreement.
We looked at the vertical and horizontal standardization. In horizontal, there’s a lot of excellent work going on—ebXML, Rosetta, Web Services, EDI, etc. We didn’t intend to criticize any of these. We could see very clearly that in the larger sense there’s opportunity for most to be technically interoperable if they’re not already so. That’s not the issue. It’s not that adopting one or another will rule out the use of others. The real issue for government is in terms of what the Federal Government should adopt is, for example, “Is ebXML our way of doing business?” Essentially, it’s not the time to do that. There’s not yet enough consensus to be able to do that. There’s still uncertainty about this, and that’s important for management to consider.
Unidentified member: The W3C has the same problem with patents as ebXML.
Mr. Royal: WSI are loaded with potential IP problems.
Mr. Ferrari: So which should it be, Web Services, ebXML? We could say RosettaNet is limited to a specific supply chain, etc. The details don’t matter as much for our message. Basically, the government needs to be careful and hedge its bets in moving forward. That’s it for major horizontal standards.
In the vertical area, many things are going on. In most cases we found they’re not far enough along yet to be adopted. Three potential standards that could be used in the future might be XBRL for reporting, HR-XML for HR things, and Legal XML is another candidate. All of these are early in their development. There are not a lot of definitions for schemas. There are some. We got into a fight with HR-XML as to how many there are. That’s no the point. It’s just that there aren’t enough to adopt anything yet.
The final point—the government needs to be cautious and as open in possible. If we go down one route, we may have to change in the future. The government doesn’t control standards, as we know very well.
Slide 9: [Federal Government faces challenges in realizing XML’s full potential—pitfalls] It’s the challenges to government. It’s chapter three of the report. We introduced a section discussing the pitfalls of XML. Let me give you some background.
We put some effort into trying to explain the benefits of XML, and why it’s something that deserves attention. Managers need to be aware of this. When we started off doing it, we became concerned that the chapter would sound as if we advocated XML as the silver bullet that would solve everyone’s interoperability problems. We wanted to make the point that it’s not an obvious no-brainer with huge benefits. That’s what this section was getting at.
We did a chart in the report that gives some examples. We talked about how once you go down this route, you’re always going to have some risk—even within an agency—that if you jump in and develop tags for a specific system, even within an agency, you might have multiple tags that aren’t the same, that require translation. Between agencies, the proliferation of different data definitions and structures (which includes all the various objects—data models, schema, DTDs, etc.) is a management issue that could lead to future expense if not addressed up front.
There’s also the risk in any implementation of implementing proprietary extensions. The most obvious example is Microsoft XBR. We won’t talk too much about Microsoft.
Security is next on this list. We heard during the review that security is an important topic that needs to be addressed. We may not have done it full justice in the report. We’re concerned about not overly emphasizing it, because the press could pick it up and overemphasize that aspect. Therefore, we mentioned the subject and didn’t dwell on it at length. We do recognize that it’s an important subject.
We’ve heard of the issue of using Unicode—that it can’t be scanned by virus checkers. I haven’t heard of any solution as yet.
There are not-so-hard issues also, for example, digital signatures. We know how to do them but it takes a conscious effort to make sure those are included. I hope I’m clear on that issue.
Mr. Don Egan: How to you weigh the risk of the first two bullets on this slide versus the last bullet on the previous slide saying that government must be cautious?
Mr. Ferrari: Good question. The question was, with regard to this chart of implementation pitfalls and the risk of redundant data definitions, etc, how do I reconcile that with the previous chart that showed overall findings about standards, and that business standards are not fully developed yet? My answer to that is that this discussion of standards is a look at what government is planning. It goes back to the task of determining where government is in the broader issue of implementation. The issue of pitfalls is talking about momentary, specific implementation decisions. The difference is the level. These are challenges the IT manager faces in deciding whether to implement.
Mr. Egan: EDI had a mutual body to wrap around. Until something like that comes out for XML, we’re at risk of proprietary standards.
Mr. Ferrari: Good point. Without a similar committee for XML as EDI, there’s the chance that developers will develop non-compatible systems.
Mr. Royal: Does that suggest that we need value-added networks?
Mr. Egan: Not to me it doesn’t.
Unidentified member: We heard the reaction from press; what’s the reaction from the CIO Council, the Senate committees—the real stakeholders in this?
Mr. Ferrari: We’ve had a good reaction, in general. The way we do things at GAO is we send a draft out to major stakeholders. This was sent to various people. Lee Holcomb wrote a comment at the end of the report. It’s fair to say he endorsed the report. We also got positive comments from members of the XML Working Group who looked at the report. CIO Council type people see this report as an opportunity to get more attention from higher levels for XML. If I’m characterizing that wrong, let me know. We also feel the same way. We hope it’ll help raise visibility—get attention into developing a registry or not. Dave?
Mr. McClure: Having a discussion with members of Congress about XML is like trying to explain PKI to your grandmother. We hope the report, while it simplifies things, takes a step forward. We have to energize. We need more motion, as opposed to remaining unfocused. Where can we put resources and management attention for more bang for the buck? That’s what we’re trying to get across to Congress.
Mr. Eliot Christian: The vast majority of government systems are not documented in any form. Rearranging the inside of the church is fine; it’s the people outside the church. To describe what we’re doing in any form would be a step forward. Once they’re in machine-processable form you can convert them.
Mr. Ferrari: Some say it doesn’t matter, because once it’s XML you can do anything. In context, you have a good point. The state of the government was such that we were picking at nits in the broader sense. On the other hand, I think the approach we’ve taken at GAO is we want to push for model IT management in general. We pushed for enterprise architecture, and I think that’s the right way to do IT investment. It’s along those general lines of “What are model management practices?” For XML, what is the right way to do it?
Unidentified member: On the third bullet—security—is the flavor geared toward the mechanisms that will provide security, or the current lack of the business world to put security into XML?
Mr. Ferrari: I think both. It’s a caution about both. We have to live with the fact that the business world isn’t stepping up to the plate. Government can’t just write it off. We’ve found, based on previous work, that government will have to lead here too. We can’t just write off the risk as we do government business.
Moving on—the next chart I have here is about strategy, which we’ve already started looking at. It’s a really simple concept, with a number of possible ideas. As the morning goes on there may be more ideas.
Slide 10 [Government challenges, continued—strategy] There is currently no explicit government strategy. We’ve found that this could be better done. A strategy could talk about where government wants to go, set specific goals, and talk about priority systems or data in XML format. In a previous review I was involved in, they set a goal that they were going to develop a machine by 1996. They didn’t get there. They got close. The point was that specific goal was valuable in making progress, justifying budgets, etc.
Part of the strategy would be to talk about a registry and how it would be used; which part of government would use it, etc. Not talking about any details at this point.
Unidentified member: Are you aware of the OSD letter of 22 April, addressing many of those issues?
Mr. Ferrari: No.
Same unidentified member: It designated DISA as the registry source. It’s done a lot of the things you just talked about.
Unidentified member: There is some question about what the DoD memo does and does not do.
Mr. Ambur: Let me point out that there’s a link in “What’s New” at xml.gov to that memo.
Slide 11: [Government challenges, continued—standards] The next major point is one of collaboration. It came up repeatedly. On one hand people told us they didn’t have resources to participate in all the organizations involved in developing standards, but when we talked to a sample of consortia representatives they complained about people not showing up to participate.
We realized something could be done a little better. Our thought s were that some consolidation might help get more leverage, if efforts were not scattered to the wind. Clearly, government has a need for unique data elements and structures. An LMI study showed that that’s not a matter of dispute anymore. That’s the main point.
Unidentified member: Where does GAO believe that point of coordination should be? Why isn’t NIST representing unique Federal Government standards? I believe they still have the unique federal responsibility for developing standards. Where do you see this coordination coming from, and what is NIST’s role?
Mr. Ferrari: In response to the first question—we didn’t see it as our position to make that call. Our job is to point out that it needs to take place. We mentioned that the EDI world has a model. EDI’s FESMCC is a possible model. We did not say it was the answer by any means. Perhaps the XML Working Group or another group could take it on.
As far as NIST’s role, in my opinion, they’re responsible for setting standards. I’m not sure they have the role of participation in standards bodies. I’m quite sure they’d say they don’t. They’re not an automatic choice to fill that role.
Slide 12 [Government challenges, continued—Registry] I’ll try to wrap this up. We have a couple more charts. This next chart is about the registry. We’re assuming this is one subject where there might be the least dispute. Everyone seemed to believe in a registry as a way to coordinate standards work, and get de facto data definitions and standards. The discussions on how to use and implement the registry are the toughest discussions, rather than the concept.
We found that effective implementation of XML would require efforts from the top and the bottom. There’s a need for leadership and vision, which we discussed in the previous section about strategy. In terms of movement from the bottom, we see the registry as the major vehicle for doing that. A good cross-agency registry would be a good grass-roots way of determining how this could be used for federal agencies. If someone would adopt that because it makes business sense, then we get momentum from the bottom up, from that perspective.
The major issues in getting this done—and this is no news—are funding. From the top, they need to commit to this as a way to move forward in XML. A lot of policies need to be put in place; “How will items be submitted?” “What are the rules for deprecating out-of-date data elements?” “Security and digital signatures,” for example. “Are people going to need to work through a bridge for verification?” etc. There are lots of issues.
Slide 13: [Government challenges, continued—Enterprise Architecture] The next chart is about implementing XML in the context of an enterprise architecture. It’s a simple concept. There’s not a lot of material in the report about it. Because the essence of making XML interoperable is how good data elements and schemas are, if you’re going to implement for the future, before you start you need to do serious analysis of your business processes and existing data elements to reduce the amount and coordinate. It’s all the kind of thing one does in putting together an architecture. It’s a concept that GAO and the CIO Council have championed. Using that framework is a way to leverage the value of XML.
Mr. Christian: Can you comment on that versus the notion of just “document?”
Mr. Ferrari: I see your question as whether a registry doesn’t penalize multiple data definitions, whereas this concept of enterprise architecture really streamlines data elements and definitions. I didn’t dwell on it on the registry point, but I think there will be a big management question of proliferating elements. There could be hundreds of elements.
Mr. Christian: Hundreds of thousands but that’s OK.
Mr. Ferrari: I think this is a philosophical question.
Unidentified member: I agree with the first point. This isn’t just about data. The first bullet is what we want to achieve—that we can have structures that can be redundant. It’s not just about data. If you create an enterprise architecture, you want it interoperable at the system level. The data is just a minor piece of that.
Mr. Ferrari: Thanks. I agree, even though I was dwelling on data. The point is that XML isn’t just about standard elements, but also business processes. That’s a big part.
Mr. Mark Crawford: I just want to add that important policy decisions need to be made. Say we use the registry in both bottom-up and top-down approaches for vocabulary builds. This is only a small piece of what needs to be done. I’m hoping the registry is much more than a place to find where we got our tags. It needs to be where we find reusable XML components, It needs to support our run time requirements. The registry needs to be an integral part of the federal architecture. the role of the registry and its functionality needs to be part of architectural decisions being made at OMB and those decisions need to be articulated in policy and funded in execution.
Unidentified member: I’d like to respond from the practical issue of standards across government. I’ve been involved in vertical X12 issues with IRS, and we’re finding that the drive for standardization is becoming an inhibitor, because they’re not being done in a business-value context.
Mr. Ferrari: I’ll comment that some standards, strictly for standards’ sake, can be non-productive. It’s in synch, then, that a strategy for moving forward is important. Having done that, then we can talk about the standards we want to discuss.
Unidentified member: A critical point just been raised on several levels. This ability to define a level of information based upon business needs is really vital. Some people just want a few fields or functions they require, and they shouldn’t be inhibited from moving forward just because others want standards.
Mr. Ferrari: Yes, standards need different levels of granularity—where in some cases it’s advisable to adhere at higher level, and in other cases, we need more involved participation.
Slide 14: [Recommendations] The last recommendation I’ll just mention. The overall recommendation was for OMB to come up with an explicit—rather than de facto—strategy. We have four recommendations. [Mr. Ferrari read the four recommendations to the audience.]:
That is basically it for the rundown of the report. I’ve attached a contact page. Feel free to reach us. The report itself is on the Web. You can get it through the xml.gov site.
Mr. Michael Jacobs: Are you expecting feedback from agencies that we agree or disagree with the final version of the report?
Mr. Ferrari: Our official process is that we expect response from agencies to whom we make recommendations. In this case, it’s OMB, so we give OMB 90 days to respond.
Mr. Crawford: Since the report came out has there been dialogue with Mark Foreman or others in OMB?
Mr. Ferrari: We had a long discussion with various folks about this. I know this issue. I’m going to bring it up today. Mark Foreman knows about this, and is very XML-oriented. The issue is, “Where we want to focus our resources here?"
Mr. Ferrari: I think your input from this Working Group is critical to this. OMB should be consulting agencies through the CIO Council on what their reactions are. Communicate this through your CIOs and make sure it doesn’t die.
Mr. Mike Tinemann (Architecture and Infrastructure Committee lead): We made a recommendation to establish an “Architecture Office” for coordination and stewardship because this can’t happen by voluntary committees. As much work as we’ve done, this is homework activity. So Dave, if you have a message for Mark Foreman and others, lets find a way to institutionalize this, because if we don’t, DoD and EPA and Energy will do their own, and we’ll go down the road of 100,000 definitions, and it’ll proliferate down the road.
Mr. McClure: You raise a good point. There are 23 eGOV initiatives which depend on this report. Two are cross-cutting. I don’t know why they wouldn’t devote the same energy to XML.
Mr. Brand Niemann: We should give credit to Mark Foreman and Lee Holcomb and Owen, for publicizing what we’ve done with XML and can hopefully be done with XML in these other eGOV initiatives. It’s the technology that’ll break down the stovepipe approach that we’ve been using.
Mr. Ambur: OK, we’re a little over on time, but our primary goal was to get an understanding of the GAO report, and I think we’ve done that.
End Presentation
FACILITATED
BRAINSTORMING SESSION
Mr. Don Egan
We thought we’d try to concentrate on establishing a list of ideas. As Owen suggested, we don’t want a person come with an idea and have another slam it, because then others won’t offer ideas. Let’s focus on getting as many ideas on the board as we can. To stir some thought and ideas you might look at the GAO briefing. After we’ve done that, we’ll consider breaking these into groups: Security, Standards, Interoperability, whatever the correct categories are. We’ll take them as we have time left into high, med, and low priorities, then attempt to rank them.
Mr. David Webber: I would start at the business level; “What, from a business point of view, are you trying to achieve?” In the DFAS world, the key is interoperability within the enterprise—achieving an agency service layer. From the government point of view, another one we heard earlier was the eGOV focus. The Canadian government is trying eGOV for the citizen. What does that mean, and what process does that drive?
Mr. Egan: So government-to-citizen capabilities?
Mr. Webber: Yes.
Mr. Jacobs: The Federal CIO Council draft a government-wide strategy.
Mr. Steve Vineski: Build on the eGOV initiatives. Use their work to build processes on them. If they develop standards, have associated groups build the XML standards.
Mr. Christian: In the geospatial realm we’re already dong that, and it cross-cuts many of the issues.
Unidentified member: Make recommendations to the Architecture and Infrastructure Committee for immediate initiatives in the Federal Government that can make use of XML, like OMB.
Unidentified member: Establishment of full-time roles and groups for funded management.
Unidentified member: Incorporate commercial, technical, and business standard into the work.
Unidentified member: Provide a communication and outreach program about positive XML projects, and map them into the four eGOV quadrants.
Mr. Christian: You inserted the word “funded” earlier. That may be a killer. Without funding, there are folks who would step up. We could do a public and private partnership.
Mr. Vineski: There are a lot of federal agencies undertaking XML. Some are application-specific, some are broader. It might be good to survey them to get an agenda for what they’re doing. See what can be shared, and see what the gaps are.
Mr. David Eng: Make a template for standard forms to use across agency implementations. Just like a registry, but a template for common forms. Another thing is to use XML—in light of the comment about management—to get a distinct management for content across agencies. Establish procedures for interoperating in a distinct nature across processes.
Unidentified member: What we’re talking about comes under eGOV for the citizen. That’s the top level. Underneath you have the capability of creating the forms for citizens, etc.
Mr. Christian: That’s too narrow.
Same unidentified member: You don’t want a disconnect, because what goes between government agencies also applies outside.
Mr. Tony Cavataio: In the GAO report it talks about OMB working with NIST. It should be broadened. It should include the President’s Management Council, not just the CIO Council. It used to be called the Quad Council. Also, there’s so much importance on enterprise architecture. This needs to be included in the strategy. Then, implementations would bring in eGOV initiatives as well as specific agency architectures.
Mr. Christian: Keying off of templates, it would be useful to take the most common data elements and get them in the registry using the ISO BSR to get it populated. You inherit the common concept to make it all useable.
Mr. Mike Tinemann: Provide specific verbiage for a Federal Architectural Framework version 2.0 regarding how enterprise architecture fits into the overall framework model.
Mr. Dan Jansen: A registry of XML for long-term preservation of federal records.
Mr. Niemann: Have each agency develop pilot projects to demonstrate three value- proposition areas: future proofing, interoperability with other agencies, and multi channel dissemination.
Ms. Betsy Schmidt: Review large-scale commercial implementation and international government efforts.
Ms. Betty Harvey: It’s important to look at the government as a whole and see where government standards align with other horizontal and vertical standards.
Mr. Tom Guinan: Add to the pilot idea, one point to include big transactions. Lots of times we talk about data standards. These decisions can be dealt with directly.
Mr. Royal: Perhaps we could create a sub-working group to address policy issues, and create a draft policy that might be used by the Architecture and Infrastructure Committee or the OMB architecture team. As far as policy, when you mentioned surveying federal agencies, I was tempted to add policy to that to see if there’s any policy used by federal agencies.
Mr. Tinemann: Develop a business plan relative to management of the registry and the full requirements to do it correctly in terms of resources, location, and governance. All requirements to make it work as an instrument of the federal government.
Mr. Royal: We’ve already started that.
Mr. Eng: Different agencies have different expertise. We need to let them have a chance to establish lead agencies by area of expertise.
Mr. Tinemann: DoD support the XML Working Group for all federal government activities related to XML. Use them as an academic clearinghouse for all things XML.
Unidentified member: Everyone is talking about agencies. We should look at the overall business spectrum. One agency might have different areas. I’m from the legal side. Different agencies would have different expertise.
Mr. Jim Benson: Picking up what she said, there are differences in defining the strategy from the federal level. Part of the strategy should be to tie in OMB and agency strategies.
Mr. Christian: Select 5-10 cross-government virtual committees. Channels where interoperability is the focus. Pick a few as candidate pilot areas. Work for success.
Mr. Niemann: Develop an “XML Seal of Approval” from selected websites that deliver good XML.
Ms. Lynn Hadden: Conduct a survey of state and local governments to see if they’re developing registries.
Ms. Susan Turnbull: Explore the standards bodies that are moving to XML-based document systems to speed up the business standards process.
Mr. Christian: At the early development stages of a new process or schema it’s easier to influence. I’d like to identify a process to track what’s happening with news standards efforts. For example, there’s a biometric initiative. I’d like to identify what’s up in their process.
Ms. Turnbull: What I meant was bodies moving to an online process where you can participate, ex INCITS is moving there.
Mr. Crawford: Identify appropriate XML technical standards efforts that map to the federal architectural framework, and ensure insertion of government involvement.
Unidentified member: Establish a subgroup in the CIO Council XML Working Group to discuss XML security issues.
Unidentified member: Establish a liaison with the federal PKI.
Mr. Vineski: To do that work where there isn’t immediate payoff. I suggest there be guidance from OMB for agencies in their overall XML policy development.
Mr. Royal: It might be beneficial for us to look at marketing the XML Working Group and xml.gov so others will know about us. Make sure we address ideas related to each of the four recommendations that GAO made on slide 14 of their presentation. The first bullet is two related, but separate issues. Have we captured that in suggestions made so far?
Unidentified member: In terms of this Working Group, are we talking about a recommendation? How exactly can we add value?
Mr. Ambur: Something struck me. We wouldn’t want people to get the message that when we say “XML registry”, we mean a centralized single implementation, so maybe the verb is to demonstrate that the Federal XML Registry is interoperable with distinct registries—at least at other levels of government.
Mr. Egan: Make sure we caught Owen’s points. Owen, I think that’s good. I wouldn’t limit it to other levels of government. I’d include commercial and private industry as well.
Mr. Eng: Develop a set of standard test methods and procedures along with test data for test interoperability.
Mr. Christian: And implement a test bed for people to try out things they’re experimenting with.
Mr. Eng: We need a set of implementation guidance for XML. Not to the point of a cookbook. Just for broad implementation issues.
Mr. Royal: It would be helpful if we could identify case studies of use of XML in business processes. We focus so much on data exchange. If we could find case studies of XML processes and the dynamic establishment of relationships, that would be useful.
Mr. Egan: Re-engineering concepts, is that right?
Mr. Crawford: Not business-process modeling. We’re talking about where it’s being used for business processes beyond exchanges—documenting and determining where XML could and should be used for federal agencies beyond data exchanges – the full gamut of XML technical specifications and their potential to impact every aspect of our architecture.
Mr. Egan: Internal processes?
Mr. Royal: No, it could be not limited to that.
Mr. Christian: Standard verbiage about SOPs of the federal government with respect to the XML registry, intellectual prop, IT concerns.
Mr. Ambur: One of John’s points was balance between top-down and bottom-up approaches. One thing we might want to do is identify the top 500 elements. I think of top-down versus bottom-up as mandatory versus optional. The top-down approach suggests strong guidance that these are elements that should be used. I think somebody also made reference to eGOV projects that’ve been identified. They provide one focus for XML activity.
Ms. Theresa Yee: I would like the last idea to be “fund all of the above.”
Mr. Egan: Say “provide OMB funding.”
Mr. Christian: Unless that’s a show-stopper.
Ms. Turnbull: Maybe GSA’s Federal Technical Service could come and “show and tell” their experience with regard to XML that would help prospective buyers.
Unidentified member: Establish usable verbiage for inclusion into contracts for use of XML in development projects and activities.
Mr. Christian: Top-down—establish an XML representation of top levels of government and their services. Along that line, an XML schema for government performance plans and reports.
Unidentified member: Build on something Marion said in a previous page. He talked about IP case studies. Within the W3C most of the requests are for use cases. We’ve begun to establish a library of use cases. Perhaps establishing a library of use cases would help others.
Mr. David Webber: A supplemental registry that ebXML has is a classification structure that allows you to discuss use cases in context. That should be in the registry to help.
Mr. Royal: My suggestion is more of a white paper to be distributed among management.
Mr. Webber: Guidelines, descriptions thereof, etc.
Mr. Royal: Yes. One idea—maybe identify at least one person ate each agency who has the responsibility for XML at that agency. It may be the CIO, but it could be the Congressional POC, or a leadership position. Maybe both?
Unidentified member: What level of agency?
Mr. Royal: All departments and bureaus.
Ms. Turnbull: Maybe something like a scaled-down Baldridge Awards to incentivize library use cases—show what they’ve done.
Mr. Crawford: I’d like to point out about the XML lead at the agencies—it depends upon the size of the agency. We should consider a recommendation to take it down further. For example, the Department of the Navy is asking for identification of XML leads from all commands in the Navy. They’re doing it because they’re establishing relationships with standards bodies, and setting in place a way of participating with the bodies to ensure that DoD positions are coordinated and that the standards bodies are hearing what the Department of the Navy wants and needs, not just what a lower level perceives as the need.
Mr. Eng: Provide free opportunities for all government employees to get XML training.
Unidentified member: Begin to explore mechanisms to resolve disparities between different XML schemas, registries, etc. across the board. At some point, once we proliferate all this stuff, we’ll need a mechanism to begin to consolidate, focus, and eliminate. We should start the dialogue to discuss how that would happen in the future. I think it’s one of the recommendations in the GAO report—discuss the governance process.
Unidentified member: There are government data standards in the EDI world. It might be useful to leverage them in the XML world.
Mr. Crawford: Append to David’s training point that xml.gov identify existing resources for XML training. There is plenty of free, online training out there, and it’s good.
Mr. Webber: Add to that—have a center of excellence for XML. Have that be the point where you find those links.
Mr. Tom Guinan: There’s a lot of confusion around leveraging existing standards into XML.
Mr. Royal: We need to increase participation of members at xml.gov.
Ms. Turnbull: Link to federally-sponsored research and development using XML—the IT R+D community (universities sponsored by NSF, Energy, and so on).
Mr. Eng: Add a free foundation of requirements for harmonizing.
Mr. Tinemann: Also, I wasn’t talking just about the Federal Government—more about the broad area of activity.
Mr. Ambur: That point reminds me about OMB’s quality guidelines. Specify an XML schema for specifying information quality, particularly that which is disseminated to the public.
Unidentified member: Develop a metadata standard for government use.
Mr. Egan: We’re getting toward the time where Owen wanted us to rank them. Before we do that, I want to see if we’ve covered everything in the GAO report. Look at Page 10 of the presentation—“no explicit strategy for XML adoption.” Have we covered that?
Mr. Royal: It was covered in the response of managing a registry. Not the overall strategy.
Mr. Christian: What’s missing is defining interoperability goals. Then we need to figure out the XML strategy within that. XML strategy by itself doesn’t mean anything.
Mr. Egan: Government-wide strategy is a little broad.
Mr. Christian: Provide input for XML strategy.
Mr. Royal: Provide XML strategy.
Mr. Crawford: Provide both.
Mr. Christian: Can you imagine the Federal Government saying XML strategy “goes here?” I don’t see that.
Mr. Royal: The GAO report called for an XML strategy as it relates to enterprise architecture.
Mr. Crawford: A strategy for government-wide adoption of XML.
Mr. Egan: Page 11 has the following: “No process defined for collaboration among standards.” Bodies did we catch that?
Audience: Yes.
Mr. Egan: We got interoperability issues. We got enterprise architecture.
Mr. Mark Calem: I understand there are 23 eGOV initiatives. Maybe there should be 24, with XML adoption as a cross-cutting enabler of government initiatives.
Mr. Royal: It’s not a new one. I don’t think it was captured. The gentleman was talking about renewing the charter of the XML Working Group.
Mr. Jacobs: Yes—renew the charter, and include in it what was called for in the GAO report.
Mr. Royal: Have the XML Working Group be the committee mentioned in the GAO report?
Mr. Jacobs: Yes.
[At this point Mr. Egan closed down the discussion:]
Mr. Egan: Owen, Marion—would you like someone to be the recipient for the discussion?
Mr. Ambur: Certainly. We have links on every page of xml.gov, so put them there and the right person will get them.
Mr. Webber: One thing I’m seeing here is ideas at the top level of the pyramid and ideas underneath them. The Canadian government has spent $50 million in developing what we’ve put in this chart here. The U.S. Government has probably done many of them as well. A lot of things on the chart are never-ending roles. If you have a pyramid, you can control them over time. Focus at the top of the pyramid, and control them over time.
Mr. Egan: Do two things? Develop a hierarchical structure for activities, and separately there’s some Canadian work we should analyze?
Mr. Webber: Yes, and some from the UK as well. They have a notion of a secure channel for development. They’ve built up a lot of these models for a lot of stuff we have in this list. It’s commonly applicable stuff. You can recast them in what the U.S. Government wants to do.
Mr. Royal: We’re talking about strategic activities as well, right? We should create a new section on xml.gov for strategic activities.
Mr. Egan: OK, let’s pick some word that’ll begin to group these things. Let’s try to do that as part of prioritizing. [The group suggested the following grouping terms:
Interoperability, eGOV, strategy,
architecture, governance, survey, outreach,
registry, archiving, pilots.
The categorization was accomplished on a spreadsheet, which is included as a separate document at xml.gov.]
Mr. Ambur: I hope you found this useful today. We didn’t achieve my secondary objective—prioritize and rank to see what provides the greatest value. We are interested in input to the xml.gov site, where we’re documenting everything we’re doing. The simple thing we can do is convert this to HTML and put it up on the site, see how we can extend it to meet the objective, and maybe have another meeting. I don’t want it to be another email operation. I’d welcome any input you have to see how we can leverage it.
Mr. Christian: Just a few people do it, and put it out for comment.
Mr. Ambur: Good suggestion. Any other comments before we wrap up? OK then. I thank you all.
End facilitated session.
ATTENDEES:
|
Last Name |
First Name |
Organization |
|
Ackermann
|
Jim |
Mitre Tek
Systems |
|
Ambur
|
Owen |
FWS, Dept. of
Interior |
|
Barnes |
Lillian |
DOC/NOAA |
|
Benson |
James T. |
Booz Allen
Hamilton |
|
Billups |
Prince |
DISA |
|
Blackston |
Carol S. |
|
|
Bove |
Andy |
Software AG,
Inc. |
|
Calem |
Mark |
AMS |
|
Carnahan |
Lisa |
NIST |
|
Cavataio |
Tony |
Department of
Education |
|
Christian |
Eliot |
USGS |
|
Crawford |
Mark |
LMI |
|
Dodd |
John |
CSC |
|
Egan |
Don |
LMI |
|
Eng |
David |
EPA |
|
Ferrari |
John |
GAO |
|
Fox |
Dan |
DLIS-VPO |
|
Fox |
Jack |
FEMA |
|
George |
Sony |
SBA |
|
Guinan |
Thomas |
IBM |
|
Guy |
Jim |
American
Systems Corp |
|
Hadden |
Lynn |
County of
Fairfax, VA |
|
Harvey |
Betty |
ECC, Inc. |
|
Havekost |
Charles |
HHS |
|
Hickling |
Donna |
SAIC |
|
Huber |
Mark |
NARA |
|
Jacobs |
Michael |
Department of
Navy |
|
Jansen |
Dan |
NARA |
|
Jenkins |
Lisa |
EPA |
|
Jordan |
Rick |
FAA |
|
Kanaan |
Muhan |
DynCorp |
|
Kline |
Sandy |
NAVSEA |
|
Knight |
Dolores |
Defense
Technical Information Center |
|
Lambert |
Kim |
LMI |
|
Law |
Steven |
GAO |
|
Lewis |
Diane |
U.S. Department
of Justice |
|
Lichtman |
Steve |
AMS |
|
Lin |
Meng-chun |
Department of
Justice |
|
McAndrew |
Tom |
NARA |
|
Metzger |
Kathy |
Cisco Systems |
|
Morgan |
Roy |
NIST |
|
Niemann |
Brand |
EPA |
|
Obey |
Nat |
DLA |
|
Ortiz |
Bert |
IRS |
|
Poot |
Lex |
Dynamic
Technology Systems |
|
Roberts |
Donald |
Mitretek |
|
Roberts |
Davis |
SAIC |
|
Rosenthal |
Lynne |
NIST |
|
Royal |
Marion |
GSA |
|
Schmidt |
Betsy |
Software AG,
Inc. |
|
Schulte |
Doug |
Booze Allen and
Hamilton |
|
Skall |
Mark |
NIST |
|
Smith |
Patricia |
Department of
the Treasury |
|
Sorrenti |
Teresa |
Integrated
Acquisition Environment IPT |
|
Standford |
Brad |
Office of Naval
Research |
|
Steinbacher |
Richard |
NARA |
|
Tapper |
Ari |
Software AG,
Inc. |
|
Tinemann |
Michael |
Department of
Energy |
|
Todd,
Michael |
Michael |
Office of the
Secretary of Defense |
|
Turnbull |
Susan |
GSA |
|
Vineski |
Steve |
EPA |
|
Ward |
Dalroy |
SAIC |
|
Webber |
David |
DFAS/XML Global |
|
WeirAdvisor |
Sherry |
E.F. Kearney
Ltd. |
|
Wheedleton |
Chris |
SAIC |
|
Wilder |
Frank |
Mitre |
|
Yee |
Theresa |
LMI |