I ran across this blog entry by Ross Mason, the CTO at MuleSource.  Having lived in the systems integrator world for a lot of years and spent a year at a BPM software company, I can appreciate the pains that lots of companies have experienced while implementing enterprise system buses (ESB) to link together disparate systems and applications.  More often than not it was not a pretty sight.

As you can see from the post, Ross ultimately ends up pushing his own product, but at least he starts from the position that you really need to question your strategy for implementing an ESB in the first place.  With the rapid movement of applications and systems to a SaaS or PaaS model, I believe it is more important than ever to rethink your strategy for building large, internal, complex and expensive ESB architectures.  Of course there will be situations where an ESB is the right solution.  But for the most part I think most integration projects can be handled in a much simpler fashion as Ross points out.  I especially like item number 9 on his checklist.  On several occasions I have seen one or more of those reasons as the ultimate driver for a specific technology strategy, and I can tell you in almost every case the outcome was not what was expected going in.  With today’s IT budget crisis, you simply cannot afford to make big expenditure mistakes…

This takes us to another topic that was touched on in the post – BPM/BPEL.  As I stated earlier I spent a year at a BPM company that had a very sophisticated product offering.  Unfortunately, it did not gain as much traction (at least here in the US) as was hoped.  I think two things drove that result.  First, while a lot of systems in this space are “drag and drop”, they ultimatey require a lot of integration work on the back-end.  Just like ESBs, this can get quite complex and expensive and could have possibly been handled in a much simpler fashion.  But once you commit to an architectural path, you have to jump in feet first and stick with it.  Otherwise your price to value ratio is going to be way out of whack – and I think many customers are experiencing just that.  Secondly, the overlap between many of the BPM/BPEL systems and ESBs is pretty significant.  Most BPM systems have some sort of “bus” back-end built in, which makes the integration problem even more complex if you have already chosen a bus architecture.  The question becomes which bus to choose for BPM that encompasses multiple elements of your supply chain?  For short-lived transactions it is probably sufficient to rely on the internal BPM bus and do “point to point” integration with a back-end system.  But if you are doing long-running complex business processes then you probably should rely on your ESB.  But when you add up the costs of these two architectures/systems, the cost becomes pretty significant.

So to Ross Mason’s point, there are some pretty tough questions you need to answer up front before “jumping on the bus”, so to speak.  Hopefully one of them you can eliminate early on is the resume-driven-development question…