Remember that classic Saturday Night Live skit where Chevy Chase hawked his merchandise as both a dessert topping and a floor wax?
In trying to be all things to all people, it's not surprising that you end up with a product that serves no one. And so, as Bertrand Meyer pondered in his last column ("Product or Service?" Beyond Objects, Oct. 2001), is software a product, a service, or both? And if both, do we arrive at something that's a lousy product as well as a questionable service? Such is the conundrum associated with the emerging market for Web services.
Nothing New Under the Sun?
My dissonance about the current hype in this market is somewhat eased by Clemens
Szyperski's model of Web services as the pairing of operating agents and their
infrastructure with software components ("Components
and Web Services," Beyond Objects, Aug. 2001). In some respects, there
is indeed nothing new under the sun. As Szyperski observed, the emerging standards
for Web services appear very close to what's come before them: Universal Description,
Discovery and Integration (UDDI) as the evolution of object traders, Web Service
Description Language (WSDL) as the evolution of interface specifications and
so on. What's new, however, is the potential pervasiveness of services, which
may in turn impact the economics of software development. Ultimately, any technology
will take hold only insofar as there exists a business case for it: faster,
better, cheaper or as an enabler of things that would not have been possible
otherwise.
The essential question, then: Do Web services offer any of these benefits?
Minimizing Metal Fatigue
Contemporary systems have lots of moving parts, some of which change at different
rates than others. Well-architected systems are resilient to change and therefore
can weather external as well as internal change; over time, poorly architected
systems break apart at the seams due to the software equivalent of metal fatigue.
Managing change and complexity is a motivator for component-based software development. A well-architected system is typically formed from a set of parts that embody a clear separation of concerns and a balanced distribution of responsibilities. If those islands of semantics are encapsulated and then delivered as components, such a system can indeed weather change: The unit of change in the deployed system is the component. Furthermore, as the manifestation of a set of semantics, both static and dynamic, a component represents a concrete abstraction: By raising the level of abstraction, components serve an important role in helping to manage complexity.
Clearly, component-based software offers some compelling benefits, and its business case has brought the concept into the mainstream—but perhaps not in the way that its early proponents anticipated. When components were just emerging, in the early days of DLL and then COM, pundits expected a revolution in software development from the creation of a public marketplace for components.
R-Evolution?
Well, for starters, I'm always skeptical when I hear of revolution: Scientific
progress is typically an evolutionary process. I've encountered only a few innovations
in the software space that I'd deem truly revolutionary. Admittedly, components
have entered the mainstream: Windows and J2EE have made component-based software
development pragmatic by offering a platform broad enough so that standard components
are possible. However, a robust public marketplace for components hasn't emerged.
Yes, there are some success stories, but by and large, the economics of software
development don't encourage such a public market. They do, however, encourage
a thriving private market. If a component were really valuable, no acceptable
price on the public market would ever be sufficient to cover its costs and provide
a good profit. Indeed, in most cases, the component creator would get a better
return on investment by dominating a particular market by building better, faster
or cheaper systems with that component.
This is what drives most valuable components into the private market, wherein development organizations craft their own set of standard components. If all developers have equal access to the same set of parts, then such parts offer no compelling competitive advantage (except for avoiding the fear of not playing on a level field). Developers scratch out a competitive advantage in their ability to efficiently assemble those parts in ways unique to their domain, with proprietary bits added that are germane to that domain.
These are the same economics that impact the market for Web services. In the case of the major platform vendors, Web services are an interesting gamble that's hedged by its secondary effects. Specifically, there's revenue from the licensing of services, but there's also enormous pull-through for the underlying platforms, both software and hardware, necessary to use those services. The issue of platform obsolescence also drives this market. As software and hardware platforms become increasingly commoditized, making margins even thinner, new revenue streams are essential for the future health of the business. Services represent such a new potential stream.
Elemental Issues
So, one can make a business case for Web services from the perspective of the
platform vendors. But what of the users? Are the economics sufficiently compelling
to drive developers to use services?
In that regard, there are three possible elements to this business case.
First: cost avoidance. The most direct way to reduce the costs of software development is to not develop any software at all. Components and services are a means of software avoidance. It's the old build-versus-buy trade-off: If the cost of simply buying (or renting) a service is less than building it, then buying is the way to go. However, hidden costs often lurk on both sides of the equation. Renting a service is usually cheaper in the short term, but its long-term costs are typically higher than if built. Similarly, it's relatively easy to calculate the costs of building a part, compared to projecting the total cost of its maintenance and evolution.
Second: complexity management. I'd much rather build my software on top of parts that I know work. I no longer write my own operating system, middleware or tools. Hence, I have to live with what I can find in the marketplace. If I don't like what I find, I'm never compelled to buy it (unless a monopoly limits my choices—but that's a topic I'm not going to touch upon here).
Third: interoperability. As individual projects produce systems that look less and less like islands of functionality, whatever I build has to play well with other systems that live in my end users' landscape. They will demand interoperability—with personal productivity products such as Outlook and Word, as well as with other systems that my organization may deliver or use. The mechanisms of the Web paint a veneer over what is really a very distributed, very heterogeneous platform, and end users expect this illusion of simplicity. An individual development team simply does not have the resources to engineer all of this illusion, and so must rely upon operating agents and their infrastructure that build upon standard software components—in short, Web services.
Are Web services inevitable? Probably, because they represent the next evolution in development, building upon the foundation of what's come before. Are Web services fiscally sound? I believe that there are some interesting economic forces that drive them. Are Web services technically sound? For now, that's hard to say, for their foundations are just emerging.