Many companies are reluctant to deploy Web services, having heard scary stories about security threats and half-baked standards. Still, a number of IT departments are moving forward--some slowly with pilot projects and others more aggressively. This most recent CIO magazine has an article on Web services early adopters and why they're keen on the technology. The highlighted organizations include Motorola, the US Navy, and Wells Fargo. Samir Desai is Motorola's CIO:
"This is about increasing the throughput, agility and cost-effectiveness of IT," says Desai. "How many times should I code a credit card check? With Web services the answer is one. In the past no one really knew the answer, but it was a much, much larger number." Merely by automating standard transactions, Web services promises to save a huge amount of effort and money.
The article goes onto list five risks and discuss how they can be mitigated. I've listed the risks from the article below, but the commentary is my answer to those risks.
- Web services isn't secure.
First step, buy and XML firewall (I've got a review on three XML security firewall products coming out soon). Next understand that Web services and other emerging technologies break down the traditional secure perimeter and require a move to a more holistic digital identity strategy. Companies that can build a digital identity infrastructure won't see Web services security as a problem, they'll see digital identity as an opportunity.
- The lack of standards breeds complexity.
I don't think lack of standards is as big an issue as the fact that there are still issues that need to be resolve and that will lead to new and different standards over the next few years. I'm still trying to figure out how this is different from the world of 3-4 years ago when there were no standards for decentralized computing. The way to mitigate this risk is to use a good Web services intermediary that can provide insulation from changing and emerging standards.
- Vendors might go out of business.
Which brings us to the fear that once you pick one, they might go out of business. That's a real fear since many of these vendors are small start-ups and there's a whole pack of them. At some point there will be a market shake-up and we'll get down to just a few. First step in mitigating this problem is to look carefully at the company and choose vendors who you believe in as a business. If they do go belly-up, make sure that standards protect you as much as possible by not using proprietary features without understanding the upside potential and the risk.
- Adoption by partners is unpredictable.
Again, Web services intermediaries provide some solace here. Most of these products will translate your Web services transactions into whatever system they happen to be using. If partner integration is a big issue in your deployment, make sure you understand what their needs are and pick and intermediary product that will provide the right adaptors to make things work.
- No evidence yet for enterprise ROI.
ROI is a great tool, but I think that business that use ROI on a project by project basis miss some real opportunities for innovation. That's not to say that you want to just start spending money on whatever looks fun this week. You will need to consider some soft gains and long term benefits to create a case. Creating a Web services infrastructure is about moving to service oriented architectures and moving away from some of the traditional IT infrastructures that we've used in the past. You can't create an ROI for that if all you look at is the cost and benefit of the next project. How much are more agility, increased code re-use, better business-technology alignment, etc. worth? Maybe nothing. Maybe everything.
My advice to organizations is to stop sitting on the sidelines, pick one or two good pilot projects, and move forward. Once you've got that experience, you have a decision to make: are we going to make service oriented architectures (SOAs) part of the way we do business? if the answer is "yes" then the next tasks involve more than technology. You've got to build an enterprise architecture that supports your move to an SOA. If you don't, the dream of interoperability is just that, a dream. Interoperability can't be achieved within your organization by the mere existence of external standards. You've got to decide which which standards apply, how they'll be used, and by who. You have to build a framework around those standards that show how they're used inside your organization. Once you've got a reasonable interoperability framework, then Web services can become part of how every project is built and designed and inform every infrastructure decision. until that point, you're bound to be underwhelmed by a few sideline projects that just happen to use SOAP.
