Hammer disses ERP

It's the fate of visionaries and prophets to be misunderstood in their own time, and it seems that Michael Hammer, the father of business re-engineering, is no exception. Companies that sought to re-engineer their businesses over the past fifteen years by investing in expensive, hugely disruptive, enterprise resource planning (ERP) software projects only have themselves to blame if it all ended in tears, he told a conference last week:

"Hammer says companies that managed ERP in process terms were the successful ones, ones that didn't were not successful, and that's the whole point," reports line56. "People started with the technology and then discovered it was a process issue," he told the ProcessWorld conference in Philadelphia. "The pattern [CRM, PLM etc.] keeps repeating, which is depressing because it doesn't have to be that way."

Perhaps it would be easier to swallow this new advice had Dr Hammer not delivered quite so many keynote pitches at ERP vendor conferences over the past decade-and-a-half. But at least he's now fully up-to-speed with today's loosely coupled process thinking, and we can't really complain about that.

The excellent line56 report is a detailed and very interesting summary of what various analysts and gurus have to say about process these days, based on proceedings at last week's conference. The event was organized by IDS Scheer, whose founder and chairman August-Wilhelm Scheer is just a much a legend of process philosophy as Michael Hammer. He too had some interesting and very palatable things to say, such as:

"When [technologists] talk about BPM they talk about transactions and pipelines. When we talk about BPM we think of the organizational processes of a company and when we develop tools, they are focused to the organizational layer and not to technical things."

Also: "This lifecycle is not just about painting pictures of processes, we want to break them into execution as parts of continuous improvement in the process and the company."

Other analysts quoted in the story include Gartner's Jim Sinur, who, along with colleagues, is reported to have "identified four uses for BPM. The first is lightweight, or visual BPM, as seen in enterprise portals. There is also collaborative BPM, as is seen across supply chains and working groups. There's integration-centric BPM, which is systematic and makes use of infrastructure. And finally there are BPM pure-plays that reach down and use different pieces of the first three categories."

AMR's Eric Austvold makes the interesting point that systems integrators are hoarding valuable process expertise in the hope of protecting their competitive advantage: "Systems integrators have a lot of the knowledge around process and they don't want to give it away, document it or put it in a tool or methodology, because then you wouldn't need them." But a lot of companies are just experimenting with process anyway, he says, and so there's very little definitive best practice at present: "It's self-actualization, companies are still trying to figure out what they can do with this, which gets back to why some of our definitions today are still in the hazy stage."
posted by Phil Wainewright 7:48 AM (GMT) | comments | link

Transactional messaging

Web services is all about sending messages, so it's surprising that the web services community should have got itself into such a mess over messaging. Web services work OK just so long as you only have to send messages one hop at a time — you simply send them to a web address, and so long as you don't get a 404 or some other error response, you can assume it got through. But if you want to do more sophisticated interactions that have to run through several different hops without falling over at the first unexpected glitch, you need to add some kind of messaging infrastructure. And would you believe it? Web services doesn't have one.

The lack of a reliable messaging system is the main factor responsible for web services deployment languishing behind the firewall or in ineffectual pilot schemes, regarded by many as a hobbyist toy rather than a serious tool. To gain enterprise-class credibility, it needs to live up to transactional messaging standards, which means having an infrastructure that guarantees messages not only get delivered, but also come from where they're supposed to have come from, are completely unambiguous, and get processed in the correct way.

In the absence of a native specification for reliable messaging, there are three options available to enterprises that want to take advantage of web services — particularly in B2B environments, where transactions are taken very seriously but where the loosely coupled architecture of web services is much easier and cheaper than previous alternatives.

1. The first is to use your own proprietary messaging infrastructure. That's not such a bad idea if you already have one, but if you don't, then the cost and hassle of building one is going to cancel out the easier-and-cheaper argument for using web services in the first place.


2. The second is to use Java Message Service (JMS), as described in Loosely Coupled's recent feature article, Integration that defies EAI convention. This is a very satisfactory option if you already have a J2EE server in place, less so if you don't.


3. The third option is to use ebXML Message Service (ebMS), as described in our article this week, Sending an unmistakeable message. Although its name suggests otherwise, this doesn't oblige you to use ebXML. In fact, it's based on the core web services standard of SOAP, but adds the ability to carry virtually any file format as its payload, as well as a complete arsenal of support for security and reliability.

I was somewhat surprised when David Longworth first filed this article to discover how little I knew about ebMS, considering its apparent and ready-to-go suitability for plugging this gaping hole in the web services standards stack. In view of how much debate has been expended on this topic in recent weeks, the lack of hype surrounding ebMS is astounding.

