Turf buster: Enterprise architecture does the trick

Just a few years ago, a vacation planner who wanted to learn about opportunities for camping, hiking and boating on federal lands had to look for information on several Web sites housed in three separate, unrelated agencies.

Now they can find everything they need at Recreation.gov, a one-stop online shop that incorporates information from 11 different agencies spread across the federal government, from the National Park Service and the Bureau of Land Management to the Army Corps of Engineers and the Tennessee Valley Authority.

Creating a Web site that combines information from multiple agencies is always difficult, especially when agency leaders become territorial about the data they supply. But the Interior Department, the spearhead of Recreation.gov, combined a well-developed enterprise architecture with a set of strong policies to make it happen.

The department's leaders figured that vacation travelers want an easy way to learn about recreation opportunities, plan trips and make reservations, and they don’t want to have to figure out if Interior, the Agriculture Department or the Army Corps of Engineers has the information they need. Nor  do they want to browse and dig through several separate – and differently organized -- Web sites to find it.

The broad view provided by enterprise architecture, developed to span various systems that each contained some of the needed information, led to the creation of Recreation.gov, said Colleen Coggins, chief architect at Interior. The agency launched the site in March 2007, and has been expanding and improving it ever since.

“Technology is probably the least of the challenges,” Coggins said. “The most significant challenge in many cases is breaking down the turfdoms which exist at agencies.” Agency leaders can balk at sharing an identity at a site such as Recreation.gov, which blurs the traditional lines of demarcation and can make the exact source of information all but invisible to the casual user.

Enterprise architecture, coupled with enforced information-sharing policies, can overcome that recalcitrance by applying a systematic framework to the effort. But enterprise architecture also has barriers to understanding, including the fading but still widespread perception that it’s only an information technology project, said Casey Coleman, chief information officer for the General Services Administration. 

Agencies' business units carry out the tasks and provide the services associated with an organization’s overall mission. The IT organization provides systems and services to perform those business processes. The architecture bridges the two, but until relatively recently, architects and agency business leaders treated it as an IT project that was not relevant to the business side.

“EA is really the umbrella over the whole business/IT process,” Coleman said. “Senior business leaders must be aware that their involvement is needed in order for IT to deliver the necessary capabilities.”

Interior, like some other agencies, solved that problem by having the technology and business units work together as the development of the Recreation.gov concept progressed. Interior developed specific policies to codify and enforce the cooperation.

Interior officials used a blueprint analogy to explain the enterprise architecture concept, she said. In 2004, architects began working with business units to develop modernization blueprints to map how to streamline the business processes. The blueprints identify ways to share information and integrate data among Interior's agencies.

Interior required architects to work directly with business units, which was critical to getting agencywide support for the program, Coggins said.

“It showed people there were a lot of opportunities to move toward enterprise solutions,” Coggins said. “When we did these blueprints, they showed a lot of redundancy in the agency.”

GSA’s Public Buildings Service calls enterprise architecture a blueprint for business, Coleman said, making it clear to people who are less interested in technology minutiae but who understand the relationship between a blueprint and a building.

“Enterprise architecture is very analogous to blueprints in how it shows you where you have business processes and what systems support those processes,” Coleman said.

Overcoming resistance to change

Architects usually encounter departments that have older systems that perform well enough as is. Coleman recommended establishing a policy that those systems don’t have to be modernized.

If an existing system is running smoothly and does not need an upgrade, maintaining the status quo should be an option, she said. Architects who don’t demand what might seem like an unnecessary upheaval just for the sake of modernizing will have an easier time gaining support in the future when those systems do need to go. 

However, if an existing system works well but needs to integrate with new systems, architects need to explain that to the business units, Coleman said. Some older systems, even ones that work well on their own, cannot coordinate smoothly with new Web-based and service-oriented systems. Explaining those challenges to individual business units is important in overcoming resistance, she said.

Interior’s policy requires architects to do extensive research about the agencies where they work. If an agency was the subject of a report by the Government Accountability Office or an inspector general, architects need to know that.

That education makes it easier for architects to collaborate with business unit leaders to solve problems, Coggins said.

In working through those problems, Interior's architects use standard business and data analysis methods. After an analysis, it is important to come up with recommendations that are feasible. Business units will lose confidence if architects make them go through an analysis and then suggest fixes that are impossible, Coggins said.

“Our vision is to produce understandable and actionable architecture,” Coggins said. “It has to be understandable to the business community and address the issues they are facing.”

How to use an architecture

After developing an enterprise architecture, a key step is using it to deliver a new or improved capability, Coleman said. GSA architects must show the business value of building an enterprise architecture.

For example, at GSA, an analysis revealed that nearly every system at the agency had its own user authentication method, so there was no consistent approach to identifying employees’ access to systems and physical areas.

That discovery, along with the mandate for the Office of Management and Budget to issue new common identity cards, led GSA to overhaul its identification system. The overhaul satisfied the mandate while streamlining the log-in process for employees.

GSA could have upgraded systems without the architecture, but the architecture's view across all systems and business units made the task much easier, Coleman said. 

At Interior, the architecture helped identify more than 100 systems that need to be retired, Coggins said.

The agency is in the middle of deploying a new enterprisewide financial system that will provide core accounting, acquisitions, budget formulation and travel services. The agency is also consolidating law enforcement systems at four bureaus into one enterprisewide system, Coggins said. “One system is better for analyzing information about potential terrorist attacks, rather than sorting through four systems,” she said.

Coggins recommends having a policy that encourages a segmented architecture approach. Segmented architecture focuses on a specific area in an agency, rather than trying to cover everything in a single enterprise architecture.

OMB has released a report, written by a group Coggins led, that provides a step-by-step process for developing and using segmented architectures. Named the "Federal Segment Architecture Methodology," the document is “very mission-focused and gives you analytical steps aimed at resolving and solving business problems,” she said.

While adhering to the segmented architecture guide is not mandatory, agencies should consider a policy recommending its use, said Richard Burk, the former chief architect at the Office of Management and Budget, and one of the developers of the guide.

The methodology clearly shows which steps and practices are optional and which ones are mandatory, he said.

“It generates information that is mandatory, and that OMB wants to have when it goes in to evaluate an agency’s architecture,” Burk said. “It generates the information OMB wants to see, whether the agency is using its architecture and what are the results they’re getting from using that architecture.”