A tale of two ITs

An article in the latest issue of Harvard Business Review is a sign of "the backlash sweeping through executive suites against IT spending," writes John Hagel in his weblog yesterday. The article, by HBR editor-at-large Nicholas Carr, is called IT Doesn’t Matter. John has got together with his frequent collaborator John Seely Brown to write a rebuttal, which will appear in July's HBR, but in the meantime John's weblog summarizes some of the key points in the forthcoming article. One point that leapt out at me from John's summary was this excerpt:

"... previous technology innovations began to stabilize and commoditize as a dominant architecture emerged (eg, think about the standard railway gauges that helped to connect tracks and establish a national railway system). We have yet to see a dominant architecture for IT emerge. In fact, we believe we are on the cusp of another major shift toward a true distributed service architecture that will represent a qualitative breakthrough in terms of delivering more flexibility and fluidity to businesses."

I think this is a key point and one that demonstrates the perils of citing historical precedents. Carr backs up his assertion that IT's innovative phase has run its course by referencing the commodotization that set in after the early development of the railroad and electricity industries. But neither of these are accurate antecedents for what we now see happening in the IT industry.

My preferred analogy for the current development of IT is the emergence of personal transportation, led by the invention of the motor vehicle at the turn of the last century. Because the motor vehicle was a form of transportation that operated in a much more loosely coupled way than the highly structured and centrally controlled architectures of the railroad system, it was able to deliver benefits to some early adopters even when the public road infrastructure consisted of little more than country dirt tracks and cobbled city streets.

As time went on, the incremental development of public highways and then a national network of high-speed freeways led to this upstart innovation finally displacing the pre-eminence of the inflexible railroad system. Innovations continued to reinforce and expand the utility of personal transportation, ultimately leading to a complete restructuring of manufacturing industry through the introduction of just-in-time delivery practices, which would never have been feasible without the on-demand flexibility of the distributed personal transportation system.

Loosely coupled architectures enabled by web services are going to bring the same waves of incremental innovation in IT — and in business — and the only IT that is going to be shown up as not working is the highly structured and centrally controlled architectures of monolithic, enterprise-scale computing systems, whose design philosophy owes more to the values of the industrial era than to the needs of the emerging information era.

Unfortunately, as I noted recently after listening to a debate on the potential value of investing in web services, "Businesses have had so many false bounces in the bear market of IT expectation that they just can't bring themselves to buy any more." John is right to speak of a "backlash". In many organizations, that backlash is going to throw out the baby of distributed services innovation along with the stale bathwater of inflexible enterprise-scale computing, just at the very moment when businesses should be buying into the new distributed architectures.

The problem here is that there are two separate information technologies today, just as in the early years of the last century there were two forms of transportation. In making that assertion, I am of course alluding to another HBR article, Marketing Myopia, by Theodore Levitt, which first appeared in July 1960. Levitt's article made the seminal observation that the railroad companies declined "because they assumed themselves to be in the railroad business rather than in the transportation business."

Today, the IT industry is led, and has its agenda set, by companies who believe themselves to be in the enterprise-scale software business. What they don't yet realize (or perhaps are helpless to do anything about — see Disruptive Technologies: Catching the Wave, by Bower and Christensen, HBR January 1995) is that actually they're in the distributed process automation business. If they and their customers don't adjust rapidly to their new market environment, their destiny will be to end up as a minor footnote in a future article in HBR about the astonishing decline of the one-time giants of our present-day IT industry.
posted by Phil Wainewright 2:42 PM (GMT) | comments | link

Concrete doesn't bend

You can't build agile businesses out of inflexible material. Yet surprisingly, there's no shortage of IT suppliers still proposing that customers attempt just that with their IT systems. The latest proposition of that nature to catch my eye comes this week from Unisys, which Network World reports has just launched a business process consulting service.

