Why SOA?

Service-oriented architecture can take elements of processes that weren't designed to work together and make them work together, quickly and seamlessly.

Hardly a day goes by without government officials lamenting over the challenges of today’s business environment. As state and local agencies face greater pressure to cut costs, boost productivity and speed development cycles, business leaders and IT departments find themselves coping with increasingly complex business and technology requirements. Aligning organizational goals with technology, delivering value and bolstering the bottom line are paramount.

So, when Chief Operating Officer and Enterprise CIO John Gillispie surveys the information technology situation in the state of Iowa, he sees only one way to manage the mélange of decentralized systems. “A service-oriented architecture allows us to build a technology platform that lets us share data and information across agency boundaries without having to be concerned about the technology choices,” he says. “It’s helping us build an architecture that’s quicker, faster and easier to manage.”

Already, Iowa has turned to a service-oriented architecture (SOA) to handle credit-card processing for parking tickets, licenses, campground reservations and a variety of other uses. It has connected to the national sex offender registry, and it is now looking to use SOA to manage its debtor files in a timelier manner. “SOA creates synergy between the business and technology side of things,” Gillispie explains.

Like Iowa, a growing number of state and local governments have discovered that the path to success passes directly through a service-oriented architecture. SOA offers a distributed computing environment with software “services” that are discoverable and available over a network.

By placing an abstraction layer atop a complex, heterogeneous IT infrastructure, organizations can adapt functionality and services to fit business processes. And, as requirements change, it’s relatively simple to tweak these software modules and systems to respond and adapt quickly.

SOA boosts productivity, reduces costs, improves service levels, ratchets up security and increases IT’s ability to perform strategically. It creates a real-time enterprise and provides on-demand data and information — thus making an organization more responsive and competitive.

“A service-oriented architecture offers a way to modernize and distribute technology without replacing the underlying applications,” states Gene Leganza, vice president of government research at IT consulting firm Forrester Research, based in Cambridge, Mass. “It has the ability to transform the services a government agency provides to its constituents and greatly streamline internal interactions.”

Yet, achieving success requires a good deal of analysis and planning — along with changes in governance. Agencies looking to leverage SOA to maximum advantage must understand what SOA can do and what it can’t do. They also need to realize how it fits into an overall strategic plan. SOA can create challenges and obstacles — some of which ripple beyond technical issues. Says Leganza: “It’s essential to address cultural issues and focus on change management. SOA changes roles and responsibilities.”


When SOA appeared several years ago, it promised faster, cheaper and better IT integration. Tapping into a spate of software development platforms and protocols — including Simple Object Access Protocol (SOAP), Java, .NET, Web Services Definition Language (WSDL), remote procedure call (RPC) and OpenEdge — SOA provides modular building blocks for developing new products and services, without constantly starting from scratch. SOA breaks down stovepipes and opens up applications so that an organization shares data and interacts faster and more efficiently. What’s more, it provides sophisticated monitoring and enforcement mechanisms that take governance to a higher level.

Used effectively, SOA becomes a central nervous system for the entire enterprise. It improves the responsiveness to business change in three primary ways: by creating better linkage between technology and processes; improving resource utilization by moving from an implementation-specific model to one that relies on self-contained software modules operating within a standards-based infrastructure; and providing consistent, progressive and flexible policy implementation.

Iowa launched its SOA initiative in 2004. Gillispie says that because the state has traditionally used a highly decentralized technology approach, many agencies and departments have “made their own technology choices.” As a result, he says, “We have a wide variety of systems and a variety of applications. It has been a challenge to move data between systems and share it in a rapid and seamless way.”

In the past, most agencies in Iowa relied on File Transfer Protocol (FTP) to exchange data. But it created its own set of problems, including keeping data synchronized and ensuring that someone had posted it on an FTP site. By moving to SOA, the state will be able to begin automating data exchange, reconciling information across agencies, and moving commerce and other capabilities into the 21st century. Plugging in SOA modules on an as-needed basis is relatively inexpensive and highly effective, Gillispie points out.

The state’s e-commerce capability is a perfect example. In the past, Iowa was awash in paperwork and printed checks. Licensing renewals, parking ticket payments, campground reservations and business tax payments all touched human hands. Processing a transaction could take days or weeks. Today, Iowa uses SOA to interconnect systems between agencies, so events occur in real time. And the systems use an authentication and authorization engine that provides additional security.

SOA will help Iowa trim costs, improve productivity and boost service levels. Nevertheless, Gillispie says that the task of identifying opportunities and implementing systems has presented a few challenges. The biggest was establishing a system for governance. “It was important to create a model that allowed us to judge projects based on a system’s adherence to standards,” he explains.

In Iowa, a governance board reviews each project and defines everything from SOA protocols to who owns the data and how it will be shared. “The key issue is developing a dictionary so that everyone is using the same nomenclature,” he says.


Understanding what is required to pull together a disparate set of systems and allowing them to exchange information seamlessly is at the core of SOA. Among the questions an organization must ask are: What organizational responsibilities come into play? How will agencies and departments share data? And what financial considerations exist? Establishing a set of standards and a strong governance model up front can greatly streamline the rollout of an SOA initiative and ensure that the enterprise matches performance with expectations.

With a sound governance system in place and the right tools to support a sturdy SOA infrastructure, an organization can begin to take maximum advantage of the technology. At that point, it’s possible to adapt quickly and implement changes within hours instead of days or weeks. It’s possible to enhance the value of technology investments by adding and removing capabilities as needs arise.

Yet, achieving success with SOA requires more than a plan: It’s crucial to have a framework for building the environment. While IT architecture and development professionals are likely to view a service-oriented model as a technical boon, managers and business decision makers are more likely to assess the technology in terms of business value. Ultimately, SOA is an ongoing journey, and an organization must build on its successes.


1. Map out a clear strategy up front. Organizations with a real understanding of their business processes can break them down into discrete service-oriented architecture (SOA) component services, thereby achieving maximum efficiency.

2. Establish a clear governance model. It’s essential for an organization to ensure that it has spelled out everything from data ownership to coding standards, from workflow to front-end interfaces.

3. Understand what different SOA vendors offer. IT should thoroughly analyze different SOA products and solutions and choose those that offer maximum flexibility and scalability.

4. Start small and build on success. As a rule, it’s best to avoid a big-bang approach and instead implement SOA one task at a time.

5. Provide training and focus on change management. SOA can result in squabbles over who owns data and who has access to it. SOA may also lead to substantial changes in workflow and responsibilities. This makes communication and training essential.

Oct 31 2006