On Disposable Software
Stuart Charlton's Blog |
October 4, 2007 8:57 AM
|
Comments (0)
I like ESBs if they're used properly -- to me, a good ESB is actually just a scripting language with supporting infrastructure. AquaLogic Service Bus, to me, is a Pipeline language, an XQuery language, and the supporting management & interoperability infrastructure, for example. But an ESB is not mandatory, and sometimes can slow you down if you're not looking to make legacy systems interoperate. And a centralized ESB is an abomination on par with centralized EAI hubs. It's just not necessary anymore. It's a service network, folks, not a service mainframe ;-)
So I agree with Steve Vinoski's The ESB Question. Don't use an ESB if it's going to slow you down. ESBs are a decent, productive tool for SOA (and even REST!) when applied properly, but so are Python or Ruby. ;-)
<< plug >> I work for BEA, so I'm biased, natch. ESBs can be very productive, particularly in "Java or .NET only" shops, which is, well, mostly everyone large. That's because, as I said above, an ESB sometimes is really just a higher level language + some infrastructure and management capabilities.
Further, to mitigate risk & help cover complexity in large organizations, it makes sense to use a platform that is vendor supported. BEA tries really hard to make Jython supported in WebLogic and AquaLogic, for example. The whole JMX object model is scriptable, and you can do some amazing things with it. And we have PHP running on WebLogic Server. << end plug >>
What's more interesting to me is this part:
Well, ESB proponents would say that this would never do because you end up with way too many one-off solutions, while mono-compiled-language proponents would natter on pointlessly about type safety, compilers preventing errors, and performance. An assumption behind these arguments is that the integration problem being solved requires high performance, and that the solution will live for a long time. In my experience, these assumptions are rarely correct, especially the second one, since business rules change so rapidly nowadays that the integrations required to implement them change all the time as well.
All of the major investment out there now on huge IT programs, whether it's $100+m on SAP, or it's a major SOA initiative, or it's a $1B rebuild of defense architecture that the US DOD is undertaking, the goal is to STOP silos & one-offs, and to separate what changes from what doesn't change -- apps from infrastructure. Strassmann has long said that we many business rules DON'T change, just the way they're interrelated with each other that do. We squander money on the same things in IT constantly, with these massive ERP efforts every 7+ years, for example.
But it seems the reality doesn't quite fit with this goal. What gives? Perhaps two things:
- software has long term residual value but our investment decisions are always short term
- we intertwingle what changes from what doesn't change
We've fixed #2 with hardware platforms. SOA was supposed to fix it for software, but perhaps not (yet).
I note that throughout my career, I've seen many fast-moving IT departments, particularly in investment banking, but even some in telecom, continue to use the "build it to throw it away" mantra with reasonable success. This works when your organization is compartmentalized. But when information sharing is of primary importance, such as the intelligence or defense establishment, for example, we get to a case where these huge organizations need a different approach. Layers upon layers of bureaucracy make it hard to abandon any pet project.
This is partly why I think Enterprise Social Computing, the Web's architecture (or some successor of REST), etc. are very exciting; they seem much more likely to strike a balance between shared agreement and decentralized execution.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
|
