Is SOA DOA?

The fact that government isn’t run like a business has rankled more than a few politicians, voters and business professionals. But in the world of service-oriented architecture, or SOA, there are good reasons why a business executive and a government executive would classify success and failure in completely different ways.

Government organizations such as the Air Force and Defense Department have made SOA a critical part of their efforts in pursuing network-centric operations. For example, the Air Force’s Distributed Common Ground Systems uses SOA design principles to stitch together intelligence data feeds from multiple systems and sources. That eliminates the need to field redundant capabilities or build one giant system to handle all the data.

“It allows us to have various systems use services provided by other systems, instead of having to have every system provide every service,” said Lt. Col. Tom Tschuor, director of the DCGS Management Office.

On the other hand, SOA has come under intense criticism in the private sector for its lackluster results. Companies were expecting SOA to generate big returns on investment by making their supporting software applications more nimble — and thus the businesses would be able to pivot quickly to cash in on new opportunities.

With a few rare exceptions, that hasn’t happened. Those in charge of corporate purse strings have had trouble connecting often significant SOA investments to new revenues or leaner operations. So when the economy soured, they cut funding, sullying SOA’s name.

Earlier this year, Anne Thomas Manes, vice president and research director at Burton Group, pronounced SOA dead in a widely distributed blog post. “Once thought to be the savior of IT, SOA instead turned into a great failed experiment — at least for most organizations,” she wrote.

“SOA was supposed to reduce costs and increase agility on a massive scale,” she added. “Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before."

“It’s time to accept reality. ... ‘SOA’ has become a bad word. It must be removed from our vocabulary.”

However, in Washington, government officials are reading from a different grammar book. Government agencies, in particular the Air Force and DOD, aren't having that kind of negative experience because they don't view SOA the same way.

Part of the reason is government's long-running interest in distributed computing concepts, of which SOA is the latest version. DOD and civilian agencies have some of the biggest interoperability headaches in IT, whether they are coordinating activities among military services, integrating myriad intelligence sources, or linking together state and federal benefits systems. SOA provides a way to smooth that integration and decrease the time it takes to develop and deploy new applications.

Government officials also seem to understand better than their private-sector counterparts that SOA's benefits won’t come overnight.

“You can do very interesting things with workflows and composing new capabilities using [SOA] tools, but those benefits become vastly more interesting once most systems have been converted,” Tschuor said. “So as you start the process, the initial conversions don't provide those significant benefits.”

But that doesn’t mean SOA is a slam dunk for government followers. They need to steer clear of the traps private-sector firms have discovered.

“In some agencies, there is a mandate for SOA, without a clear business driver for SOA,” said Jason Bloomberg, an analyst at SOA consulting firm ZapThink, which sees an increasing proportion of its U.S.-based business coming from DOD SOA projects. “As a result, the risk is that the implementation may not meet the true business requirements."

Government leaders seem at least aware of this risk. SOA might not be the answer to every situation, but it provides "a viable approach for solutions that lend themselves to a service-oriented model," said Kenneth Fagan Jr., chief of the Defense Information Systems Agency’s Data Services Branch.

SOA aims to get away from the traditional approach of designing software applications as monolithic systems that try to provide all the business or mission functionality that users require in one big package. Instead, SOA breaks apart the software into a series of components or building blocks, called services, which deliver different pieces of the overall set of capabilities. The components are packaged using technical standards so that they can be easily deployed, integrated or reshuffled as user requirements and missions change. This approach offers a faster, more flexible and, in the long run, less expensive way of developing and maintaining software.

There are numerous examples of SOA projects in government. DOD’s Net-Centric Enterprise Services (NCES) program uses SOA to promote the discovery and sharing of services across the military. That effort includes a suite of collaboration services, including instant messaging and Web conferencing.

At the policy level, DOD Chief Information Officer John Grimes directed all defense agencies earlier this year to use common IT capabilities and services.

DISA continues to refine its net-centric SOA components through what DISA calls the SOA Foundation. Fagan said the NCES Service Discovery Registry was upgraded earlier this year to include an improved user interface for publishing and retrieving information. It also allows for broader integration with DOD’s Metadata Registry and the NCES Content Discovery capabilities.

DOD now stands to reap the benefits of its SOA investment.

“The ability to discover services alone is paying huge dividends,” Fagan said, noting that more organizations are launching development activities to take advantage of the Service Discovery Registry.

