Web services (aka "XML Web Services") have been getting a lot of attention lately. They're very interesting because some major companies are investing millions of dollars into making them work. Prior to finding an explanation in a recent book I read (reviewed below), I had always wondered what the big deal was and why everyone was getting so excited. Technical people seem to have the hardest time understanding what all the fuss is about. This is because, to technical folk who have been paying attention, Web services represent incremental technology rather than a revolution. I mean, at the fundamental level, all they are is a way of calling programs and passing XML data back and forth between systems, using standards like HTTP, SOAP, UDDI, and WSDL. In the early examples shown by vendors, they tended to be shown from the user perspective, where Web-service-enabled apps reminded one of Web portal pages. No big revolution there. Recently, though, I read a book targeted at non-technical people that explained the potential of Web services from a business standpoint, revealing why the industry is so excited about them. In fact, IDC says, "Web services will become the dominant distributed computing architecture in the next 10 years" and will eventually define the fabric of computing. Wow.

Prior to reading Out of the Box: Strategies for Achieving Profits Today & Growth Tomorrow Through Web Services by John Hagel III, I had fallen into the same of mindset that I think many technical people fall into. "What's the big deal about Web services?" I was always wondering. What's the value that is going to make people want to use that technology over any other technology? After all, Web services are essentially a communications protocol, and there are many communications protocols that can accomplish basically the same thing. So what makes Web services different from other technologies similarly touted as "paradigm shifts"?

One fundamental place where Web services are different, according to Hagel, is that they don't try to replace existing infrastructure. Instead, they are themselves an infrastructure that can sit on top of existing infrastructures. They promise to vastly simplify the creation of data and program interfaces because an interface can be created once and subsequently used by anyone else who supports the standard. Just as USB made connecting peripherals easier, Web services and related technologies are intended to make connecting data, programs, and systems easier. It is an attempt to reduce the number of proprietary interface points (which all seem to require at least occasional maintenance) between systems.

With the way the vendors are headed and the amount of money that is being invested, despite some ramp-up issues regarding vendors and standards, there is likely to be large industry support. IDC predicts that Web services will be a $27 billion (US) industry in 2010, and many vendors are scrambling to add Web service functionality to their products, despite the standards being in their early stages. The platform and development tool vendors such as IBM, Microsoft, and numerous others have clearly thrown their hats in the Web services ring.

So how are glorified interface programs going to potentially change the way we do business? The answer is "incrementally." While prior "paradigm shifts" tried to replace existing functionality, Web services are designed to sit on top of existing functionality, to extend it, and to integrate new functionality much more easily than before. For example, if you need to get information from an external system into your application, you could use Web services to retrieve that information from any other system that provides Web services. Conversely, if you have functionality or information that you would like to make available to other authorized users, you can make it available via a Web service. This incremental approach allows you to apply the technologies directly and show the immediate benefit.

Competition spurs the quest for more efficient systems, and that causes companies to seek the maximum value from their technology investments. The best way to do this is to leverage those investments as much as possible. That's marketing-speak for "we gotta get the best bang for the buck." Web services make it easier to do that by leveraging existing and new information assets and allowing them to be combined in ever-more-efficient ways. Hagel describes such "loosely coupled applications" as one of the key concepts in how Web services are extending efficiencies. If applications from different vendors on different platforms in different locations can communicate easily and exchange information in a meaningful manner and if clients take on more portal functionality, it becomes less and less important where specific processing is done. But that's jumping ahead a bit, so let's continue.

This type of functionality will enhance rather than replace existing systems, and it can be introduced over time. The book starts with an example of an application in a department being shared by other departments through Web services. It goes on to emphasize that this type of sharing should not be subject to departmental boundaries. In fact, it should not even be subject to enterprise boundaries. The author explains that businesses will find true new efficiencies by rethinking the model under which they operate. Loosely coupled systems will make rapid changes easier. This is in contrast to tightly coupled systems, such as huge ERP applications. Hagel argues that tightly coupled systems hinder businesses by restricting their ability to change and optimize business processes in a more isolated, and therefore easier, manner. The theory goes that with loosely coupled systems, changes to the underlying systems and processes are more isolated, thereby making them easier to maintain and also making it easier to connect them in ways perhaps not possible before.

One example of the type of efficiencies that can be introduced would be the addition of value up and down the supply chain by getting rapid, accurate information directly into the hands of those who benefit from it. Increasing knowledge in the supply chain can mean a decrease in inventories for those in a position to take advantage of it, which leads directly to the bottom line and makes management happy. Hagel cites the example of Dell, an early adopter of Web services. One way Dell uses Web services is to enhance its supply chain management system by sharing information with vendors. An early result was that, by increasing visibility, Dell was able to reduce inventories at its assembly plants by a whopping 80%. These types of incremental, direct-payback projects represent the early victories and immediate results that management so loves to see.

Hagel's vision doesn't stop there, though. He says, "Managers will generate much for business value by moving beyond one-time implementations in pursuing a more systematic program to target the key economic leverage points of the enterprise." The possibilities that he describes eventually lead to the reshaping of the business landscape. Businesses that begin by creating more efficiency through the use of loosely coupled systems will be able to focus on the business functions that are the most profitable, streamlining some of the redundancy present today and creating new revenue possibilities by exposing new company assets.

Hagel's strategies remind me of something that IBM has been saying for years: The real money (the "benjamins") is not on the consumer side of things, but on the business side of things. The adoption of Web services promises to change the way that money flows. That is what bosses tend to pay attention to. Given the amount of benjamins being invested by the technology companies along with the incentive of increasing bottom-line benjamins that heightened efficiency offers to business, I think it might be prudent to investigate Web services in your organization, if you haven't started already.

What do you think of the industry's push toward Web services? Are you going to use them in your shop? Have you already started? Hit the comments link below and share your thoughts and experiences.

When he's not riding across the desert or blogging, Brian Singleton is busy helping organizations make the best use of their ever-more-complex IT investments. Brian can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..