Culture

Commentary: Ten tips for killer Web services

Forrester experts synthesize the best and worst practices of early adopters into tips for business and IT managers to avoid common pitfalls and build killer Web services.

Commentary: Ten tips for killer Web services
By Forrester Research
Special to CNET News.com
January 7, 2003, 4:00AM PT

By Ted Schadler, Principal Analyst

In 2004, many firms will put customer-facing Web services into production. But will those services be successful? We've synthesized the best and worst practices of early adopters into tips that business and information technology managers should follow to avoid common pitfalls and build killer Web services.

Fifty-seven percent of the companies Forrester recently interviewed plan to deploy customer-facing Web services in 2004. The timing is good. After all, in August 2003, Web services standards reached a milestone when the 170-member-strong Web Services Interoperability Organization (WS-I) approved a test suite to certify that your customers can use your Web service as easily as they can use your Web site. But will your customers use it? You'll increase the chances by building killer Web services that:

• Solve clear business problems
The more painful and visible the problem, the more likely your customer will use the Web service rather than an existing manual or proprietary connection. For example, Amazon.com uses Web services as the back-end link to its retailers. And if the service generates revenue--the way NEC Solutions customer Kodak Japan's Print@Kodak Web service does--so much the better.

• Make your customers more productive
The best Web services will give time, money or flexibility back to your customers.


Get Up to Speed on...
Web services
Get the latest headlines and
company-specific news in our
expanded GUTS section.


Instead of staffing up the call center to report laboratory results, a hospital network in King County, Wash., is using a Web service to securely deliver lab results directly into physicians' hands. This service hits three goals: faster turnaround, cheaper delivery and convenient access.

• Can be used without modification by many customers
Instead of building a service to the first customer's spec and then customizing it for each new customer, spend time up front with four customers from different segments to understand the data and processes they need. This upfront time helped uBid, an online auction house, build Web services that multiple auction aggregators could immediately use to post inventory--without changing the way the service works.

Six tips for business managers
Business managers can build "business" Web services to provide low-cost, high-intimacy services to their customers or suppliers. But to take advantage of this technology without stumbling into common traps, business managers must master the intricacies of yet another electronic channel. To avoid these trips, killer Web services borrow heavily from successful Web sites--E*Trade Financial and Google, for example--built jointly by an IT-aware business team and a business-focused IT team. Six tips will ease the move to business Web services:

Tip 1: Focus first on business integration
In 1998 and 1999, business executives were fired up with the transformational potential of business-to-business technology. Alas, the technology wasn't ready. But in the past four years, business integration technology has matured in the form of Web services, and sophisticated companies like Southwest Airlines, Amazon and the RouteOne auto-financing consortium have used the technology to implement B2B business models.

RouteOne, for example, is using Web services to do auto loan processing for 22,000 DaimlerChrysler, Ford Motor, General Motors and Toyota dealers. It's a B2B dream come true. Many of the e-business projects that were on the table in 1999 are possible now, with technology that is robust, mature and cheap.

Tip 2: Give away simple Web services to important customers
This "keep it free, stupid" tip overcomes three common barriers: 1) simplifying the business case; 2) fretting about security and trust; and 3) deciding how to get started. By giving your best customers power over an order status query, price and availability check, or production schedule, you will uncover the issues and avoid misplaced investments--while putting money in your pocket and your customer's pocket. And as a bonus, you will help customers use this low-cost electronic channel and not your high-cost manual channels.

Harley-Davidson, for example, uses Web services to tell partner Ticketmaster that a ticket buyer is a HOG--a Harley-Davidson Owners Group member--deserving of a merchandise discount. Over time, you will gain confidence in the technology, hear what else your customer or supplier wants from you--and how much they'll pay--and what other customer segments you can profitably serve.

Tip 3: Do your homework before building billable Web services
Companies with established electronic channels--Galileo International and Sabre Holdings in airline booking, LendingTree in loan processing and WebMD in health care claims routing--have already established pricing and billing mechanisms for value-added Web services, usually priced for each transaction completed. But many new services won't be transactions, so they'll therefore need new billing models and mechanisms.

Firms will have to gain experience and conduct a market analysis before putting a price on an enhanced order status query service, a lab-results reporting service or a regulatory filing service. When thinking about the pricing model, be sure to consider the complexity of measuring and billing for the service, and anticipate a rapid ramp up in demand for the service. Supply chain visibility vendor BridgePoint's first Web service had 500 times more hits per month than the firm had anticipated.

Tip 4: Master the art of the reusable business document
A good business Web service looks more like a purchase order than a function call. To build business Web services, business and IT managers must start by asking what the customer needs--then cross-check the data, process and business terms with three more potential customers to build a service "big enough" to handle 80 percent of requests. Be sure that the service is described in your customers' business terms, carries all the information needed to process a request, and is instrumented for billing, reporting and exception handling.

Tip 5: Don't let security paranoia interfere with good business sense
Web services put critical business data on the wire. And that makes security architects quake. But too often, the fear that data might get into the wrong hands prevents business managers--and the IT executives who support them--from thinking clearly and economically about the security concerns. This fear should sound familiar to executives who once worried about using their credit card to buy a book from Amazon.

The simple fact is that Web services for trusted customers and suppliers in an invitation-only network can be secured using the same technology your Web site uses. Instead of letting security concerns stop a Web services project cold, smart business managers will borrow a page from J.P. Morgan Chase's playbook and build security risk into the business case as an expense.

