I've talked about my latest article, ESB-Oriented Architecture. In a comment to ESB-OA on ZDNet, Jeff Anderson asks:
Regarding your "ESB-Oriented Architecture" article: If you replaced the words "ESB" with "Process Server", would you still agree with the central premise of the article?Interesting question.
A project based on WebSphere Process Server would tend to be more successful (as judged by the criteria described in my article) than one based on an ESB product (such as WebSphere ESB, WebSphere Message Broker, the DataPower XI50, etc.). This is because Process Server has capabilities for implementing and hosting service providers, wrappering the functionality in external (aka legacy) applications as services, implementing business processes that orchestrate services, and so on. These capabilities, focused on services, tend to produce applications with functionality that users need, functionality that thereby produces business value. To draw on an analogy from my article, Process Server focuses on the faucets and drains that give the user access to water, instead of the pipes that covey the water. Just as (working) faucets also have pipes, Process Server has an ESB (WESB is built in, and you can augment it with WMB, DataPower, WMQ, etc.) which provides connectivity to the services, but the services (not the ESB) are what provides value to the users.
Just to make sure I'm being clear: I'm not saying, "Process Server good, ESB bad." I am saying, "Services good, ESB for connecting services good, services (and ESB) in Process Server good." And as the article said, "ESB with no services bad." I hope that removes any ambiguity.
Continuing trying to be clear: I'm not saying Process Server (or any other product, really) is some magic bullet that will automatically make a project successful. I'm sure one could come up with a project that uses Process Server to implement services that somehow have no value to the business. Such an application, despite running in Process Server, would still be a vestigial organ within the IT department, providing no value (only cost) to the business. I'm just saying that Process Server (and more so than any ESB product) lends itself to implementing services, ones which are somehow hopefully driven by some sort of requirements that hopefully are influenced at least in part by what would be helpful and valuable to the business.
Thus far, in describing Process Server and services, I've said "business value" several times. And that should point out that the question is kind of asking the wrong thing. The question isn't really, "Will Product X make an SOA project successful?" As I described in Business/IT Alignment, what makes a project successful is that it aligns with the busienss and produces business value. This business value produces ROI (see ROI from SOA), whereby the project which had cost to produce creates business value; the business value hopefully is sufficient to make the project pay for itself, and the quicker the better.
So if there's any magic bullet here, it's business value: The project (namely its results, such as a running application) should produce business value. SOA is one way (a very good way) to help make sure IT projects produce business value. Business services in an SOA that perform functions the business needs produce business value. SOA application server products (like Process Server), ESB products (WESB, WMB, DataPower, etc.), and SOA IDEs (like WebSphere Integration Developer) help code and execute business services in SOAs that produce business value.
So you need all of it--products implementing functionality in an architecture that produces business value. Like my article said, an ESB by itself won't get you business value. Process Server won't guarantee business value either, but by focusing on services, it'll get you a lot closer. In the end, regardless of product or technology, the goal is to produce business value--and that's something only you and your organization can judge.