Web services technologies blow the doors open for true service-based software to take hold and sweep the planet as the Next Big Thing in computing.
Software and applications as we know them today disappear into the digital ether to be delivered by featureless machines humming along in dark closets, buried in bunkers, redundant, protected, hyper-cooled, the epitome of operational efficiency and scale.
The Velcro-like nature of these XML-networked services will allow applications to be pulled apart and put together interchangeably to create new collaborative tools.
Computing undergoes the third major phase of its evolution, from mainframe to client/server to distributed network, the computing platform for Web services. Web services will open new opportunities and create new services and products that help businesses become stronger and more profitable at what they do.
All of this is so exciting and new that few have paid much attention to sticky issues like security, intellectual property, profitability and the very words we use to talk about these things--the little things that will make or break it.
You say tomato; I say Web services
First off, the term "Web services" is an unfortunate one because it doesn't reflect that Web services is both a business model and a technology architecture. This may sound more like a gripe than a legitimate roadblock, but it's actually hurting adoption because a lot of intelligent people can't talk about Web services for more than ten minutes and still be talking about the same thing. To the average developer, Web services is still just an interesting, new frontier with very indistinct features.
That's about to change, but for now let's get our terms straight. "Web services" means two things. First, it's a business proposition in which companies package and sell their business process applications by combining them with others and making them available to partners and customers via the Internet. Second, it's a technology proposition in which distributed computing reaches the masses.
This happens through developers using a framework that replaces the desktop application paradigm with a software as a service paradigm, shifting focus from code engineered for the client desktop to XML information exchanged over networks. Programs created with Web services tools and emerging interoperability standards such as SOAP and UDDI make it easy for developers to remove technology barriers to integrating disparate, otherwise code-bound, platform-dependent applications.
This brings us to the second hurdle to widespread adoption of Web services--concerns about security. If the Web services strategy creates an architecture that enables collaborative applications to work together, how will businesses protect their data, their applications and their intellectual property if it all lives on a fluid, decentralized network?
Microsoft's Passport identity service stores sensitive consumer information on Microsoft's servers. Consumers are wary of giving up control over their personal information. Similarly, IT departments are apprehensive about moving sensitive company information offsite, let alone loosing it onto the Internet. There are data privacy issues around e-mail, finance data, CRM, accounts payable and the like, all of which contain sensitive information that could ruin a company if not protected.
Businesses will need to be careful and deliberate in locking their applications down and encrypting sensitive data to avoid attacks. They will soon have entire business processes--not just transactional information--residing on Web servers. They will need carrier-class security that isolates their data. They should also perform a full security audit and risk analysis before moving any business processes to Web services.
There are other reasons businesses need to be careful when making public the very things they've used to build their best core business practices. A company that uses Web services technology to "productize" an internal tool--a killer CRM analytics application, for example--could profit by offering the tool to customers or other businesses directly via its Web services or through incorporation with others. However, this company is exposing a key component--a proprietary portion of the guts of how it runs its business--to the world. And this is the third challenge Web services faces before it will be widely adopted: intellectual property issues.
One of the great promises of Web services is the ability to easily take your best technology, capturing your core competencies, and make it available to your customers and partners for use in conjunction with other applications. But the digital world's issues with intellectual property rights are far from settled and about to get massive.
To participate in Web services, companies must be willing to publish their application programming interfaces--the layer of XML that allows developers to create composite applications. This could be problematic; it's not difficult to deduce what a product can and cannot do by examining its interfaces. By publishing an interface on a network as a Web service, a company gives thousands of customers--and potential competitors--access to it. The company will have to weigh the benefits against the risks of doing this.
Finally, there are the bottom-line issues of payment and profitability. Microsoft and other major industry vendors have already begun to deliver powerful Web services technologies to the market. With this wave of new technologies and the rush to the Web services business model comes the need for a real-world revenue model.
It's not clear how Web services will allow service partners, which in a couple years is going to be just about every major company with a Web site, to fairly share revenue for composite applications. In the new collaborative commerce world of Web services, you may be dealing with half a dozen companies and partners delivering a single Web service, without clear boundaries around revenue sharing and who gets paid and when.
It may make self-evident business sense for a company to subscribe to a CRM analytics Web service through the same ASP (application service provider) that provides its teleconferencing services, but how will the service provider measure and bill competitively for the company's usage? How will the provider simultaneously and transparently charge for its bandwidth, divide revenue between the companies whose Web services make up the analytics application, and build in payment to the credit card company that helps it charge for the service?
These issues will have to be resolved before the Web services world will become a reality. For companies to deliver their offerings as Web-powered application services, they will need a way to share revenue--pay what they owe to the Web services companies, hosting facilities and other partners. They're going to need some kind of XML billing technology that can join cross-platform with existing systems to provide the missing ingredient--profitability--in collaborative commerce.
Looking back from our vantage point, hosted applications were the first step toward Web services. They didn't live up to their initial promises because of the cost and complexity of integrating and maintaining them. That shouldn't be a problem with Web services. But the ASP model has provided the foundation for the spontaneous creation of services that will emerge from them fully formed and ready. Hosted apps are to Web services what the caterpillar is to the butterfly.
Online exchanges were basically just a dating service introducing business partners. Matching services and buyers is one thing. Matching business partners to create new services is what XML-based Web services can be. It is something altogether different, and it's going to take a different set of business rules to make it work.
Web services offer nothing less than the potential to transform the way people use their computers and the way businesses use the Internet to reach their customers and collaborate profitably with partners. The companies that think intelligently and creatively about the bigger picture will appreciate what it means.