Too Bad About the Name
One of the great shames of Web services is its moniker. It's a dumb name for which we can thank some boffin in engineering at Microsoft. It fails at every level to describe itself adequately, and yet it appears we are now saddled with it. To make matters worse, the technologies required for it to work are a hodgepodge of unattractive four-letter acronyms, such as SOAP and UDDI. It just isn't a concept that lends itself to anyone but a hard-nosed technologist, yet the business benefits can be substantial.
In organisations large enough to support a CIO and a dedicated IT staff, a Web services project will most likely be under way. It may be only a skunkworks, or perhaps a small-scale experiment aimed at providing a demonstrable benefit to a unit within an enterprise.
The debate about whether Web services will take off finished two years ago. As a legitimate technology strategy, it has definitely left the tarmac. Now, it is just a question of how it will fly and the time it will take to become a ubiquitous communications media between computer systems and the occasional human. It has the basic platform to be successful: A mass of vendors supporting the technology, a number of high-profile adopters, such as Google and Amazon.com, plus analyst ratification that this is not another industry mirage.
The pitch for Web services is simple; that it is simply an evolution of technology not a revolution. The analysts at Gartner are particularly keen on parroting this phrase, and executives from vendors such as IBM and BEA are happy to re-quote Gartner's carefully crafted statement.
But it is a strategically delivered understatement.
The analysts and vendors know you won't buy into another revolution, not after Y2K and that whole dotcom catastrophe. No one but Dubya is into revolutions nowadays. Yet, if you stack up the analyst numbers in terms of what Web services technologies can provide in terms of efficiencies, especially when it comes to driving down software development costs, then this appears to be a startling advancement. Five years ago, they'd have been talking revolution.
Time Is Money
Stephen Mills, who works on IBM's Websphere team, says that in a Web services environment only a third of the code is needed for an application development project because of the commonality of other code to ensure interoperability. And the time to deploy should be reduced by 20 per cent, too. Figures from analyst IDC support that view, even claiming that a heterogeneous Web services world would make programmers almost twice as productive.
A logical conclusion from all this might be your commitment to code-cutting staff would reduce, they would not need to be so skilled and, therefore, could not demand the current level of wages.
"The budget to integrate applications is one of the largest buckets of IT money as organisations strive to achieve a single view of the customer," says Mills. "Web services creates an environment where software packages such as Siebel and SAP can talk to each other through a set of common protocols. In the past, you would have had to develop a $500,000 'hub and spoke' architecture for the same outcome."
Protocols are built into applications now to make it all happen, he says. "It is simply another blade on your Swiss Army knife."
At a most basic level, we will begin to slowly see Web services pull down the walls of proprietary systems in the back office. The key platforms to achieve this will be Microsoft's .Net and J2EE. The software protocols fuelling the flames are WSDL, which is the interface, while Microsoft's SOAP acts as the messaging protocol and XML is used at the common language, a digital Esperanto. The other common acronym is UDDI, which is a directory to find companies with Web services, but up to this point it is little used.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.