- Critical Success Factors for Web Services
- Seven Critical Success Factors
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Seven Critical Success Factors
Whether you opt to start with an internal or external project, experts suggest you adhere to the following recommendations for working with Web Services:
Frame the project in terms of how it can optimize business processes, not just on its technical merits. As Shirley Foster, vice president of engineering for Wakesoft, explains, "What we saw in the component-based development world was the creation of technical components that provided some standard way to gain access to data or provide some other technical functionality. But the critical success factor for any kind of service interaction is the service portion of it. A service needs to have functionality that provides a business value, not necessarily technical value. And the first step toward that is providing process-level or business functionality reuse."
Wetteman concurs: "I was at a conference in the U.K. not long ago and everyone was excited about what Web Services could do from a technical perspective. But what they should be focusing on is how Web Services can support the business strategy."
Leverage existing business rules in the enterprise. When focusing on the business processes and business value, it pays to look at how you can reuse the most valuable and relevant business rules that exist in legacy systems. According to William Ulrich, president of Tactical Strategy Group and a member of Flashline's Software Development Productivity Council (SDPC), "People have been writing computer code for 40 years in many of these companies. That means they have a large wealth of potential software that can be reused as Web Services. Finding and using those business rules may be somewhat difficult, but recreating those functions from scratch is extremely expensive and risky." After all, notes Ulrich, the people who are writing an organization's new software components are likely to be less familiar with the legacy business rules than are the people who developed them originally and who may be still involved in maintaining those systems. Ulrich notes that using a repository for cataloging and managing software assets-such as components and business rules-can make it considerably easier to identify key business rules for reuse.
Implement a phased approach, starting with the most simple, obviously useful projects. "You want to focus on quick and easy pieces first so you can test your developers' skills and the ability of Web Services to do what you need," says Wettemann. She suggests beginning with projects that can demonstrate a tangible benefit within three to six months. These projects might include simple customer or employee self-service projects, such as making back-end functions available via a user-friendly interface. "People are going after the low hanging fruit first, trying to solve the most obvious or simplistic problems," explains Ulrich. "Order processing is an example of low hanging fruit. If you have an order processing system and you can clearly see the rules you want to recreate, then you might create some front-end order processing capabilities."
Keep the team small. A September 2002 study by analyst firm Gartner found that many companies are launching Web Services projects that involve only a handful of developers. Gartner recommends that projects not exceed eight developers, preferably fewer, unless your organization is unusually committed to Web Services deployment.
Don't assume Web Services work well for everything. "If I have a connector that works well with my SAP system, then that would probably be a better choice than trying to do the same thing with Web Services," notes Wettemann. Another example: If you've got all your applications on the same platform, you probably don't need Web Services. As Christensen explains, "If you've got every application running on Windows computers, there are already mechanisms for integrating those applications using .NET and COM. Web Services would simply impose additional overhead."
Also, he notes, some services are simply too complex to construct using Web Services. "You don't want to be making many, very small calls using Web Services, because that's going to take more time to marshal all the parts of the process. You should consider which types of calls are best converted into Web Services and which ones would be better off implemented with typical RPC methods."
Develop a shopping list of key tools. Generally, there are three categories of software tools that an organization will need in order to create and maintain a Web Services environment.
A Web Services layer, which may be a standalone development environment or may be built into the application server. If you have a heterogeneous environment, or aren't sure that you will always want to stick with your current platform vendor, then you might do well to purchase a Web Services environment that is not tied to a specific vendor's application server, advises Christensen. "If you use a vendor-specific implementation, you will be locked into how that vendor handles Web Services on the back end. That gets into issues such as how SOAP headers are processed and how incoming SOAP requests are associated with the back-end environment. Some vendors, for instance, use JNDI [Java Naming and Directory Interface], while others might use a form of Java beans discovery. There are a number of issues involved in translating Web Services calls into the back-end environment, so be leery of vendor specific enhancements that lock you into that vendor." For example, he notes that in BEA's WebLogic Server 7.0, the Web Services run-time is tightly integrated with the WebLogic Server security framework, tying a company's security model to BEA's product and making a future switch in platform more difficult down the road.
Web Services management and monitoring tools. "You will want to be able to sit at a console and look at what's going on with your Web Services environment, gather usage statistics to monitor the load on the servers and tell you how much additional load is placed on the environment by Web Services traffic," explains Christensen.
A repository or directory for categorizing and managing Web Services. Such a repository might be based on UDDI (Universal Description, Discovery and Integration) or another organizational scheme but must be able to aggregate information on the various Web Services throughout the organization. "The types of metadata that may be useful include the WSDL (Web Services Description Language) associated with the Web Services component, performance characteristics of the service, known limitations, error handling, and diagnostic procedures," explains Wayne Lim, an author, consultant and also a member of the Software Development Productivity Council founded by Flashline.
Don't base your ROI strictly on short-term savings. While the measurement of success for most IT projects these days has been on short-term ROI, the fact remains that some technology initiatives should be undertaken with an eye toward future competitiveness and long-term growth. This is the case with Web Services. While initial projects should, as a practical matter, be aimed at achieving some useful, measurable, business benefit, there should also be a longer-term, broader strategy involved.
As consultant Jim Fisher of The SequenceGroup explains, "For internal projects, such as pilots and other point solutions, the real benefit may be in the software licensing savings, with the tangible dollar savings being the lower cost of the Web Services software versus the alternatives. However, the experiences and knowledge gained from small internal projects can be applied to larger initiatives later on. Initially, I believe an ROI for a Web Services project can be calculated in the same manner as with traditional ROI projects. However, Web Services provide other opportunities down the road. And as more applications take advantage of Web Services, the payback could potentially skyrocket."