Everything that's wrong with "ESB"

This email recently crossed my Inbox, and it just completely typifies everything I find wrong with the ESB:

Title: "Architect Complex Integration with ESB's"

Body:

F1000 Keys and Barriers to ESB Success
[Event]

Event:  [Name struck to protect the guilty]
Date:
  [struck]
Times:  [struck]
Place:   Online No-Charge Conference

 

Gartner reports these 2 facts:

1) F1000 firms increasingly see the Enterprise Service Bus as a “core component” in their multi-million-dollar Service-Oriented infrastructure investments.

2) ESB software is by far the fastest growing application integration middleware market segment in all of IT – with growth rates exceeding 100% year-over-year!

 

At [EVENT], you will hear top ESB and business integration experts from IBM, Software AG, and Progress Software show you how F1000 customers design, build and deploy powerful and flexible ESBs—and cut risks and boost rewards.

12noon ET (9AM PT): Case Studies Roundtable (Keynote Panel)

In a fast-paced ESB Case Studies Roundtable, you’ll hear 6 F1000 Case Studies. Our ESB experts will share details on how ESBs improved business value and ROI for their F1000 customers.

[Name struck]
IBM
WW Marketing Content Lead for SOA Reuse and Connectivity

[Name struck]
Software AG
Dir. of Product Marketing for ESB, Enterprise Integration & B2B Tools

[Name struck]
Progress Software
Senior Product Marketing Manager

1:00pm ET: Presentation

Introduction to the webMethods ESB Platform

[Name struck]
Dir. of Product Marketing for ESB, Enterprise Integration & B2B Tools

2:00pm ET: Presentation

How ESBs can power your business

[Name struck]
WW Marketing Content Lead for SOA Reuse and Connectivity

3:00pm ET: Presentation

Progress Sonic and the SOA Portfolio: It’s your world it’s your SOA

[Name struck]
Sr. Director, Progress Product Marketing

[Event] is an [Media Company] production series designed to provide executives, business managers, software developers and architects with valuable "hands-on" information about improving techniques and results for design time and runtime SOA projects.

So what do I find so offensive about this email? Just about everything. Consider these little tidbits:

  • Start with the title: "Architect Complex Integration with ESB's". The desire to create complexity is a misguided one; enterprise data centers already have too much complexity within them, and creating more just adds to the mess. Neil Ford hits this point perfectly when he talks about the difference between "essential complexity" and "accidental complexity" in his NFJS keynote. Essential complexity is that complexity required to solve the problem--the business workflow that comes as part of a business process, for example, or the rules that go into calculating shipping & handling for an order. "Accidental complexity", however, is all that complexity that occurs in software that has nothing to do with the problem at hand. When accidental complexity gets too large, the desire to "rewrite the whole thing from scratch" kicks in, something that might be OK for a single application, but clearly won't hold for systems already set in Production and working. Naturally, this means that we have to find ways to integrate all this stuff, and here comes the battalions of consultants and ideas, ranging from "data feeds" to "flat files" to "CORBA" to "Web Services" to "ESBs" to whatever-comes-next to create an n-squared problem as each system hooks up to other systems in a point-to-point fashion (regardless of what the technology was originally supposed to do). Unfortunately, as it turns out, we as an industry are much better at building accidental complexity than we are at building lean, mean, efficient systems, and holding complexity up as a goal of a system is not helping matters.
  • Next, we have two "facts" reported by Gartner, with no citation of the report or the source of the facts to enable any kind of follow-up fact-checking. Don't get me wrong, I have no doubt that Gartner said these things, and in fact, I won't even dispute the facts themselves--ESBs were pretty unheard of a few years ago, so the fact that it's the "fastest growing application integration middleware" wouldn't even surprise me--anything to help solve this problem of complexity in their data center is welcome, and hey, it's a lot easier to purchase something than to face the problem. After all, it's only money. And the fact that "F1000 firms increasingly see the Enterprise Service Bus as a “core component” in their multi-million-dollar Service-Oriented infrastructure investments"? Sure, I buy that too: if you have a multi-million-dollar infrastructure investment, and everybody seems to be doing ESBs, then by Golly, you're going to do an ESB too, because "Nobody ever got fired for buying IBM", which, loosely translated, means, "If I'm a CTO, and I spend a million dollars on something that everybody else is spending a million dollars on, you can't really fire me when--not if--it doesn't work. After all, it's only money, and it's not my money, to boot, compared with losing my job if I spend that million on a serious in-depth look at our IT infrastructure and find out exactly what it would take to get some of that accidental complexity under control."
  • Next, we have the fact that this event is an event "designed to provide executives, business managers, software developers and architects with valuable 'hands-on' information about improving technologies and results for design time and runtime SOA projects." How can you create an event that will be appealing and useful to that diverse of a crowd? The concerns that executives face are nowhere near the concerns that face software developers, and business managers' concerns are definitely different from those that architects face. To be useful to the executive, it must be high-level; to be useful to the software developer, it must be low-level. You cannot serve two masters well, much less four.
  • Following up on said quote, let's examine the fact that this is a webcast (an online event), yet it claims to provide 'hands-on' information. Last time I checked, 'hands-on' meant I can get my hands on it myself and, presumably, drive it for myself to see how well it works. This is remarkably difficult to do in a webcast event, particularly one that's only three hours long and consists of a panel. So "hands-on" here must mean you can touch your keyboard, which, of course, is connected to the computer that's displaying the web browser in which this information is being displayed. That must be the new definition of 'hands-on' in this "Web 2.0" world. I guess.
  • Oh, and did anybody else notice that all of this "information about improving techniques and results for design time and runtime SOA projects" is being presented by not one but three managers? Of Marketing? No offense to the intelligence of these three gentlemen intended, but last time I looked, Marketing guys don't spend much time implementing SOA projects of any time, design, run- or otherwise. They spend time trying to cook up good campaigns to reach developers and their managers in order to sell product. Not exactly a huge source of technical information, at least, not in my experience.
  • Last but not least, does anyone find it at all suspicious that this seminar is being sponsored by three companies with a vested interest in selling you on ESB so that they can sell you on their ESB product? I dunno about y'all, but when the salesman comes around to my door, I don't take much of anything he says too literally or too naively. Why we take Marketing and Sales executives from technology companies without the same degree of cynicism has never failed to amaze me.

At the end of the day, sensationalist presentations, claims of amazing productivity, or wild-eyed testimonials without sufficient history to prove or disprove them do not only hurt the developers and companies seeking to use these tools, they hurt the credibility of the companies promoting these tools. Claiming that your product is the answer to all the IT world's ills is a recipe for disaster unless you can deliver the goods, and frankly, I have yet to see a tool--any tool--answer that promise.

A message to the ESB vendors: Don't make it harder on us... or yourselves. Give us hard technical info, not sensationalist claims.