For example, the National Geospatial-Intelligence Agency recently registered numerous services that the National Senior Leadership Decision Support System plans to use to build composite applications.

SOA also provides a cost-reduction benefit. Fagan said NCES contractors can perform integration activities using NCES capabilities “without near the level of effort and coordination that such integration activities would have taken just a few years ago.”

That’s one of the benefits the Air Force’s DCGS seeks. By separating a software application’s user interface from the underlying business logic and data, it will be easier to integrate these interoperable components.

“We can have a more agile acquisition cycle because we can develop the major components independently but still be able to relatively easily integrate the final system,” Tschuor said.

Net-centric principles are also catching on in the civilian sector. Health and social services is one active domain. The federal Centers for Medicaid and Medicare Services’ Medicaid Information Technology Architecture is based on SOA. Elsewhere, the Center to Promote HealthCare Access uses SOA to integrate its One-e-App system, which lets people submit one application for multiple, publicly funded health and social services programs.

Bobbie Wilbur, director of application solutions at the organization, said SOA is the only way for her organization to effectively get its work done, given the number of IT systems One-e-App works with. “If a person has to operate and manage a net-centric shop, I wouldn’t want to do business without it,” Wilbur said.

The Center to Promote HealthCare Access built a rules engine as a service, said Ashok Rout, application manager at the center and chief architect for One-e-App. The rules engine contains the benefits eligibility requirements for all programs available through One-e-App.

The rules engine resides on an enterprise service bus (ESB), which is based on Microsoft’s BizTalk and Windows Communications Foundation. Counties that provide One-e-App for their residents tap into the eligibility rules engine through the ESB.

Before the common service existed, the center copied its rules engine from county to county. Wilbur cited greater efficiency in consolidating the rules engine and other services onto the ESB.

Even though SOA is making inroads in government, practitioners note that the approach has not yet reached its full potential.

Greg Wenzel, a vice president at Booz Allen Hamilton, said SOA adopters so far have failed to achieve the nirvana of widespread service reuse. He said the many definitions that surround SOA inhibit the ability to create shareable services. In contrast, he cited the establishment of IP as an overarching standard that lets multiple providers offer the same piece of interoperable network technology — a router or hub, for example.

“When you move into SOA…there’s no governance or policy group doing that,” Wenzel said.

That doesn’t mean that organizations shouldn’t create their own governance structure to facilitate SOA adoption. For example, the Air Force’s DCGS created a services portfolio management process, which documents and manages existing and needed services.

“It allows existing services to be reused and services to be identified for development in order to fill identified gaps,” Tschuor said.

Governments also might need to overcome cultural hurdles to make SOA work.

Bob Coxe, former Army chief technology officer and chief information officer at Criterion Systems, said government agencies “may or may not have a cultural affinity going toward the stovepipe [systems], and the sharing activity is somewhat new.”

Another issue relates to how organizations should acquire services instead of traditional, stand-alone applications. Dennis Hayes, CTO for the Navy Marine Corps Intranet account at EDS, an HP company, said he believes government agencies that hope to consume services need to rework the acquisition process.

Although requirements for a stand-alone application might be fixed, the performance parameters for a service might change. Hayes said a service could be designed for one organization to meet a 20 transactions-per-second requirement, but a user could seek to triple that benchmark. He said efforts to deal with the acquisition question are in their infancy.

Hayes said DOD should also consider changes in the security accreditation process.

“The ability to rapidly recombine SOA components into different composite applications poses challenges to the accreditation framework that need to be studied,” he said.

The way organizations think about SOA might need to change, too.

Retired Lt. Gen. William Donahue, former communications and information director at the Air Force and now executive vice president at TechTeam Government Solutions, said he believes SOA deployments have become too focused on IT considerations.

“I see IT people argue about technical issues,” he said. “They need to take a much broader view.”

Similarly, Peter Woodhull, president of Modus21, makes a distinction between buzzword SOA, which he views as a technical exercise, and service orientation as an architectural framework. The latter is critical to net-centric operations, he said.

“We’ve come to the realization that to make this information available at the right time to the right people we have to holistically architect a distributed computing capability,” Woodhull said. “The way we do that is through services.”

Added Keith Rhodes, CTO for QinetiQ North America’s Mission Solutions Group: “I would argue that if you truly want to have effective net-centric operations, you are going to have to do something like SOA.”