Under the service, called Business Blueprints, Unisys consultants will "design a blueprint of a particular business process using modeling tools ... Clients are able to then decide which parts of the blueprint need to be custom developed, which parts they can pull from existing assets, and which ones they can tap into from a library of business process components offered by Unisys." Forrester analyst Mike Gilpin tells Network World that the emergence of standards like BPEL4WS will encourage "more and more vendors" to start offering similar services. He cites IBM and webMethods as examples.

The trouble with this kind of story is that it reinforces completely wrongheaded conceptions of what BPEL is really about. Business process modeling has been around for quite a long time, and its traditional use as a pre-development tool is a completely different usage than the real-time business process orchestration and management that BPEL is designed to enable.

What Unisys is offering is an opportunity to pay their consultants to model an expensive, inflexible way of automating your processes. Gilpin then seems to imply that it will be a really great idea to go ahead and build their proposed system at great expense using IBM and webMethods software. While you're at it, plug in some off-the-shelf process automation from the Unisys component store so that you'll always be going back to them for help whenever you want to make any changes.

While there's a smidgeon of truth in Gilpin's assertion that "There is a value to having those standard business processes defined," the value will be utterly squandered if the definitions are then implemented as immutable lumps of software that, once they've been levered into place, will be just as unwieldy and costly to manage as the manual systems they're supposed to be an improvement on. The way to get value out of business modeling is to deploy it as a means of continuously monitoring and adjusting business processes in a constant feedback system. And the only way to do that is to implement it in the context of a service-oriented applications infrastructure where software executes processes as a service, rather than by lumping together huge software components that have no inherent flexibility.
posted by Phil Wainewright 11:00 AM (GMT) | comments | link

Bosworth befuddles the message

Adam Bosworth, BEA's chief architect and SVP of advanced development, has always been consistent in putting messaging at the heart of the web services model, insisting that it must be founded on messages that meet the three criteria of being:

1. asynchronous — they don't depend on getting an immediate response


2. loosely coupled — they don't require a specific execution


3. coarsely grained — they contain enough information to perform the required action.

Now he has a fourth requirement: the messages must be reliable.

Obvious, really, when you think about it, because if none of the above happens reliably, then you can hardly build an enterprise application on top of it, which is the market BEA plays in. Bosworth's problem is that BEA doesn't yet play there with a reliable messaging capability to complement its web services vision, and thus he's begun spreading what sounds very much like the sort of fear, uncertainty and doubt — FUD for short — that used to be notorious as IBM's favorite marketing strategy when it didn't have a suitable product to hand.

In a curious InfoWorld interview published today, Bosworth starts out by stating that BEA is "quite far along" in the process of bringing a "smart bus" and "smart repository" to market — the two core ingredients of a reliable messaging infrastructure. But then a few paragraphs later on, there's a strange juxtaposition.

First, he appears to contradict his earlier statements about the closeness of a BEA product: "There's just this [incredible] complexity here. It's my guess that we're at least five years away from seeing this sort of thing being done." And then he moves smartly on to politely trash the capabilities of other vendors that already do have products in the market: "If you look at the web service management companies, [the] little ones, they have [simple] forms of this."

This is quickly followed up by an assertion that the poor unfortunates will soon get crushed anyway once they have to confront the overwhelming competition from BEA's putative offering: "... historically, once you get standards, the stacks very quickly adopt those standards. And at that point, that turns out to not be a good startup business. I don't think, to be honest with you, that this is a very good startup business [to be in] because we clearly have this in our sights."

So, just to sum up to this point, a) BEA will have a messaging offering soon b) but maybe not for five years c) other vendors only have very primitive offerings d) BEA's offering will wipe the floor with them.

Then comes the final amazing twist, when Bosworth discloses "the dirty secret" that you don't really need a messaging infrastructure at all for most applications: "Messaging, at the end of the day, is about reliable delivery. And as soon as web services has as part of its standards reliable delivery [asynchrony], you're pretty much done. You've now opened up what has been a closed architecture."

So there we have it. BEA is working on a messaging product, even though it doesn't need one, and the competition should be very worried. Make of that what you will.
posted by Phil Wainewright 12:04 PM (GMT) | comments | link

