Sorting SOA fact from fiction
7 truths about service-oriented architecture that savvy leaders can take to the bank
By FCW Staff
Published on February 12, 2007
With the exception of the World Wide Web’s ascent a decade ago, few recent technology movements have received as much attention as service-oriented architecture.
If you use SOA to create and manage lean software applications of well-defined work processes, you’ll finally have the tools to glue together disparate systems into a collaborative whole, proponents say. They add that SOA is a way to assemble services into agile composite applications that help complex organizations turn on a dime. Its other benefits include writing code once and using it in multiple applications, extending the life of older programs and re-orchestrating business processes for greater efficiency.
To the wary, SOA sounds like the latest silver bullet that never quite lives up to the promises. “It’s a bit like pixie dust — just rub some on and the results are marvelous,” said David Sprott, chief executive officer of Everware-CBDI, a research and consulting firm. The reality is less magical, he added, because by definition SOA addresses information technology architectures. “Nothing that’s architectural in nature is going to be an instant fix,” Sprott said.
Where do SOA’s benefits end and pixie dust sparkle begin? We examine seven widely held assumptions about SOA to gauge how closely the dream matches reality.
Assumption No. 1: Everybody’s using SOA
Reality: False
In Arkansas, SOA hype is breeding caution. “We don’t even want to use that term ‘SOA’ because of the baggage it brings,” said Drew Mashburn, the state’s chief enterprise architect. Thus far, the state is still investigating the technology and has yet to begin a large-scale implementation, he added.
According to estimates by market research company Gartner, Arkansas
isn’t unique. Although interest in SOA is high, only about 12 percent of organizations say SOA will attract a lion’s share of their application development efforts this year.
“If I ask an audience of 300 people how many use Web services, every hand goes up,” said Burr Sutter, senior product manager at the JBoss division of open-source software vendor Red Hat. Web services are industry standards for building interoperable applications that are closely associated with SOA. “If I then ask how many people have more than five Web services, half the hands go down. It’s obvious to me not everybody is using a ton of Web services.”
Even agencies that say they are “doing SOA” may only be referring to using some Web services, not an overarching architecture. “Government organizations have huge complexity in their application portfolios, and much of it is heavily siloed,” Sprott said. “If you want common citizen services with a consistent view every time someone logs onto the Web to talk to a government department, it’s very difficult unless you have architecture.”
Sprott said architecture development is a slow process that can require five to 10 years to complete. Nevertheless, government IT managers believe the public-sector incentives will spur the push to SOA because of enterprise-architecture mandates and desires for interagency collaboration. SOA “really is about transferring information between jurisdictional areas, so the opportunity is probably larger in the government sector than in most others,” said Randy Hughes, Utah’s state technical architect.
Assumption No. 2: SOA can only be done using Web services standards
Reality: False
Many people assume that the SOA framework applies only to software built on Web services protocols. However, the architecture may work just as effectively with proprietary message-oriented middleware, which facilitates communications among a variety of operating system platforms.
SOA “actually originated in the early ’90s, predating Web services,” said Ron Schmelzer, a senior analyst at ZapThink. “There’s a lot of SOA out there that leverages mainframes, using MQ Series [middleware] and COBOL” programming language.
However, the beauty of a SOA/Web services marriage lies in the widespread adoption of Web standards. “It’s very hard to get heterogeneity in service-oriented architecture unless you have some common standards,” Schmelzer said. “SOA without Web services can work, but you have to be in a controlled environment.”
Assumption No. 3: SOA offers cost savings and efficiencies because it’s a framework for easily reusing software in multiple applications
Reality: False
Not only is this assumption false, it “might be one of the biggest misconceptions about SOA,” said a spokesperson for the chief technology office of the Defense Information Systems Agency in an e-mail response. DISA officials are interested in using SOA as a means to lower IT costs and increase flexibility.
“SOA provides the opportunity for a greater resource optimization because
it is not the software that is reused but rather [the] function performed by the software, along with its management, operation, and maintenance,” the DISA official said.
Even reusing services, as opposed to software, is rarely simple, Sprott said. “It’s very easy to create a service. It’s much harder to create a service that is highly generic, applicable in many different situations, and engineered so that it can be gracefully upgraded and extended without causing major trauma to all of the consuming applications,” he said. “These are nontrivial architectural problems.”
Reuse raises practical questions for developers. To achieve reusability, programmers must look beyond their current requirements and anticipate how the service might be used in the future. “How can anybody who has a defined budget and timeline justify the extra expense and time to make things reusable in a way that they can’t predict?” Schmelzer asked.
Even if multiple departments band together to share a service that addresses common needs, questions arise over who pays for development and its ongoing maintenance and management. “Reusability turns out to be much more imposed by how the whole system is organized rather than any particular piece of code,” Schmelzer said.
Finally, reuse among agencies represents risks. Before an agency can rely on a service for a core application, it must somehow vet its dependability and the support behind it, said Mark Zalubas, chief technology officer of Merlin International. “At least if we [develop] our own service, we can guarantee that we will support it,” he said.
Assumption No. 4: Organizations that rely on SOA are more agile than ones that run traditional applications
Reality: True
Agility can be a concrete benefit of SOA, but achieving it takes a long-range effort. “One of the biggest fallacies with SOA is that people believe that their first application will be built faster than using a conventional method, and that’s probably incorrect,” Zalubas said. The development time for “the first, second and third application may actually be a little bit slower. It’s the fourth, fifth and sixth application that you start to get economies of scale.”
The key to agility is having access to a wide range of services to choose from so agencies can find the right capabilities to plug into new applications. “And that’s where the problem is: Most government agencies haven’t reached critical mass with Web services,” Zalubas said.
Meanwhile, testing is another hurdle to agility. Because services may be used in ways unintended by their designers, IT departments need to test the new implementations for functionality and reliability.
“The service interface should be extensively tested to make sure that it performs as expected and cannot be exploited to support nefarious objectives,” the DISA spokesperson said. “The potential service provider also needs to understand fully what performance levels [the service] can offer potential customers as well as the scalability of their system and operations to support new service customers.”
Assumption No. 5: SOA requires significant new investments in
technologies and developer training
Reality: False
Influenced partly by commercial hype, many agencies assume they need an expensive IT makeover to make SOA work. Zalubas said this may lead to overbuying for agencies that adopt SOA incrementally. Agencies “may go off and buy registries and governance tools and everything else that sounds like a pure-play SOA tool,” he said. “Then they publish a single Web service in their directory. That’s akin to having a Yellow Pages with one phone number in it.”
Even tools and training for developers don’t require an overhaul, he added. Developers with Web programming tools and skills have a working knowledge of Web architectures that applies to SOA. “What’s different is that at the end, when we mark up code for human consumption, we use HTML and deliver it to a Web browser,” Zalubas said. “On the Web services side, we mark it up in XML and we deliver it to a Web services client, which is analogous to a Web browser.”
Assumption No. 6: SOA requires an enterprise service bus to be successful
Reality: Sometimes
Enterprise service buses are a useful traffic cop when services feed transactions that run over time or among different systems, said John Fitzgerald, product marketing manager at Software AG, which sells an ESB product. “It’s very helpful when you have two different systems that might have data stored in different formats and there is a need to transform that information,” he said.
However, Schmelzer warned that different companies have different definitions for ESBs. “Vendors offer enterprise service buses that look very different from each other,” he said.
How to choose? First, make sure you don’t already have technology that performs ESB capabilities. “Most companies already have message buses and e-mail transfer mechanisms,” Schmelzer said. “They have an application service to expose service interfaces or a run-time environment.”
If an agency needs an ESB, IT managers should first identify the specific requirements, such as metadata management. “Agencies shouldn’t be looking for the mythical ESB creature that is supposed to provide the answer” to architecture challenges, Schmelzer said. “Fundamentally SOA is about architecture. That means you need to actually have architects to do the job” of architecture design.
Assumption No. 7: SOA is a technology innovation that only concerns the IT
department
Reality: False
The DISA spokesperson said the technical challenges created by SOA are
easy compared to the business issues that agencies face. Among the knotty questions are: What services should IT provide? What service-level agreements and performance guarantees can IT support? How rapidly can IT scale SOA operations to support rapidly increasing user demand?
SOA also represents a change in how IT and business departments interact, Hughes said. “The adoption of SOA is predicated on business requirements,” he said. “That’s a flip in thinking for a lot of organizations because it puts the business [side] more in the driver’s seat.”
Instead of the traditional software development process where a department leader might outline a need and the IT department goes off to build a solution, SOA requires both sides to work more closely in concert, Hughes added.
Those issues create “a major culture shift,” said Bob Brown, a senior staff member at the U.S. Patent and Trademark Office’s Software Development and Maintenance Group.
A focal point in this shift is code reuse. “Where is the financial incentive for
people to generate less code?” Brown asked.
He criticized outmoded contracting vehicles that pay software developers by the hour or by the lines of code they write, an approach that is counter to the goal of reusing as many prebuilt services as possible.
The answer is revising how IT people are rewarded. They should get “better reviews, more raises or bonuses based on sharing more stuff and showing how they’ve reduced the footprint of the infrastructure,” Brown said. “That’s the way to get people to change their behavior. Otherwise, they are just going to continue with the old ways.”
|
