By Alan Radding
Imagine the response of any of your IT consulting clients when barraged by the incessant hype surrounding Web services as the Microsoft- and IBM-driven Web services juggernaut picks up momentum. Re-engineer every application and interface? Throw away last year's investment in EAI middleware? What about the ERP, CRM, SFA, supply chain, and host of other applications that are only just beginning to deliver a payback? New protocols, an alphabet soup of new standards — XML, SOAP, WSDL, UDDI, ebXML — means what? More training, more delays, more disruption. And coming at a time when budgets are cut, no, not cut, but decimated. Maybe your client thinks, "I'll just drop this hot potato — Web services — into the lap of my IT consulting provider." So now, it is your headache. Welcome to Web services.
The Web services bandwagon continues to roll, but IT analyst Carol Baroudi advises IT managers not to worry about jumping on now. They should think about how they might take advantage of Web services in the future, but not fret over it. As with other watershed technologies, their organizations will collect many of the benefits of Web services without lifting a finger, without anyone attending a single seminar or vendor demo, and without anyone writing a line of code if they don't want to.
"The vendors will build Web services capabilities into the technology products you will buy in the future, so you will automatically get the benefits of Web services," she tells them. And until the vendors finally succeed in making Web services both bulletproof and transparent for end users, the IT consulting firms will be there to handle the tough parts.
In this sense, Web services as an emerging infrastructure technology are no different from object-oriented programming or component-based systems or Java or other core IT infrastructure technologies. Much of the enterprise software deployed today is object-oriented or component-based or built-in Java, but most organizations do not themselves build software objects or components or write in Java. Leading-edge technology adopters may have a small group immersed in these technologies and can work with them. Most organizations, however, simply buy products — software, middleware, application servers — that incorporate the emerging infrastructure technologies as they mature. In the end, you don't have to know software objects or Java to benefit from applications built using objects or Java.
Baroudi is president of Baroudi Group, an IT research firm based in Arlington, MA. At this still-early stage in the evolution of the technology, she says, Web services, regardless of the potential, are a game for technology vendors — particularly software developers and technology infrastructure companies. It also should interest IT consulting and system integration firms and early enterprise IT adopters. These are the organizations that have the biggest stakes in how the standards and technology details finally shake out. The rest — the vast majority of organizations — will simply use whatever comes out of the process. In the meantime, they might just as well wait, watch, learn, and plan until Web services technology is ready for prime time.
Praendex Inc., a consulting firm based in Wellesley, MA, is representative of where many companies are when it comes to Web services. The company has been migrating its predictive behavior services from paper to the Internet, and Web services look like an attractive fit. Specifically, it plans to migrate to .Net, Microsoft's implementation of Web services, but it hasn't yet. "We will be moving to .Net, but it wasn't ready when we started 15 months ago," says Praendex CIO Allen Falcon. Instead, the company opted for conventional Web technologies in the expectation of adding XML and .Net as these Web services technologies mature.
Among the early adopters, however, Web services technology already is starting to take hold. "From a standards perspective, there is enough to get started," says Bob Sutor, director, e-business standards and strategy, at IBM, although "more needs to be done." There certainly is enough ready for IT consulting firms to start working with the technology, at least in particular situations.
"We have begun using Web services with clients," but the impact at this point has been minimal, reports Michael Gregoire, senior vice president at PeopleSoft Global Services, the professional services and consulting arm of the ERP software provider. To date, the company has developed about 60 discrete Web services that it uses to provide low-level technical capabilities within supply chain systems. One such service, for example, helps set up a reverse auction, part of the procurement system process, and takes advantage of UDDI, the core Web services standard for the directory.
Web services are pieces of software that communicate system-to-system across the Internet or the corporate intranet or extranet using a small set of basic standards and protocols. These include XML for data exchange, SOAP to deliver the message, WSDL to define the Web service, and UDDI to register it in a directory. If you think of standards development and adoption as a four-year process, "we're just over half way there with Web services," says Sutor. The basic standards were pretty much locked down last fall, although work continues. "SOAP, WSDL, UDDI, and XML were solid by the end of last year," he notes.
Now, the industry groups are turning their attention to higher-level Web services standards to handle such issues as security, reliability, transaction integrity, and other capabilities that must be nailed down before organizations can begin using Web services to conduct real business. Until the industry makes progress in these areas, Baroudi advises organizations to refrain from widely deploying Web services and instead use them to help integrate systems within the secure, trusted environment of the corporate network.
But the outlook for these higher-level services is changing fast. For example, IBM, Microsoft, VeriSign, and others have been busily hammering out WS-Security, a Web services security standard that is now ready to be handed over to an industry standards body. "By the end of this year, you will see the first versions of the security specification, and within a year the first implementations will appear," predicts Sutor.
A security standard will go a long way toward making Web services ready for prime time use and acceptable to large enterprises. "You can't really use Web services externally until the security improves," observes Patrick O'Kane, chief architect, ePresence Inc., an IT consulting firm based in Westborough, MA. Right now, ePresence regards Web services as infrastructure plumbing, a set of XML interfaces to facilitate the exchange of data between dissimilar systems. But the company uses Web services only behind the corporate firewall because the security isn't in place to open them to the outside environment.
Testing presents another set of challenges to those hoping to build complex enterprise applications with Web services. Today, most companies are using Web services internally, where they can test all the components individually and end-to-end. When companies start to use Web services that were created by others and reside outside the organization, things get hazy. "Testing inside the organization is doable but not trivial. Testing becomes a huge problem as soon as you want to use Web services inter-enterprise," notes O'Kane.
For example, if you want to use someone else's Web service, say a credit scoring service, in your loan origination application, how will you test it? Sutor dismisses such testing concerns. "An individual Web service is nothing more than an application with an external interface. You test as you do any application and interface," he insists. That sounds good in theory, at least until the other party starts moving the Web service to another location or changes the Web service so that it doesn't produce the results your application expects.
Beyond concerns about security, testing, and other details, Web services face a number of even more basic hurdles before the technology is ready for broad use by consulting firms and their enterprise IT customers. To start, "there isn't even a single Web services set of standards," Gregoire points out. Depending on how you count, there may be three, five, or more organizations involved in efforts to develop Web services standards. Before Web services can really take off, "we need to get agreement on a single definition, a single set of standards," he believes.
In late June, for example, Sun Microsystems, in conjunction with other software vendors, proposed adding yet another candidate to this bubbling brew of already extant Web services standards. This one, Web Service Choreography Interface (WSCI), is intended to coordinate activities and transactions between systems using Web services over the Internet. According to the announcement, WSCI will provide a standard way, using XML, for developers to describe actions and the order in which they should take place to support complex collaborative processes. Other vendors participating in the announcement included SAP, BEA Systems, and Intalio.
Without broad industry agreement on the standards and definitions, Web services remain a generally experimental technology offering some relatively quick payback and great promise of future benefits. For example, Web services today can be used behind the firewall to ease the job of integrating dissimilar systems. With a standard external interface, standard data exchange language, and standard call procedure, companies and consulting firms can use Web services immediately to connect loosely coupled systems, getting them to exchange information and act on one or another's requests.
Although Web services could eventually dispense with the need for the various EAI middleware currently used for integration, it seems unlikely the EAI vendors will allow Web services to displace them. More likely, the EAI middleware vendors will incorporate Web services into the next releases of their products as just another set of supported standards and protocols.
For consulting firms, Web services present a new opportunity, particularly when helping clients with application and system integration efforts. But before clients buy into Web services, consulting firms will have to build the ROI case.
Baroudi sees a limited immediate ROI from Web services, mainly taking the form of a reduced effort when integrating technology and in the ease of leveraging previous technology investments. Bigger ROI opportunities from the reuse of Web services and new Web services-based business models remain much further down the road. That won't begin to happen until Web services capabilities are built into all technology products.
So where does that leave the IT consulting firm today in regard to Web services? Simple, just reassure the client. You'll monitor the standards development, you'll watch the interfaces, and you'll train the staff when the time comes. In short, you'll take care of everything. Because when the time does comes, the vendors will have done most of the heavy lifting and your job should be easy.
© Arc, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.