Turning IT inside out

There are two ways of looking at an enterprise IT infrastructure. The CIO looks from the inside out. Everyone else looks from the outside in. Two ComputerWorld articles this week offer an example of each perspective, and how diametrically opposed they are.

The CIO's perspective comes, appropriately enough, from ComputerWorld's Australian edition — a continent that we Brits like to refer to as 'Down Under'. Headlined Event-driven architecture poised for wide adoption, the article describes how service-oriented architecture (SOA) — which few IT shops have yet got round to adopting — will soon be superseded as the hot "next big thing" by event-driven architecture (EDA). In its train, predicts Gartner, yet another three-letter acronym, complex event processing (CEP) will be holding sway by 2007.

Doug Kaye has already pointed out some of the flaws in the way this story is reported. The primary characteristic of EDA is complementary to SOA, in that it uses loosely coupled messaging to trigger processes, rather than relying solely on predetermined sequences. Adding EDA, and subsequently CEP, is simply how most SOAs are going to evolve anyway.

But the thing that stands out for me is the topsy-turvy, inside-out view of the world that permeates the entire article. It discusses system design without any reference to the purposes those systems are designed for, insulating its concepts by dressing them up in three-letter acronyms that disguise their true import. The result is an absurdity, in which IT architects are quoted bemoaning the fact that they're now going to be expected to design systems that are driven by events, as if it weren't enough trouble already to re-engineer them so that they can deliver their functionality as readily assembled services.

What does the word 'events' mean in this context, if not 'stuff that happens in the real world'? Seen from this perspective, the shift to event-driven architectures in corporate IT is merely the adoption of computing that responds to what's actually going on in the business world outside. And of course 'complex events' simply means 'stuff that happens in the real world, the way it happens in the real world'. We should be celebrating the prospect that the leading edge of IT is at last contemplating being able to handle complex real-world needs in real time. But instead, IT professionals turn the whole exercise into yet another burdensome TLA (three-letter acronym) that they're expected to implement.

Turn now to the second article to get an insight into how all this really looks from the outside, looking in. The author is Paul Strassman, a man who's already made the journey from the inside out, having served as CIO at General Foods, Kraft and Xerox, before going on to write the 1997 bestseller The Squandered Computer: Evaluating the Business Alignment of Information Technologies. You would expect a man so sceptical of the business value of computing to be dismissive of such an over-hyped fad as web services. But he's not.

Headlined Enterprise Software's End, Strassman's opinion piece guns for expensive all-in-one enterprise software suites — in particular ERP — as the overrated fad, and advances loosely coupled architectures based on web services as their nemesis:

"Why do I now pronounce the ERP era as coming to an end? The answer is Web-based services that can deliver integration of dissimilar systems. Web services make it possible for corporations to plug into best-of-breed suppliers for rapid acquisition of innovative applications. Web services enable pilot tests that can verify performance before the company commits to implementation. They offer a superior architecture for enterprisewide integration of diverse, distributed and refurbished "legacy" applications that can remain in place until gracefully upgraded or retired. Web services promise a way to reduce huge development budgets. Web services avoid the shock of forced insertions commonly associated with all ERP ventures because they can be trickled into the workplace as the workforce is ready to absorb changes. Web services smooth the migration from hard-to-manage (and insecure) client/server environments to outsourced network service providers that offer the protection of experienced security staffs.

"Web services accept diversity in applications instead of a single application architecture dominated by one supplier. They allow integration through network message sharing (in vendor-independent universal standard formats such as XML) instead of forcing every data element into a monolithic data repository."

Strassman goes on to bemoan the slow speed at which organizations are adopting web services, calling for a change of mindset among CIOs. IT people may feel they have enough on their plates as it is, but Strassman argues that if that's the way they feel, they should take steps to divest some of their responsibilities. While IT people are looking at how much they already have to do, the perspective from business managers on the outside looking in is how little they've yet achieved.
posted by Phil Wainewright 1:59 AM (GMT) | comments | link