Making the case for better data

As co-chairwoman of the CIO Council's Architecture and Infrastructure Committee, Kimberly Nelson is in the thick of all things associated with the federal enterprise architecture. She also tracks data management issues as the Environmental Protection Agency's chief information officer.

She recently shared her views on data architecture with Federal Computer Week.

What data architecture best practices do you see emerging now?

We are very early in the process. I'm not sure the term "best practice" is the most appropriate here. But I see some things emerging as important areas. One of those is lines of business.

We are certainly seeing through our chief architects and chief architects' forum an awful lot of learning going on throughout the government as a result of line-of-business issues — issues they are raising in terms of what does it really mean to understand the data architecture of an agency and the relationship of the various architectures in individual agencies to the overall federal enterprise architecture. That's an area where you are seeing an explosion in learning.

[Another area] is the data architectures. My own personal experience here, and I don't think EPA is that different from most federal agencies, is up to now we have spent a better part of the time and effort on technical architecture, the technical enterprise architecture, and have only really started to get into the data architecture.

We are seeing the emergence of a real understanding throughout the federal government of what it takes to build a logical data architecture.

And the third thing, I think, is with all of the focus on data architecture there is clearly more interest than ever before on the issue of metadata. A couple of years ago, you started hearing Cabinet heads and senior executives use words like "enterprise architecture."

You are now starting to see executives talk about metadata. I think that is important because having the ability to understand the data that we collect and having the ability to register that data through a data registry...and all the metadata to go with it show a greater sophistication than we have ever had before [in the federal government].

What are the main benefits of a data architecture? Efficiency and cost savings? Improved operational effectiveness?

I think cost savings are important, and they are really an outcome of a well-designed and implemented architecture. But I think we have to be careful not to get too hung up on cost savings alone. What citizens want most out of their government is service. So to me, the priority for a well-implemented data architecture is that it improves the mission of an organization and makes an organization more results-oriented.

Here at EPA, the information we need to understand the condition of the environment is to a large degree not available from EPA systems. A lot of federal partners engage in environmental activities, and state and local partners [as well].

Data architecture allows us to work with all of those partners and collect and aggregate the data in such a way that it is scientifically and statistically valid. The data architecture provides that blueprint to really understand which data elements need to be shared within an organization and which need to be shared with other...partners.

How might data architecture efforts dovetail with the development of service-oriented architectures?

They go hand in glove. When you are talking about an SOA you are really talking about what services, what information, an organization needs from others and what services you can offer as an organization to others. And that gets back to...having an understanding of the data you are collecting yourself or having an understanding of the data you need for decision-making purposes that you have to collect from others. Once you understand those critical pieces of data, you can start to develop the appropriate service-oriented architecture. ... I can't imagine how you can design a service-oriented architecture without a good understanding of your data needs.

How do you sell top managers on a data architecture project? How do you go about changing data practices within a given agency?

I think sometimes the culture card is overplayed a little bit. You probably don't go out and sell "data architecture" per se, using those words, because sometimes you do get a glassy-eyed stare.

I approach it from a programmatic, results-oriented perspective. Ask any single manager in an organization, what...data have they always needed in terms of managing their programs. Do they have that data? Can they say they have 100 percent of all the data they need to effectively run their program? You won't find very many managers...who answer yes to that question.

What is the information you need to manage your program? Knowing the answer to that question, you can go back from an architectural perspective and ask, "Does that data exist?"

Moore is a freelance writer based in Syracuse, N.Y.