The IT Strategy Letter
A digest of Doug Kaye's weblogs
for the week ending October 14, 2002
(Subscribe)
|
Out of the Box--Strategies for Achieving Profits Today and Growth Tomorrow through Web Services [This week, a special edition dedicated to a review of John Hagel's latest book. I shared an early draft of this review with John, who generously took time to reply. Where he convinced me of his opinions, I've preserved some of my original comments for the sake of encouraging debate and to further illustrate the issues.] Whether you tend to agree with him or not, there's no doubt that John Hagel III has become one of the most influential business/technology strategists of the dot-com-and-beyond era. Last month, accenture ranked him 67th on their list of Top 100 Business Gurus. I first became aware of John in 1997 when I read his book, Net Gain (co-authored with Arthur G. Armstrong) that addressed the concept of virtual communities. As part of a management team then building an on-line dating service, I found the book both inspirational and distracting--a reaction I've now come to expect to John's writings. John continues to write important books aimed squarely at the current hot topics. He did it again in 1999 with Net Worth (co-authored with Marc Singer) all about infomediaries. At that time I was developing just such a business, and again, I was both inspired and distracted. And now here he comes with Out of the Box, just as I'm trying to finish my own book on web services. John is always a few steps ahead of the rest of us. Why distracted? Because John gets us thinking beyond our current concerns. He straddles the line between strategist and futurist, and he's good at both roles. But the reader's challenge is to separate the solid strategy from the hypothetical futurism. It's often hard to find the boundaries in John's books, and the latest is no exception. In fact, the subtitle warns us to expect it: Out of the Box--Strategies for Achieving Profits Today and Growth Tomorrow through Web Services. (We cut futurists some slack, and only expect them to be right half of the time. For example, those venture-backed pure-play infomediaries are all dead. With perfect hindsight, we can see why, but in 1999 I drank the Kool-Aid along with everyone else.) This is not a technical book. It's for business managers. If you want to learn anything technical about web services, look elsewhere. The book has four parts, each emphasizing a high-level strategy.
I'm not going to tell you all I agree with in this book. There's too much. But I'll use this opportunity to point out the few themes with which I take some exception to John's positions. The Service Grid John believes that the "...functionality delivered by the service grid [will] be provided by specialized utilities," specifically these third-party service providers. "All of this functionality could be provided by software utilities installed within the enterprise. Managers who choose this option, however, must wrestle with significant complexity, both in terms of the implementation of the software and then in terms of the management of regular updates of functionality...Take the example of security services...in the absence of a service grid [security] would need to be dispersed across each enterprise. Even very large enterprises would have difficulty building the depth necessary to ensure world-class security capability." If that was the case, we wouldn't be using network-layer firewalls today. Instead, we'd all be accessing the public Internet through EDI-style value-added networks (VANs) whom we'd be paying to manage security for us. Many of the elements of the service grid can be delivered as well or better by software or appliance vendors. Application firewalls or XML proxies are no harder to maintain than today's network firewalls. To the extent they require development of extensive application-specific rules, those tasks are equally as demanding when implemented by third-party services. There's no reason we can't plug rules into our own firewalls rather than dictating them to suppliers who then enter them for us. In a subsequent discussion with John, he expressed two concerns: First, that it's to everyone's advantage to reduce complexity and cost at the end points of the connections and to concentrate it in shared services that are better equipped to leverage economies of scale and scope. I see his point. But I wonder if it's not a temporary phenomenon. Once the standards are in place, won't the solutions become commoditized and easily packed as appliances? As I wrote back in early July, I expect the horizontal technologies of the service grid (the center layer of my web-service pyramid) to so migrate over time, forcing the web-services networks to work their way higher up the pyramid. John's second clarification about the importance of the service grid is particularly interesting as it relates to this evolving role of service providers. He pointed out the value (and cost) of learning. "No matter how well defined the rules are," he said, "there will always be exceptions--this is where much of the complexity and cost is concentrated. The opportunity is to create robust feedback loops regarding exceptions that have occurred so that rules and practices can be further enhanced to reduce exceptions. Service grid providers will see a broader range of exceptions than any individual company will see and they therefore have a potential to accelerate learning and refinement of policies and practices in a way that would be difficult, if not impossible, for any individual company to replicate." [I took the liberty of quoting a private communications from John because I just couldn't think of a better way to say it.] By the way, readers should consider that John was a founder of 12 Entrepreneuring, the incubator that gave birth to Grand Central Communications, the quintessential third-party service-grid providers. I'm not suggesting any conflict of interest--indeed John's consistency is a virtue--but there are viable alternatives to fleshing out the service grid. The "Where to Start?" Question John has been leading the charge for companies to focus their initial web-services efforts at the edge of the enterprise. He's repeatedly said and written that this is where companies will realize the greatest benefit in the short term, and throughout the book he makes a convincing case to support his argument. On one hand, the arguments are anecdotal, based on case studies such as Dell, who undoubtedly has achieved tremendous benefit from their efforts. Does this apply to all companies? I suggested that only companies that are the 800-pound gorillas of their markets or companies whose businesses are dedicated to supporting one such gorilla can make the case for a positive ROI from such external web-services projects today. On the other hand John has now studied over 60 production web-services implementations, probably more than anyone else, and he's convinced that not only is this what companies are actually doing, but that it makes sense because it's where the distinctive advantages of web services today are most pronounced relative to previous generations of technology. John does caution against having unrealistic expectations, but he doesn't go far enough. "Precisely because not all elements of the technology architecture are in place today, business managers must be realistic about what is achievable with the current state of the technology. They must map out a migration path based on an objective assessment of current capabilities of the architecture. They need to avoid initiatives that depend on elements not yet available." If you're one of those 800-pound gorillas, by all means mandate the XML business semantics for your suppliers and/or channel and reap the benefits today. But most companies aren't in this position, and I think it's important to consider that for such companies the R in ROI may not exceed the I at this time. Remember, the cost of investments in web services will decline sharply over the next few years. There's a tremendous risk of investing in external projects too early. [Take a look at my so-called O'Reilly Curve, an early version of which I published in April. It illustrates how ROI can be dramatically improved by delaying the start of a projects in situations where development costs are declining rapidly.] John questioned why my argument doesn't equally apply to internal projects. It's because more of the costs associated with these simpler projects have already declined, whereas many of the problems unique to external projects (those addressed by the service grid, in fact) are still complex and expensive to solve. By definition, the service grid exists only to meet the needs of external web services. ISVs Racing? I'm not sure about that. They're doing so, but only to keep up with their competitors. Indeed, web services represent a substantial threat to the entrenched ISVs, for web services will undoubtedly lower the barriers to entry for any upstart companies that want cherry-pick opportunities to replace functions of major application suites on a module-by-module basis. ISVs certainly fear such a commoditization of applications and components. Web services are a classical disruptive-technology catalyst. Gems
It's important to remember that like any other hard-copy book, Out of the Box was subject to publication lead times of many months, and in this rapidly changing world of web services, that can be an eternity. I urge you to visit John's web site and check out his more-recent working papers. In Out of the Box, John Hagel continues his string of stimulating and distracting writings. This is the best to date, and because it's not specific to the world of e-commerce--or perhaps because e-commerce now is the world--this is the book I suspect will appeal to the broadest audience. |
|
|
The IT Strategy Letter is published weekly by Doug Kaye. The content is identical to Doug's weblogs.
| Options: |
Subscribe |
|
|
|||||||||
|
