ESB Spaz Out Excerpts

A couple 2-3 excerpts from the ESB spaz out that caught my eye. I have largely sat this one out since playing a small part in starting it. Perhaps I'll say something soon, but for now, here are a few quotes that caught my eye. I'm too spent from a long week to say much more.

Steve Vinoski: Reactions to the ESB Question

Eric Newcomer comment: I tend to think of the IT world as divided between systems designed before the Web, and those designed to include it. The mindsets are very different, as you point out, but I would add that the pre-Web mindset is kind of driven by mainframe centric designs - I like to think that the issues with existing middleware (and perhaps binary languages) is due to the fact we always felt we had to design in all the features/functions of mainframe based systems in order to entice enterprises to move those apps to standards based systems.

There is a lot of truth to this. I live with a lot of big iron. Interestingly, AtomPub & the whole pull based feed approach to integration is somewhat similar to batch processing. Perhaps it can help bridge that gap a little bit? Hey, that would be cool - Atom feeds from VSAM files & AtomPub from CICS. Maybe, but it is the batch cycle itself that has a strangle hold. Batch cycles that have been nurtured for 30+ years are very difficult to untangle. Things are really bound up there.

The Enterprise Cool URI will save us yet.

Steve Vinoski: The Degenerating ESB Discussion

Dan Hatfield:Honestly, I see the ESB as primarily a political thing. It allows for a greater degree of control on delivered solutions. In large companies, we don’t often do architecture - we do politecture…The politics drive the architecture. Not the way it should be…but that’s the way it is.

Politecture! Ouch. Sad but true. I walk this line on a regular basis. I push the envelope as far as it can go, but politics are ever present.

More Vinoski: Another non-technical way to look at it is from the viewpoint of Clayton Christensen’s classic book, The Innovator’s Dilemma. For quite a few years now, we’ve seen a series of sustaining innovations in the “object/service RPC” line of descent originally popularized by CORBA and COM, both of which built on earlier RPC, distributed object, and TP monitor technologies. RMI, EJB, SOAP, WS-*, and ESB are all offspring in that line, and there are surely more to come. I feel that REST, on the other hand, fits the definition of a disruptive innovation perfectly (and if you’re too lazy to read the book, then please at least follow the link, otherwise you won’t understand this at all). The proponents of the sustaining technologies look at REST and say, “well it can’t solve this and it can’t solve that” and voice numerous other complaints about it, precisely as Christensen predicts they would. But Chistensen also explains why, at the end of the day, any real or perceived technical shortcomings simply don’t matter (and in this case, they’re mostly perceived, not real). HTTP-based REST approaches have a lower barrier to entry and are less complex than anything the sustaining technologies have to offer, and REST is disrupting them, whether all the smart folks pushing ESBs like it or not. It’s not a technical issue, and there’s no amount of technology the non-REST tribe can throw at it to stop it because it’s based on how markets work, not on the technical specifics.