The gist of my presentation on "ROI of web services" at CNET's Building a Web Services Foundation conference this week was neatly summed up by a joke about sex. I'd been in two minds about whether to use it, but then my co-presenter, Paine Webber's Gunjan Samtani, broke the ice by likening web services to high-school sex ("everybody's talking about it, but practically no one's doing it and the ones who are doing it aren't doing it very well"). From that point on, I knew I wasn't going to be breaking any taboos.
My theme was that web services dramatically changes the nature of ROI (return on investment). Instead of ROI being a tool to justify huge investments in big-ticket projects where the break-even point is far in the future, web services projects prove themselves as they go, I suggested. Because of various factors, a little investment can go a long way, and therefore you should be able to see returns from your web services investments on a continuous basis.
In fact, if the ROI is not instantly obvious without having to sit down and calculate it, you've chosen the wrong project, I argued. Buyers need to recalibrate their expectations. Instead of investing six- or seven-figure sums with no certainty of a return, you should be demanding solutions that deliver ROI for five figures or less.
That's where my analogy came in. In traditional IT projects, I said, ROI has been as elusive as high-school sex: "The question was always, are you going to get any?" But with web services, ROI is more like married sex: "You know you're getting it, but you're always wondering, what can we do to make it better?"
The only exceptions are the infrastructure projects you'll need to invest in to make the strategic move to a service-oriented architecture across the enterprise. But if you start by using web services technologies to achieve quick-hit returns in tactical business-oriented projects, you'll pave the way to justifying the larger investments in infrastructure later on.
I'll be publishing a more detailed document in the next few weeks that covers various issues from the presentation more extensively, but in the meantime, here are a few other quick points:
The best returns come from projects that involve transactional processes that extend outside the enterprise. Why? Because transactional processes tend to be the best defined in an organization, so it's easier to identify where they need improving, and because web services deliver the most benefit when you're linking disparate systems.
In a down economy, ROI is often achieved at the expense of people's job security. When you automate swivel chair integration, remember to think about what's going to happen to the person who used to sit on the swivel chair.
Be prepared for unexpected costs. If we'd known all the figures for total cost of ownership of PCs back in the 80s, we'd never have made the case for switching over from mainframes to client-server.
Continuous ROI evaluation implies real-time monitoring and reporting of costs and benefits. Be careful what you include in your ROI calculations at the start of a project, as they may return to haunt you later on.
The legendary Silicon Valley VC Vinod Khosla is right on the mark about enterprise computing in the web services age. Speaking at DCI's Creating the Real-Time Enterprise conference in San Francisco this week, he laid down a set of principles to follow when building business automation that harnesses the real-time capabilities of a service-oriented architecture:
"Anything you do today is legacy next year." This is the philosophical cornerstone of his proposition. Change is inevitable and persistent. Therefore you must design for continuous migration. "This notion of an architecture that accommodates continuous migration is very important," he told delegates.
Adopt an iterative approach to system specification. "I suggest planning on systems that are always wrong but can be changed very rapidly, that are adaptive. Get something running in 90 days, let users try it, they tell you what's wrong, you can easily change it. Don't make it a massive transformation for the company. Get into a world of rapid modification as an architecture."
"Do a thousand 90-day projects as opposed to one three-year project." Use the encapsulation and componentization capabilities of web services to break up big-ticket projects into more manageable chunks that are much easier to tune to your real-time business requirements. Plus, if you make a mistake in a 90-day project, it's not the end of the world.
"Customization is bad. Everything should be configured." Customization makes your systems inflexible, because every time you need to change something, you need to bring in special expertise and resources to make that change. Whereas configuration builds the ability to change right there into the system itself. "You cannot have adaptability with customization," explained Khosla. "Customization is what makes systems static not adaptable, not changeable."
"Applications should be federated not integrated," he said. "You should be optimizing systems for adaptability and flexibility. Optimization doesn't matter if your requirements change and in the real world, they change all the time. Federation is the key, not integration ... We need to go beyond app servers into application services and an application assembly environment, and using all the application services to build composite apps."
"The real-time enterprise is about an economic, not a technical goal. It should be a discussion at a CFO and a CEO level. It's not about what IT you have. It's do you want to increase your revenue per employee in your enterprise per year? ... It's not simply the architecture for software, it's the architecture for the enterprise."
There's much, much more about Khosla's thinking on the real-time enterprise in a white paper (PDF, 154k) he co-wrote with Murugan Pal, VP technology strategy and product management at Asera, which is the Kleiner Perkins portfolio company Khosla has been focussing the most of his attentions on in the past couple of years.
Asera has a lot of experience under its belt of working with this kind of architecture, and it has its own proprietary solutions. You could almost say that Asera is the Bowstreet of composite applications, although of course that is a double-edged description. Both companies are heavily VC-funded startups backed by well-known visionaries who identified a trend very early in its development. In the case of Bowstreet, that trend was web services. Asera started a little later and picked up the trend toward application assembly. But Asera, like Bowstreet, may have got in the game a little too early for its own good, and as a result has perhaps ended up with an over-complex and expensive offering.
All the same, you can't fault the vision. I found I had virtually no points of disagreement with Khosla's presentation. He has identified and articulated a whole range of concepts that speak directly to the practical concerns of enterprises that want to achieve more responsive and adaptable business automation. I expect to be quoting him a lot more from now on.
posted by Phil Wainewright 2:38 PM (GMT) | comments | link
Thursday, December 12, 2002
Standards within standards
Even technology standards are starting to form into fractal patterns, I've learnt this week. Standards were very much on the agenda at CNet's Building a Web Services Foundation conference in San Francisco on Tuesday. But I found the roundtable session, where representatives of four industry bodies were quizzed about web services standards, not very illuminating.
The session attracted some press attention because an audience show of hands demonstrated an overwhelming majority in favor of having just one standards organization. Personally I felt the question had been loaded to get the answer, a bit in the form of "Who thinks web services standards should be simpler?" Sure, we'd all like an easy life, but if you want to get anything done, it normally takes effort, and web services standards are no different. I sided with WS-I's Tom Glover, who pointed out that having multiple standards bodies meant no one interest group could dominate: "If you hear all of us singing in unison, you should be a lot more confident that it's an answer you can trust."
But the highlight of the day for me was a private chat with Winston Bumpus, who is VP of standards at Novell and a participant in a long list of standards initiatives, including acting as president of the Distributed Management Task Force (DMTF). If you have technology geeks and policy wonks, then I suppose the sum of all these activities makes Winston Bumpus a standards gonk.
Winston made a couple of points that I found intriguing:
Standardization on the basic building blocks of web services has created an architecture that other standards can now build upon. His specific example was in creating models for instrumenting services, which as he pointed out is a key first step towards effective services management. Because the web services architecture is already componentized using standardized interfaces, the management specifications can use those interfaces rather than having to start from scratch.
One of the finest examples of an agreed set of semantics within an industry just happens to be the Common Information Model (CIM) for identifying components of an IT infrastructure. All of this conjured up a fractal-like image of standards-within-standards repeating the same patterns at different orders of magnitude.
Although often overlooked, systems management (or in this case, services management) often gets to be the first arena where leading-edge principles being discussed in IT get put to the test. It seems that's certainly going to be the case in web services management and it will be interesting to keep tabs on it.
The most important element of a decentralized network is neither at the edge nor the center but wherever the clients are. Discussions this morning at the Supernova conference in Palo Alto (from where, thanks to the wonders of WiFi wireless broadband, I am writing this) have emphasized the client, but have also made the mistake of assuming that the client always resides at the edge. This is misleading because it is still thinking in terms of the network having a clientless center.
Without clients, there would be no network. There would be nothing but an inert technology infrastructure. The network consists of its clients. Therefore it is meaningless to talk about the 'edge' of the network (except in the limited technology sense of reaching the end of a cable). There are clients all over the network. Some of them are servers, some of them are peer devices or client appliances. Most of them are not machines at all, they are people. They participate in processes that stretch across the network. Collectively, they are its center. But typically they don't act in a homogenous way; they act in a decentralized way.
This creates problems as well as opportunities. Mike Helfrich from Groove Networks made this point: "There really isn't a central point of failure in a decentralized network." That's an advantage, of course, but it's only true because there isn't really a center at all in a decentralized network. Just as it won't easily fail, so for the same reason it won't easily be controlled.
Howard Rheingold, the author of Smart Mobs: The Next Social Revolution (among other achievements), opened the morning with a presentation that took as its theme the notion that, "Every time power is decentralized, new kinds of opportunity arise for all kinds of collective action." But in the discussion that followed, several contributions explored the dark side of this statement, which Bob Frankston neatly summed up with the comment that, "We're concerned about the power of the corporation, but the one thing scarier is decentralized mob rule ... Not all groups that act collectively have beneficial aims in mind."
In fact, human history has shown that the most efficient mechanism of change is anarchy the ultimate in decentralized social organization. The challenge of decentralization is harnessing its creative power without descending into irretrievable anarchy.
Another contributor complained that collective decentalized action is never sustained: "We've never successfully slashdotted Congress". The reason why that's the case is that people need to care enough to form a mob, and that commitment is rarely sustained. The only way to achieve sustainable collective action is to establish an institution. Is it possible to create institutions that are decentralized in nature? Probably yes, now that we have the technology. But we probably haven't yet developed the cultural skills we'll need.
posted by Phil Wainewright 12:20 PM (GMT) | comments | link
Assembling on-demand services to automate business, commerce, and the sharing of knowledge