Service-Oriented Architecture

What is it?

Although it has been discussed in the information technology industry for a decade or more, service-oriented architecture, or SOA, continues to be one of the more hotly debated buzz phrases in IT. It is used to describe different types of business or software processes. At its most basic level, SOA means taking multiple software or business processes that reside on the same network and designing a plan to make them work together as simply as possible.

A good example is online banking. When you log on to your account on your bank's Web site, you actually perform several processes. One verifies your username and password (and possibly shows you a security image or code to comply with multifactor authentication). Once you are logged on, another process accesses your bank records to show your current balance and past transactions. If you want to conduct an online transaction, such as transferring money to another account or paying bills online, your computer accesses another process.

A service-oriented architecture plan is designed to tie all these processes together and present them to the user in a way that appears seamless and simple. A chief driver of SOA is that the underlying technical complexity of a linked system should not be apparent to or have to be understood to work through a process; the user should be able to easily and seamlessly initiate a process and receive results.

What Does It Allow Me to Do?

The goal of employing SOA is to harness the flexibility and adaptability of Web-based applications by loosely coupling together different systems and sharing information easily across multiple platforms. SOA theory holds that by emphasizing dynamic, agile and adaptable flexible systems, both internal users (employees, managers, developers and others) and outside users (customers, end users, partners, citizens) can perform advanced functions on a network and have better results.

SOA differs from object-oriented architecture in that the latter focuses on linking disparate programs or applications, whereas SOA focuses on linking disparate programs with the added intention of packaging them as a service. SOA binds together existing components and systems in a plan that dictates standards and processes -- developed through an enterprise governance process -- to provide a service, rather than allowing different business units or agency offices and bureaus to create applications or programs to address needs and business processes.

SOA often is linked with Web Services, another buzz phrase, which is applied to many types of programming or business situations. Web Services most commonly refer to programs that communicate with each other across the Internet, and SOA often is employed to create plans that link different Web Services to create a working system. Common components of a SOA system include XML (eXtensible Markup Language) (which allows designers to transmit data across different systems), SOAP (the protocol used to transmit XML-based data over the Internet), and WSDL (Web Services Description Language) (the XML language that provides a framework for a particular Web Service).

Typical guiding principles of an SOA include componentization, modularity (the ability to swap components in and out), reusability, standards compliance and leveraging existing assets whenever possible.

Why Should Agencies Care?

SOA caught on quickly in the private sector, because many businesses saw the possibility of saving money by spreading the use of existing systems throughout the enterprise and by harnessing Web-based applications to deliver services to customers. Research firm Gartner of Stamford, Conn., predicted in 2003 that SOA would replace typical software architecture development by 2008, accounting for 75 percent of projects involving SOA and Web Services as concepts. (Some experts doubt this goal will be achieved.) Popular adoption of SOA was considered to reflect larger trends in the IT industry, moving away from developing new processes and automating existing systems to tying current systems together.

It's clear to see why SOA should, in theory, work for government agencies. First, it works well in large organizations that have redundant business processes. The processes used by, say, each of the 22 institutes that make up the National Institutes of Health are similar and can be tied together and reused. Furthermore, many of those services most likely can be used across the Health and Human Services Department, of which NIH is one component.

Indeed, the potential for agencies to use SOA is considerable and is a major part of the Bush administration's push for wider use of to streamline business processes. The President's Management Agenda, released at the beginning of President Bush's first term, called for removing redundant business functions in agencies and centralizing them in so-called "shared service centers," a process that parallel's SOA's core principle of using existing systems and applications to meet mission requirements and not to write similar software programs dozens of times throughout government. SOA's mantra: Write one time, use many times.

Why Isn't SOA Used More in Government?

Agencies' adoption of SOA has been slow, however. A 2006 survey of 196 government IT professionals sponsored by a consortium of SOA vendors found that half of the respondents didn't know what SOA was. Of those that did, only 13 percent had successfully implemented SOA in their department, with civilian agencies outpacing military departments as primary users.

