If you ask 10 CIOs to define service-oriented architecture (SOA), you'll likely get as many different answers. Most, however, would know that it's about breaking down their software infrastructure into smaller, reusable building blocks to make application development cheaper and faster.
And Chris Curran has some advice for CIOs considering moving to an SOA: Make sure you build on solid foundations.
"SOA adds a whole new level of complexity," said Curran, chief technology officer (CTO) of Diamond Management and Technology Consultants in Chicago. "You have to have solid capabilities in project delivery and governance if you're going to handle integrating multiple services. Otherwise you're likely to fail."
One goal of SOA is the creation of composite applications made up of underlying services that snap together like Lego pieces, letting developers rapidly change applications as needed to deal with compliance issues or technological changes.
The most widely adopted implementation of the SOA concept to date involves Web services that use XML-based open standards to enable communication between existing applications.
As public-sector CIOs shift from SOA planning to implementation, some find that vendors and consultants have overstated SOA's short-term potential, leading them to underestimate the cultural transformation required in dealing with governance, security and finance issues.
A 2006 survey of federal IT decision-makers by the Merlin Federal SOA Coalition, a consortium of vendors, found that although 56 percent of federal agencies said they thought they would benefit from SOA, only 22 percent said they had participated in a successful implementation, with 78 percent noting partial or no success.
"There was a lot of hype about this new and emerging technology, and in many cases, the expectations exceeded where the adoption curve may have been," said Mark Zalubas, CTO of Merlin International in Englewood, Colo., which leads the SOA coalition. People building their first applications using the SOA framework can't yet tell whether what they've created will evolve or adapt, he added. "You won't know that until the third, fourth or fifth application you build."
The key to achieving the holy grail of SOA, he said, is to get to a critical mass of services available with new and interesting functionality. "I point back to the object-oriented model. Object orientation was hailed for its reusability, but it didn't really take off until there was a critical mass of objects to pick and choose from," Zalubas explained. "SOA is not going to hit its stride until there is a mass of business services to choose from. Having a registry listing one Web service is like having a Yellow Pages with one phone number in it."
The survey also asked about the challenges inhibiting governmentwide SOA adoption. Twenty-one percent of civilian agency respondents cited a lack of SOA knowledge among IT staff, while 28 percent of Department of Defense respondents cited interagency turf battles as the No. 1 impediment.
And just as there are myriad definitions of the terms "SOA" and "Web services," there is disagreement about how much real SOA development activity takes place in the public sector.
A 2006 Forrester Research survey found that SOA is the "hottest three-letter acronym in government IT circles," and that SOA adoption is stronger in government than in the private sector. But Ron Schmelzer, senior analyst at Baltimore-based ZapThink, a research firm specializing in SOA, said adoption varies considerably at different levels of government. At the federal level, there's been quite a bit of activity because the Federal Enterprise Architecture basically mandates large agencies to start facilitating information sharing.
"At the state and local level, it's been more patchy," Schmelzer noted. "Local CIOs don't tend to stick around long enough to see something like this through. This is not a two-year project, so staying power is an issue."
Schmelzer also said that SOA doesn't make sense for everyone. If you're a small city government with a homogeneous platform, "you're not going to get any bang for the buck with SOA. You'd be over-engineering."
Also, drivers in the public sector are different from those in the business community. Public-sector CIOs are not looking at the bottom line or a quarterly earnings statement, he said. They want to improve information sharing with other agencies and their constituents, increase flexibility and deliver new services.
Although many organizations are planning SOA projects, Schmelzer said, there have been relatively few success stories so far. "In the vast majority of cases, organizations don't know how to move forward," he said. "That's natural, because this is a big change."
Some IT leaders make the mistake of putting the cart before the horse: They try to solve business problems with services before defining SOA for themselves, Curran said, or worse, they let software vendors define it for them. "Organizations need to understand this is a new design principle. But from the vendors' point of view, it's just like portfolio management, project management or any other recent trend, and they are quick to offer solutions to solve the 'problem.'" Before talking to vendors, organizations should decide what SOA means to them, he said. Once they figure this out, then they can decide what tools to pursue.
Arizona's Government Information Technology Agency (GITA) has followed Curran's prescription of strengthening its organization and not rushing into SOA projects.
The state spent the last several years defining and implementing enterprise architecture for its executive branch, including well outlined principles, governance structure, roles and responsibilities, said Rupert Loza, planning manager at GITA.
Loza said GITA is convinced SOA, as a design principle, can help state agencies improve operations that directly affect citizens, and that it can improve operations and integration between programs. State governments such as Arizona often find their business processes crossing agency boundaries. Application design and data ownership have been barriers to effective information flow. The state hopes to use portal technologies and Web services to bring together business processes from multiple agencies.
In September 2006, GITA initiated an SOA awareness campaign with its CIO Council to discuss Arizona's proposed approach to SOA. The agency is working to identify IT assets that exist in multiple locations and can become service components.
One goal of the awareness campaign is to get people to change how they think about building applications. "SOA drives centralization in terms of effort; it requires effective IT leadership by influencing the activities of others or groups toward achieving service goals for the state through SOA projects," Loza said. "Such leadership needs to be active, exert influence, requires effort and must be related to project management goals and deliverables."
In 2007, the state will choose four multiagency SOA projects that will serve as models or case studies. "We hope to accomplish those in six months to a year," Loza said. "We have to prove to state leaders they will add value immediately if we're going to convince them that SOA is the way we want to go from here."
New Technology, Same Problems
Although SOA's merits are clear to many IT executives, convincing business managers of its value can be difficult, especially in decentralized organizations.
Brian Busby, senior project manager of the University of Wisconsin-Madison's Division of Information Technology, said although the university and its major software vendor Oracle are both interested in SOA conceptually, the decentralized nature of IT throughout the university system makes the transition difficult.
"The tech stuff is no big deal," Busby said. "It's the governance, policy and security issues -- all the hard stuff that people have thrown their hands up about for the last 30 years." For instance, he said, there isn't a single security policy at the enterprise level that would allow developers to create standardized services to reuse across the system. "Without solving those fundamental issues, we aren't going to get the benefits of reusing Web services."
The university has been looking for ways to better integrate systems on different campuses. "We recognized that instead of point-to-point interfaces between these campus systems, SOA was a good way to move forward," Busby said. His department led a pilot that built an application to provide a composite view of data from multiple sources.
This proof-of-concept exercise dealt with an administrative department hiring a student, which involves accessing several enterprise systems to verify the student is enrolled and eligible for work-study, and entering the student's data into a human resources system. "This has traditionally been a real pain," Busby said, "and it is something the philosophy of SOA solves,"
The traditional funding model for applications tends to strengthen the silos that already exist, he noted. People don't think in terms of shared services. "It's very hard to get people to think about strategic directions in the long term. The decentralized nature of our organization doesn't lend itself to that," he added. "We can only suggest."
The SOA movement may eventually get the University of Wisconsin-Madison to address its underlying governance and policy issues, Busby said, but right now there isn't a big enough push for adoption.
Busby isn't the only one in the Badger State working on the issues raised by SOA adoption. Allen Poppe, an architect and project manager at Wisconsin's Division of Enterprise Technology, said his organization is helping agencies confront trust issues and find funding mechanisms.
Like the university, state government has to deal with a decentralized structure in which each agency gets its own funding for IT projects. One recent innovation involves establishing communities of practice around business topics for Web service developers. "We want people working on similar business projects in health, education or justice to start collaborating rather than the agencies and their applications dictating down to them," Poppe said.
Almost four years ago, under the leadership of former CIO Matt Miszewski, Wisconsin began moving to Web services and enterprise service bus (ESB) technology to simplify data integration tasks. "When one department needed info from another, we used to do one-off, point-to-point integration projects," Poppe explained. The ESB uses XML messaging technology to route data among applications, eliminating the need for many of the individual project-level coding projects.
The first Web service project the state tried involved gathering procurement data from multiple systems to present a consolidated view of, for instance, how many pencils the state buys so it can better negotiate with vendors. It has since moved on to more complex tasks such as integrating statewide criminal justice systems and pulling together No Child Left Behind data from school systems statewide.
One challenge is how to fund Web service development. Poppe said the state is looking at a franchise model to motivate agencies to create Web services that would be valuable for reuse by other state groups. "For instance, if the Department of Health and Family Services creates an enterprise-class service that other agencies could benefit from, they could charge fees for the use and support of that service. It could help motivate IT people who enjoy creating enterprise services and provide an incentive for the agency to recoup some of its expenses."
Building Blocks, Federal Style
During Hurricane Katrina, people in the field trying to get U.S. Environmental Protection Agency (EPA) data had to take the time to register for each application they wanted to access. But with the agency's move toward service orientation, EPA application developers will have access to a reusable component for ID management that includes single sign-on.
At the EPA, the goal is to build services as blocks the agency's IT contractors can reuse. The expectation is that the EPA can save 30 percent of the cost for new application development within two to three years, said Phil Magrogan, Lockheed Martin's CTO for its nine-year application development contract with the EPA.
"Our hope is that by building this application platform and giving away the methodology and guidelines, it will make it ubiquitous within the EPA," he said. "We want program offices within the agency to see this as a cheaper, faster way to develop applications than building from scratch."
Magrogan sees two perspectives on integration: A component service bus creates the building blocks that allow applications to be built faster, whereas an enterprise service bus allows data to be shared across applications horizontally.
"The priority for the EPA now is to come up with these common building blocks so that the franchisees can be building on the same infrastructure and stop the bloat of using different approaches, products and protocols," he said. "Getting to services that reach across applications is a goal, but it will take a longer period to achieve and there are more issues to work out."
Steve Hufford, program manager for Systems Engineering in the EPA's Office of Environmental Information, Office of Technology Operations and Planning and National Computer Center, said there are several reasons SOA is catching on at the EPA. First, the agency has a history and culture of collaboration between its groups. People have always been willing to talk across offices. Second, the EPA has a reputation for having a good enterprise architecture planning shop.
"There are already processes in place and work groups to talk about processes and where we want to go," Hufford said.
But the new paradigm may require major operational changes. "Like many organizations, the EPA has a lot of experience designing and using applications," Hufford said. "But now we are challenged to design services, and a fundamental question is, are the structures we have set up to manage applications going to work?"