Admit it. You were tempted to skip this story because a) you have no idea what Web services are or why you'd need an essential guide to them; b) you're vaguely familiar with Web services and think the topic is so technically esoteric that only your IS department needs to worry about it; or c) you've heard so much hype about how Web services will radically change the way companies do business that you're certain the technology's been vastly overrated.
Well, it's a good thing you've decided to read on. Because Web services do represent a fundamental shift in the way companies build and use software. They can make it easier to link complex business systems, saving your company time and money and, in turn, letting it respond more flexibly to business demands. You must learn the basics about Web services even if you'll never have to write a single line of code yourself because business executives have a crucial role to play in ensuring the success of any Web services strategy. And trust us, you will need a Web services strategy, because Web services won't just fade away.
This story will help you understand what Web services are, how they work, why they won't be the answer to every technology problem and what responsibilities a business executive has in shaping a company's Web services plans. We promise to keep the gnarly tech terms, three-letter acronyms and unadulterated hype to a minimum.
What Are Web Services?
One of the more confusing things about Web services is the very term itself. The word services conjures up visions of people paying for something and getting something back. But at the most basic level, Web services are just a new flavour of standards-based software technology that lets programmers combine existing computer systems in new ways, over the Internet, within one business or across many.
Web services let companies bridge communications gaps between software written in different programming languages, developed by different vendors or running on different operating systems.
An example here might help. The Bekins Co., a Hillside, Ill.-based company that handles logistics and transportation for manufacturers and retailers, relies on a network of trucking partners to ship tons of big-ticket goods coast to coast. It needed a faster and more reliable way to let its trucking partners know about excess freight sitting on the loading dock, waiting to be shipped faster than phoning and faxing. Until recently, getting Bekins' mainframe-based scheduling system to talk to its partners' transportation management systems would have meant painstakingly hand-coding links to each one years of work. Yet by using Web services, Bekins was able to let its system talk to any of its partners' systems and to let those partners talk back over the Internet. And it was able to do that in just three months.
That sounds simple enough. But to add to the confusion, you'll hear the term Web services used in several ways. It describes the overall approach to stitching software programs together and building new systems over the Internet. It can refer to the specific software that links two or more systems; you could say that Bekins "wrote a Web service" to share information with its partners. People talk about the day when companies will be able to "rent" ready-made Web services from other companies and the day when consumers will eventually be able to subscribe to Web services too. What unifies all the term's uses is the notion that Web services run over the Internet or Internet protocol-based networks, such as intranets and are built on a specific set of software standards.
Why Are Web services Receiving So Much Attention?
The technology is drawing such huge hype because it promises to make it easier for companies to integrate software and reuse software that they or others have already built, historically an expensive and time-consuming process.
Why do Web services hold such promise? First, they run over the Internet, which pretty much every company is connected to, and over intranets or other Internet protocol-based networks, which are common inside companies. Second, major technology vendors, including BEA Systems, Hewlett-Packard, IBM, Microsoft, Oracle and Sun, have agreed to support a set of standard software technologies that spell out how different computer systems should interact with each other an unlikely level of cross-industry cooperation.
The Web services approach doesn't necessarily make earlier integration technologies obsolete. But it makes types of integration possible that would have been hellishly complex otherwise. Bekins, for example, first considered using a different computing architecture called CORBA to tie its freight scheduling system to its partners' transportation management systems. But Randy Mowen, Bekins' director of data management and e-business architecture, says he found 50-odd standards that he'd have to follow, and a dearth of documentation. "We kind of abandoned it before we got too far along," Mowen says. "It never really materialized because of the complexity."
How Do Web Services Work?
In contrast with the more traditional means of integration that came before it, Web services offer a more flexible or "loosely coupled" way of linking applications. Think of Web services working like an old-fashioned telephone switchboard. If Mr. Smith wanted to ask Miss Jones out for an ice cream soda, he didn't need a direct wire from his phone to hers; he went through the switchboard operator, who plugged in the connection and then disconnected it when he and Miss Jones were done speaking. Mr. Smith could also use the same technology to call Mr. Johnson at the bank. Likewise, if Mowen's programmers write a Web service that pulls information from Bekins' freight scheduling system, it can send that information to systems at suppliers A, B and C; the code doesn't have to be rewritten for each partner.
Using the switchboard example, in order for people to communicate over the phone, parties on both ends need to agree to use standard telephones, answer their phones when they ring and speak the same language. Web services standards perform similar functions.
The most important of these standard software technologies is XML, or extensible markup language (yes, it is a three-letter acronym, but it's probably one of the most important ones for a business executive to know these days). XML is a way of describing data that masks the differences between disparate software systems and lets them understand each other; think of it as the Esperanto of the computer business. For Web services to work, both sides need to be able to speak XML. (For details on how this works at Bekins, go to www.darwinmag.com/printlinks.)
One important thing to remember is that Web services aren't used to build new systems from scratch. Rather, they're a tool to use with existing computer systems that you want to stitch together to create something new. "You still need your customer relationship management application, your core database, your application servers," says Evan Quinn, chief analyst at the Hurwitz Group, a consultancy in Framingham, Mass. "You still need to have a good infrastructure and rich computing resources. If you don't, Web services aren't going to do much in the business world." So don't ask your CIO if he can use this newfangled Web services stuff to build you a sales-force management system. Ask him if he can use it to let your new sales-force management system tap in to information from the accounts receivable system so that sales reps can find out whether their customers actually pay their bills.
How Are Web Services Being Used Now?
Companies testing the Web services waters generally tackle internal software integration projects first, chiefly because in-house projects are less risky and easier to test-drive. "People will integrate applications, processes, business flow, even content," says Gary Hein, senior analyst at The Burton Group, a Midvale, Utah-based consultancy. At Texas A&M, for example, the IS department wrote Web services that authenticate users' identification; it is also working on Web services that would pull information from several legacy applications and present it over a Web page so that students can check their schedules and their tuition accounts online.
Some Web services pioneers have already started to develop external applications, which use Web services to connect to trusted business partners. Overall, however, it will be 12 to 18 months before most mainstream companies start building Web services that cross corporate firewalls, Hein predicts.
In The future, How Will Web Services Be Used?
Perhaps the biggest Web services hype and the biggest doubts surround future uses of Web services. Vendors and analysts envision a world where companies will list their Web services in public online directories. A company might be able to assemble a whole business by piecing together Web services created and maintained by other companies. For example, a company looking for a way to check the credit histories of its customers could have its order-processing software automatically scan the Web to find companies that offer a credit-checking Web service, figure out which company offers the best deal, negotiate it and then hook up to that company's Web service on the fly even if the two companies never did business together before.
But David Schatsky, research director and senior analyst at Jupiter Media Metrix in New York City, believes that this expansive hype won't become a reality any time soon. Too many technological and business questions remain unanswered: How will security be handled? How will companies make sure that the company delivering a Web service will keep the service up and running reliably? How will companies pay for the use of Web services? Who will be held accountable if a Web service fails to deliver as promised? "Using Web services to dynamically discover and interact with business partners maybe ones that you don't already have relationships with is risky," Schatsky says. And according to Jupiter, it's a risk most companies don't plan on taking any time soon; only 16 per cent of IT managers interviewed said that their companies plan to pursue this type of Web services use by mid-2002.
When Are Web Services a Bad Idea?
Even when it comes to application integration, Web services aren't always a good choice. Let's say a company wants to link two software offerings developed by the same vendor. There may not be any reason to use Web services, Hein says, since those packages probably already know how to communicate with each other.
Likewise, Hein says, the Web services approach isn't necessary if a company is able to dictate certain key parameters that software on both ends of the transaction will use. In other words, if software developers agree that both of the applications to be integrated speak French, there's no reason for them to speak Esperanto. And Hurwitz's Quinn notes that if the applications in question have already been integrated in one way and "you have a new integration requirement between these applications, it would probably not make sense to use Web services. After all, you already have the integration facility and expertise in place."
Another drawback is that today, Web services standards just can't deliver the same guaranteed, high-level, bullet-proof performance that you'd get from traditional business applications. Until they do, you won't want to use Web services in a situation where transaction speed, reliability and security are of the essence. Vendors are working on new specifications to address these weaknesses, but it could be another 18 months before such specifications become standards and get more broadly adopted, Hein says.
What Is Your Role in Planning a Web Services Strategy?
OK, if you're not a programmer, you'll probably never have to write a lick of XML. But there are a few things you can do to help get your company ready for Web services.
Be realistic about how quickly your company needs to implement Web services. Web services won't be something that's hyped and then disappears, Hein says, but the technology hasn't achieved industrial strength yet, either. His advice? Don't rush out tomorrow and insist that the entire company and all its partners change over to a Web services approach. Instead, keep an eye on the Web services market, which he expects will grow in the next year to year and a half, and start experimenting internally.
Lend a skeptical ear to vendors' marketing claims. Vendors will go on and on about how they've had umpteen people involved in the development of XML since 1997, or they were the first to roll out beta code that supports such and such standard. And they'll claim that this has put them way ahead of their competitors when it comes to Web services support. Take those claims with a grain of salt. "It's too early in the development of Web services to make a strategic call on which vendor is the best to wed yourself to," Schatsky says. The best strategy is to work with a vendor that you already have a relationship with until the market matures.
Make sure that your company's up-coming business applications support Web services standards. "Business managers may not make decisions about platform choice, but they do often get heavily involved in the selection of business applications," Schatsky says, such as enterprise resource planning or customer relationship management systems. He advises executives to add Web services support to the checklist of things they'll need from business application vendors most will offer such support by late this year.
Recognize that deploying Web services is as much of a business problem as it is a technology problem. Yes, vendors will roll out more Web services-enabled software and (one hopes) agree on more sophisticated standards. But companies won't be able to point and click away the hard work of deciding which computing resources should be integrated internally, which ones should be shared with partners and which should be opened up to consumers. "Just because you have an easier-to-use technology doesn't mean you change the world's business models overnight," Quinn says. So while the IS department is experimenting with internal uses of Web services, business executives should be thinking about future business opportunities afforded by the technology.
Web services are undoubtedly a work in progress, and the grand Web services scenarios envisioned for the future won't happen without a serious bit of work on the technology side and the business side. But if you start experimenting with simpler Web services now, you'll be in good company and you'll also be ready when Web services really start to take off.
The Basics Web Services
A new flavour of software technology that makes it easier to integrate systems over the Internet or Internet protocol-based networks. Web services rely on the following software standards.
XML (extensible markup language) - A common method for describing data, XML lets programmers write their own tags to identify information in a document and put it into context. Industry groups are getting together to define their own XML dialects. For example, the shoe industry might agree on one tag to represent shoe size, another to represent shoe colour and so on.
SOAP (simple object access protocol) - Describes how one application talks to a Web service and asks it to perform a task and return an answer. SOAP makes it possible to use Web services for transactions say, credit card authorization or checking inventory in real-time and placing an order.
UDDI (universal description, discovery and integration) - A virtual yellow pages for Web services that lets software discover what Web services are available and how to hook up to them. Major software vendors are working together to develop a public UDDI registry that will enable companies to find one another's Web services over the Internet.
WSDL (Web Services Description Language) - If you think of UDDI as a virtual yellow pages, WSDL is the little blurb associated with each entry that describes what kind of work the Web service can do say, that it can give you access to a database of ZIP codes.
Case Study 1
Life Time Fitness
Eden Prairie, Minn.
The business: Operates a chain of 23 "sports resorts" in Illinois, Indiana, Michigan, Minnesota, Ohio and Washington, D.C.
The Web services application: Integrates Life Time's public web site and private intranet with an online scheduling system from Xtime, an application service provider.
The payoff: Life Time's 300,000 members can use its web site to book health club facilities and services, including massages, personal trainers and racquetball courts; customer self-service saves employees' time. Employees can use the same system with Life Time's intranet.
Software partner: Sun Microsystems
Early Adopters
In the next year, how will your organization use Web services? Here's what IT managers say.
60 per cent - To integrate applications behind the corporate firewall
53 per cent - To integrate with external applications of known suppliers, customers or partners outside the firewall
23 per cent - Do not intend to deploy the technology in the next year
20 per cent - To become a provider of Web services to third parties
16 per cent - To dynamically discover and interact with external applications of third parties
Source: Jupiter Media Metrix, from a Jupiter/ERI Executive Survey in June 2001 of 471 I.T. managers
Microsoft Always Has to Be Different
Its grand plan for Web services is no exception to the rule
Microsoft's Web services strategy makes things a bit more confusing for people trying to understand Web services, largely because its strategy is so broad and so different from what other vendors are doing. Known as Microsoft .Net, the strategy encompasses more than just development tools. The Redmond, Wash.-based software giant plans to offer free and paid subscription-based online services for consumers say, ones that let consumers keep a calendar online or get reminders when they need to go to the dentist. Other Web sites will be able to build on those basic services. The initiative, known as .Net My Services, will debut some time this year.
What might the .Net My Services world look like? Here's a hypothetical example: Let's say a consumer subscribes to Web calendar and e-mail alert services from Microsoft. When she goes to the Jiffy Lube Web site and wants to sign up for an oil change at the branch near where she works, the Jiffy Lube site can ask for access to her online calendar. If she agrees, the site could find a free time slot in her schedule, write in the appointment and even arrange to send her an e-mail alert at work the day before. Jiffy Lube would need to pay "some nominal yearly fee" to be certified for and participate in the .Net My Services network, says Adam Sohn, a project manager in Microsoft's .Net platform strategy group. Microsoft also expects other companies to develop similar consumer-oriented Web services. Still, some fear that Microsoft's plan will give it too strong a hold on consumer information.
Case Study 2
Storebrand asa
Oslo, Norway
The business: Provides financial services including health insurance, life insurance, banking and asset management to some 280,000 clients.
The Web services application: Captures employee data from clients' payroll systems, calculating pension amounts and sending the information to Storebrand's mainframe database.
The payoff: Because Storebrand employees no longer need to manually enter and double-check employee information, the application improves efficiency and frees up some employees to do other tasks.
Software partner: IBM
Case Study 3
Fidesic
Bellevue, Wash.
The business: Offers electronic invoicing and payment systems to small and midsize companies.
The Web services application: Connects financial software systems from one company to those at another company.
The payoff: Fidesic takes a paper-based process invoicing and bill payment and turns it into an electronic one; its entire business model is built around the use of Web services to integrate systems across companies and over the Internet.
Software partner: Microsoft
Sari Kalin (skalin@darwinmag.com) is a Senior Editor at Darwin (US).