IT managers cited two chief reasons for not adopting SOA on a wider scale --turf battles among agencies that did not want to give up ownership of their applications and systems, and concern about the long-term costs of implementing a still-evolving process like SOA. The FBI stands as a typical example of why it is hard to implement. Although the bureau initially was a quick adopter of SOA as part of its plan to revolutionize a system to share information and evidence on cases it was handling, it eventually chose to pursue a tiered, measured approach while it evaluated any unintended consequences of adopting SOA. For example, the bureau was concerned about SOA introducing security vulnerabilities and vendors providing systems that did not work together. (Remember, SOA requires systems to be interoperable, thus requiring a strong enterprise architecture and governance process to set standards to which everyone adheres.) The experience led Jerome Israel, the FBI's chief technology officer, to sum up the bureau's effort this way: "We've gone from maybe hyped up about it to the cold realization that 'Hey, this SOA is a lot harder than industry is making it out to be.'"

Still, federal chief information officers consider implementing SOA because of its potential to make data and information sharing easier across government. IT managers say the government's legacy software applications -- some decades old -- are the primary obstacle to adoption, according to Forrester research firm in Cambridge, Mass., but government IT leaders are just as interested in adopting flexible strategies like SOA as their private sector counterparts.

The Current Scoop on SOA

SOA continues to be popular in theory, but like all hot trends the reality doesn't always match the hype. Although Gartner has championed adoption of SOA in business practice, it also has warned that many early SOA projects failed due to ballooning costs and user dissatisfaction. International Data Corp.'s research arm warned in 2007 of a "rising tide of SOA exuberance," which comes about from CIOs' inability to recognize that they have to change business processes and accurately predict costs. Perhaps owing to burnout from the hype, SOA was voted the "most hated tech buzzword" by respondents in a 2006 Network Computing survey.

based in Midvale, Utah, released a report in 2005 that codified three primary obstacles to SOA: requiring proprietary systems to enforce security and access, resistance from the workplace to new philosophies, and adopting design principles to create systems that work with SOA.

Nevertheless, SOA has found a positive reception in state governments, because they are smaller and have greater flexibility. Kentucky adopted SOA as the state's IT application architecture, saying SOA "will help agencies respond more rapidly and cost-effectively to changing conditions by promoting reuse of existing IT assets." Vibhas Chandrachood, executive director of application development in Kentucky's technology office, claimed in a white paper that SOA would help Kentucky address business problems such as the mass retirement of older government employees. "We currently have the personnel [to manage operations]," said Chandrachood, "but we may not have that luxury in the future. So part of SOA is answering the question of how to do more with less."

Arizona's Government Information Technology Agency recently unveiled four pilot projects using SOA to improve information sharing and automate business processes in agencies such as the Health Services and Revenue departments. The National Association of State Chief Information Officers (NASCIO) has promoted the use of SOA as more than just a technological plan, but as "a whole philosophy about sharing and decoupling business processes from technology to enable a fluid enterprise that can adapt and change quickly."

There are signs that the federal government is rethinking its philosophy on SOA. The Navy recently announced a migration to a new information technology environment based on SOA principles. Consolidated Afloat Networks and Enterprise Services will introduce systems even as the Navy's architecture is implemented, following the SOA principle of adaptation and flexibility.

ZDNet's Joe McKendrick has predicted that as the SOA hype dissolves, the practice will simply become common sense for creating linked business applications, much as Web browser-based interfaces are simply accepted as part of the Internet experience. McKendrick believes that the SOA acronym itself will eventually not be used or will be folded into larger concepts as the principles become more widely used.

Martin Bosworth is a technology writer who lives in Washington, D.C.

"An SOA for the Federal Enterprise"

"Addressing SOA's Vulnerability,"

"Services and Components Based Architectures," Federal Chief Information Officers Council, January 2006.

"What Is Service-Oriented Architecture?" September 2003

"SOA and the Government: A Slow Process," Datamation, September 2006

"Service-Oriented Architecture: A Unifying Governance," presentation by SOA CoP, March 2006

Articles

"Let a Thousand Flowers Bloom," Government Executive, Feb. 1, 2007