During the past months, ToughtWorkers have been regularly pounding on ESBs in a manner that Martin Fowler has neatly summarized like this:
"Hang around my colleagues at ThoughtWorks and you soon get the impression that the only good Enterprise Service Bus (ESB) is a dead ESB. Jim Webber refers to them as Egregious Spaghetti Boxes. So it's not uncommon to hear tales of attempts to get them out of systems that don't need them."
The reasons for such a reaction to ESBs are multiple and, more often than not, very valid. I think they stem from two main issues: the proprietary nature of such platforms (see Ford's "Standards Based versus Standardized") and the architectural quagmire an excess of "enthusiasm" towards them can entail (see Dörnenburg's "Making ESB pain visible" and Webber's "Guerilla SOA").
The only problem I have with thought leaders pounding on ESBs is the negative aura it can create around developers involved in integration projects.
What? Why do I dare talking about integration while the subject is about ESBs? Well, both subjects have become intertwined because many so-called ESBs out there are simply re-purposed integration platforms. And by re-purposed I really mean deployed as an ESB topology because ESB is first and foremost a topology and not a product (as Ross Mason pointed out in "To ESB or not to ESB").
So can developers working on integration projects be real craftsmen? I think they can and I think they should.
This may sound a little naive but it's not. Consider the following:
- Integration has patterns. Thanks the work of Gregor Hohpe and Bobby Woolf, developers have access to a vendor-independent semantics under the form of the Enterprise Integration Patterns. Being able to model and discuss integration without referring to a particular implementation is invaluable for craftsmen.
- Integration has testing. It is oftentimes a challenge to test complex integration project and developers could be tempted to skip it altogether. Once again thanks to Gregor Hohpe, but with Wendy Istvanick this time, testing at all level of an integration project has been proven possible and documented.
- Integration does not preclude SDLC practices: one point we tried to make in Mule in Action, is that even if your project consists in configuring an integration tool, you should not cease to be a craftsman and you should exercise good judgment and abide by your professional standards. You want to shoot for no less than reproducible builds and deployments in your integration projects.
So, whether ESBs are better dead or undead, developers dealing with integration projects should strive to be software craftsmen above anything else.
PS. Isn't it ironic that Gregor is an ex-Thoughtworker?
