The Federal Quest for a Service-Oriented Architecture

By Courtney Macavinta

When the Washington, D.C., city administrator asked his IT team to create a dashboard system that would allow him to keep tabs on how 66 city agencies were delivering municipal services -- especially public safety services -- it seemed like a tall order. Overall, the district's agencies didn't have a unified system for sharing data or compiling it in a meaningful way. In fact, most of the data needed to create the dashboard was locked away in hundreds of separate data silos maintained by various agencies or offices.

But with the adoption of a service-oriented architecture (SOA), the project became possible. Building off an already successful SOA pilot, the team created a plan for building a more flexible IT architecture by implementing an enterprise service bus (ESB). The ESB enabled the city government to loosely integrate participating agencies' legacy databases and cull and interpret variant data formats so that the city administrator could have a single Web-based dashboard that pulled data from multiple agencies. And -- even more importantly -- the dashboard could present the data in a meaningful context.

Case in point: The dashboard presented a citywide map showing that more than 2,000 abandoned automobiles reported to police had yet to be towed as requested. (Such cars often double as drug dealers' sales posts.) Now that the police and towing company's data could be shared via the dashboard, the towing company was able to get a more current towing list and pick up all the cars in one weekend. In the city's 14 worst zones, crime declined by 23% and violent crime dropped by 34%. The decrease has been attributed to the new information-sharing capabilities among agencies that are feeding data into the dashboard.

"At the end of the day, the thing that we're most proud of is the result of the reduction of crime in these very troubled neighborhoods," says Jamey Harvey, deputy chief technology officer for the government of the District of Columbia. "We took the same amount of money that would have bought just a dashboard and instead created an SOA that will serve us over and over again. It's a model for governments to follow."

What's driving SOA in the public sector?

Many public sector bodies are planning to follow the D.C. model, according to a new Forrester Research Inc. survey of 20 federal enterprise architects. Forrester found that SOA planning and implementation was on the rise among federal agencies. And with good reason.

In the wake of 9/11, information sharing -- especially among emergency response teams -- has become a top goal for both federal and local government. In addition, the public sector is driving to keep administrative costs down by increasing efficiency among its agencies, and enabling more citizens to conduct self-service transactions through the Web. In addition, agencies that have long been locked into legacy systems want to be able to upgrade to new technologies without having to "rip and replace" old systems, which can be a costly undertaking.

SOAs, on the other hand, can allow IT teams to more easily integrate old and new systems, enable data sharing between various applications or databases, or create "services" that can be reused or modified when new business needs are identified. Ultimately the goal of an SOA is to provide a series of standards-based, loosely coupled, highly interoperable and often reusable functions to an organization.

"When we surveyed IT decision makers in government, what always makes the short list is the need for integration, security, and reducing costs," says Gene Leganza, vice president of government research for Forrester. "What makes SOA great for government bodies is that, when you design an application using SOA, you're preventing it from becoming tomorrow's legacy problem."

How to overcome SOA challenges 

Even though government agencies are realizing the benefits of SOA, they face unique challenges when it comes to implementing SOAs. This is true primarily on the procurement side.

Traditionally, when the public sector sets out to purchase IT, there is a detailed process that centers on requests for proposals (RFPs) for a particular application. With SOA, they are not buying self-contained applications with a set feature list -- they are building services. So the procurement process can be difficult to carry out. 

For CIOs within the public sector -- or for those who count government agencies as their customers -- Leganza and Harvey offer several points of advice when it comes to overcoming roadblocks in SOA planning: 

• Create definitions  When designing an SOA, it's important to come up with an organization-wide system for classifying data and services. In the end, these definitions allow services to be shared and integrated. "It means that integrating the service is done at the design time -- not as an afterthought," Leganza says.
• Build SOA pieces into other IT projects  Harvey suggests that CIOs can also purchase the components needed to roll out an SOA as part of larger IT projects that have already been defined. SOAs are often rolled out in phases so that a CIO is not creating an RFP just to procure and build an entire SOA, which might not get approved as easily. "You have to go through some procurement pain to have it turn out the way you want it to," he says.
• Make the case for information sharing  These days, the government is really focused on public safety. As Leganza points out: "It's about getting the right information to the right person at the right time." So CIOs can explain to decisions makers during the budget approval process how an SOA can help achieve this goal by enabling more efficient data exchange between agencies. An SOA can also help better secure sensitive data within the infrastructure by creating security standards for handling data that are tied to previously set definitions.
• Focus on increasing integration and efficiency  One of the biggest promises of SOA is that it can save organizations money down the line by speeding up business process management and development. In addition, it also allows organizations to build the SOA in pieces -- not all at once. The same can be true for the public sector. "Open a dialogue about what you'd like to do and how you can get there -- integration will be a main drawing card," Leganza says. "You need to have a vision for how an SOA will be strategic in your agency, but define it thinly and then start to get there via pilot projects to demonstrate the viability of the model."

As for Harvey, he's convinced that with the proper planning and expertise, an SOA can better empower government agencies to be more nimble, progressive, and efficient.

"You can get more value out of your IT dollars -- there are opportunities to do it," he says.

Courtney Macavinta is a Silicon Valley-based business and technology writer. Her articles have appeared in CNET News, Business 2.0, Red Herring, Wired News, and The Washington Post.