To ESB or not to ESB... that is the question...

After reading Jesus' blog post about ESB, I got to thinking.  At the end of the day, its really about just getting disparate systems to play nice together.  We can't get countries in our own world to play nice together.  If we can agree that everyone in the world speaks a common language, it doesn't mean that we're going to play nice together.  Some will need a Translator, or at least a Broker to share the same idea, but with different implementations (think English-to-Spanish translator vs. German-to-Spanish).  The trick is to see and embrace those differences, encapsulate the difference, and figure out a way to mitigate them as quickly and painlessly as possible.  If you think a merger will ever be as simple as changing a configuration setting, creating a new Receive Location, and adding a Send Port, you've never been involved in a merger (and you're using BizTalk).

To think there's a standard to anything is a naive approach.  And to imagine that those standards will survive the test of time is even sillier.  Face it.  In some development environments waterfall actually works and agile really fails.  Its about the culture, skill set, management and so many other factors you can't even begin to imagine.  Its about adaptability.

I always like to look to the business to solve our enterprise and technology problems (Eeeeh?).  If you can get to the people closest to the business, and they describe a customer as X with Y accounts and an account as N with M funds, then you are getting the sense of the business/IT model.  Everything else is just plumbing.  We love, as technologist, to find relations among everything, but we have to be forward enough to see that if the business says "we'll never have more than 100 accounts for each customer" we make a decision to not enforce it in our entity models.  You can enforce it somewhere else, but make it configurable ;-)

I think an ESB is a great step in the right direction for many companies facing an "IT identity crisis".  If not for anything, then just because it forces anyone adopting it to take a step-back and look at their business domains.  It forces us to establish a canonical model of major business entities which I believe this is vital to the success of a business and IT strategy.  It seems people ascribe the word "canonical" to mean "never-changing, permanent, inflexible", but this is a huge misnomer. 

That being said, if you want to change what your company or industry considers the canonical model of what a "sales order" looks like, you'd better have a darn good reason.  That reason needs to be signed off on by X, Y, and Z and it needs to be versioned and documented and syndicated to all other subsidiaries.  It shouldn't be easy and you should need buy-in from several people making much larger paychecks than you. 

If you're not in a position to create a canonical model of what a certain business entity looks like in your company, please don't bother to play with an ESB.  It will only complicate your life when you find out that a sales order line item really doesn't do a “real-life” sales order line item justice.  I suggest as a first step to step away from the technology and look at (and understand) your business domain.  This is the key to a successful business / IT strategy and its the promise of SOA deployed properly.  It’s all about business driven development.  Did I just coin that?  Apprarently not.

No Comments