By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Sara Grant: In looking at the future of Web services -- defined as application-to-application communication -- some vendors and futurists paint a scenario where businesses collaborate and compete in profound new ways. But your research suggests that this is not happening and is not likely to happen any time soon. Why have Web services not lived up to the hype?
McAfee: Because the hype is unrealistic. It is, in fact, getting easier to integrate applications, but it's never going to be easy. There are two reasons for this: one technical; one organizational.
The technical problem is that any two applications are virtually guaranteed to contain dissimilar data and execute dissimilar business processes. One might store dates as DD/MM/YYYY and put the date first in the purchase orders it sends out; the other might store dates in the MM/DD/YYYY format and expect the date to be the first field in any electronic purchase order it receives. Before any systems integration can take place, these dissimilarities need to be resolved. There is no magic bullet in the Web services toolkit that does this automatically or quickly.
The organizational challenge comes as all stakeholders get together and hammer out common definitions. This might not seem like the kind of work that leads to disputes, but it is. In most companies, questions like the following would lead to heated discussions:
- Who's got the real customer contact information? Who gets to access it? Who gets to update it?
- What's the last day for bookings in each quarter? Is it the same all around the world?
- Do we have to do a credit check before scheduling every order for production?
- Who gets to certify approved vendors? What's the process for adding a vendor to the list?
Answering these requires a combination of diligence and tough-mindedness.
A couple of years ago Cisco called a halt to all new IT efforts and spent over 18 months and $300 million to resolve exactly these kinds of dissimilarities within the company. If any Web services tools could have made this work cheap, fast and "easy," don't you think Cisco would have used them?
What are the characteristics of successful Web service implementations today? What kinds of companies can benefit most? Are there certain types of processes that work best as Web services?McAfee: Web services technologies work equally well within and between companies. Cross-company implementations, however, are still comparatively rare. We see them between large and technically sophisticated organizations who have longstanding ties, and we're also starting to see them between big companies and their smaller suppliers.
Big companies have the power to convince or compel their partners to participate, and to shortcut negotiations by simply dictating terms. Amazon and eBay have both done brilliant work with Web services to open up their IT infrastructures and let thousands of small sellers plug into them, but it's a "take it or leave it" proposition. Amazon and eBay don't renegotiate Web services standards with each seller; they simply publish their standards and wait for other companies to adopt them.
So far Web services are being used to automate simple business processes -- transmitting an order, acknowledging a shipment, describing an item for sale, etc. Over time the processes enabled via Web services will become more complex, but it's best to start small and build incrementally.
For companies that have invested in Web services, what benefits have they realized? Do they gain competitive advantage?
McAfee: It sure looks like Amazon and eBay are strengthening their positions and continuing to grow by using Web services well. I studied an effort by IBM and its independent distributors in Europe to automate the ordering process for midrange computers. All the parties I talked to felt that productivity had increased, but they talked about the work more as capability development than benefits realization. They were learning how to "speak Web services," and were confident that they would have many opportunities to use their new language skills.
What questions should a CIO or other company leader ask as they consider a Web services project?
McAfee: Who are we doing this with? Can we be sure that our partner is in this for the long haul? How are we going to reach agreement with them about shared data and business processes? What's the first set of interactions that we're going to automate, and what are the next ones? What do we eventually hope to achieve by using this technology? How are we going to ensure that we capture our learnings as we go, and actually develop a capability?
Notice that this list of questions does not include anything about cost savings or ROI. I just don't think there are crisp and meaningful ways to do these calculations. This doesn't mean, of course, that a company shouldn't try to minimize costs and identify benefits; it means that it's not smart to focus from the start on cost savings, then get upset when they don't materialize quickly enough.
What research are you working on now?
McAfee: I'm looking at how the Italian networks of small and medium-sized companies use technology. It turns out that they make heavy use of "freeform" technologies such as email and websites but aren't heavy users of structured technologies such as EDI, XML and Web services. I'm working with Francesca Gino and Stefano Micelli to understand who uses structured technologies for intercompany communication, and why.
To read more articles like this one, visit HBS Working Knowledge, an online source for business analysis, information and research.
© 2005 President and Fellows of Harvard College