.NET & Beyond: Why there’s no business case for Web services
|At a Web services conference earlier this year, I sat through a talk titled “The Business Case for Web Services.” After listening to the speaker for nearly an hour, I realized that he wasn’t addressing anything close to what his title suggested. When I thought about it, the reason for his omission was obvious: He wasn’t talking about the business case for Web services because there is no business case for Web services. While we in IT are rightfully excited about these technologies, businesspeople just don’t care about them. Here’s why.|
To start with, SOAP and its fellow travelers are clearly infrastructure technologies. How many businesspeople do you know get excited about infrastructure? The closest previous experience we’ve had to a universal agreement on SOAP was the agreement on TCP/IP that jelled some 10 years ago. In the same way that TCP/IP provided easy connectivity among machines, SOAP promises to provide easy connectivity among applications. This is a great thing, but it does not warm the hearts of typical businesspeople. They just don’t care much about technical infrastructure, nor should they.
They do care, however, about the applications that use this infrastructure. The business-oriented arguments that drove the installation of TCP/IP were all about those applications -- e-mail, the Web and others. The argument for Web services is also about applications, whether they help increase sales, lower inventory costs or perform some other useful function for an organization. It’s not about SOAP, WSDL, UDDI or any of the other core Web services technologies.
OK, so what is this application-oriented argument? There’s no single answer to this question, a reality that cuts to the heart of why there is no business case for Web services. Unlike, say, e-mail, CRM applications or data warehousing -- all of which have quantifiable benefits that a businessperson can understand and care about -- the benefits that accrue from deploying Web services are buried within whatever applications use them. Any value that Web services bring is incremental, since there are always other ways to connect those applications. An integration scenario that once used an expensive proprietary solution, for instance, might be able to get away with using just a straight SOAP connection instead. And as integration gets easier, it will also become more common. Hooking together two applications that weren’t initially designed to communicate won’t be such a big deal, so the business process these applications support will be able to change more readily. This is a good thing, and the folks who pay us -- that is, the businesspeople -- like this idea. Yet there’s no business case for Web services per se because they’re not associated with any single kind of application.
Besides, compared to TCP/IP, deploying Web services is cheap. You don’t need to convince anyone to buy routers or other new hardware, and most of the software we’d like to use with Web services has or will soon have built-in SOAP support. Given the minimal investment required, why bother trying to interest businesspeople in what to them is most likely just another dull technology? Like TCP/IP, SOAP is on the way to ubiquity, and ubiquitous infrastructure technologies don’t need business cases. In fact, although I enjoy Web services-focused conferences (I even speak at some of them), they won’t be around for much longer. Like TCP-oriented events a decade ago, they’ll fade away quickly as Web services become a standard part of what we do.
The bottom line is that Web services make it easier for applications to communicate. This is all businesspeople need to know, and it’s all that most of them care to know. I’d encourage you not to bore these folks by laboring to make a convincing business case for Web services. Just use the technology where it makes sense and show the people who run your business how it makes connecting applications easier and cheaper. Then sit back and watch the smiles spread across their faces.
David Chappell is principal at Chappell & Associates, an education and consulting firm focused on enterprise software technologies. He can be reached via E-mail at firstname.lastname@example.org.