Make good data great
Flashy it's not, but a well-oiled data architecture project can pay dividends
- By John Moore
- Feb 01, 2008
Fancy new computers and slick software packages come and go, but electronic data, if handled carefully, can deliver value for years.
Although some agencies treat data as a byproduct of automation projects, it doesn’t have to be that way. Smart executives are learning that the extra care involved in creating a solid data architecture can produce immediate and long-term benefits.
Such architecture projects organize data so it can be shared among internal groups and external partners.
Data sharing is among the primary benefits of a data architecture project.
Those projects also can eliminate duplicative data and improve quality so that agency decision-makers can work with clean, reliable data.
External policy mandates start many agencies down the data architecture track.
A number of executive branch agencies have undertaken data architecture initiatives to comply with the federal enterprise architecture and the Clinger-Cohen Act, said Shani Hernandez, program manager at project management firm Robbins- Gioia.
Internal circumstances also play a role.
“The catalyst is usually low data quality,” said Michael Brackett, consultant data architect at Data Resource Design and Remodeling.
Agencies may be unable to find the data they need or discover that data exists in too many variations.
“Organizations come to a point where they need a reliable source of consistent data,” Hernandez said. “They want a single version of the truth.”
Is a data architecture project in your agency’s future? Here are some pointers on how to set up a successful project. 1. Build a team that will focus on results
Data architecture practitioners say moving a project from the theoretical discussion phase requires the help of a high-level champion.
“You need to have some sort of an executive sponsor,” said Bruce McGregor, senior associate at Booz Allen Hamilton.
McGregor said such a sponsor typically comes from an organization with a large stake in having reliable data, such as the office of the chief financial officer. But the champion could come from any data-intensive organization.
After the project has a sponsor, a project team handles the daily responsibility for building a data architecture. That team should include business and technology managers.
“Data architecture development is typically collaborative in nature,” said Suzanne Acar, senior information architect at the Interior Department. “Ideally, the key players are business managers, their subject matter experts, the systems administrators, data stewards and data architects.”
Agency employees assigned to a team may receive additional contractor support.
Acar, co-chairwoman of the Federal Data Architecture Subcommittee, said contractors often are data architects on those teams.
Three groups should be involved in data architecture projects: planners, business people and technical specialists, Hernandez said.
- The planners are project managers and architects. Project managers focus on funding and resources. Architects devise long-term data strategies.
- The business people contribute their knowledge of how data is used in the organization.
- The technical specialists are the database administrators and data modelers. Contractors typically contribute to the technical specialist category, Hernandez said.
Those specialists are concerned with providing the technical means to store, manipulate and transport data.
The information technology group also is responsible for ensuring that newer data is properly integrated with older systems and data, said Scott Starsman, director of defense systems at Avineon, an IT services firm. Starsman said the business side’s knowledge of data use is important. However, business groups don’t need to understand the technical relationships between the data, he said. That’s the IT group’s job.
The person responsible for leading the team may come from either the business or IT side. Starsman said business leaders may be more effective in that role. “The business people tend to have the larger view,” he said. “You sometimes get a very focused mentality from the technology folks.”
Many data architecture projects are part of broader enterprise architecture initiatives.
In turn, those initiatives tend to fall under the chief information officer’s purview. 2. Chart the baseline, set your goals
Organizations create data architecture plans to produce business benefits.
“In general, data architectures need to be relevant to the business strategies and goals,” Acar said.
“From a top-down perspective, the initial step would be to study the business processes associated with the business goals. The business processes will reveal the data that is important to the business.”
“We always start with the business needs, which then drive more detailed requirements,” said Mary Beth Kush, director of Global Services at Acumen Solutions, a business and technology consulting firm.
The next step is to assess and classify existing data. The goal is to document and understand an organization’s diverse data holdings, Brackett said. Some projects attempt to build a desired architecture without taking the current environment into account, he said.
“The approach that doesn’t work is to forge ahead and do a desired architecture without understanding the existing data,” Brackett said. “You end up with a very good architecture…but you have no idea of how to get the existing data to the desired” architecture.
The data classification process also uncovers redundancies and opportunities for data integration and standardization, Acar said.
After baseline data is established, employees can design the target data architecture by defining the types of data needed to support the organization. The earlier task of classifying and categorizing existing data refines the target architecture.
Older systems data, for example, can be mapped to the data entities in the target architecture, Acar said. 3. Keep up the tempo
Architecture work is often difficult. Even in the best of circumstances, it won’t be among an organization’s flashier projects.
People not directly involved in the project may have difficulty understanding the architecture and its goals. Organizations may struggle to sustain enthusiasm under those circumstances.
“That’s a huge challenge,” McGregor said.
However, consistent support from the business side can help maintain progress.
“The business owners should stay involved to champion the project, which helps keep the project moving forward and ensures adoption of the solution,” Kush said. A business owner is someone other than an IT manager who has a stake in the project or funds the project through his or her budget.
Support from above is crucial.
However, involvement of users also is important for sustaining projects, said Hee Sun Choung, vice president of IT service at Avineon.
“The peopl e who are going to be using these systems need to know how it’s going to benefit them,” Choung said. Architecture leaders must communicate their ideas and vision as the project progresses.
E-mail updates and periodic meetings are useful ways to communicate.
McGregor said that giving the data project a brand-like name can be helpful. The National Information Exchange Model is an example of effective naming, he said.
The NIEM architecture, developed by the Justice and Homeland Security departments, supports information exchange standards.
Successful data architecture managers also provide points of contact to help users navigate the data in the new architecture.
Appointing data stewards, McGregor said, helps puts a face on the data. Stewards can guide people who need to access certain types of information to build a report, he said. Stewards typically work in a particular data subject area such as contracts or invoices. 4. Schedule success
Of course, nothing drives architecture adoption like the ability to demonstrate results.
The sooner those results appear, the better.
Practitioners often suggest splitting an architecture project into pieces to quickly produce tangible benefits.
“To drive adoption, we break the architecture into small modules that can each be delivered in three months,” Kush said.
“We map the modules back to the business requirements, map the dependency among the modules, and then prioritize the delivery.”
Business demands may determine where to start. However, other considerations, such as the disposition of a particular agency group, also come into play.
“We don’t target the biggest and most important system per se,” Hernandez said.
Architectural results may be demonstrated in various ways. For example, an organization could build a metadata repository that stores information about data and provides a consistent way to access it.
Hsu said State is working on a catalog to help users locate information in much the same way as a library’s catalog helps people find books.
In addition, a project team could unite two formerly separate data resources to create new value. Avineon took on a project of that kind for the Naval Sea Systems Command. Navsea maintained a data source that kept information on shipboard combat systems configurations and a separate repository on electromagnetic interference problems encountered on ships, Starsman said. The data was related but not integrated. Avineon helped the Navy reach its objective of integrating the data.
Practioners said improvements in one aspect of an agency’s data architecture often invite broader participation and acceptance.
“I rely a lot on what I call success motivation,” Brackett said. “A lot of little successes go a long way.”