Tip 6: Put a power meter and steering wheel on every Web service
What good is a business Web service without a way to measure and control it? After all, when shipping status information is flowing over the wire into your customers' procurement alert system, you can no longer rely on Ralph in the warehouse to tell you when a delayed shipment is about to ruin your best customer's day.

To avoid building "dark" Web services that are invisible to all but the most dedicated data center operator, be sure to demand visibility, accountability and hands-on control over the service. Once the Web service is in operation, make sure that you will be able to get answers to questions like: Who's using the service? How often are they requesting it? How many requests succeed? How many fail? You must free up the budget to build these control tools.

Four more tips, for IT professionals
Business Web services--like corporate Web sites--are chock-full of new technology. IT professionals must step up to the table alongside business managers to hash out the details--service definition, operating metrics and business controls--of each project. To fulfill their end of the bargain, IT professionals must master the disciplines of service-oriented architecture and new service-oriented infrastructure technology to secure, control and administer the XML traffic that will fly back and forth between applications--and between businesses. Early adopters offer four tips:

Tip 7: Establish a Web services framework and design review process
Because Web services are delivered over the Internet, they can go from just-built to massively adopted in an unbelievably short time. To get out ahead of that adoption curve and give developers and project leaders a Web services tool kit that will keep every Web service in a consistent, service-oriented architecture, the Web services team should:

• Start with the WS-I Basic Profile
The WS-I will ship a test application in the first quarter of 2004. This test suite and guidelines give firms a starting point and a guarantee of WS-I compliance. One caveat: The critically important SOAP (Simple Object Access Protocol) with Attachments implementation won't come from the WS-I until later in 2004.

Adopt different templates for internal and external Web services. Internal Web services often don't require the same level of security and control as do supplier- or customer-facing Web services. Lydian Trust, a back-office provider to LendingTree, provides an internal-only template, but it then requires an extensive review and "hardened" external template for business Web services exposed outside the firewall.

Build a developer portal for design-time assistance and review. This site will make it easier to offer developer tools like templates and clarify the review process. Be sure to include some useful services to show how it's done, a training guide for the templates and a downloadable SOAP client for testing services.

Tip 8: Master the Web services life cycle
A Web service is a software application that must be built, deployed, and operated--and, of course, improved over time. This application touches service developers, provisioning managers and network operators, all of whom need tools in each of five distinct stages in the Web service life cycle:

• Design time: Help developers build loosely coupled Web services
Developers need new tools to apply the programming model of the Web--asynchronous communication, very late binding and a use-only-what-you-need protocol stack--to this new business integration. The service requirements of business communication--reliability, latency, throughput--must be addressed in the design cycle by network engineers.

• Publication time: Implement a "service management" system
As with critical business documents, business Web services must be vetted before being published. Managers need a work flow-based approval process and service registry to keep tabs on which services are ready to be used.

• Connection time: Give connection managers security and provisioning tools
Developers shouldn't be burdened--or trusted--with security implementations. Instead, security, addressing and performance policies should be set up when a new connection--a link between a requesting app and a service--is provisioned.

• Runtime: Instrument XML networks with in-band and out-of-band controls
At runtime, IT operations must manage message flows, exceptions and service instances in real time as well as handle reporting, audits and billing offline. The key to doing this is having centralized policy management and distributed policy execution.

• Revision time: Use a registry to implement a generous upgrade policy
When creating a new version of a service, it's important to keep the old service running until all requesting applications are using the new service. The solution to this customer satisfaction challenge is a service and connection registry that keeps track of who's using which version of which service.

Tip 9: Choose a Web services platform as a foundation
Because business Web services require a new layer of applications, they can--and should--live in a separate software tier. To get the most consistency and leverage from skills, tools and servers, IT shops should pick a single Web services platform--from BEA Systems, IBM, Microsoft, Oracle, Sun Microsystems, or perhaps WebMethods or SAP. All of these application platform suppliers can host Web services applications, albeit often with remarkably different architectures. The simple choice is to use the same application platform for Web services that you use for your Web applications.

Tip 10: Use specialty tool kits to extend the foundation
A large number of vendors--start-ups and established players alike--provide specialty tool kits to fill the gaps in Web services platforms. It's too early to easily rank these specialists. Limit your investigation to the specialists with strong partnerships with your Web services platform supplier, and ask them for references on your platform. Narrow the fields by choosing several specialists with the tool kits that solve your biggest problems, and do pilots with each of them.

• Secure connections
These vendors specialize in securing the XML traffic between a service requester and a service provider. The implementation will vary, based on the network topology--an XML firewall can secure the perimeter; an agent, proxy or broker configuration can put security close to the application.

• Data and process interchange
To get the most use out of a service, you must often morph the message slightly to match the data format, transport protocol and process the context of the customer. Use a specialist to do this at the perimeter rather than build every permutation into the service itself.

• Message control
Routing messages to the right service is the sweet spot of Web services management specialists. These vendors also offer security, interchange and business administration features, but they're best at message routing.

• XML processing
If throughput is your biggest challenge--often the case in large-volume applications over the public Internet--use a specialist that can process XML messages at wire speed in a dedicated hardware appliance.

• Business administration
Business managers need visibility into what a service is doing. The foundation of visibility is efficient message logging and a robust tool kit for reporting, notification, auditing and monitoring. Web service management specialists do this today, but not all do it equally well.

© 2003, Forrester Research, Inc. All rights reserved. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.