Down to the Numbers
Say you're ready to pitch the idea of using Web services, but you need to justify the initiative via an ROI model. One readily apparent return is in lower costs over the development life cycle versus conventional software-development techniques. Unfortunately, this is a cost savings model; you won't bring in hard dollars, so this particular justification may be less than successful in convincing financial types to take advantage of Web services.
However, implementing Web services also decreases the time it takes to deploy a B2B solution. Business agility can be as concrete as the ability to perform just-in-time switching to the lowest-cost supplies based on availability of a particular product component or as abstract as the ability to immediately react to changing market conditions.
There are a number of factors to consider in the ROI equation:
• Costs: hardware, software, training, bandwidth
• Business Payoffs: end-user productivity gain, participation in dynamic business, better and cheaper customer service, collaborative business activities
• IT Payoffs: software-development automation, streamlining of middleware, use of standards-based integration, reusability of code
A sample ROI model for Web services is: ROI= (Business Benefits + IT Benefits - Costs) / (Costs + quantifiable risks) * 100
Quantifiable risks are nebulous. One oft-used example is the fact that Web services standards have not been finalized and continue to evolve; the cost of potential redevelopment should be factored in as a quantifiable risk. Let's take a hypothetical situation: You want to use Web services for supply-chain management, specifically to order the parts you need to make your widgets based on availability and lowest per-part cost. Assuming your hardware and bandwidth are sufficient to handle Web services, you still need software. A reasonable estimate is $20,000 for the platform and developer seats and $30,000 for training.
If you've determined that Web services will increase developer productivity by 10 percent, and for each 1 percent productivity increase you save $25,000, the total benefit is $250,000.
You may be asking, "Why is bandwidth in that equation? I get the rest, but bandwidth?" The move to Web services means an increase in both the payload being exchanged and, most likely, the number of exchanges on a daily basis. A SOAP request and response is considerably larger than its HTML-form-based cousin (see "Fatter Payloads, Bigger Bulge" at right). You may need to increase your current bandwidth capacity to ensure timely receipt and delivery of Web services traffic.
If diving in isn't an option, you can phase in Web services. Start with isolated implementations, then move to developing the core services used throughout the organization, then slowly migrate critical applications to a Web services architecture that takes advantage of existing services. The best way to achieve a high ROI on these implementations is to do up-front work on common services across the organization and then build those services one by one until you can reimplement existing applications based on Web services.
|
By The Numbers
In a recent Peerstone survey asking about Web services:
• 102 of 191 respondents said Web services would be of "fundamental importance" in the way software applications are built and deployed at their organizations
• 74 of 172 respondents now use Web services to make functions or data contained in major packaged applications--for example, ERP, CRM, supply chain--available on their e-commerce sites or portals for suppliers/customers/partners
• 102 are thinking about or actively experimenting with using Web services in this way
|
The Endpoint
If you do take the plunge, do so cautiously, paying close attention to security and standards. The benefits, both short and long term, are tangible, and eventually you'll be forced to get on and ride whether you want to or not. Most software vendors, especially in the enterprise application market, are moving toward Web services and eventually will remove the ability of your developers to interface with these critical applications in any way other than Web services. Indeed, many software vendors are moving rapidly in that direction, having grasped the benefits of a service-oriented architecture that decreases the cost of their products in terms of support, both from an API and a customer viewpoint. But do not underestimate the dangers: Make sure your infrastructure is capable of supporting the bandwidth and security needs of Web services. Start with something noncritical and work through all the bugs before moving forward.
Ultimately, business process management/workflow standards such as WS-Choreography and WSFL (Web Services Flow Language) will help you turn your enterprise into a lean, mean automated business machine, capable of turning on a dime and turning that dime into a dollar.
For further product updates, ongoing insights and more information on Web services, please visit our ongoing Project Weblog at blog.networkcomputing.com/webserv.html. Our review of six Web services platforms can be found here.
Lori Macvittie, a Network Computing technology editor, has been a software developer, network administrator and member of the technical architecture team for a global transportation and logistics organization. Write to her at lmacvittie@nwc.com.
Post a comment or question on this story.
RSS
