In-Depth

Reader Feedback: Management's Web-Services Push Meets IT Resistance

Many IT pros remain skeptical about service-enablement, but—as a growing number are finding out—they don’t have a choice in the matter

• By Stephen Swoyer
• 07/05/2005

Last month’s article on service-oriented architectures (SOA) drew several responses from readers, many of whom are dealing (to one degree or another) with SOA mandates in their own organizations. (To read the original article, visit http://esj.com/Enterprise/article.aspx?EditorialsID=1421.)

Among the respondents was Kevin Kinney, a veteran mainframe operator with a leading provider of information management solutions for the financial services industry. He is extremely skeptical of the SOA trend, which he described as an effective rebadging of existing ideas.

When Kinney was interviewed for last month’s SOA article, he suggested that SOA wouldn’t necessarily mesh very well with his company’s business model.

“Our mainframe-based business model [is] different. PC software is based on the number of shrink-wrapped boxes moved out the door. In our particular case—on the mainframe—our revenue is based on licensing as well as consulting with clients who desire personalized solutions,” Kinney said. “Yes, that can be a pain at times, but simply switching from a customized solution to a cookie-cutter approach is something that needs to be carefully considered.”

Kinney spoke with us ahead of some paid time off he’d scheduled; when he came back, he says, he was told that—as far as company executives are concerned, anyway—SOA is in fact a natural fit. “I took the early part of this week off, and came back to a bunch of e-mails. It seems our parent company is rolling out a BPM [and] SOA product and/or service. It seems they are using the ‘do as I say’ model,” Kinney confirms. “Sometimes the only humor you find is bitter irony.”

Kinney’s marching orders could be part of a growing trend. As he himself puts it, do-as-I-say directives from executive decision-makers infatuated with a still largely inchoate SOA technology vision.

Of course, the attraction of this vision is undeniable. For example, instead of an inventory management application, with all of its attendant quirks (and vendor-specific lock-ins), you’d have an inventory management service—preferably exposed via SOAP, WSDL, and other Web-services standards—which may or may not reside locally on your own network.

Ditto for other common business processes (such as payroll management and management), too. Similarly, in the SOA visions touted by BEA Systems Inc., IBM Corp., and others, enterprises can cobble together virtual or “composite” applications composed of multiple independent services, and services themselves will be plug-and-play.

Web-services enablement assumes a somewhat portable understanding of what are (from enterprise to enterprise) often wildly different instantiations of traditional business processes. The approach is dependent on the maturation of enabling technologies, such as the Business Process Execution Language (BPEL), the Business Process Modeling Language (BPML), and Electronic Business XML (ebXML), among others.

This has many IT pros—including many who aren’t nearly as skeptical about the SOA vision as Kinney—calling for prudence and restraint.

“SOA is an observed trend in application development. Consider Web services: using this technology, one can design distributed applications across heterogeneous platforms, independent of communication methods,” says Stephan Bren, a programmer with a prominent global solutions provider. “Web-service technology has grown dramatically in the past decade, as XML has been defined and software platforms developed that directly support Web services. SOA seems to me to be a natural manifestation of the availability of such development technologies, as Web services.”

But Bren, like other IT pros, isn’t convinced that SOA is a complete, much less coherent, technology vision. Instead, he describes it as an “evolutionary development” of an ante-concept—code-reuse.

“You can trace the development of re-usability from the concept of procedures (which introduce re-usable code—functions and subroutines—within the context of a single program on a single platform) through the concept of classes (which introduce re-usable code objects within the context of multiple programs on a single platform) to Web services (which introduces re-usable code within the context of multiple programs across multiple platforms). SOA to me merely recognizes and formalizes this evolutionary development.”

Priya Patel, a programmer with Exoftware, a programming consultancy based in the EU, has a similarly pragmatic—and even quasi-skeptical—perspective. For starters, he notes, not all systems (legacy and non-legacy alike) are going to be of value in the long-term—so it doesn’t always pay to service-enable them in the first place.

“Companies need to assess what assets they have, what condition they are in, and then make the call on what to do with them. Once they do, the messy job of dealing with it falls to developers—which is why most developers think it is more trouble then it is worth,” he concludes.

At the same time, Patel concludes, the companies—and IT pros, for that matter—ignore the SOA vision at their own peril. “I think it is an idea that could take off—with time. It is still [in its] early stages and there are many kinks still to be worked out. However, in my view, anything that assists businesses in taking advantage of technology for competitive advantage is worth considering—after all, the technology we are talking about is ultimately about bringing business value.”