Open Standards and Powerful Protocols

The technology of Web services uses the open communication standards and software standards to let businesses obtain pieces of an application solution from vendors across the 'net. Just as a Web site may be composed of multiple pages that exist separately on any server connected to the Internet, so too Web services can pull together many application pieces from a variety of vendors (as applets) and stitch them into a comprehensive and cohesive application solution. It enables customers to embed those pieces--to mix and match them--within their own Internet-enabled applications. The pieces are customizable and configurable, letting customers meld together bundles of services into a seamless Web-enabled application at a price that is substantially smaller than the cost of in-house development. Development time is cut to a minimum, while functionality of the applications soars. It sounds like the perfect solution to the high cost of Web-application development.

A very good white paper on this technology is entitled "Your Next IT Strategy." In this white paper (published by the Harvard Review, freely available through IBM's Web site at http://www.ibm.com/services/ondemand ), authors John Hagel III and Seely Brown map the compelling technical reasons for Web services.

(Click image to enlarge)

At the foundation of Web services are the standard communication protocols and software standards, such as XML and SOAP, that let information exchange easily between applications. Above the foundation are sets of services, called service grids, that provide shared utilities to enable security, billing, and auditing, and users interact in a trusted environment. On top of the service grid, specific application services reside, providing things such as credit-card processing or production scheduling--you name the process, and you can bet that a Web services component for it is available or soon will be.

Not only are the services modularized, but each specific application service has a potential to be fully customizable, allowing the customer a full range of functions that may make a completed Web application completely unique. Like a large mosaic composed of individual tiles, the Web services architecture is designed for quick deployment and modular development. It's precisely the kind of "You-gotta-see-it-to-believe- it /You-gotta-have-it-once-you've-seen-it" technology that is designed to win the imagination of every CTO and COO of the Fortune 500.

Pathways for SMB: WebSphere vs. Web Services

For IBM, there is a special allure in creating a Web services architecture based upon IBM's WebSphere middleware. Why? Not only do Web services reinforce the WebSphere brand's "integrate everything" message, but they also creates a marketplace for services that can be sold downstream through the IBM value chain.

For instance, if your company can't directly afford to develop a complete IT infrastructure with the IBM WebSphere packages, you will still probably be able to afford to purchase Web services from IBM Business Partners who have based their solutions upon the WebSphere brand. And this raises an interesting question: If Web services are designed to be so powerful, why would an SMB even bother building the WebSphere programming infrastructure at all? After all, why build your rapidly evolving IT infrastructure when you can rent or lease significant parts of it right off the 'net?

Easier Than Rolling Your Own

Indeed, if you squeeze an IBM WebSphere marketing representative long enough--asking him how a small or medium-sized organization could possibly afford all the WebSphere modules--you will very quickly hear him squeal, "Web services! Web services!"

Consider. For most SMB customers, the cost of investing directly in all the WebSphere products for developing in-house Web applications is daunting. Though the individual price of the different WebSphere modules is quite competitive, the combined overall investment when all is said and done will easily swamp most SMB IT budgets.

More importantly, however, the cost of training WebSphere developers in small shops is incredibly high by SMB standards. This is not because XML, UDDL, or WSDL is all that difficult, but because the SMB developer community hasn't cultivated these newer required skills and has very few education dollars to spend. By comparison, Web services implementation is a snap--or more accurately, a point-and-click. Learning to integrate Web services follows a simple configure-and-go kind of scenario. Compare that learning curve with learning the vagaries of XML, UDDI, or WSDL, and the choice is easy to make.

Web Services Is the Better Business Deal for IBM Solutions Providers

But most important of all is how IBM solutions are expected to arrive at the door of the SMB. IBM fully anticipates that most small and medium businesses will be purchasing their customizable solutions directly through the IBM Solution Provider channels. Web services are one of the feature mechanisms by which those highly customizable solutions will entice SMB customers.

Consequently, IBM doesn't really expect CTOs or CFOs of the small or medium-sized organizations to really embrace WebSphere or its long return on investment. Instead, it expects IBM Solution Providers to deliver WebSphere through their packaged solutions and customers to use Web services to customize and tailor those packages to their needs.

Great Expectations

But is this a reasonable expectation for WebSphere and Web services? Indeed, an informal recent survey of midrange CFOs confirms this: Most SMBs will accept whatever technology their IBM Business Partners bring to their doors, as long as the solutions fit the needs of the company and the price is right. They want the most bang for their buck, and they trust IBM Business Partners and Solution Providers to deliver it. They want neither the complication, nor the expense, nor the confusion of new technology to delay their overall business plans.

ASP Meltdowns: A Cautionary Tale

OK! So IBM says Web services are the wave of the future for the SMB. But is this the right technology for the SMB market segment? A quick review of recent application service provider (ASP) history may show the flaw in Big Blue's thinking.

Four years ago, the industry was touting ASPs as the most effective technology for relieving software development costs for SMBs. ASPs were to be the wave of the future, remember? And indeed, many new ASP services in standard application flavors--like payroll, collaboration services, and invoicing--proved to be very cost-effective solutions for the smallest of the SMB market.

However, as the stampede to Internet gold began to stumble, so too did the support of many well-financed ASP companies. Customers who got caught under foot while ASP collapsed were often left trampled, with no option by which to continue their IT applications. Many found themselves on proprietary platforms with no clear point of transit to newer services. Worst of all, some were caught with their pants down and their data held hostage as the lines to their technical support dwindled and the doors of their chosen ASP creaked closed.

Dream Weaver or Nightmare Builder?

Now consider the implications if a similar debacle were to occur in a Web services environment: pieces of applications that no longer functioned; embedded support that suddenly disappeared. Indeed, while the promise of Web services holds many of the finest IT dreams for Internet enablement of custom applications, it also may hold the germ of a real IT nightmare. So much will depend upon the Business Partner relationships that support the applications that the customer's IBM Business Partner delivers. And that places new responsibilities upon both the Business Partner and the customer alike.

That's why it will be wise for small and medium-sized businesses to go slowly with Web services technologies, whether they are derived from WebSphere, Microsoft .NET, or any other software platform. It's not the technology that will define the success or failure of this intriguing and powerful new environment, but the maturity of the business relationships, over time, that support this burgeoning technology.

Thomas M. Stockwell is the Editor in Chief of MC Press, LLC. He has written extensively about program development, project management, IT management, and IT consulting, and has been a frequent contributor to many midrange periodicals. He has authored numerous white papers for iSeries Solutions Providers. His most recent consulting assignments have been as a Senior Industry Analyst working with IBM on the iSeries, the mid-market, and specifically on WebSphere brand positioning. He welcomes your comments about this or other articles and can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..