Web Services Strategies
Vectors to the Holy Grail
Now at the start of the 21st century, web services are poised
as the next technology to change the way we link businesses. It
seems as though web services have appeared suddenly, just as the
transcontinental telegraph appeared to have been instantly created
at the moment its eastern and western wires were joined. But web
services haven't burst onto the scene any more quickly than FAX
or email. Like the telegraph, email, and FAX, web services are
the result of many decades of invention.
Twelve vectors--a collection of both successes and failures--have
converged at this one point in time and space to bring life to
web services as illustrated in the figure below.
There's long been a search for the Holy Grail of data communications:
that perfect technology for linking all systems, large and small,
wired and wireless. Ask any CIO or CTO what he or she wants in
this regard, and you'll probably hear something like this:
- to link to any organization, anywhere in the world, but with
only a single connection to the network;
- to communicate with all business partners using just one universal
set of protocols, documents, and business processes;
- to communicate securely, reliably, and without concern for
scalability (i.e., the volume of usage);
- to use the same technology to communicate within the organization
as is used externally;
- to loosely couple organizations so that they don't need to
know the internals of one another's business processes or technologies;
- to be able to reuse data and processes in order to reduce
- to be able to change components or swap out one for another
without breaking anything; and
- to make money by providing data and services to others over
It's a long list, but it isn't new. Look at the list again, but
this time, consider how each objective applies to the FAX machine.
Then read it once more with the telegraph in mind. You'll have
to bend a few definitions here and there--they didn't use the
term business processes in the days of the Pony Express--but the
concepts haven't changed. The list has been fulfilled by every
successful generation of data-communications technology. The list
remains the same as the technologies continue to improve.
For example, there's always been a data communications network,
even if it was based on a relay of riders on horseback. Likewise,
it's always been important to have a single connection to the
network, in whatever form it might be. Western Union made certain
you could walk into one office and reach someone located near
any other office. Today, with one FAX machine connected to one
telephone line, you can reach any other FAX machine in the world.
What CIOs, CTOs, and those with other titles decades before them
have tried to do hasn't changed. The objective remains the efficient
linking of organizations. What's new is that web services are
the first technology that promises to achieve this objective in
the 21st century, by directly linking our computer systems via
the public Internet.
Why was this objective so elusive? What were the missing pieces?
Was the Internet the only catalyst we've needed to discover this
Holy Grail of computer-to-computer communications? If so, then
why haven't we been doing this since the mid 1990s when the Internet
first got our attention? What have we been waiting for? If not
the Internet, was it the invention of XML, the eXtensible Markup
Language, that's been universally adopted as the basis for web
services? Is that the missing piece? Why now? And why all the
Like the splicing together of the eastern and western wires to
instantly create the transcontinental telegraph, the arrival of
web services was preordained by the convergence of a number of
technological developments and economic and political events.
We'd been trying to create the equivalent of web services for
many years, but it wasn't until all the planets came into alignment
that web services suddenly appeared--as if out of nowhere.
[The above is an excerpt from Chapter 1: Evolution of
Missing Pieces of Web Services.]
U-Joints for Integration. John McDowall has been thinking about integration, and points out that some of the best minds recommending web services still don't understand the benefits of loose coupling. "We should not mistake the pressures to interoperate for the pressure to integrate. It might be harder initially to design and implement interoperable interfaces but in the long run the loosely coupled results will allow more sustainable systems to be built."
Posted Monday, March 03, 2003 5:43:38
Interoperability: Not Yet. With all the hype surrounding the standardization of web services, you'd think that linking systems based on Java and .NET would be a straightforward process. But no. Even after two years of web-services developments, interoperability remains a challenge. This article by Daniel Savarese in JavaPro magazine confirms what all of my clients tell me: crossing the J2EE/.NET boundary still takes a lot of work.
Posted Sunday, March 02, 2003 11:15:13
Chris Stone on Novell. You'll find this interview with Chris Stone, essentially Novell's CEO, to be frank and insightful. You'll get a good sense of what's happened to Novell over the past few years, where Chris is trying to take the company, and the obstacles he's got to overcome. [Source: News.com]
Posted Thursday, February 27,
2003 5:33:44 AM
CIO Priorities: Reducing Costs Isn't #1. CIO Insight magazine recently surveyed nearly 400 CIOs, and while many questions are only of interest to the respondent group, others are of more general significance. With all the talk about tight budgets and pressure to reduce costs, I was intrigued to find that cost reduction was only the top priority for 6.0% of CIOs. Here's the complete list:
By a 3:1 ratio, CIOs consider "making the enterprise more adaptive, flexible, and faster" to be more important than cost savings. All the more reason to think of the business-agility benefits of web services as the primary objective, and that leads to loosely coupled services as the place to focus your attention.
- Aligning IT with the business: 31.7%
- Making the enterprise more adaptive, flexible, and faster: 18.4%
- Developing strategies that leverage new technology: 13.6%
- Ensuring security and business continuity: 11.9%
- Ensuring projects are completed on time and on budget: 10.1%
- Reducing costs: 6.0%
- Helping to launch new products or lines of business: 5.2%
- Ensuring systems uptime: 1.8%
- Recruiting, retaining, developing staff: 0.3%
Posted Tuesday, February 25, 2003 6:51:11
Making Web Services More Flexible. David Chappell and Tony Hong are trying to get programmers thinking about creating loosely coupled systems in this article in XML & Web Services Magazine. The pitch: SOAP over JMS.
Posted Tuesday, February 25, 2003 5:35:22
Web Hosting Strategies
Monthly. The latest (March) issue is now online. This
month's articles include:
Posted Monday, March 03, 2003 2:26:31
- The Emergence of Server Virtualization
- HP: Virtualization a Step Forward
- Why You Need a Business Play
- DMCA: Protecting the Providers
- Finding the Sweet Spot (my column)
- Heightening Internet Security
When 100% Uptime Isn't. In this story reported on WebHost Directory, EDS claims to be the first hosting vendor to offer 100% uptime. I'm fairly certain that's not true, as I've worked with other vendors (including at least one major one) who have previously made such guarantees. But the real irony of the 100%-uptime claim is that it comes with a time-to-repair commitment. Wait a minute--If a system never goes down, why should there be a time-to-repair?
No, it just appears that EDS is just offering a good, aggressive SLA, including penalties that kick in after as little as one minute of downtime. Don't take the 100% uptime SLA to imply that your systems will always be up. That's just hype. I could offer you a 100% uptime SLA, even though my box seems to go down at least once a week. The real substance is the aggressiveness of the penalties and the vendor's ability to meet the agreed-to service levels. Oh, and the price you pay to achieve those levels of service.
Posted Tuesday, February 25, 2003 2:56:33
and Contact Info
The IT Strategy Letter is published weekly by Doug Kaye.