Perhaps one explanation is that no vendor has any vested interest in promoting ebMS (though if that were the true reason, it would be quite a telling indictment of the vendor community). A more likely explanation is that web services purists tend to dismiss anything associated with ebXML as being tainted by association with inflexible, proprietary EDI solutions.

Nevertheless, as David's article this week makes clear, it would actually be quite a smart move to bring the vast mass of EDI users into the ambit of web services, and ebMS has been designed to do precisely that. What's more, it's probably a mistake to dismiss the combined experience of a global community that has been attempting to perfect the art of enterprise-class e-business messaging over the past several decades. They've probably learnt a good few lessons about things that wouldn't even occur to you if your only knowledge of messaging was based on what happens within the sterile confines of a single enterprise network computing environment.

While editing this week's article, I was able to have an email exchange with Jean-Jacques Dubray, who as well as being chief architect of software vendor Eigner Precision Lifecycle Management (and a former CTO of eXcelon) is also a long-time proponent of and contributor to ebXML. He made some interesting points that, since they didn't make it into the article, are worth quoting here:

"Actually there are several forms of B2B — Travel-agent kind of B2B, Boeing to 28,000 suppliers kind of B2B, Nobody is in control B2B ... Unfortunately, I now believe that there is not a single form of B2B infrastructure that is possible and here is the reason why: In 'highly connected' systems you have to optimize the cost of connecting all the agents. This is very different from 'highly distributed' systems which in the mid-90s were addressing issues like scalability and fail over ... The second factor is that when you deal with a highly connected system you need levels of protocol to help each agent understand what is going on ...

"So ebXML is trying to optimize both aspects: lower cost and provide different grades of protocols that give you the kind of assurances you need when 10,000 or 100,000 or 1,000,000 agents are conversing with each other ... the short answer to your question: 1) you need choices to allow a given community to choose the point of lowest cost for connectivity 2) you need several levels of reliability."

Jean-Jacques went on to make some other points that were included in the finished article, describing some of the levels of reliability he mentions as being necessary in high-volume, production environments. I'm sure there are some drawbacks with ebMS that we weren't able to discover in our research, but it does seem to me that it's been unjustly neglected as a candidate for consideration, and I hope this week's article will go some way towards redressing that balance.
posted by Phil Wainewright 11:23 AM (GMT) | comments | link

The end of tech?

There's been a lot of bluster in Silicon Valley this past week, reports Washington Post writer Leslie Walker, from leading figures in the tech industry. Intel chief Craig Barrett and Microsoft founder Bill Gates have been among those rushing to condemn this month's Harvard Business Review article by editor-at-large Nicholas Carr, IT Doesn't Matter, which argues that IT has become a mature commodity that no longer delivers a competitive edge to businesses.

"'Mr. Carr totally misses the point,' Barrett fumed," writes Leslie Walker, while Bill Gates "said he 'strenuously' objects ...".The strength of these reactions clearly demonstrates that Carr has hit a raw nerve, even though, as I mentioned previously, there's a crucial flaw in his reasoning.

Gates went on to pursue a line of argument that will please readers of Loosely Coupled: "Gates said the software industry is on the verge of delivering an entirely new type of software called 'Web services' that will change the dynamics of electronic commerce and many business processes. 'This is where I think in some ways people are really underestimating what can be done,' he added."

Unfortunately, although web services will indeed be a new source of corporate competitiveness, I don't see it doing anything to rescue the IT industry from its current economic doldrums, since many CIOs will find they can Buy web services and spend less. But although that's bad news for the industry as a whole, it's good news for web services specialists, and just one example of how innovative deployment of web services delivers clear competitive advantage to early adopters.

The trouble I have with Nicholas Carr's assertion that IT has reached the end of the line is that it puts me in mind of Francis Fukuyama's 1989 essay (and subsequent book), The End of History, in which he asserted, "What we are witnessing is not just the end of the Cold War, or a passing of a particular period of postwar history, but the end of history as such: that is, the end point of mankind’s ideological evolution and the universalization of Western liberal democracy as the final form of human government."

As soon as people start making such confident assertions that we stand on the threshold of achieving some golden age of perfection, you can bet your bottom dollar that fate is about to come round and deal a bitter blow to their complacency (Fukuyama's most recent book is The Great Disruption). The world never stands still.

Although there's a grain of truth in Carr's contention that IT — at the infrastructure level — is approaching mature commodity status, any CIO who draws the conclusion that they can now rest on their laurels will be making a big mistake. It is precisely the stabilization of infrastructure technologies that is creating such a great opportunity now for innovation in higher-level business process automation and agility. Perhaps a chapter is coming to an end, but now is not the time to close the book on IT.
posted by Phil Wainewright 1:34 AM (GMT) | comments | link