Technology that works

Real-life examples are starting to emerge of web services delivering results that users actually want. This is technology, once famously defined by Brian Ferren as "Stuff that doesn't work yet," nudging up against the cusp of becoming stuff that works so well, we take it for granted. It's not completely there, but it's getting closer.

I saw another fine example described yesterday at Butler Group's Web Services and Integration Symposium in London. What impressed me the most was that it used the technology to automate existing working practices as unobtrusively as possible. This I think is the key to successful deployment of web services, and it was a theme that recurred in several of the morning's sessions that I attended.

The case study showed how web services had been used to automate the purchasing process in a British hospital group, Bradford NHS Hospitals Trust. This is an environment full of the kind of real-world challenges that often defeat technology-driven solutions:

• Many of the prospective users have never touched a PC in their lives, let alone used a web browser


• The organization's network infrastructure is overstretched and unreliable


• The existing financials system and online interfaces to suppliers are due to be upgraded in the near future


• Purchasing has critical dependencies relating to patient care, such as scheduling of operations.

The solution was devised by KPMG Atos Consulting (formed by the acquisition of KPMG UK and Netherlands by Europe's third-largest IT services group, Atos Origin). Based on Microsoft .NET, it uses web services to deliver role-specific catalogues to iPaq handheld PCs, on which nurses, doctors and related staff can prepare requisitions, check order progress and administer user priveleges. The web services interface was essential to enable the communications to the wireless devices in a way that supports disconnected working, explained KPMG ATOS Consulting's David Whatley.

Implemented with a simple client interface that requires just a two-hour training session before staff are up and running, the system has automated a formerly fraught and inefficient process in a way that is easy for staff to pick up and integrate into their exisitng working routine without disruption. It provides an immediate win by reducing unpredictability and waste in the purchase-to-pay process, while at the same time winning staff confidence in a new technology platform that can be used later on to roll out more sophisticated capabilities in fields such as patient care.

The speaker that came after, Macromedia's Andrew Hindle, opened his session with the declaration, "I'd like to talk about web services in the context of human beings," and I think that's a great rubric to keep in mind when discussing web services. In an earlier session, Oracle product manager David Keene had presented one of those slides that shows the evolution of the Web, starting in phase one with person-to-person communication in the form of email, followed in phase two by server-to-person information publishing once websites arrived, and finally reaching the third phase of applications, enabled by automated server-to-server links, based on web services.

Of course, this is usually presented as an upward progression, with each step adding more automation and less human intervention. But the people haven't disappeared, have they? They're still there, initiating the processes and responding to the results. Every one of those three phases is about person-to-person interaction, and the progression that is taking place is a deepening of the automation within those interactions. Technologists have a habit of thinking that the more automation there is, the less they have to worry about the human element, but that's completely and utterly wrong. Unless you have the human interaction front of mind from beginning to end of your application design, you will end up automating processes that bear no relationship whatever to the real world.

What I realized by the end of yesterday morning's sessions was that it's the client side of web services deployments that matter the most. Yes, you need the infrastructure, you need the management. But the only way you'll provide real utility is if you deliver automation that users can simply and easily assimilate into their daily routine. That's why Macromedia's rich internet client capabiliities are so important, along with XML-based links into Microsoft Office, and various other client-side tools and capabilities that are starting to appear. Web services are not just about what happens on the servers. If they're going to be any use to anyone, the applications have to go all the way to the users.
posted by Phil Wainewright 2:34 PM (GMT) | comments | link

ROI of web services

I will be speaking on this topic at CNET's Building a Web Services Foundation conference in San Francisco next month. ROI is a hot topic in IT at the moment, but there are signs that the advent of web services is changing the groundrules. That should be good news, but inevitably there is a downside if you're not on top of the changes that are taking place.

The session is on Wednesday 11th at 10.15 am, as part of the ROI of Web Services stream being led by Gunjan Samtani, who is VP of Information Technology at UBS PaineWebber. Gunjan recently gave a preview of his views in a TechRepublic interview republished on ZDNet, and was lead author of the chapter on ROI in Web Services Business Strategies and Architectures (originally published as a white paper on WebServicesArchitect). It promises to be a lively session.

I won't pre-empt my presentation by saying any more for now, but here's a brief selection of ROI-related postings and articles I've published here and on ASPnews over the past six months:

• A good time to adopt web services "... the extra flexibility that comes when you assemble component-based web services in a loosely coupled configuration introduces a third dimension ... "


• The Future's Bright For ASPs That 'Get' It "... achieve remarkable returns on investment (ROI) — not just a few percentage points, but double, triple or orders of magnitude more than their investment ... within a web services-based framework."


• Web services stall big spending "... companies are doing a lot with web services, but they're doing it without having to buy expensive new releases from software tools vendors."


• Fear and loathing in web services "... customers will implement web services in projects where they can carefully measure incremental return on investment step by step."

This will be my first visit to California for more than a year, so I'll be doing quite a lot of catching up with contacts, both new and old, while in San Francisco. I usually find that I never get round to see all the people I mean to see, but if you're reading this and thinking it would be good to meet that week, please drop me a line.
posted by Phil Wainewright 6:55 AM (GMT) | comments | link

Serious spending for on-demand services

Delivering software-based services on demand is hard. At last, it's going to get the investment it needs. IBM is setting up a new research division called On Demand Innovation Services, with a reported annual budget of $1 billion.

As I mentioned in my ASPnews column this week, IBM is no stranger to the notion of on-demand computing. It's been helping ISVs service-enable their software for more than four years, under its ASP Prime program (later renamed xSP Prime, and now apparently subsumed into the broader on-demand computing strategy). But for many years, ASPs suffered from a lack of commitment from industry leaders to really invest in developing the technologies, standards and infrastructure that this form of computing requires. Now at last that's going to change.

I've been getting some serious bouts of deja vu in the past week or two as IBM has started rolling out its on-demand strategy at the same time as the spotlight starts to turn on web services management. It all sounds familiar because the ASP industry confronted (and flunked) all the same issues years before. Here's what I wrote in a February 2001 white paper (an updated version of points I first started making in August 1999). Does any of it sound familiar, by any chance?

"ASPs and other pioneers of Internet computing discovered the distinctive requirements of online delivery as soon as they first moved applications out of enterprises into their own external data centres. Even that single first step throws up unexpected complexity, stretching architectures in very different ways than traditional LAN-based, client-server computing. The challenges quickly mount up:

• Internet scale — They must scale to tens of thousands of users instead of hundreds, and operate consistently across 24x7 hours, not 9-to-5


• Internet connectivity — The unpredictable open Internet replaces the known parameters and closeted security of the LAN


• Multiple customers — Customers using shared resources still demand the same standards of security and load balancing they would enjoy in a dedicated facility


• Multiple configurations — With no means of enforcing standard clients across separate organisations, providers are forced to manage diverse user profiles and configurations


• High-volume infrastructure — Serving the needs of those diverse populations with economies of scale demands new forms of automated infrastructure management


• Commercial service provision — They have to deliver all of this within a service level agreement, and issue an accurate, auditable invoice at the end of each month

"Yet this is only the beginning; the consequence of moving computing just one step away from the enterprise into shared data centres. Each of those data centres has a high-speed, direct connection to the Internet backbone, putting it just a few short router hops away from a vast array of external services delivered by a multitude of like-minded providers. Suddenly software finds itself directly plugged in to an efficient wide area network infrastructure where inter-system collaboration rapidly becomes the norm. Solutions are formed out of multi-tiered partnerships in which hosting providers, managed services, ASPs, trading exchanges and information portals meld their services together into an apparently seamless whole. The management complexities notch up several orders of magnitude in sophistication, while software itself takes on a completely new character."

posted by Phil Wainewright 1:02 PM (GMT) | comments | link

Realizing the value of management

Web services management is deservedly making headlines, as its sheer complexity begins to dawn on people. As Bowstreet founder Frank Moss told a meeting in London earlier this year, if you thought managing client-server was hard, just you wait till you see what it's going to take to manage web services. The distributed component model expands the requirement by orders of magnitude. Having previously run systems management giant Tivoli before selling the company to IBM, this is someone who knows what he's talking about.

Venture backers of companies like AmberPoint and Confluent Software, both of whom recently announced substantial second-round funding wins, have been smart to get behind early leaders of this new field. The market may become the preserve of big-name companies later on, as ZapThink's Jason Bloomberg asserts in his new report, published yesterday with impeccable timing, Service-Oriented Management: How Web Services Management is the Key to the Service-Oriented Architecture. But I suspect they'll have to pay quite large sums to get their hands on some of the key intellectual property and market share before they can do that. IBM, remember, ended up paying $1 billion for Tivoli.
posted by Phil Wainewright 8:14 AM (GMT) | comments | link

Shades of loose coupling

Doug Kaye has made a valiant effort to pin down what loosely coupled actually means by setting out a table of contrasting attributes between tightly coupled and loosely coupled systems. It is a valuable contribution in the vital quest to arrive at a clear and communicable understanding of these concepts. But it is equally important to avoid giving the impression that there can ever be a single, perfect definition that can be applied universally. This is not a black-and-white concept, it is one that consists only of shades of gray.

There is no absolute, perfect state of loose coupling that can be held up as an example for everyone to aspire to. Instead, there are an infinite number of degrees, ranging from not-very-tight-coupling all the way to almost-completely-decoupled. The absolute end point of that continuum is not coupled at all — it is detached, permanently disconnected, standalone.

Thus the ideal state of loose coupling for any given system can only be defined in relative terms — it is to be as decoupled as is practical in that specific application context. Since the context for most enterprises today is that the vast majority of their IT systems and business practices work on tightly coupled principles, the only practical course presently available to them is to loosen that coupling in small, incremental steps. This is where Doug's table becomes invaluable, since it will help to pinpoint the areas in which looser coupling can most readily be achieved.

Having taken those early steps, a further round of loosening then becomes possible — and so on, through multiple iterations. In practice, therefore, the ideal loosely coupled state is going to remain a moving target, always a few more steps away from the degree of loose coupling that you have already achieved.

After a seemingly endless succession of these iterations, you may eventually reach a point where you do indeed reach the perfect state of loose coupling for your specific business situation — but only fleetingly. In a loosely coupled environment, the business context will be constantly shifting, so that however much you've defined and understood the concept, you'll never be able to predict with absolute certainty when you're going to arrive at that destination. And as soon as you've got there, the target will move again (you may even find you've overshot it, and need to tighten up again). That's why it's not enough just to know the definition of loosely coupled — you really do need to be able to recognize it when you see it, and be able to tell whether what you see is working for you.
posted by Phil Wainewright 3:45 AM (GMT) | comments | link