In-Depth

SOAs: Too Good to Be True?

The service-oriented architecture vision in practice may not be quite the slam dunk it looks like on paper

• By Stephen Swoyer
• 10/26/2004

Service-oriented architecture (SOA) has be talked up by thought leaders including Gartner Inc. for a long time now, and a number of major vendors—including BEA Systems Inc., IBM Corp., and Microsoft Corp., among others—have caught SOA fever, too. The consensus seems to be that SOAs are inevitable, and to the extent that bleeding-edge companies are service-enabling their applications, there appears to be some truth to this. But for many organizations, experts acknowledge, SOAs are far from a straightforward proposition.

More to the point, some critics charge, the SOA vision in practice may not be quite the slam dunk it looks like on paper.

One principal stumbling block is software development: The SOA vision entails a radically different development paradigm, and, in many cases, also requires the use of new development tools and methods.

At its Symposium/ITxpo 2003 conference, for example, Gartner championed a new technology vision—called business process fusion—that depends to a large extent on service-enabling applications. At the same time, Gartner vice-president and distinguished analyst Donna Scott cautioned that service-enablement requires a new development paradigm, which she called service oriented development of applications—or SODA. “[SODA] is the practical impact of these ideas as far as the development team is concerned,” she explained. Added Gartner vice-president Mark Raskino: “That means the IT department has to step up to the plate here, to create a pool of new people who can do business process mapping, modeling, and modification.”

Jonathan House, a programmer with custom software development house SurgeWorks, says this is the crux of the matter. “There is a difference between SOA as an approach to writing distributed software, and SOA as an approach to exposing internal functionality. The first is alive and well in companies—a lot of internal distributed applications are being built using SOAs. But you don't see a whole lot of the latter, even though this is the ‘dream’ that the IT industry is preaching at the current time.”

House concedes that some good can come out of service-enabling applications, but cautions that the SOA as an enterprise-wide vision could be little more than a pipe dream. “Regardless of the ‘promises’ of SOAs, there is one fundamental problem that keeps them from encompassing all business function as they were envisioned. That problem is one of money,” he says. “All of the SOA advocates say that within a few years every business will take internal processes and convert them into ‘services’ that can be used by other companies. But does it make financial sense to do so?”

Some would argue that House is erecting a straw man. After all, no one—save, perhaps, for the most opportunistic of vendors—is advocating the complete service-enablement of all enterprise applications, at least, not now. Instead, SOA advocates say, organizations should start to think about service-enabling applications where it makes sense to do so.

“I would say a lot of customers are still at what I would call the Web services stage [of SOA adoption], so they’re like, ‘I want to access this because I realize I can get reuse from this particular entity and I wish to describe it as a service so I can leverage it from a number of different entities in the enterprise,’” said Kareem Yusef, lead product portfolio strategist for IBM’s WebSphere Application Server platform, in an interview earlier this year.

As it turns out, however, this is exactly what House means. Simply put, he doubts there’s an economic incentive for many companies to expose their most important applications as services.

House offers the example of a brokerage firm such as Dunn & Bradstreet that offers a credit-scoring service to which customers subscribe. “If you want to use [these credit scoring tools], you have to subscribe to their service and use their declared interface for interacting with their service,” he says. “If you want to use a different service, not only do you have to unsubscribe, but you also have to re-interface with the new service you are intending on using.”

This is expensive work, he says, and—on its surface, anyway—offers a strong argument for service-enablement: “Rather than having to rewrite your interface software, all you have to do now is unsubscribe from D&B and subscribe to Standard & Poors instead—you could literally switch services in between interactions with the scoring systems. Since the SOA for credit scoring comes with an evolved interface for interacting with credit scoring services, you shouldn't have to change your interface.”

There’s just one catch, House says: Why would companies like Dunn & Bradstreet or Standard & Poors want to make it easier for customers to switch to competitive services? “Will D&B spend money on developing this type of interface that in essence ‘commoditizes’ their service? Not in my experience. They will do it only if they are forced to by competitive pressures, but not for any other reason,” he says.

Like House, Uri Sherman, a WebSphere application developer with the Israeli army, believes it’s possible to implement an SOA using today's applications and development tools. At the same time, Sherman suggests, service-enablement still may not be desirable: “I think that the trade-off in the service-enabling of existing applications is not a question of technology or compliance or lack of standards or easy-to-use development tools,” he comments. “It is a question of design. It depends if the application is by definition a service-oriented application, or at least is it designed in a way that enables some kind of service oriented ‘view’ over the ‘tasks’ it is intended to perform.”

Sherman says it’s easy to design applications from the ground up for service-enablement, but notes that most organizations don’t have that luxury. “Surely the trick is to expose *some* applications that are fit, but in cases in which these applications provide real business and [are] more than just a few simple ‘utilities,’ it is quite a problem ‘forcing’ them to ‘look’ like SOAs if they weren't designed that way in the first place,” he argues.

Of course, IBM, BEA, and other vendors purport to address just this problem by shopping SOA-ready middleware, in the form of the Web application server. Several weeks ago, for example, Big Blue announced a new version 6.0 release of WebSphere that offers new features and other enhancements for organizations deploying SOAs.

SOA-enablement isn’t just limited to the Web application server. Database vendors are also getting into the mix. Last month, Big Blue made noises about the SOA-readiness of its new DB2 UDB version 8.2 “Stinger” database, and two weeks ago, data-warehousing specialist Teradata, a division of NCR Corp., touted the SOA-friendliness of its new Warehouse 8.0 release.

“A lot of our leading customers are the leaders in the industry and they are adopting SOAs, and they are going that way,” comments Randy Lea, vice-president of products and services for Teradata. “But I also think a lot of our customers aren’t quite there yet, and in some cases, we are introducing this to them. A lot of data warehousing customers are kind of caught in the BI tools space and haven’t really moved into the enterprise space where SOAs are being implemented in many of their own companies.”

Vendors argue that by building SOA capabilities into database, application, and middleware offerings, they’ve already done much of the legwork for enterprise developers, who can exploit Web services or adapter technologies to expose their applications as services or otherwise tie them into service-enabled middleware. Some developers aren’t so convinced, however, noting that customizing an application that’s been designed for one purpose to make it serve another purpose is often a laborious and frustrating undertaking.

“You don’t see the pain until it comes time to implement the nitty-gritty requirements, and then you say, ‘Oh, man, this framework is really being stretched beyond what it was intended to be, and now we’re two-thirds of the way through the project and it’s too late to back out,’” concludes Roy Miller, an independent developer and author of "Managing Software for Growth: Without Fear, Control, or the Manufacturing Mindset."